This is not the world's best rails hiring process - there's no such thing. The title makes you sound arrogant; it will surely turn some potential hires off.
Anyways, here are a few assumptions your process makes:
1) Of the pool of Rails developers world-wide that you could hire, the smartest/best ones are among the 10-50 devs that show up to a local rails/pub nite.
2) That there is a strong correlation between the number of reference checks (beyond 3), and the quality of a hire.
3) Bloggers and open source contributors are better programmers than those that aren't.
Here are a few things I would change:
1) A take-home project is fine, but I would not expect a potential hire to spend 10 hours. Why can't you think up a problem that takes an hour or so to solve instead? I've hired plenty of sharp engineers by asking them to perform a short take-home.
2) Because your project is now a lot shorter, you could have the candidate do this before they meet face-to-face. This would save you time, and moving the face-to-face near then end of the process allows you gather the most info before committing to a whole day of interviews.
3) A much more interesting phone screen question would be 'What are the disadvantages of TDD?'. I want flexible thinkers, ones who can argue both sides of a point.
TEN to FIFTEEN references? If you're (a) "that fast" on reference checks, or (b) that totally dependent on references the candidate provides you instead of backdoor references at their employer, you are doing that part wrong.
How do you know that a back-door reference from someone they did not list would not poison the well on an otherwise qualified candidate? Perhaps the candidate is ill-placed enough at his current employer to be likely to garner a one or more middling reviews -- perhaps that is why he is looking elsewhere. It's possible that your corporate culture is sufficiently different that he can thrive, but how would you know?
Really the opposite could be said for references he provided; they'll sing his praises, even if he is a total dud.
Not saying references aren't extremely important, but I wouldn't mind some thoughts on getting past the apparent fragility in the process.
You don't, just like you don't know whether a "front-door" reference would really hire the candidate again, or is in fact just being nice. The whole references thing is frought with peril; I got tanked on (one, longshot) VC due diligence thing from a bad back-door reference. A friend of mine I recruited for a company I worked for got tanked on her back-door reference. She went on to be a total rock-star at the job she got instead of us.
On the other hand, I have stories about back-door references that were collected too late to avoid tragic mistakes.
You want to do both. The back-door reference is harder. The idea that you're getting real information from "10-15" fast reference checks from friends and family seems crazy.
I agree that 10-15 references is totally bogus; I said so much in a reply to a different comment.
I'm still boggling though, actually more so than I was before your reply. You mention examples here that make the whole process seem incredibly error-prone, bound to result in false positives and negatives, and as you described it fraught with peril. This is a discouraging testament to the utility of doing reference checks.
I feel quite uneasy questioning years of standard hiring practice, but do the benefits of this sufficiently outweigh the drawbacks? You gather data about the candidate, but no metadata about the recommendation, which I can see make a considerable difference in how the reference is acted on. Metadata such as:
* the relationship dynamics of the recommender to other people besides the candidate
* how candid the recommender is about the benefits and drawbacks of things he/she evaluates
* what sort of events the recommender encountered, and what mood that set him/her in before talking with you.
All of these would put the recommendation in better context. There are probably other data points (recommendations of the recommenders, etc), that could be considered, and then there are time/benefit trade offs to decide which are best left unconsidered.
I will agree that a reference check will likely shuffle out someone who is obviously a raving lunatic, and would never work out no matter where they are hired. But, beyond that, it seems more nebulous. I have the sense that there is a combination of institutional inertia and real benefit that drives this practice; I want to understand where the bounds of each are, and whether my intuition is completely off-base.
references can/should be really fast. can get them all done in a couple hours... worth it, given all the good stuff you can discover. You are going to work and pay this person for months/years.
Regardless of how long it takes the interviewer to review them, I think it is pretty extreme to ask the interviewee to give 15 references, assembling 10-15 references, especially if you are young or maybe have worked at a small shop for a long time would be pretty annoying
Agreed. If I can provide references from peers and superiors at my previous jobs and also character references from outside of work, why would I need more references?
The 10-15 includes all references of all kinds, professional, friends, even family.
I spoke to one of my hire's father, one time, because he worked for him for 2 years. You'd be surprised, family members are often the most honest. The point is to get to know the candidate as quickly as possible and make a good decision. Speak with as many people that know them as possible.
I like to keep my work life and my personal life separate. If I gave you references of my previous supervisors and a couple colleagues (3-5 references) will those extra references really matter to you? They certainly would to me. I would have to be pretty hard up to do anything but walk away if someone asked me for 10-15 references, unless it was the opportunity of a lifetime. Maybe that's what you are trying to screen though... On a related note, there are plenty socially inept hackers that would have issues with this.
I wouldn't specifically ask for friends and family of course. The moral of the story is to try to collect as many perspectives as you can on the candidate.
So, without commenting on the "ethics" of this --- I don't care that much --- it's worth it for readers to consider the practical implications of your approach.
(1) Most interviewers won't ask for a 10 hour sample project.
(2) Most interviewers won't ask for 10 references.
(3) Good serverside web dev talent, even in this economy, is not in surplus.
(4) There are extremely talented developers who are just going to say "no" to these weird requests.
Your loss.
I don't mean "unprofessional" as in, "you'll get kicked out of the guild". I mean, "this will make you look bad". It's as much an interviewer's job to sell their company as it is to qualify a candidate. Perhaps if you're getting a stream of people that's so bad you feel like you need to talk to their Mom and get them to work on spec for you, your real problem is that you just have a really crappy hiring pipeline.
I agree. I think it's great that these guys want to make sure that they get good talent, but yeah, I'd have to really want to work at a place before I'd put in the time to complete a 10 hour project and provide 10 - 15 referees plus whatever else is also involved. Maybe these guys are awesome to work for and stuff, I'm not really meaning to comment on this.
But from personal experience, I very much agree that it is also the interviewers responsibility to sell their company. I've been in the fortunate position for some years now that I haven't needed a job. When I move, it's from the position of already being employed. Near the end of a job interview there will usually be the point where the interviewers will ask if I have any questions for them. My stock questions always include:
a) What do you like about working here?
b) What do you not like about working here?
I love observing their reaction/response to question b) particularly. :) And I feel asking these kinds of questions sends a clear message to the interviewers that I am not desperate for the job, which puts me in a better bargaining position when it comes time to talk salary etc. Of course, this tactic only works when you really aren't desperate.
But asking for more references will not guarantee more perspectives; it is simply guarantees more data, possibly repeated data. It is quite possible that the 10-15 references you ask will say within delta of the same thing about the candidate. You get reinforcement, but that doesn't seem quite useful enough to justify all the added calls.
You'll get to know the candidate better if you go grab a beer and just talk than by interrogating their family. And I'd expect family members to be the least honest (we look out for each other).
Only someone who NEEDS a job will agree to go through this process, and in my limited experience, the best hires usually DO NOT need a job.
I for one am certain, that I would neither give 15 references nor agree to work on a take-home project as part of an interview process
I'll never understand why someone would want to hire a "Rails developer". That makes as much sense as hiring a "Blub developer". Rails is just another framework in a sea of similar products that all do similar things.
Wouldn't it make more sense to hire skilled and intelligent developers who can learn Rails if necessary?
I think a lot of what was said is right on - hiring the right people is hard and I've really stuggled with that at times.
But I think making people code for free is somewhat unethical unless it's for open source. As an applicant I would feel that I was being taken advantage of if you used my code, didn't open source it, and didn't give me the job.
I'm not a lawyer, so I could be totally wrong on this one - but I'd be a little worried that this could become grounds for a lawsuit. Perhaps not a serious one, but, for example, a lawsuit to obstruct an eventual IPO or investment.
I agree. At least he's upfront about his ridiculous standards in his blog.
The amount of code and then the use of the code strikes me as unethical. I don't see where the company would own any of that code whether or not the coder is hired. If you want a contractor for a short project you should pay for the work, file proper tax documents, etc.
Presumably, you're only providing suggestions for what your applicant writes; if they want to demonstrate their ability by writing a modular synthesizer simulator in Ruby with an AJAX front end, you're going to let them do that instead. Open source or not, asking for portions of your own product up front is spec work, and it's also unprofessional.
Call it what you will, but as a hiring manager you really should review as much code as possible before hiring. Usually they can't show you proprietary code from their last company, so unless they've already done open source contributions, there won't be much to look at unless you give them a project.
In the past I've given candidates projects that we've come up with together. Check out the ones mentioned in the article... fairly straightforward Rails plugins. One of the was particularly successful, and included in the Advanced Rails Recipe book.
So you're fine with (a) open source contributors just providing you with samples of their previous work, (b) people who can show you non-public code just showing you that, and (c) candidates coming up with example projects totally unrelated to your own products, so long as it's demonstrative of the right expertise.
Anyways, here are a few assumptions your process makes:
1) Of the pool of Rails developers world-wide that you could hire, the smartest/best ones are among the 10-50 devs that show up to a local rails/pub nite.
2) That there is a strong correlation between the number of reference checks (beyond 3), and the quality of a hire.
3) Bloggers and open source contributors are better programmers than those that aren't.
Here are a few things I would change:
1) A take-home project is fine, but I would not expect a potential hire to spend 10 hours. Why can't you think up a problem that takes an hour or so to solve instead? I've hired plenty of sharp engineers by asking them to perform a short take-home.
2) Because your project is now a lot shorter, you could have the candidate do this before they meet face-to-face. This would save you time, and moving the face-to-face near then end of the process allows you gather the most info before committing to a whole day of interviews.
3) A much more interesting phone screen question would be 'What are the disadvantages of TDD?'. I want flexible thinkers, ones who can argue both sides of a point.