“Blink” and the Art of Hiring the Best

I do the same thing -- I give new developers some repository credentials and give them a small task.

One thing to watch out for though, is competent developers who are unreliable over time. They have the skills, but they spend their time surfing.

Sounds like a great idea. I would definitely like to try it out in my organization. The few problems I see with the approach are:

1. For closed source companies, does this increase the recruiting complexity by requiring potential candidates to sign NDAs as they will be looking at proprietary code?

2. Does it add overhead if you have a lot of applicants? They would all be sending in questions that you need to review. Since the process may take long and is not time boxed, you may lose productivity as you get interrupts from a new channel. From the article it didn't seem as if the author performs any kind of pre-screening

[EDIT]2.1 If the applicant pool is large, this also sounds like a waste of money.

3. For reasonably complex systems (I am currently in enterprise software), you would need to provide a quick way for a new hire to finish setup of your application. There was a time when we expected a new guy to finish the first install of our app in a week (!!). Things are much better now with hosted VMs that you can just fire up with the install being 1 click, but not all companies are going to have that luxury

I am also assuming that to accommodate applicants that are applying while still being employed (they need to pay their bills too!), we would need to ensure that the task to complete is short enough/can be done over the weekend or off hours.

The only concern I have with giving programming puzzles for hiring is that it can be quite the burden on candidates. This is fine if your company is a top player and candidates REALLY REALLY want to work for you, but if you aren't that established (like as a startup), the candidates might not like the amount of effort needed to apply. We tried this for some interns a while ago and about half balked at the idea and it wasn't necessarily the "bad" half.

Top talent are going to have options. If you ask too much too early, they may just wonder if it's worth 10 hours of coding up front to get the honour of applying to your company. One should always look for code before hiring, but it shouldn't be done in a way where you are filtering out the non-desperate as well as the incompetent.

Sounds like good advice, but why does Blink have anything to do with this? Isn't it obvious that you only want to base your decisions on factors that actually have to do with the outcome?

If anyone is interested in more details, I've just posted an interview here with the same guy. Worths the check.

http://blog.assembla.com/assemblablog/tabid/12618/bid/10041/...

In my opinion, the procedure he describes sounds great to measure the skills of the candidate(s), but that's too early to called the 'Best' resource of the bunch. It will not be until he or she is actually working there that you will be able to measure the real quality (both on the technical and the human perspective ) of him/her.