9 ms·

Job application challenge

14 points by ropiku 16y ago

frossie 16y ago
Submit your resume via git? What is there not to like here? It will weed out a lot of the nohopers, without making the decent people feel like they are jumping through unreasonable hoops. I like it.
- cookiecaper 16y ago
  I think that those hoops are unreasonable. When you give tests like this, you need to be respectful of the applicant's time; they all have others things to do and other opportunities to consider, it is incredibly arrogant to demand anything that takes more than a couple of hours imo unless you are both very serious about placement. The refactoring of the code is probably OK; I haven't looked at the code so I don't know for sure, but writing a Ruby script with the GitHub API and the second task is a bit over the top. They should choose one or the other; if an applicant can refactor code well, he should be able to know how to use libraries, and if an applicant can write clean code to do the GitHub task, then he should know how to refactor. No need for both.
  - InclinedPlane 16y ago
    They're just front-loading and automating the 1st pass of candidate screening (normally something that might be done in a phone screen). I think this is perfectly legitimate. For anyone who is seriously applying for a position this isn't a significantly greater burden compared to the normal multi-stage application process at any other company. For people who are just blanket spamming their tarted up resume to anyone and everyone hoping for a lucky hit, this is a lot more work in comparison. But I think that's a feature not a bug.
idoh 16y ago
I know that getting a stack of resumes to vet is a big pain. But surely there is a better way to find good candidates then seeing how many hoops they can jump through. Basically, isn't the ideal employee one that would be entertaining multiple offers? Doesn't this challenge filter those candidates out?
- btmorex 16y ago
  I sort of agree. Actually, I like companies that give applicants challenges. But usually they are fun and interesting challenges, not "refactor this crappy code". Refactoring bad code is a useful skill, but my guess is that they're going to end up filtering out a lot of qualified people just because their challenge sounds boring.
  - frossie 16y ago
    If the job involves a lot of refactoring, or, if looking at legacy systems is how the job will derive its requirements, then it is a good test. I tend to object to "fun and interesting challenges" more - all they tell me is that somebody had a lot of spare time, and don't rule out the possibility that somebody needs "fun and interesting" stuff in order to produce work.
derefr 16y ago
This is exactly the sort of thing I wish more companies did: not relying on external credentials, or judging the developer in one marathon interview, but instead, just giving the developer some work representative of what they'd be up to every day at your company, and seeing if they can accomplish it.
- Periodic 16y ago
  I think both are good to have. The challenge will get you the applicants whose resume and CV might not reveal how talented they are. The traditional route is great for people who are already well established who want to drop off a resume through a friend and don't have much time for a long interview test process. I suppose the tests might not be that hard if you really are experienced, but they are a huge barrier when you are low on time and energy.
- InclinedPlane 16y ago
  From my limited experience interviewing candidates, at a "large, Redmond, WA based software development company", I observed almost no correlation between resumes and talent. I've seen good people with relatively poor resumes, and bad people with otherwise very promising resumes. As a hiring tool I think the resume is damned near useless.
kevinpet 16y ago
This is great, except for the minor issue of not wanting to announce to the world that you're applying there.
- JoachimSchipper 16y ago
  As obliquely pointed out in the comments, there are ways around that, e.g. http://www.rot13.com/?text=ubfgvat%20gur%20ercbfvgbel%20lbhefrys http://www.rot13.com/?text=ubfgvat%20gur%20ercbfvgbel%20lbhe...). For that matter, it would be hard to find this if you don't put your name on your resume and create a new Github account...
  - weaksauce 16y ago
    Exactly. Create a new account and don't put anything identifiable on the resume if you are worried about it. You can just correspond to them via the built in github messaging.
bhiggins 16y ago
I am a fan of simple code-writing challenges after having seen the results: a lot of bad code...
scorchin 16y ago
Did nobody else see the flaw in this? The GitHub forks are public. If you wanted to, you could just look through ~30 forks and see what their commits/code look like. It would be fairly easy to find the "best" solution and work from there. Furthermore, having your resume public gives you a better idea of how qualified you are in comparison to your peers that are applying for the same role. Seems slightly fishy to me.
known 16y ago
Between passion and experience what would you choose?

14 points by ropiku 16y ago

Submit your resume via git? What is there not to like here? It will weed out a lot of the nohopers, without making the decent people feel like they are jumping through unreasonable hoops. I like it.

cookiecaper 16y ago
I think that those hoops are unreasonable. When you give tests like this, you need to be respectful of the applicant's time; they all have others things to do and other opportunities to consider, it is incredibly arrogant to demand anything that takes more than a couple of hours imo unless you are both very serious about placement. The refactoring of the code is probably OK; I haven't looked at the code so I don't know for sure, but writing a Ruby script with the GitHub API and the second task is a bit over the top. They should choose one or the other; if an applicant can refactor code well, he should be able to know how to use libraries, and if an applicant can write clean code to do the GitHub task, then he should know how to refactor. No need for both.
- InclinedPlane 16y ago
  They're just front-loading and automating the 1st pass of candidate screening (normally something that might be done in a phone screen). I think this is perfectly legitimate. For anyone who is seriously applying for a position this isn't a significantly greater burden compared to the normal multi-stage application process at any other company. For people who are just blanket spamming their tarted up resume to anyone and everyone hoping for a lucky hit, this is a lot more work in comparison. But I think that's a feature not a bug.

idoh 16y ago

I know that getting a stack of resumes to vet is a big pain. But surely there is a better way to find good candidates then seeing how many hoops they can jump through. Basically, isn't the ideal employee one that would be entertaining multiple offers? Doesn't this challenge filter those candidates out?

btmorex 16y ago
I sort of agree. Actually, I like companies that give applicants challenges. But usually they are fun and interesting challenges, not "refactor this crappy code". Refactoring bad code is a useful skill, but my guess is that they're going to end up filtering out a lot of qualified people just because their challenge sounds boring.
- frossie 16y ago
  If the job involves a lot of refactoring, or, if looking at legacy systems is how the job will derive its requirements, then it is a good test. I tend to object to "fun and interesting challenges" more - all they tell me is that somebody had a lot of spare time, and don't rule out the possibility that somebody needs "fun and interesting" stuff in order to produce work.

derefr 16y ago

This is exactly the sort of thing I wish more companies did: not relying on external credentials, or judging the developer in one marathon interview, but instead, just giving the developer some work representative of what they'd be up to every day at your company, and seeing if they can accomplish it.

Periodic 16y ago
I think both are good to have. The challenge will get you the applicants whose resume and CV might not reveal how talented they are. The traditional route is great for people who are already well established who want to drop off a resume through a friend and don't have much time for a long interview test process. I suppose the tests might not be that hard if you really are experienced, but they are a huge barrier when you are low on time and energy.
InclinedPlane 16y ago
From my limited experience interviewing candidates, at a "large, Redmond, WA based software development company", I observed almost no correlation between resumes and talent. I've seen good people with relatively poor resumes, and bad people with otherwise very promising resumes. As a hiring tool I think the resume is damned near useless.

kevinpet 16y ago

This is great, except for the minor issue of not wanting to announce to the world that you're applying there.

JoachimSchipper 16y ago
As obliquely pointed out in the comments, there are ways around that, e.g. http://www.rot13.com/?text=ubfgvat%20gur%20ercbfvgbel%20lbhefrys http://www.rot13.com/?text=ubfgvat%20gur%20ercbfvgbel%20lbhe...). For that matter, it would be hard to find this if you don't put your name on your resume and create a new Github account...
- weaksauce 16y ago
  Exactly. Create a new account and don't put anything identifiable on the resume if you are worried about it. You can just correspond to them via the built in github messaging.

bhiggins 16y ago

I am a fan of simple code-writing challenges after having seen the results: a lot of bad code...

scorchin 16y ago

Did nobody else see the flaw in this? The GitHub forks are public. If you wanted to, you could just look through ~30 forks and see what their commits/code look like. It would be fairly easy to find the "best" solution and work from there. Furthermore, having your resume public gives you a better idea of how qualified you are in comparison to your peers that are applying for the same role. Seems slightly fishy to me.

known 16y ago

Between passion and experience what would you choose?