4 ms·

This is something that bugs me about whiteboard-style interviews - they test almost none of the typical day-to-day aspects of programming. Without Google, witho

This is something that bugs me about whiteboard-style interviews - they test almost none of the typical day-to-day aspects of programming. Without Google, without docs, without a REPL, without the code-run-debug cycle, how is it that you think you're assessing how effective I am in real life? EDIT: not to mention that you're also not testing me for one of the most important abilities of a coder in a software shop: how well I learn new things.

MBlume 14y ago
A good whiteboard interviewer will be those things for you. And language details are less important -- "well, let's both agree a for loop has this syntax for now"
- arjunnarayan 14y ago
  Yes. A good whiteboard interviewer should constantly stipulate things that seem intuitively right, and let you use obvious helper functions that should exist in your environment, without penalizing you for getting the _name_ wrong. I.E. if we're talking java, you should be allowed to use anything that "feels" like it should be in java.util, without having to name it correctly. Because that part can be quickly googled for. Sometimes interviewers even let me just define the signatures of helper functions whose behaviors are tedious to write out, but in words we can cleanly go over the expected behavior. I have a habit of writing "pre" and "post" documentation for functions that specify finer grained types than the porous Java type system; chalk this up to my love of OCaml, but it greatly pacifies interviewers who know that I am mentally type checking, and will let those helper functions go unimplemented.
- nollidge 14y ago
  I'm not talking about loop syntax or stdlib argument order. I'll google around for algorithms or concepts or data structures too. I'll bring up the docs and study them to figure out what data structures I've got so as to do the least amount of work. Do you want to test the things I've already learned, or how quickly and neatly I can actually get things done? And it's far too easy to start going down a long and winding dead end path when you can't incrementally run an algorithm. I've had a couple whiteboard interviews where I get the sense that I've gotten something wrong early on that's causing me trouble, and while stopping and pondering on it doesn't immediately reveal a problem (and oh shit, I've only got 10 minutes left in the interview, gah, well, guess I'll just keep trucking), running it once to see the output could easily do so. It's nothing like real-life coding, is my point. Also: > A good whiteboard interviewer will be those things for you. Would that they were all good ones...
  - alexanderh 14y ago
    I applied for a job posting at Khan Academy and ran into exactly this kind of interview. It shows absolutely nothing about me other than I am not a good test taker, and without incrementally debugging my programs I am a fairly worthless programmer. I dont see how putting someone on the spot like that really extracts any knowledge about the type of person they are. All of my peers describe me as 'the best programmer they know' yet every programming interview I've ever gone to in this style doesn't work out for me. Frustrating.
- lucian303 14y ago
  "A good whiteboard interviewer" is an oxymoron.
- ozgung 14y ago
  Whiteboard interviews have another fundamental flaw. Introverted people (typical for programmers) tend to perform terribly when they're watched and being evaluated. Even when you're provided with Google, docs and REPL the most important tools may still be missing: your mind and your ability to focus. Whiteboarding sessions are useful for many things, but coding is not one of them.
windexh8er 14y ago
Is anybody going down the path of giving the candidate X hours yo complete a project, shoe iterations via source control history, showcase documentation and the overall build - plan? I would think you'd find the high performers easier in this light. Not being a programmer by day but proficient in bash and Python I was in an interview last year where the person asking the questions did just not get it. In one example he asked me to count the number of files that had a specific string in the name. I excluded the file descriptor based on his ask. So, he said I got it wrong. I explained the way it was presented I was making the problem harder, and more exact, but he wouldn't budge. The point being, I could easily do what he asked, but wasn't actually measured on that.
- sherwin 14y ago
  The problem with this is that it can take a significant amount of the candidate's time. Scheduling a project (here's a spec, you have 3 days) is a major inconvenience for a lot of candidates.
- hv23 14y ago
  That's how we operate technical interviews at Grubwithus. After a short phone screen and a ~2 hour test for basic competency, we invite candidates into the office to work with us on a 1 to 2-day project where both we and the candidate get to see how we like working with each other. We get the chance to evaluate the candidate's ability in a (sort of) normal working environment as they tackle actual problems they'll face in the day-to-day job, as opposed to a high-tension technical interview with irrelevant/meaningless questions. https://www.grubwithus.com/escape-the-cold https://www.grubwithus.com/escape-the-cold
- sirmarksalot 14y ago
  My best explanation is that a lot of programmers have Asperger's syndrome, and in a pinch, some of them will be called upon to take part in an interview loop. I once had an interview where the interviewer asked me to write him a partial template specification in C++. Any time I gave him anything that wasn't exactly right syntactically, he would just say "uh uh," with no further feedback. I did eventually get it, at which point he moved on to bit manipulation questions, which I must admit were somewhat outside the box of what one normally expect from an interview, so I'll give him credit for that. Needless to say, I didn't get the job. Later that day, I Googled the interviewer, and found his home page, which had a collection of clever bit twiddling hacks he'd collected over the years. I guess that's important or something.
teebs 14y ago
Having gone through a handful of whiteboard-style interviews recently, I found that the opposite is true. If you can't remember the interface for hash tables in Java, for example, they usually let you make one up that you think makes sense. If you can't remember that "=" means assignment or that for loops need curly braces around them, you'll be in trouble, of course, but they'll help you with the details. When it comes to REPL and the code-run-debug cycle, they usually ask you to explain how to code would run to them step-by-step, which simulates having a computer run it. They do the same and pipe up if you miss something. So it's not the same as running the code, but it's similar enough and it also shows how well you understand the code you're writing. I do think that the major flaw of whiteboard interviews is that it does not show a programmer's ability to organize large amounts of code. In most programming, you won't be solving logic puzzles as much as organizing several parts and sticking them together. The organization is far more important in the long run than the individual code itself, especially since the code will likely be changed later on (which is made easier if it is well organized).
ultrasaurus 14y ago
I agree, we do the whiteboarding but what I really care about is how well you can take a problem and make a solution (that's a big part of my application process http://www.pagerduty.com/jobs/engineering/growth-and-internal-tools-developer/#applylikeyoumeanit http://www.pagerduty.com/jobs/engineering/growth-and-interna... )
eldude 14y ago
One of the most effective coding interviews I ever had involved giving bringing in my own laptop and mirroring it on an external monitor. I was asked typical "whiteboard" questions, but I was able to program in the style I've grown accustomed. This accomplished both the typical negative-filter (fizzbuzz) as well as enabling me to build something higher level and more complex than typically posssible during a 1hr interview.

MBlume 14y ago

A good whiteboard interviewer will be those things for you. And language details are less important -- "well, let's both agree a for loop has this syntax for now"

arjunnarayan 14y ago
Yes. A good whiteboard interviewer should constantly stipulate things that seem intuitively right, and let you use obvious helper functions that should exist in your environment, without penalizing you for getting the _name_ wrong. I.E. if we're talking java, you should be allowed to use anything that "feels" like it should be in java.util, without having to name it correctly. Because that part can be quickly googled for. Sometimes interviewers even let me just define the signatures of helper functions whose behaviors are tedious to write out, but in words we can cleanly go over the expected behavior. I have a habit of writing "pre" and "post" documentation for functions that specify finer grained types than the porous Java type system; chalk this up to my love of OCaml, but it greatly pacifies interviewers who know that I am mentally type checking, and will let those helper functions go unimplemented.
nollidge 14y ago
I'm not talking about loop syntax or stdlib argument order. I'll google around for algorithms or concepts or data structures too. I'll bring up the docs and study them to figure out what data structures I've got so as to do the least amount of work. Do you want to test the things I've already learned, or how quickly and neatly I can actually get things done? And it's far too easy to start going down a long and winding dead end path when you can't incrementally run an algorithm. I've had a couple whiteboard interviews where I get the sense that I've gotten something wrong early on that's causing me trouble, and while stopping and pondering on it doesn't immediately reveal a problem (and oh shit, I've only got 10 minutes left in the interview, gah, well, guess I'll just keep trucking), running it once to see the output could easily do so. It's nothing like real-life coding, is my point. Also: > A good whiteboard interviewer will be those things for you. Would that they were all good ones...
- alexanderh 14y ago
  I applied for a job posting at Khan Academy and ran into exactly this kind of interview. It shows absolutely nothing about me other than I am not a good test taker, and without incrementally debugging my programs I am a fairly worthless programmer. I dont see how putting someone on the spot like that really extracts any knowledge about the type of person they are. All of my peers describe me as 'the best programmer they know' yet every programming interview I've ever gone to in this style doesn't work out for me. Frustrating.
lucian303 14y ago
"A good whiteboard interviewer" is an oxymoron.
ozgung 14y ago
Whiteboard interviews have another fundamental flaw. Introverted people (typical for programmers) tend to perform terribly when they're watched and being evaluated. Even when you're provided with Google, docs and REPL the most important tools may still be missing: your mind and your ability to focus. Whiteboarding sessions are useful for many things, but coding is not one of them.

windexh8er 14y ago

Is anybody going down the path of giving the candidate X hours yo complete a project, shoe iterations via source control history, showcase documentation and the overall build - plan? I would think you'd find the high performers easier in this light. Not being a programmer by day but proficient in bash and Python I was in an interview last year where the person asking the questions did just not get it. In one example he asked me to count the number of files that had a specific string in the name. I excluded the file descriptor based on his ask. So, he said I got it wrong. I explained the way it was presented I was making the problem harder, and more exact, but he wouldn't budge. The point being, I could easily do what he asked, but wasn't actually measured on that.

sherwin 14y ago
The problem with this is that it can take a significant amount of the candidate's time. Scheduling a project (here's a spec, you have 3 days) is a major inconvenience for a lot of candidates.
hv23 14y ago
That's how we operate technical interviews at Grubwithus. After a short phone screen and a ~2 hour test for basic competency, we invite candidates into the office to work with us on a 1 to 2-day project where both we and the candidate get to see how we like working with each other. We get the chance to evaluate the candidate's ability in a (sort of) normal working environment as they tackle actual problems they'll face in the day-to-day job, as opposed to a high-tension technical interview with irrelevant/meaningless questions. https://www.grubwithus.com/escape-the-cold https://www.grubwithus.com/escape-the-cold
sirmarksalot 14y ago
My best explanation is that a lot of programmers have Asperger's syndrome, and in a pinch, some of them will be called upon to take part in an interview loop. I once had an interview where the interviewer asked me to write him a partial template specification in C++. Any time I gave him anything that wasn't exactly right syntactically, he would just say "uh uh," with no further feedback. I did eventually get it, at which point he moved on to bit manipulation questions, which I must admit were somewhat outside the box of what one normally expect from an interview, so I'll give him credit for that. Needless to say, I didn't get the job. Later that day, I Googled the interviewer, and found his home page, which had a collection of clever bit twiddling hacks he'd collected over the years. I guess that's important or something.

teebs 14y ago

Having gone through a handful of whiteboard-style interviews recently, I found that the opposite is true. If you can't remember the interface for hash tables in Java, for example, they usually let you make one up that you think makes sense. If you can't remember that "=" means assignment or that for loops need curly braces around them, you'll be in trouble, of course, but they'll help you with the details. When it comes to REPL and the code-run-debug cycle, they usually ask you to explain how to code would run to them step-by-step, which simulates having a computer run it. They do the same and pipe up if you miss something. So it's not the same as running the code, but it's similar enough and it also shows how well you understand the code you're writing. I do think that the major flaw of whiteboard interviews is that it does not show a programmer's ability to organize large amounts of code. In most programming, you won't be solving logic puzzles as much as organizing several parts and sticking them together. The organization is far more important in the long run than the individual code itself, especially since the code will likely be changed later on (which is made easier if it is well organized).

ultrasaurus 14y ago

I agree, we do the whiteboarding but what I really care about is how well you can take a problem and make a solution (that's a big part of my application process http://www.pagerduty.com/jobs/engineering/growth-and-internal-tools-developer/#applylikeyoumeanit http://www.pagerduty.com/jobs/engineering/growth-and-interna... )

eldude 14y ago

One of the most effective coding interviews I ever had involved giving bringing in my own laptop and mirroring it on an external monitor. I was asked typical "whiteboard" questions, but I was able to program in the style I've grown accustomed. This accomplished both the typical negative-filter (fizzbuzz) as well as enabling me to build something higher level and more complex than typically posssible during a 1hr interview.