3 ms·

I try very hard to focus on what the candidate knows. Most of the other stuff is bullshit anyway. Recent interviews: - A somewhat well-known poster here, the

I try very hard to focus on what the candidate knows. Most of the other stuff is bullshit anyway. Recent interviews: - A somewhat well-known poster here, the kind of coder who parachutes in when startups are having trouble shipping and need help. Didn't actually know the programming language very well, which is sadly common amongst coders of the language in question. Sometimes that's ok, but this person presented themselves as an expert in the language and did not know very basic things about it. - Again, not very strong with the language, but very strong in other languages and overall quite an impressive candidate. I recommended to hire this person, but for a different engineering role. Got hired for a different role and is doing a great job.

Impossible 12y ago
I had an interview pretty recently where, I'm positive the interviewer came to the conclusion that I didn't know the language despite years of experience because I made some embrassing syntax mistakes during a phone screen. This was something I know, is very basic and core to the language but I hadn't done in a while because it's a construct that is explicitly disallowed in the code base I currently work in.
- serve_yay 12y ago
  That sucks! I think it's unfair to ask candidates to write code on the spot. You're already nervous, and if you don't have your computer with you then you're totally out of your element and without the tools you normally use. We have a small coding exercise we ask candidates to do at home in their own time. I think it's much more fair that way. In the interview itself, as I said, no coding. Sometimes I will ask the candidate to spot bugs in a function, or read code and say what it outputs, or have a whole function written with one thing missing, and ask what's missing. But asking the candidate to create something where nothing yet exists is not fair, I think. Whiteboard coding and all that, it's no good. When I say the candidate didn't know the language well, I meant conceptually. Like, imagine if someone told you C had a built-in array type, for example. It was that sort of thing. And remember, this was a person claiming expertise.
- jtheory 12y ago
  We don't use coding in interviews partly for this reason -- but more importantly, it sounds to me like the problem here was partly that flub, but possibly more an issue with your communication skills. One of the principal things I look for in candidates is ability to speak comfortably about their thought processes & confidence level -- because it's so much more valuable to have a developer say "well, I can think of two ways to solve this, but I'll have a much more solid answer if I can take 10 minutes to refresh my memory on a project I did 5 years ago" than one who says "there are 2 options". This shows up in interviews (and I look for it); if you give a wrong answer to a question, but you seem to be confident, that's bad. If you give the same wrong answer, but you mention that you don't use the construct (and thus aren't fully confident on your response), that can even be better than giving the right answer. An interview that only saw correct answers can easily be less informative than one that ran into areas of uncertainty -- because it's crucial to see how they handle that. Do they realize they're guessing? If not: don't hire. Are they comfortable revealing uncertainty or missing knowledge? If not, don't hire. Ideally they should know how roughly how confident they should be, and also know how to get to a better answer quickly. Real development isn't at all like a closed-book test, and interviews that operate like a closed-book test aren't useful for that reason.

Impossible 12y ago

I had an interview pretty recently where, I'm positive the interviewer came to the conclusion that I didn't know the language despite years of experience because I made some embrassing syntax mistakes during a phone screen. This was something I know, is very basic and core to the language but I hadn't done in a while because it's a construct that is explicitly disallowed in the code base I currently work in.

serve_yay 12y ago
That sucks! I think it's unfair to ask candidates to write code on the spot. You're already nervous, and if you don't have your computer with you then you're totally out of your element and without the tools you normally use. We have a small coding exercise we ask candidates to do at home in their own time. I think it's much more fair that way. In the interview itself, as I said, no coding. Sometimes I will ask the candidate to spot bugs in a function, or read code and say what it outputs, or have a whole function written with one thing missing, and ask what's missing. But asking the candidate to create something where nothing yet exists is not fair, I think. Whiteboard coding and all that, it's no good. When I say the candidate didn't know the language well, I meant conceptually. Like, imagine if someone told you C had a built-in array type, for example. It was that sort of thing. And remember, this was a person claiming expertise.
jtheory 12y ago
We don't use coding in interviews partly for this reason -- but more importantly, it sounds to me like the problem here was partly that flub, but possibly more an issue with your communication skills. One of the principal things I look for in candidates is ability to speak comfortably about their thought processes & confidence level -- because it's so much more valuable to have a developer say "well, I can think of two ways to solve this, but I'll have a much more solid answer if I can take 10 minutes to refresh my memory on a project I did 5 years ago" than one who says "there are 2 options". This shows up in interviews (and I look for it); if you give a wrong answer to a question, but you seem to be confident, that's bad. If you give the same wrong answer, but you mention that you don't use the construct (and thus aren't fully confident on your response), that can even be better than giving the right answer. An interview that only saw correct answers can easily be less informative than one that ran into areas of uncertainty -- because it's crucial to see how they handle that. Do they realize they're guessing? If not: don't hire. Are they comfortable revealing uncertainty or missing knowledge? If not, don't hire. Ideally they should know how roughly how confident they should be, and also know how to get to a better answer quickly. Real development isn't at all like a closed-book test, and interviews that operate like a closed-book test aren't useful for that reason.