The problem is that this method disproportionately hurts people who don't have the time or energy to effectively hold two jobs (one full-time position at their day job and one as an independent developer or open-source contributor by night) because of family, friends, or some other facet of life beyond their laptop.<p>I think it's totally unreasonable to expect that everyone spend every minute of their lives coding or to have some kind of deep, personal connection to the code they write.<p>This thinking is ridiculous, and doesn't really appear in any other industry. Do you care whether your accountant's idea of an enjoyable Friday night is sitting at home making more spreadsheets? Would you demand that your eye doctor go home and craft her own lenses in her garage for fun? Competency doesn't require fanaticism, and no employer should expect that their employees devote their entire lives to their occupation.<p>If I want to code for 8 or 10 hours a day, go home and enjoy myself in the little free time I do have, then wake up and do it again, I don't see why that makes me an inferior employee.<p>This just seems like more misguided, unjustified cultural absolutism that is so prevalent in the industry.<p>EDIT: For those saying that the article doesn't necessitate spending massive time outside of work writing code, the author clearly conflates the two. "i have always been convinced that those who love code do not restrict their coding activities to their work. they take home that love and continue to create for fun as a hobby." Personally, I think passion could be a valuable heuristic in hiring, but the author seemed to imply that passion is only measured by your willingness to work outside of your day job. At the very least, that seems to be his expectation of good candidates, and his hiring process clearly disadvantages people who can't or won't code 24/7.
The flaw in this method is that it assumes there is only one kind of developer: the lone architect, who builds fine tents out of whatever is lying on the ground and then departs.<p>What it won't get you is breadth of experience, operational background, full-stack thinking, or people who can look at somebody else's work and say "here are the ways in which that is going to blow up in your face, two years from now". (Anybody care to add to this list?)<p>If all you ever do is bootstrap new projects from nothing then maybe that's the sort of people you want to hire, but it's probably not enough to build a sustainable product.
One of my favorite questions is, "Tell me about the best bug you've ever found."<p>It's a great touchstone. Sure, it's subjective, but it gives valuable insight into someone's level of skill, how they approach problems, how they do diagnosis, and so on. Are they scientific? Do they hate on people and their code? Do they follow through with testing?<p>I've gotten answers ranging from "I don't know" (which is a fail, by the way) to full-stack expositions that boil down to bad code generated by the compiler, to someone finding and solving a fundamental design problem in a years-long project.<p>Any sufficiently senior engineer will have a tale of a bug that they tell in the circle around the campfire when the kids are tucked away (and probably still listening anyway). And if you're not a seasoned vet, I'd still like to hear about the race condition / double free / syntax error that took you a while to find.
In these free-form discussions I find it really important to politely disagree with some technical decision of their project to see how they take the feedback and defend the decision. Red flags are when they either cannot accept disagreement or come up with questionable justifications. Correct answers include clear explanations of what the trade-offs would be and clear rationale for their original decision process.
tl;dr:<p>The question he arrived at is: <i>“... will you please tell me about the best project that you’ve ever created?”</i><p>Then watch for enthusiasm and pay attention to the details. The goal seems to be to identify someone who really enjoyed and takes pride in a program they've written.
Everyone seems to have missed the most important part of the article "this was in France, and you can't just fire someone so if you hire badly you are stuck with that person forever"<p>The US has the most liberal/right wing/psychotic labour laws in the Western world, and as such the best approach is to hire anyone not an idiot and fire them once on the job experience teaches you if it's a good fit.<p>This results in massive turnover, and little incentive to improve the interview process<p>I'm not sure where I am going with this but I am amazed that the local labour laws are not mentioned on this three (afaik)
From an interviewee's perspective, these are my favorite interviews too. I get to talk about something that interests me, and have a discussion about the different decisions I made. If the interviewer wants, they can dig into specific details, or ask more pointed questions about the programming language. I find trivia questions off-putting, and tend to limit the depth of discussion into my skills.<p>And to the people saying that this necessitates projects outside of work - I don't see why it does. You can talk about school projects, projects from previous jobs, etc.
It's always surprising how often interviewers fall back on "API Jeopardy" when trying to make hiring decisions. Maybe it's just because my career hasn't really allowed the luxury of getting deep on any technical stack and staying there, but I just don't keep the details of obscure function calls in my head all the time. And I have to wonder at the utility of testing a developer on having memorized the kinds of things that they will always, ALWAYS be able to look up when they're actually working.
On the one hand, this resonates with me... the last time I was doing a round of interviewing (being interviewed at several companies), one person asked this question -- and it was the one point when I really "lit up" and really enjoyed being interviewed.<p>On the other hand, I wonder if it really produces results that are any better. At least, with a quiz, you can give it to current employees who work great, and discover the quiz turns out to be worthless. (As the author described.)<p>But with a open-ended question inviting open-ended answers, how can you tell if it's really working? Of the many coworkers I've had before, I can think of one who certainly would have aced the question -- a programmer through and through -- but who was fired after a few months due to poor work ethic and sloppiness. Because while he had enthusiasm for programming, he had no time for "standards" or "teams" or "business needs" -- things like commenting code, communicating well with others, following through on commitments, etc.<p>So I wonder if the author is going to discover, after a few more months, that there are a few more questions than just this 1 question that also matter just as much...
The best advice I've seen on how to structure an interview came from Nick Corcodilos of Ask the Headhunter [1] fame, from his book Reinventing the Interview to Win the Job [2]. If you want to show someone you can do the job (or see if they can do the job), do the job, or as close as you can get to it in an interview setting. Anything will be selecting for indicators that will be more or less correlated with job performance.<p>[1] <a href="http://www.asktheheadhunter.com/articles.htm" rel="nofollow">http://www.asktheheadhunter.com/articles.htm</a><p>[2] <a href="http://www.amazon.com/gp/product/0452278015/ref=as_li_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=0452278015&linkCode=as2&tag=wwwonebadseec-20&linkId=OBQZTIGOSOWYFUSZ" rel="nofollow">http://www.amazon.com/gp/product/0452278015/ref=as_li_tl?ie=...</a>
I like a more structured technique called GRASS, described in Ovid's 'Agile Companies go P.O.P.' presentation: <a href="http://www.slideshare.net/Ovid/a-14058644/22" rel="nofollow">http://www.slideshare.net/Ovid/a-14058644/22</a><p>The basics are: ask the candidate to describe a project they worked on (that they enjoyed, listed on their resume, or anything). Ask follow-up questions until you find out: the Goal of the project; their Role on the team; what Actions they personally took to reach the goal; whether the project Succeeded or not; and Speculation on what they would do differently in hindsight.<p>Repeat until they run out of projects to talk about, or you run out of time.
Others have noted that the best way to interview is to see if someone can do the job is to have them do the job or the closest thing to it. For the typical developer not available for freelance I combine this approach with the approach in the article.<p>Show me some code from a project of yours and I will ask you to add a feature, fix a bug, or maintain it. The project can be something really simple. It is hard to learn new technologies without creating some kind of simple project.<p>This is a second interview, the first interview is by Skype to figure out the logistical/cultural fit, go over resume, and then spend some time talking through a technical issue.<p>This worked very well for my first hire. The downside of this approach, and a big reason it is not done is it requires an hour of preparation time for the interviewer to understand the candidate's code, run it, look for bugs, and figure out what to ask about. I think it is a much less arrogant way to conduct interviews though and a much more rewarding process for the candidate: they get to delve further into something they already have interest in.
If you are limited to one short question, a better choice is to ask them: "Teach me something technical you've learned recently." You can evaluate their answer on technical depth and correctness, communication skills, and timeliness of the topic. And if they can't think of anything they've learned recently, that tells you something as well.
To add on to the "Tell me about a project you are most proud of?" question, having gone through different stages from burnout to re-kindling of the hacker within, I can see it measures attitude well, which is crucial. For aptitude, however I would go a few layers deeper. "What was the toughest problem you have worked on or solved?", "How did you solve it?", "What did you learn?" the choices of problems tell you as much if not more than the answers about where the candidate's passion stands. Are they vague or specific? Do they use industry terms or are they self taught? What types of issues make their eyes spark? etc. If you are hiring entry level people, passion is most important, but if you need to have people who hit the ground running in an area, nothing beats a nice rigorous interview, with some code writing involved, in addition to your question.
That's almost exactly what I was doing for years. Two differences:
1. I sometimes ask 1-2 technical questions, for example if the candidate claims exceptional knowledge of some important (for us) technology, but his/her resume doesn't show extensive use of it. Like: "You say you know CouchDB inside out, but you've used it only once and not for long, interesting.... Can you tell me how the _changes feed works - if I listen on this feed do I get just the changed documents IDs or whole documents?"
2. Instead of "what's your best project" I ask more aggressive question - "imagine I give you 1 million dollars right now and in return I want to be a part of what you use it for - a share of profits, credits in the movie, etc. What would you do?".<p>Edit: ah, the almost mandatory third question: why do you want to leave the job you're currently having?
It seems that every week there's a post on HN about the "right way" to do interviews. It's too bad there's never any research done to actually test these strategies. I don't believe that you can get a good answer just from personal experience.
Thank you, finally someone who gets the idea. Though I like to ask two questions, one the best project you ever worked on, one the worst project you ever worked on. You can learn a lot about a programmer by the details they relate in both cases.
I really hope that the magic question is useful, and I agree that many boilerplate Java-specific questions are misguided and less useful. Still, but I find it unwise to bet everything on one question.<p>Did the author collect data once he perfected his technique. Is there data?<p>In my experience, the best tests have many questions, including "experimental" ones, because you want to be able to test your hypothesis against various data points.<p>I'm also <i>not</i> saying that everything needs do be quantified. Open ended questions are very useful. But why not at least collect the data and tally it to the best of your ability.
In addition to hiring people passionate about coding, I have found out that anyone who is really passionate about something (music/surfing/rock climbing etc) is a good programmer. Some of the best programmers I worked with were either crazy about programming or passionately followed through with something else in their lives. The key being that they followed through with their passion. Has anyone else seen this? Or is my data too limited to my personal experience
My best project was 12 years ago and I hated it at the time.<p>If you had asked me about it while I was working on it, and I didn't sugar coat, I bet you would have said no hire.<p>Secondly, it has just taken me 10 minutes to remember the details in enough depth to have a proper conversation about it. Again that would probably be "best work behind him...", or "doesn't seem to know the details....insincere" etc.<p>This question is easy to game and disadvantages people who aren't prepared for it.
Shows up to the interview and then spends 5-10 minutes quietly reading the candidate's resume and making notes. Not very courteous and makes for an awful first impression.
The real problem with this style of interview question is that it is good for those who talk well, and bad for those who don't talk well. I have seen my fair share of candidates who are great talkers, but can't code for crap. The interviewers who didn't ask coding questions loved them, but those of us who made them code knew they sucked.<p>You should have stuck with programming on the white board. That's the right way to find good programmers.
The "tell me about your best project" question is great, but I always combined it with one apparently simple programming question, like giving the quadrant from the (x,y) coordinates. Maybe the OP is able to understand how logic-minded his candidates were just from talking, but many times I was disappointed from the actual ability to write down some code (even discounting the stress of the situation).
I see this kind of passion about personal projects and excitements about doing something only in the programming field, maybe some other fields, but never fields like dentistry or civil engineering.<p>Am I missing something? What prevents people from other fields from having "personal projects" to be excited with?
Ok this is good. I have been facing the same problem. I did fizzbuzz, we have the quiz I also often ask about he "favorite" or most challenging "project", but I don't dwell enough on it. But now I think I should. I like this, I will have to steal this idea.
Great article. Despite the comments decrying this 'one question' as unfair, I think we can all agree that having a real passion for programming is the single most important thing in making it from nooblet to competent and confident developer.
I'm fairly certain I can't pass this test even though I've tried. Just haven't had the skills yet for what I want to make and the stuff I've made doesn't impress the people I want to be with.
I like to ask a variant of this: "what's the most interesting project you've done?" If they come back with something that impresses me, I take that as a good sign.
With all the APIs and frameworks that make churning out good looking, usable apps a relatively simple process, I don't think this is a good question by itself.
My interview question was similar "What is the biggest program you have ever written" (As I hire only freshers). Problem is, not even 1% seems to pass this test. For those who are talented but lazy till now, I offered another choice, or "Can you do me a small Snake game now"?
Everyone knows that the only question you need to ask is "how is this an issue?"<p><a href="http://27bslash6.com/interviews.html" rel="nofollow">http://27bslash6.com/interviews.html</a>