Whiteboard Interviews...

[homercles337]

I am not formally trained as a programmer, but 70% of what i do is programming--at a keyboard. How is writing code on a whiteboard an accurate reflection of skills, knowledge, or abilities?

I ask because I recently interviewed at a company for a PhD level scientist position. The position was nebulously defined but basically it would entail a lot of algorithm development, statistics, signal processing, with a healthy dose of computational and theoretical neuroscience. Needless to say, i completely bombed the "whiteboard segment" of two interviewers (there were 9 or 10 total). The questions were ill-posed and i just do not work like that--never have. When tackling a challenging problem i will usually sketch out something for my data structure (but only if its complex), but then i sit at a keyboard. I have never written code with a pen/paper or on a whiteboard, until last week that is. I guess i will be taking the "Kaplan Prepare for Whiteboard Interviews Prep-course" now. Lame.

 

[Markbnj]

Asking people to write code at a whiteboard is stupid, in my opinion. The last time I was asked to do this was in 1993, and I was asked to write a function to convert an ascii character c to an integer i. This is what I wrote...

int i = atoi(c);

I didn't get the job.

 

[DaveSimmons]

I sketch ideas on paper sometimes, but I mostly just go from brain to keyboard.

> int i = atoi(c);

. I assume they were looking for i = c - '0' ; but how often are you converting a single character instead of a string?

 

[Leros]

I think the important part of a problem-solving interview is to think out loud and show them your thought process. If that involves drawing figures on the side of the board, then do that.

I had a similar style interview where I had trouble writing code out on the board, but I was able to explain my process as I thought about the problem out loud. I think it was pretty clear that I understood the problem, but I just needed to be at a computer to write code.

 

[KIAman]

I don't see anything wrong with whiteboarding some code or pseudo-code. Most places that are "engineering" heavy or process oriented want their programmers to be able to write out their process.

If they were looking for exact syntax for a specific language, I would disagree but to be able to communicate your process beyond the keyboard is a strong skill and almost a must-have for non-code monkeys.

 

[Markbnj]

I sketch ideas on paper sometimes, but I mostly just go from brain to keyboard.

> int i = atoi(c);

. I assume they were looking for i = c - '0' ; but how often are you converting a single character instead of a string?

That's exactly what they were looking for. I could have given it to them, but they had already kept me waiting 45 minutes past the appointment time and I was pissed. Personally, I would have preferred to give the job to someone who knew what atoi() was for, but then this was 1993 and they probably hadn't heard of the C runtime library yet .

Kiaman, whiteboarding logical flow. pseudocode, or architecture is completely different, and I would agree that it makes much more sense.

 

[Oyster]

I resort to asking "whiteboard this" kinda questions in every interview. As some others mentioned, the things that tech shops look for mostly include your ability to think through your code. It also tells the interviewer something about your ability to explain your work.

We don't ding them on the syntax - at an intermediate/advanced level, the assumption is that if you know one language, you will know (or at least learn) them all. The gist of the matter is your ability to actually program, and not simply be a code-monkey.

If they dinged you on the syntax, shame on them. As a side note, I'd like to add that a lot of shops still resort to this technique. I'm on the West Coast, and this seems to be the norm in most shops in WA (C#-heavy) and CA (Java-heavy). A couple of my friends interviewed for quant roles (C/C++) in the NY and the CT area for high-frequency trading kinda roles... they were also subjected to "whiteboarding."

On a humorous side, we still receive resumes from people who claim they have 15 years of T-SQL programming experience and who are experts of SQL Server 2003. For people who don't follow Microsoft-technologies, there is no such thing as SQL Server 2003.

 

[homercles337]

I don't see anything wrong with whiteboarding some code or pseudo-code. Most places that are "engineering" heavy or process oriented want their programmers to be able to write out their process.

If they were looking for exact syntax for a specific language, I would disagree but to be able to communicate your process beyond the keyboard is a strong skill and almost a must-have for non-code monkeys.

Not once during these whiteboard tests did i ever feel like the process adequately addressed my talent, skills, or abilities. I have been a staff scientist for almost 5 years now, and was a postdoc for 3 years before that. I, nor anyone i have ever worked with, have ever pseudo-coded anything on a whiteboard unless it has been thought through beforehand. I think its fine to use pseudo-code to explain what was done, but if youre writing pseudo-code on a whiteboard before having thought about a problem (which is what these testers wanted) and written real code, youre just wasting the time of others. This whole notion that people can be given a horribly worded, ill-thought out problem and be expected to write pseudo-code on the spot is completely foreign to me. Short of signing up for some "whiteboard test prep course" i have no clue how to prepare for this kind of thing.

 

[KIAman]

Not once during these whiteboard tests did i ever feel like the process adequately addressed my talent, skills, or abilities. I have been a staff scientist for almost 5 years now, and was a postdoc for 3 years before that. I, nor anyone i have ever worked with, have ever pseudo-coded anything on a whiteboard unless it has been thought through beforehand. I think its fine to use pseudo-code to explain what was done, but if youre writing pseudo-code on a whiteboard before having thought about a problem (which is what these testers wanted) and written real code, youre just wasting the time of others. This whole notion that people can be given a horribly worded, ill-thought out problem and be expected to write pseudo-code on the spot is completely foreign to me. Short of signing up for some "whiteboard test prep course" i have no clue how to prepare for this kind of thing.

Maybe they were testing your ability to think on your feet? And people DO get horribly worded, ill-thought out problems all the time. In my experience, that is the norm and tests your ability to get clarification, ask questions and extract further requirements.

Did they specifically WANT code or did they not say? Maybe they were looking for your ability to diagram or do some UML.

 

[Cogman]

Not once during these whiteboard tests did i ever feel like the process adequately addressed my talent, skills, or abilities. I have been a staff scientist for almost 5 years now, and was a postdoc for 3 years before that. I, nor anyone i have ever worked with, have ever pseudo-coded anything on a whiteboard unless it has been thought through beforehand. I think its fine to use pseudo-code to explain what was done, but if youre writing pseudo-code on a whiteboard before having thought about a problem (which is what these testers wanted) and written real code, youre just wasting the time of others. This whole notion that people can be given a horribly worded, ill-thought out problem and be expected to write pseudo-code on the spot is completely foreign to me. Short of signing up for some "whiteboard test prep course" i have no clue how to prepare for this kind of thing.

What were the questions asking for, if I might ask. I can see a whiteboard test being a good filter, however, like all filters it may be too fine grained. (You shouldn't ask someone to program a 3d rendering engine, for example, on a white board.)

 

[degibson]

I'll be the voice of opposition. Whiteboard questions are great, provided the questions are great, and the interviewer is decent and responsive to the skillset of the interviewee.

Here's why: Lots of folks are comfortable coding. That's easy. What's not easy is communication, so using a whiteboard and forcing the interviewee to respond to changing conditions of the test quickly, with pseudocode, in an unfamiliar environment to boot, separates the cream from the milk. By no means is it the only approach to do so, but it works well.

I say again it relies on quality interviewers, in a very heavy way. The questions must be properly aimed at whiteboard-style coding. "Convert a character to an integer" is not a whiteboard question -- its a screening question, maybe. Good whiteboard questions take the form of "route a network" or "write a file system" -- answers that require a lot of high-level consideration in which the low-level details aren't all that relevant.

... and lastly, I'd like to offer a suggestion to homercles337

Short of signing up for some "whiteboard test prep course" i have no clue how to prepare for this kind of thing.

This is a good question. Pick a friend of yours -- smart, but no coding experience. Sit him or her down, in front of a whiteboard (or a piece of paper), and explain to them how a linked list works. If they get it right away, explain in more detail. If they're lost, go back and explain in more simply. Explain the corner cases. Explain why linked lists are good, and bad.

In short: In my opinion, whiteboard examinations are not about coding, they're about communication and thought process. Show both, and you'll do well.

EDIT: I meant none of the above to imply that I agree with whiteboarding douchebaggery -- expecting someone to vomit perfect syntax on the whiteboard totally misses the point of the whiteboard exercise. Those are key examples of bad interviewers.

 

[Markbnj]

Here's why: Lots of folks are comfortable coding. That's easy. What's not easy is communication, so using a whiteboard and forcing the interviewee to respond to changing conditions of the test quickly, with pseudocode, in an unfamiliar environment to boot, separates the cream from the milk. By no means is it the only approach to do so, but it works well.

I agree with the part about communication, although I don't think communication skills are absolutely necessary in every good coder. As far as coding being easy... easily half or more of the people I meet/interview/work with are absolutely terrible programmers. They're shitty at decomposition, shitty at naming, shitty at architecture and structure, shitty at objects, shitty at thinking. I have a big problem with the idea that programming is easy if you have good business skills. It's like saying that designing a bridge is easy as long as you can understand what kind of bridge the customer wants. Programming is not easy, and at least half the people doing it shouldn't be.

 

[Oyster]

Short of signing up for some "whiteboard test prep course" i have no clue how to prepare for this kind of thing.

To me, this tells me that you went into the interview ill-prepared. I apologize if this sounds rude, but the sooner you know it and the sooner you get past this experience, the better you'll fare in your future endeavors. I can't imagine interviewing with any tech company [for a software-related gig] without a whiteboarding session. Here is an awesome post on the process of how interviews with Fortune giants are structured: Get that job at Google. Most of the tech questions in the post, IMO, are for recent graduates, but the overall hierarchy is how most major companies conduct these interviews. Here are a couple of quotes from the "Interview Anti-Loop" and "Warm-Up" sections:

The bottom line is, if you go to an interview at any software company, you should plan for the contingency that you might get genuinely unlucky, and wind up with one or more people from your Interview Anti-Loop on your interview loop. If this happens, you will struggle, then be told that you were not a fit at this time, and then you will feel bad. Just as long as you don't feel meta-bad, everything is OK. You should feel good that you feel bad after this happens, because hey, it means you're human.

You want your mind to be in the general "mode" of problem solving on whiteboards. If you can do it on a whiteboard, every other medium (laptop, shared network document, whatever) is a cakewalk. So plan for the whiteboard.

Oh, and if you think whiteboarding is bad, Google "Investment Banking Superday," and see how Wall Street gets a majority of its much-envied talent (for front as well as back offices). Also, it may not hurt to check Glassdoor before your interviews to see if you can land some tips.

Again, please don't take my post the wrong way... I hope some of this info helps.

 

[degibson]

... I don't think communication skills are absolutely necessary in every good coder.

100% Agree. Just those who want to work with others, communicate ideas to others, and especially, lead others. But there are some amazing coders out there with no communication skills whatsoever.

As far as coding being easy... easily half or more of the people I meet/interview/work with are absolutely terrible programmers. They're shitty at decomposition, shitty at naming, shitty at architecture and structure, shitty at objects, shitty at thinking.

I sympathize. Fortunately, there's a good set of filters in front of me that prevents me from seeing 95% of these candidates. But of the 1 in 20 that make it through the filter and are still bad... yea, those qualities make interviewing a real pain.

... I have a big problem with the idea that programming is easy if you have good business skills...

(emphasis added)

I don't really view communication as a business skill. There's "marketing", the selling of ideas, which is a skill that transcends a lot of disciplines. But for me, "communication" in this context is the ability to get your ideas across to someone else, who happens to be at a different technical level (higher, or lower).

 

[Ross Ridge]

The last time I was asked to do this was in 1993, and I was asked to write a function to convert an ascii character c to an integer i. This is what I wrote...

int i = atoi(c);

I didn't get the job.

Unfortunately, that's not valid C code. You need to pass a string pointer to atoi(), not a character value.

You could've demonstrated your knowledge of the C library with something like:

int ctoi(char c) {
    char buf[2];
    buf[0] = c;
    buf[1] = '\0';
    return atoi(buf);
}

But "int i = c - '0';" is really the correct answer here.

 

[tatteredpotato]

Also watch out for ambiguous questions and/or questions without any "good" answer. I've run into some of these and they want to see you ask questions and make sure you know exactly WHAT the problem is before you try to solve it. Trust me it's easy to dive in and forget to clarify things when you're asked to do it on the spot and pressure is on.

 

[silverpig]

int ctoi(){
return 099;
}

 

[Markbnj]

Unfortunately, that's not valid C code. You need to pass a string pointer to atoi(), not a character value.

You could've demonstrated your knowledge of the C library with something like:

int ctoi(char c) {
    char buf[2];
    buf[0] = c;
    buf[1] = '\0';
    return atoi(buf);
}

But "int i = c - '0';" is really the correct answer here.

Good point. It was a long time ago.

 

[Markbnj]

I don't really view communication as a business skill. There's "marketing", the selling of ideas, which is a skill that transcends a lot of disciplines. But for me, "communication" in this context is the ability to get your ideas across to someone else, who happens to be at a different technical level (higher, or lower).

Ok, I grant the point about business vs. communication skills. I guess what I reacted to was the perceived idea that coding is easy, but standing at a whiteboard and talking about how you would code separates the men from the boys. I have an intense negative reaction to that idea .

I think code is the part that is valuable. Architecture, design, structure, all of the web of human interaction that defines and supports a project, are all valuable and necessary, but ultimately useless without someone who can connect that really very thin veneer of thought with an execution engine and create code that works. That process is an individual process of art and craft, and while I can't say it will always be an art and a craft, I do feel it will be that way for a very long time. I might have said "very, very long time", but what with that whole Watson/Jeopardy thing I feel a little less certain .

Which is all part of the reason I hate whiteboard code gauntlets. They reinforce the idea that writing code is a linear process that is all about speed and efficiency, and that anyone proficient should be able to demonstrate both on command. I think that's damn near the opposite of what coding is. What I want a candidate to demonstrate is comprehensive knowledge, intellect, curiosity, agility, resilience, joy in the work, and yes, I'd like to see some code they've written. But I don't expect them to be able to code as performance art.

 

[homercles337]

To me, this tells me that you went into the interview ill-prepared. I apologize if this sounds rude, but the sooner you know it and the sooner you get past this experience, the better you'll fare in your future endeavors.

This was a PhD level scientist position. I was asked to write Matlab syntax for an undergrad signal processing problem that i have not thought about in over 15 years. In addition, i did not expect this level of detail. I am a scientist that uses programming as a tool. Im not a code monkey or a programmer. I am a scientist. You want me to walk you through a complicated algorithm (providing detail and explanation at any/every level) at a whiteboard? No problem. But asking me to write matlab code on a whiteboard solving an undergrad math problem is fucking retarded. This was after i had given an hour long job talk on a paper (one of over two dozen) that I published last year. Ill-prepared? I dont think you read my original post.

 

[Oyster]

This was a PhD level scientist position. I was asked to write Matlab syntax for an undergrad signal processing problem that i have not thought about in over 15 years. In addition, i did not expect this level of detail. I am a scientist that uses programming as a tool. Im not a code monkey or a programmer. I am a scientist. You want me to walk you through a complicated algorithm (providing detail and explanation at any/every level) at a whiteboard? No problem. But asking me to write matlab code on a whiteboard solving an undergrad math problem is fucking retarded. This was after i had given an hour long job talk on a paper (one of over two dozen) that I published last year. Ill-prepared? I dont think you read my original post.

Whether you like it or not, this is how things are done in the industry. A lot of people don't like it, but the main point of most interviews is to get you out of your comfort zone. From MS to Google to Amazon... they will all subject you to some level of whiteboarding, regardless of the position, title, or credentials. Even more so at your level because they'd expect you to be operating at the architect level!? This last statement is an assumption on my part - I don't know what kind of roles you're looking into, so I am assuming you're looking for architect-level roles given your credentials.

Again, I agree with you that it was retarded of them to ding you on specifics of Matlab/syntax. All I am trying to say is that you can either continue fighting whiteboarding or actually prepare for acing a theme that is pretty common across the entire industry. You'd be unlucky if you ran across people who evaluate you based solely on your whiteboarding session.

They reinforce the idea that writing code is a linear process that is all about speed and efficiency, and that anyone proficient should be able to demonstrate both on command. I think that's damn near the opposite of what coding is. What I want a candidate to demonstrate is comprehensive knowledge, intellect, curiosity, agility, resilience, joy in the work, and yes, I'd like to see some code they've written. But I don't expect them to be able to code as performance art.

Agreed, but again, you'd be surprised as to how many executives (think Apple, Cisco, and Amazon) think at a technical level. Also, think at the customer-level... I believe that whiteboarding is a way to gauge if you can explain your work to a broader audience.

The argument against a whiteboarding session (assuming it is evaluated properly) is pretty blunt in this day and age when most companies indulge in activities like frequent videoconferences across countries/continents. Guess what, two weeks after you're hired, you'll be whiteboarding your thoughts over video. Boeing's Dreamliner has teams across Europe, Asia, and the US - their Program Manager in is WA... how many whiteboarding sessions do you think they conduct on such a humongous project? At that point it doesn't matter if you're an intern, an architect, or how weird your accent is .

Again, I want to emphasize that I sympathize with the OP for getting dinged on syntax and specifics. I don't think it makes sense to generalize this one event. Ultimately, it is a matter of finding the right fit - in a way, the OP should be happy that s/he actually won't be working with weirdos, right? Conversely, s/he should be thankful to the douches for exposing him/her to an interviewing activity that is pretty common for technology roles.

 

[degibson]

Ok, I grant the point about business vs. communication skills. I guess what I reacted to was the perceived idea that coding is easy, but standing at a whiteboard and talking about how you would code separates the men from the boys. I have an intense negative reaction to that idea .

Even the best possible whiteboarding will certainly fail a class of programmers that are genuinely excellent, top-tier talent on the coding front. I'm not say all such programmers will fail whiteboarding, but it may. When well choreographed, the process measures a linear weight of communication and programming.

When poorly choreographed, the process measures whether a candidate has thought about a particular problem in the last two or three months, and can parrot an answer. In short, it is a terrible thing when done poorly, as seems the case for OP's research position interviewer.

 

[veri745]

I have given candidates for engineering positions at my company the "programming" portion of our interview process, and I find whiteboards to be very helpful for both myself and the interviewee.

Of course, the questions you ask someone to answer using a whiteboard are not long or complex, but usually more centered around process. For instance, I like seeing someone solve the same problem multiple ways, so I may pose a question, and then after it has been answered say, "OK, now use recursion", or "Now solve without using an array", etc..

Usually I provide some or most of the code already on the whiteboard before we begin.

Obviously if you're looking for correct syntax and language-specific items, it's difficult to write clean, correct code quickly on a whiteboard, but any good engineer can learn a new language in a matter of weeks, so syntax and whatnot isn't really a concern.

 

[SunnyD]

Unfortunately, writing "http://www.google.com" on a whiteboard doesn't work too well.

I'm a book programmer. I hate reinventing the wheel. I know almost every problem has been solved at least a dozen times, so why should I waste time trying to do it again from scratch when I know there's solutions or half solutions out there already?

That's something I pride myself and my skill set on. I may not know everything, may not retain everything, but I sure as hell know how to find the answer if I don't know it.

 

[Train]

I'm with Joel Spolsky (Author of "The Guerrilla Guide to Interviewing" and "Smart and Gets Things Done")

http://www.joelonsoftware.com/articles/fog0000000073.html
http://www.joelonsoftware.com/items/2007/06/05.html

A candidate MUST write code during the interview. NO Exceptions. Would you hire a chef without tasting, at the very least, a few simple dishes?

Ever since I have instituted a strict hiring process, I have hired nothing but all star coders. Resume's be damned. I'll never go back to hiring people with stellar resumes who couldn't write anything past the boiler plate code once they actually sat in front of an IDE.