Hacker News new | past | comments | ask | show | jobs | submit login

As many blog posts this one focuses on the "false positive" candidates, the guys who get hired but turn out to be bad.

But I would be curious about the false negatives, the guys who were rejected (or almost rejected) but turned out to be truly good. Why they gave the impression they were bad in the first place? How did they proof the initial assumptions were wrong? What were they doing bad in the interview?

Does anyone have experience with these "false negatives"? How not to miss them in spite of a bad interview?




You can't write about the people who weren't hired... There's a strong selection effect here.


There may be interesting anecdotes where people run into rejected candidates at some later time, to learn they were actually quite competent.


I've been a false negative several times, I'm sure. Here are some of the reasons why.

1. Poorly defined questions. One time, the interviewer kept referring to the browser as "the server" (in the context of a web app), despite my questioning him about it several times. After 5 or 10 minutes of trying to figure out what he even wanted, I told him I didn't want the job and ended it. From his perspective, he'd successfully weeded out an incompetent. From my perspective, I avoided working for someone with terrible communication skills.

2. Unclear objectives. One interviewer asked me to extend a small language by adding string support. No problem.

"OK, I'd start by modifying the parser."

"That's not what I had in mind."

"But that's clearly the first step. This isn't even a real language. What's the point here?"

"To get a feel for how you approach a problem in the real world."

"Well in the real world I'd modify the parser."

"Well just don't."

3. Pointless questions. "List some design patterns." Seriously? Sometimes my mind blanks on such questions. There's GoF over there on my bookshelf, and I could talk about the nuances of when and when not to use (almost) any particular pattern if they'd mention one, but from their perspective I know no design patterns at all. From my perspective, I'm glad I didn't end up working at a place whose screening process selects for rote memorization.

4. Insulting questions. "Write a for loop." I mean, I just told you I've been coding for 17 years. You're basically calling me a liar. I don't respond well to that. Enough of these and I might turn you down and walk out. A professional relationship (like any relationship) requires a certain amount of trust, so an interviewer this jaded/distrustful casts doubt on my ability to be accepted and productive there.

5. Trick questions. I hate them and I might have to count down from 10 if you ask me how many square manholes are in Beijing or whatever. You'll probably think I'm googling the answer.

6. The "figure out on the fly what I learned by reading a paper" question. Frequently I'll respond with a working but sub-optimal solution, then they'll prod me with hints until I come up with (or more often don't) the exact algorithm they had in mind. Sometimes they can't even explain what I need to improve about my answer, they just tell me to try something else. Sometimes this is the first question of the interview, and if I don't figure out the clever trick it becomes the only question, because they let me spend an hour banging my head against it without moving on. From their perspective, I answered zero questions and might not know anything at all. From my perspective... well I have no perspective by the end because I'm so tired and angry from being put through such a process.


Agree on 1,2 and 3 - they are jobs you don't want really.

I don't get offended by 4 (although I don't have 17 years of coding experience :); I understand the need for them to weed out the really incompetent ones. Think of this as a store clerk asking for your ID when you purchase cigarettes.

6 is, IMO, the biggest cause for false negatives. The interviewer feels that she gave ample hints, but really all she ascertained was that you did not have a crystal ball.

I also think that the interviewer anti-loop that Steve Yegge mentions (http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...) contributes to the false negatives.

_Well, back when I was at Amazon, we did (and they undoubtedly still do) a LOT of soul-searching about this exact problem. We eventually concluded that every single employee E at Amazon has at least one "Interview Anti-Loop": a set of other employees S who would not hire E._


RE #4 - note that the context here is the embarrassing inability of many applicants to, in fact, write a simple for loop.


I suppose good developers should be glad when these basic questions come up in interviews, cause then we can rest assured that no incompetents are nicking our jobs (or warming the seats for a few months until they get sacked, thus slowing the hiring process down for everybody else).


Plus these questions can assure that you get hired to a team where everyone knows how to write a for() loop. :)


Oh, goody. I would feel assured that I would work with people at the level of CS 1, as a professional.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: