I've interviewed a lot of programmers and I think there are many misconceptions about what an interviewer is looking for or expecting.
I don't expect you to be able to code quicksort from memory. I do expect you to be able to code quicksort given the spec for it.
Just because I point out an error doesn't mean I'm counting it against you. I'm pointing it out to see how you handle it.
I do expect you to ask questions. If you are unfamiliar with an algorithm or forget the details, ask. I may not give you the answer but I'll at least point you in the right direction.
I generally try to make this clear to candidates so that they don't get uncomfortable if I point out some problem, but a lot of interviewers don't, which can be hard on the interviewee. I doubt, however, that there are many who expect perfect code on a whiteboard.
This reminds me of my Cambridge University interview. I thought I'd done terribly because I couldn't provide the answer to most of the questions they asked, but I did explain how I would find that answer if they gave me 10 minutes and some paper. I passed the interview, and many of my peers that were able to recite the formulae by rote when prompted (and thus felt they had done well) did not.
I feel exactly the same. Don't try to make stuff up you don't know, do ask me questions, do just TRY, rather than noodling about and not saying or doing anything.
I believe this was the original intention of the "coding" interview, but it morphed from being used to expose thought processes into a binary checklist (e.g. Can he code a linked list? Yes. Can he code a quicksort? No. Oops, no job).
As the blogpost pointed out, it's pretty useless to require the knowledge of the implementation of these items because 99% of programmers will never need to code it from scratch. If someone on our (web) team was building a new linked list library, they're doing something wrong.
Comments
I've interviewed a lot of programmers and I think there are many misconceptions about what an interviewer is looking for or expecting.
I don't expect you to be able to code quicksort from memory. I do expect you to be able to code quicksort given the spec for it.
Just because I point out an error doesn't mean I'm counting it against you. I'm pointing it out to see how you handle it.
I do expect you to ask questions. If you are unfamiliar with an algorithm or forget the details, ask. I may not give you the answer but I'll at least point you in the right direction.
I generally try to make this clear to candidates so that they don't get uncomfortable if I point out some problem, but a lot of interviewers don't, which can be hard on the interviewee. I doubt, however, that there are many who expect perfect code on a whiteboard.
It's as much about the process than the result.
This reminds me of my Cambridge University interview. I thought I'd done terribly because I couldn't provide the answer to most of the questions they asked, but I did explain how I would find that answer if they gave me 10 minutes and some paper. I passed the interview, and many of my peers that were able to recite the formulae by rote when prompted (and thus felt they had done well) did not.
I feel exactly the same. Don't try to make stuff up you don't know, do ask me questions, do just TRY, rather than noodling about and not saying or doing anything.
The thing that sucks is when the interviewer doesn't care about that, but instead cares about specific answers to their particular list of questions.
It can be astonishingly random who gets through an interview. Bizarre that just a few words can tip the balance.
I believe this was the original intention of the "coding" interview, but it morphed from being used to expose thought processes into a binary checklist (e.g. Can he code a linked list? Yes. Can he code a quicksort? No. Oops, no job).
As the blogpost pointed out, it's pretty useless to require the knowledge of the implementation of these items because 99% of programmers will never need to code it from scratch. If someone on our (web) team was building a new linked list library, they're doing something wrong.