4 ms·

In my experience (also interviewing hundreds of people) this is totally an urban (internet) legend. Not once has someone been able to talk intelligently and at

In my experience (also interviewing hundreds of people) this is totally an urban (internet) legend. Not once has someone been able to talk intelligently and at length about a project they built and the underlying technology choices and then been unable to deliver. Once you gain experience building things yourself, it's pretty easy to suss out whether someone is any good just by talking to them. No coding tests needed.

panopticon 7y ago
At one of my previous gigs, we managed to hire someone who couldn't write more than basic control structures. I have absolutely no clue how it happened as I wasn't involved with the interviewing process at the time. The people who were involved blamed the recruiting firm for not doing adequate technical screening, but that doesn't explain how this person passed the on-site interview they performed... At any rate, we let them go after 3 days. I have no way to prove to veracity of my story, so feel free to add it to the "urban myth" pile. But it was extremely bizarre to experience.
jjav 7y ago
Agreed. The best way to interview is to simply have a joint discussion about their past projects (from resume). There is no value in whiteboard puzzles. It is easy to gauge who is competent and who didn't do or didn't understand the work they claim on the resume. In over 25 years of interviewing candidates, this approach has never failed me. I've never asked for whiteboard coding. Whiteboarding architectural concepts, sure. The only caveat is the interviewer needs to have substantial experience in the same field to spot the wheat from the chaff in a casual conversation. If the interviewer is very junior, I can see how this might not work. Solution: don't have your most junior people run the interviews.
- donretag 7y ago
  I use the same approach. Also has never failed me. If you can code system X, then you know how to use an if statement.
billti 7y ago
I've interviewed hundreds of candidates over more than 20 years. I've lost count of the number of times that a candidate has talked-the-talk so well that I'm thinking "This guy/girl is amazing. They're a shoe-in. Better do a little coding just to make sure"... and then they literally couldn't even get close to solving something like fizz-buzz. I agree asking highly specialized, deep CS-algorithm type problems is usually a terrible indicator. I typically start with a very rudimentary question that could go off in various directions and to various depths as time/progress allows. I let candidates choose the programming language, and to use either whiteboard, pen & paper, or laptop with choice of IDE. I've seen candidates who claim to have years of "senior" experience struggle to get the basic syntax of their "language of choice" right - to the point where a competent hobbyist who spent a weekend doing a couple tutorials would wipe the floor with them. There's just something about coding that makes it impossible to truly evaluate a candidate (for a developer role) unless you see them actually code.
- malvosenior 7y ago
  I've not had this experience. How are you screening your pipeline? I have a hard time believing that someone who can tell you why they designed a particular REST api the way they did, describe the schema and talk about what performance issues they encountered and how they dealt with them and can intelligently discuss the language they're using but can't code fizzbuzz.
- blub 7y ago
  My guess is that either your interview is too much fluff, and not enough technical detail, or you're intimidating the candidates and they get lost. It makes zero sense that someone can have a deep technical discussion but they're not able to write fizz buzz (which by the way is a crap exercise). Sure, if one is asking general questions about agile, TDD, SOLID and other fluff, anyone can answer those.

panopticon 7y ago

At one of my previous gigs, we managed to hire someone who couldn't write more than basic control structures. I have absolutely no clue how it happened as I wasn't involved with the interviewing process at the time. The people who were involved blamed the recruiting firm for not doing adequate technical screening, but that doesn't explain how this person passed the on-site interview they performed... At any rate, we let them go after 3 days. I have no way to prove to veracity of my story, so feel free to add it to the "urban myth" pile. But it was extremely bizarre to experience.

jjav 7y ago

Agreed. The best way to interview is to simply have a joint discussion about their past projects (from resume). There is no value in whiteboard puzzles. It is easy to gauge who is competent and who didn't do or didn't understand the work they claim on the resume. In over 25 years of interviewing candidates, this approach has never failed me. I've never asked for whiteboard coding. Whiteboarding architectural concepts, sure. The only caveat is the interviewer needs to have substantial experience in the same field to spot the wheat from the chaff in a casual conversation. If the interviewer is very junior, I can see how this might not work. Solution: don't have your most junior people run the interviews.

donretag 7y ago
I use the same approach. Also has never failed me. If you can code system X, then you know how to use an if statement.

billti 7y ago

I've interviewed hundreds of candidates over more than 20 years. I've lost count of the number of times that a candidate has talked-the-talk so well that I'm thinking "This guy/girl is amazing. They're a shoe-in. Better do a little coding just to make sure"... and then they literally couldn't even get close to solving something like fizz-buzz. I agree asking highly specialized, deep CS-algorithm type problems is usually a terrible indicator. I typically start with a very rudimentary question that could go off in various directions and to various depths as time/progress allows. I let candidates choose the programming language, and to use either whiteboard, pen & paper, or laptop with choice of IDE. I've seen candidates who claim to have years of "senior" experience struggle to get the basic syntax of their "language of choice" right - to the point where a competent hobbyist who spent a weekend doing a couple tutorials would wipe the floor with them. There's just something about coding that makes it impossible to truly evaluate a candidate (for a developer role) unless you see them actually code.

malvosenior 7y ago
I've not had this experience. How are you screening your pipeline? I have a hard time believing that someone who can tell you why they designed a particular REST api the way they did, describe the schema and talk about what performance issues they encountered and how they dealt with them and can intelligently discuss the language they're using but can't code fizzbuzz.
blub 7y ago
My guess is that either your interview is too much fluff, and not enough technical detail, or you're intimidating the candidates and they get lost. It makes zero sense that someone can have a deep technical discussion but they're not able to write fizz buzz (which by the way is a crap exercise). Sure, if one is asking general questions about agile, TDD, SOLID and other fluff, anyone can answer those.