4 ms·

It's a very difficult situation. I know we spend a lot of time discussing this on HN, but I'm glad we do, this really is one of the biggest issues facing our i

by geebee 11y ago

It's a very difficult situation. I know we spend a lot of time discussing this on HN, but I'm glad we do, this really is one of the biggest issues facing our industry. We (software developers) essentially have to study for and pass a comprehensive whiteboard exam almost every time we apply for new job. Alternatively, we may have to spend up to a day or more on a "take-home" exam. I do think that Gayle Laakman McDowell (who wrote "Cracking the Coding Interview") has written a couple of good posts on this topic. http://www.gayle.com/blog/2015/6/10/developer-interviews-are-broken-and-you-cant-fix-it http://www.gayle.com/blog/2015/6/10/developer-interviews-are... It's a pretty good roundup of the various interviewing approaches, and the problems with each. I have some differences of opinion, but I agree with the overall point, which is that there really isn't a great way to do this. The in-person coding exam (I don't like to call it an "interview" because I really do think it is more reasonable to call it an exam) at the whiteboard may not be the worst of a bunch of bad choices. Here's my main problem with all of this - it is extremely unpleasant, developers clearly don't like it, employers acknowledge that it has a very high false negative rate… yet seem to see no connection between this and their own constant complaints about a "shortage" of software developers. I do see my friends in other industries interview, and they don't go through anything like this. Lawyers, doctors, nurses, and actuaries (among others) certain do take exams, but they take those exams under much more controlled circumstances, where well understood degree programs and study paths prepare you for the exams you will be taking (even so, many people describe these exams as the most stressful academic experiences they've gone through). All in all, I do think that this practice deters people from becoming software developers, staying in the field, or changing jobs. It's one of those things that makes individual sense for a single employer, but in aggregate takes a heavy toll on the field. I do think some kind of highly respected professional accreditation could solve this problem (actuaries, for instance, must pass a rigorous exam on vector calculus, linear algebra, differential equations, and so forth), but I'm guessing that senior actuaries don't have to do a tricky integration by parts during an interview. Devs most definitely do. Then again, I fully recognize that "professionalization" does come with serious risks (with a few edge case exceptions, anyone who wants to become a lawyer has to go through three years of law school at $100,000+ cost, and many many people feel this is excessive and is really there for regulatory capture/cartel building). Again, there's no perfect answer. My only thing I can say with real conviction is that companies that engage in this kind of interview exam, accepting that it is stressful and produces a high false negative rate, really need to stop scratching their heads about the "shortage" of good candidates. I find that a little hard to take. I accept that there are good reasons to do these exams, but you must understand the role you have played in your own shortage when, by your own admission, your process weeds out lots of good candidates. And one other thing - whatever the process, employers should not look for ways to push the inefficiencies of the interview process out onto the candidate. Although I just didn't study enough for my google interview exam (and who knows, I may not pass even if I took 6 months to study), Google clearly spent the valuable time of its own engineers to interview me. I've done a take-home exam where I spent 8+ hours, and honestly, I received so little feedback I have no idea if they even read it, it was a one-line brush off a full month later ("we've decided not to proceed with your application at this time."). Another good post from Gayle McDowell on this one: http://www.gayle.com/blog/2013/09/18/companies-who-give-candidates-homework-assignments-knock-it-off http://www.gayle.com/blog/2013/09/18/companies-who-give-cand... That I won't do anymore. It has cost me some opportunities, but I do sort of feel we need to make some kind of stand as a "profession" (it is very difficult to make this stand as a scattered collection of individuals, which is why I put "profession" in quotes).

gkop 11y ago
Thanks for the link to Gayle's post. This is what I have concluded also. Near the beginning of our hiring process I explain to the candidate all the steps in the process and why each step exists. I acknowledge the process isn't perfect and express gratitude for the candidate bearing with our imperfect process. I also ask the candidate if she has any questions or concerns before we move on to the next step. The vast majority of feedback on the process I receive from candidates is positive, and good candidates do persevere to the end.
fishtoaster 11y ago
I'm torn on homework assignments. On one hand, Gayle's point is a good one: they're asking for a big time commitment from candidates. On the other hand, they seem to be the challenge that maps most directly onto actual work performance. Our process here is: 1. Non-tech phone screen 2. Tech phone screen 3. Homework 4. Onsite The onsite is, to many candidates, surprisingly light. This is because the homework makes up most of how we're evaluating your tech skills. The onsite is just to make sure that you wrote the code you submitted, and then to test your non-coding skills (architecture, communication, working with non-engineers, etc). But we do lose some number of candidates who just don't get around to doing the homework (or possibly, as you do, refuse to do it). This worries me, since I suspect the people least willing to do homework will be the most senior and/or those with the most competing offers. We've recently started experimenting with allowing candidates to chose between homework and a code sample. The idea is that a sufficiently complex and interesting coding sample should tell us about as much as coding homework. It involves more time on our part to evaluate it, but less for the candidate to prepare it. The early results have been mixed (a lot of unsuitable coding samples), but we're iterating on how we ask for coding samples to try to get better quality ones.
- MartinCron 11y ago
  The last time I've done homework I gave the candidate a choice of problems. As in "pick one of these, solve the problem, and explain why you chose it". Some were larger than others, some were very simple and straightforward while others were more amorphous.

by geebee 11y ago

gkop 11y ago

Thanks for the link to Gayle's post. This is what I have concluded also. Near the beginning of our hiring process I explain to the candidate all the steps in the process and why each step exists. I acknowledge the process isn't perfect and express gratitude for the candidate bearing with our imperfect process. I also ask the candidate if she has any questions or concerns before we move on to the next step. The vast majority of feedback on the process I receive from candidates is positive, and good candidates do persevere to the end.

fishtoaster 11y ago

I'm torn on homework assignments. On one hand, Gayle's point is a good one: they're asking for a big time commitment from candidates. On the other hand, they seem to be the challenge that maps most directly onto actual work performance. Our process here is: 1. Non-tech phone screen 2. Tech phone screen 3. Homework 4. Onsite The onsite is, to many candidates, surprisingly light. This is because the homework makes up most of how we're evaluating your tech skills. The onsite is just to make sure that you wrote the code you submitted, and then to test your non-coding skills (architecture, communication, working with non-engineers, etc). But we do lose some number of candidates who just don't get around to doing the homework (or possibly, as you do, refuse to do it). This worries me, since I suspect the people least willing to do homework will be the most senior and/or those with the most competing offers. We've recently started experimenting with allowing candidates to chose between homework and a code sample. The idea is that a sufficiently complex and interesting coding sample should tell us about as much as coding homework. It involves more time on our part to evaluate it, but less for the candidate to prepare it. The early results have been mixed (a lot of unsuitable coding samples), but we're iterating on how we ask for coding samples to try to get better quality ones.

MartinCron 11y ago
The last time I've done homework I gave the candidate a choice of problems. As in "pick one of these, solve the problem, and explain why you chose it". Some were larger than others, some were very simple and straightforward while others were more amorphous.