Is "White-Board-Coding" inappropriate during interviews?

Question

This is a somewhat subjective quesiton but I'd love to hear feedback/opinions from either interviewers/interviewees on the topic.

We split our technical interview into 4 parts. Write Code, Read & Analyse Code, Design Session & Code on the white board.

For the last part what we ask interviewees to do is write a small code snippet (4-5 lines) on the whiteboard and explain as they go through it. Let me be clear the purpose is not to catch people out. We're not looking for perfect syntax. Hell it can even be pseudo-code. but the point is to give them a very simple problem and see if their brain can communicate the solution to us. By simple problems I mean "Reverse a string", "FizzBuzz" etc...

Note that we always ask for an explicit language first. We're a .NET C# house. we've only said "pseudo-code" where someone has been blanking/really struggling with the code.

My question is "Is it inappropriate / unreasonable to expect a programmer to write a code snippet on a whiteboard during an interview ?"

Answer 1

In my view, It is very appropriate. If you are wanting a job to do a particular skill, then it is entirely appropriate to be expected to demonstrate that skill at interview.

The effect of this technique on the recruitment process is very noticeable. 90% of candidates fail this task. but the developers recruited are good, and the developers will be respected inside the company.

If as a candidate facing this technique, first of all relax. Its about assessing you as a programmer and your thought processes. It is not about your perfect syntax. If you make a syntax error then I might play the role of a compiler and tell you that the code fails to compile on a certain line, and give you an error message, and see how you respond. Likewise if you add a ; onto a loop or an if statement that would compile, I'd play the debugger and talk you through a single step through the code. Again, its not about the mistake, its about how you would cope with the mistake, and are your thought processes good.

Answer 2

My question is "Is it innappropriate / unreasonable to expect a programmer to write a code snippet on a whiteboard during an interview ?"

It's very reasonable. An alternative to a whiteboard might be a laptop and a beamer, since programmers are more used to writing code on a keyboard than on a whiteboard. Just make sure a development environment like Eclipse or VS or Idle is already running with a blank project when the candidate starts, so she doesn't have to waste time searching through your installed applications.

Answer 3

It is not inappropriate, but know that it might NOT always reveal the true insights into the programming or problem solving abilities of the person you're interviewing. And I guess that's exactly what you're after.

Secondly, note that there's always the fear of failure, constantly nettling the person's brain. "What if I screw up?", "What if I make a silly mistake". The greater share of the person's brain is busy constantly inspecting how they're coming off -- only few can hold the nerves.

So, in this kind of situation, even the very best might end up faltering.

For the last part we ask interviewees to do is write a small code snippet (4-5 lines) on the whiteboard and explain as they go through it

That's OK. But again, just because somebody could not explain something properly does not mean they don't know it well. (Explanation is an art of speech).

If I were you, I'd do this For the last part...

Hire them for a very tiny (but realistic) project. See how they code, take decisions, assimilate the working conditions and team members, etc., and then based on that, make the final decision.

Answer 4

Not inappropriate, but remember that some people (and maybe a greater share of the programmer crowd) can be very stressed out in an interview. I think most of us know the guy from the office who is a brilliant coder and a very trustworthy person, but he would melt down in such a situation. His performance could not be measured in such a test, so don't make this a go/no go test.

Answer 5

I think it's not a reasonable thing. We try to find candidates, which are good at the task we want them to do. Writing code on a whiteboard is not one of them and I don't think it's a valid filter to find good candidates.

• Good code doesn't get written, it gets rewritten. A whiteboard is pretty much immutable, as it's hard to change once you wrote it. It should be as easy as possible to change your mind as soon as you understand the problem better.
• Being in an interview is a stressful situation as it is, there is no need to put additional pressure on the candidate. Many computer people don't have a good handwriting. Modern IDEs provide lots of tools that you're used to. And being able to google something the minute you need it is also part of the working style of most programmers. Why take all these things away and create an artificial environment, that they'll never have to work in if you make them an offer?
• We're also very interested in the ability to write good tests, maybe even do TDD. This is not possible to see during whiteboard coding.

Most of the clues that you could get out of a whiteboard coding session you also could get out of a pairing session - And I believe, pairing is a much better tool to get a feeling, how a candidate solves a problem and how he works. He can bring his/her own computer and work in an environment he's/she's comfortable with. And it's much easier to apply to the task you want them to do once they join. We for example have a large legacy code base, so we ask them to refactor some extracted code for the real project. And we actually pair as much as possible in our daily work, so it's well fitting.

While a whiteboard session probably helps to filter out bad candidates, it probably also filters out many good programmers.

Answer 6

I personaly think that this is one of the best things you can do. As you said you don't look for correct syntax or something similar the most important part here is to see if someone can communicate... I have seen so many good developers who can only work alone inside their own space... Unfortunatly this isn't possible in a huge amount of cases so having a skilled guy who also is able to TELL what he thinks in a clear and concise way is a more valuble member of the team then someone who thinks:"They won't understand it anyway, I'll just do it myself and demonstrate later".

Communication, communication, communication that's something that is the foundation of every medium to big sized project (even smaller once need it)

Answer 7

Personally, I'd walk out on any interviewer asking me to do FizzBuzz. I don't know when this became the new industry standard, but it's really a waste of time. FizzBuzz is a filter that can be used ahead of an interview, although personally I think if I had to pick from N candidates of which enough have some open source code or a blog I can look at, I'd definitely prefer that as a filter.

Simply put, I think in an interview for a programming position (except maybe for juniors or internships), it should already have been established/determined that the interviewee can program.

But yes, whiteboard is perfect, although I think you should take a different set of problems. Throw them a real-world problem and have them draw a bunch of UML-ish squibbles to explain their overall strategy to solve that problem. Give them a computer with internet, so they can look for 3rd-party libraries they could use as black-boxes in their squibblescape.
Within a few minutes, you will really see how they tackle problems. You can actually make this a very interesting thing, by picking problems that you don't necessarily have a solution for in mind and attempt to "solve" them together, to see how well they communicate and how well they can incorporate input (however don't push them too hard - some people might just freeze if you do). And then add a few requirements on the fly. This is kind of like software development without implementation and -most importantly- without debugging, so 15 minutes is a lot of time.

Answer 8

Let me respond with another question:

Does writing code on a white board offer any real advantage in assessing programming ability, compared to typing and executing the code on a computer?

I think it's absolutely appropriate to ask a candidate to write code in an interview. However, to me, being able to execute the code is a critical part of the feedback loop that makes up programming. On a white board, you're tying one hand behind my back, and you're not getting the full picture of how I work through a problem.

Answer 9

No, but IMO a better approach would be to use the whiteboard for its intended purpose and use UML/sketches/notes for some fictitious project, rather than the old "write me a sql query to get all records" or "write a method that reverses a string".

One of the best interviews I had was spending like 20 minutes discussing with the lead developer the architecture (non-software) for a mad scientist's mansion (complete with secret hideout, death ray and dog kennel). He got to see my approach at solving problems, and the problem was something fun not typical rote programming 101 stuff that's been solved by modern languages a thousand times over. Incidentally I also did a piece of code like this before, but I felt much more "under pressure" than with the architecture part.

Answer 10

These days, a lot of programming is done in teams. For teams to work, people have to be able to communicate. A big part of this is being able to communicate in front of a whiteboard (brainstorming, mentoring, code reviews proposed fixes, etc.)

I would look for whether the candidate explained how to go about the solution to a programming problem using whiteboard code to assist. If the explanation is good enough, the other good programmers in the room will mentally auto-correct any typos/mistakes on the board.

For most types of team positions, it would be unreasonable NOT to expect a candidate to be able to explain and scribble their attempt at a solution.

Answer 11

No, it is a good thing to code for an interview, but you should allow code in any reasonable language as it is usually easier to train a coder competant in another language than to get a a so-so coder in the language you want, up to a competant level.

Answer 12

I would say it is appropriate, but in most cases it isn't an efficient way to find out who is good in programming and who isn't. If you want a job done (= hire somebody who is capable), then the interview should focus on measuring real-life skills. So far the best interview I had worked like this:

• Greetings, welcome by HR.
• Few words about me, about the company, etc... and she explained the rest of the interview.
• She gave me a laptop with a program which missed few parts, had failed unit tests because of that. The missing parts were commented there as texts, it was about implementing a basic task, like create connection between few classes, and introduce a simple business logic.
• If everything went well, the unit tests became green.
• Saying good bye, and agreement of coming back in few days.
• On that day the leader met up with me, and asked about the finished program, what did I do, and why.
• Also this leader asked about my past experiences, and few other questions.

So to summarize: if you are looking for workforce into a production code, test their skills in real environment. If you are curious about their theoretical knowledge, it is better to ask them about these things. If you are stripped from IDE, or you are nervous because you have to program on white board on front of somebody, I can understand, especially in IT people are sometimes introverted and many of us can't handle these situations well, so on white board our efficiency will look worse than it actually is.

Answer 13

I don't find it unreasonable unless the interviewee has a bad bad handwriting(or i should say boardwriting) :-) . Besides the only difference in your approach is the use of a board and marker. In some cases interviewers do this thing but they give a paper and a pen instead. Incase there are 3-4 persons conducting the interview, i would say your approach will be much better and suited.