Why you should refuse to participate in coding interviews
1–10 of 47 posts
Re: Why you should refuse to participate in coding interviews
#2I really don't understand where this meme has come from. How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work?
Re: Why you should refuse to participate in coding interviews
#3While I fully agree with the author that coding interview questions are not great, I think something important to keep in mind is that "fixing" programming interviews it is an incredibly difficult problem to solve.
I think the best way to gauge a candidates programming ability is to work on a small project with them, similar to Automattic's approach [1]. Unfortunately, this method is extremely expensive, to both the candidate and the company.
Maybe company's are "lazy" for sticking with archaic methods that are not always fair to the candidate, but when the author claims that companies are simply "too lazy to figure out how to interview people effectively", I feel he is trivializing a very difficult problem to solve.
Re: Why you should refuse to participate in coding interviews
#4I really don't understand where this meme has come from. How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work?
> How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work?
Unless the job is responding to problems and being watched while you work, the argument here is that you're not actually assessing anything that's very useful.
Most engineers/developers, for example, spend a lot of time thinking about a problem or trying out their ideas (many of which quickly get thrown out). If you do this in most programming interviews, you're going to fail them.
Re: Why you should refuse to participate in coding interviews
#5I really don't understand where this meme has come from. How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work?
The problem as I see it is the difficulty in posing a problem that's interview-sized and still relevant to their actual workflow. I don't know how much whiteboard algorithm time you spend during your day to day, but for me it's vanishingly small.
What is relevant in my day to day is dumb shit like "What do you name things?" "How do you control access to classes internals?" "How do you construct an API?" "How do you communicate your designs to people living outside your head?"
Virtually none of which you can get done on a whiteboard with a problem set that you can define in five minutes or so.
Re: Why you should refuse to participate in coding interviews
#6My experience is that knowing who's a good programmer is like knowing what's art: you know one when you see one. That's why I don't get the coding interview.
Just an everyday conversation with a coder will give you a better idea whether he's any good or not, and it will do this without stressing him out or impugning his integrity (which is exactly what you're doing when you ask someone a bunch of trick questions on a subject they've already claimed expert knowledge on in their resume).
Re: Why you should refuse to participate in coding interviews
#7I give coding interviews and I try to take the original concern (Questioner can't think fast enough or freezes) into account, but I can't really say with any certainty if I'm successful or not.
About 10 years ago, I gave a woman a coding interview question and her hands were literally shaking. She got through it, but I felt terrible because clearly she was the type of person who gets really nervous when under that type of pressure. She was very experienced and my discussions with her really seemed to indicate she learns quickly and would probably be a decent fit. The only reason we didn't hire her was I found another woman who was a better fit.
Since then, I've tried a lot of things. Lately, I've been putting the emphasis that we allocate some time to pair program. We simply get in a room to make something together and we may take turns with the keyboard. I actually go out of my way to tell people this is not a coding test, but rather a play date. I emphasize I don't expect them to know everything and I even half-joke I deduct points for not asking questions.
Some people have told me they really like this approach, the others haven't commented one way or the other, but I'm still skeptical about my method. Most seem to relax well enough, but there are always people who may be more than competent who simply don't manage to relax in a realtime environment.
Some people work like tortoises. They may appear slow, but the culminated effect of their very deliberate and careful decisions accumulates far better than a hare. I'm pretty sure my current process doesn't work in their favor, but I'm at a loss for better alternatives at this time.
I'd love to know what HN readers think. Do your interview processes penalize tortoises or other people who don't simply fit a mold? Do you have a good system that takes into account the diversity of people's talents?
Re: Why you should refuse to participate in coding interviews
#8I really don't understand where this meme has come from. How else are you supposed to assess a candidate's ability to do the job, if not to pose them a problem and watch them work?
A good start would be talking with them like they were professionals: asking for advice, listening to their answers, debating their answers if you disagree so they have a chance to respond and possibly change your mind. Or, you could just have them jump through hoops and do tricks like trained monkeys.
Depends on what you're looking for.
Re: Why you should refuse to participate in coding interviews
#9While I fully agree with the author that coding interview questions are not great, I think something important to keep in mind is that "fixing" programming interviews it is an incredibly difficult problem to solve. I think the best way to gauge a candidates programming ability is to work on a small project with them, similar to Automattic's approach [1]. Unfortunately, this method is extremely expensive, to both the…
I think there's a business opportunity here. Imagine something like ETS's system for administering the GRE: Come into a location in your city at a particular date/time, sit down at a computer pre-loaded with various editors / IDEs for common languages, and run through an 4-hour coding exercise specified by the hiring organization, and, at the end, your code is provided to the hiring organization for examination. Internet access is freely permitted but it is fully logged and reviewable by the hiring organization. A proctor is present to keep an eye out for cheating and to resolve any technical difficulties. This reduces the pressure to something not much higher than working in a regular office.
Bear in mind that this is for the coding part, which people seem to have the most difficulty doing on a whiteboard under pressure. There would still need to be a conventional behavioral interview as well.
Somebody want to run the idea past YC? ;)
Re: Why you should refuse to participate in coding interviews
#10While I fully agree with the author that coding interview questions are not great, I think something important to keep in mind is that "fixing" programming interviews it is an incredibly difficult problem to solve. I think the best way to gauge a candidates programming ability is to work on a small project with them, similar to Automattic's approach [1]. Unfortunately, this method is extremely expensive, to both the…
Is it possible to lower the cost of failure? Quarantine new hires and let them go quickly if they don't work out. Have a bunch of "ready-made" tasks ready for them. For senior hires, talk for a bunch of hours.