Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As I get it, having an error (even a typo like or missing ";") in your whiteboard code will often cost you some interview points. Avoiding that will inevitably make one proof-reading code again and again (losing time and possibly neural energy / concentration) or even using a simpler (and thus less effective) algoritm -- and both these ways are "costy" again!

So, why not just fast write code as elegant and effective as you would having a (unit) testing framework at your disposal and then just normally test it it (just on the whiteboard) ?

Has anyone tried / seen this approach? Is the whole idea worthy?

[this also applies to the pen-and-paper case of course]

share|improve this question
17  
If I wanted someone to write code on a whiteboard or paper during an interview I wouldn't expect it to be 100% syntactically correct - that's putting them under too much pressure. Yes it should be broadly correct, but missing semi colons or even getting a method name/parameter profile slightly wrong is (or should be) OK. –  ChrisF Nov 4 '10 at 12:25
11  
I'm a big fan of whiteboard coding in interviews, but anyone who's expecting your whiteboard code to be syntactically perfect is doing it wrong. The point is to see how you attack a problem, not to see that you can produce syntactically perfect code in a totally unrealistic environment. –  Tim Goodman Nov 4 '10 at 12:57
2  
you should be able to tell which is which by asking them to give a running commentary on what they are doing for example or discussing the solution with them after they finish. –  ChrisF Nov 4 '10 at 13:07
2  
Being overly concerned about exact syntax and spelling will cost the interviewer points in my book. –  JeffO Nov 5 '10 at 16:17
1  
this is what psuedo code is for –  jk. May 18 '12 at 12:33

7 Answers 7

up vote 42 down vote accepted

I absolutely want you to test the whiteboard code I ask you to write. I want you to talk out loud while you write it, look it over, spot most of the syntax mistakes you made, and point out how it could be more efficient. In fact, that's kind of the point of doing it at the whiteboard. It's not a one-shot, write-it-all-out, uh-huh-you-get-70/100 kind of thing. It's a conversation, mediated by code and held at the whiteboard instead of across my desk.

Here are some great ways to fail the "Whiteboard coding" test:

  • refuse it
  • don't ask a single clarifying question (language, platform, something about the requirements) AND don't tell me your assumptions about any of it AND make assumptions that are way off what I would have answered

(eg: write it in Fortran, interpret "display" or "print" as "write to the event log", that sort of thing. I might allow it if you told me in advance those were your assumptions)

  • ask me what language I want it in, receive an answer that is in the job description, and then write it in a different language because you're not comfortable in the language I asked for.

(We're consultants here. I am testing for consultant behaviour as much as coding. Asking the client is only correct if the client actually has a choice. Controlling conversations with people who will pay you is hard. This is lesson 1. It's a mark against you on any topic, but for the specific "you're hiring an X programmer but I don't want to write in X for you" you now have two big black marks.)

  • show me what an architecture astronaut you are by filling two whiteboards with interfaces, factory patterns, abstractions, injections, and tests when I wanted you to "print the numbers from one to 5".

(you think I'm exaggerating but I had a guy who generalized my problem dramatically - sticking to the example above let's say instead of 1 to 5 his solution would do any arbitrary sequence of integers (got from where? I wondered) and was 5 times as long as anyone else's - and he forgot to actually call the function that did the work. Repeated prompting and suggesting that he walk through it as though he was the debugger did not lead to his noticing that the function was never called.)

I always say "do you like that?" "can you improve that?" "walk me through that" and the like. Typically the missing semi colon gets spotted, or the off-by-one, in that conversation. If not, I usually mark it up to nerves.

Other things you may not think matter at the whiteboard that matter to me:

  • when you're done, can I still read it? Have you smudged, scribbled over, switched colours, drawn arrows, crossed out and generally left a mess that can't now be used? Or are you aware that whiteboards are erasable, pointed to lines of code in the air instead of circling/arrowing them, and left me something I could take a picture of and keep in the design file?
  • how much did you ask me as you did it? Do you like to be left alone and not discuss your code, or do you see code as a collaborative thing? How did you respond when I asked you things while you were still writing it?
  • did you sneer at the "easy" task or faint at the "hard" one? Were you rude about being asked to show you can code? Are you easily intimidated by a technical problem, or arrogant about your ability to come up with a good algorithm?
  • are you working it out in your head, or remembering a solution you read somewhere? I can usually tell for the hard problems.
  • did you plan ahead about where you started writing? Folks who run out of whiteboard usually start too low or write too big - I can tell they didn't know this was going to be 20 lines of code and so only left room for 5 - believe it or not this tiny detail is mirrored in bigger estimating tasks as well.
  • did you look it over before you said you were done? Did I see you pointing or tapping your way through it and testing it yourself before I asked you to? When I prompted you, or asked you specific questions about it, did you look at it again, or just go from memory? Are you willing to consider that your first draft might not be complete?

I strongly recommend practicing coding at the whiteboard. I always warn interviewees that they will be asked to do it. If you have access to an actual whiteboard then set yourself some simple problems and practice doing them there. It will help your performance and your confidence.

Sorry I know I'm in TL;DR territory but here's the thing - coding at the whiteboard is about more than coding. It's a test of more than your grasp of syntax. There are a lot of behaviours of good programmers that are demonstrated in your response to this task. If you think it's only about coding you are missing the point.

In other conversations about whiteboard testing, people tell me I may reject a good candidate with it. Honestly, that's a risk I'm willing to take. Every hiring round contains several people I could hire. Some people with great resumes, who are doing ok in the question-and-answer part of the interview, fall apart at the whiteboard and clearly cannot (with any amount of prompting) write simple code in the language they claim to know. I might have hired some of these. Any tool that prevents that is a tool I will continue to use. I have never ended up in a no-one to hire boat because all my candidates messed up at the whiteboard and I don't expect I ever will.

share|improve this answer
2  
Seems to be one great answer (and to be honest far more intersting that I initially hoped to receive). Many, many thanks. –  mlvljr Nov 4 '10 at 15:55
2  
@mlvljr: I agree, it's a fairly detailed answer for a question I thought would be "easy". I never suspected the level of insight this simple exercise could generate. –  Matthieu M. Nov 4 '10 at 19:07
3  
Whiteboard tests are stupid. Does anyone really care about a missing semicolon and the like in the days of intellisense. Most of these tests are useless anyway. Have someone code an actual project if you want a real test but even then you are only proving they are skilled at a very specific problem which one person may have done recently vs. another candidate who hasn't done it in awhile. We don't do all things every day so if you're problem isn't very generic than that is a fail. A great answer, but people's love for whiteboard tests I simply don't understand. –  KingOfHypocrites May 18 '12 at 13:38
6  
@KingOfHypocrites did you actually read the answer? I don't care about missing a semicolon. Look what it says I care about. 20 minutes at the whiteboard tells me a lot about you. –  Kate Gregory May 18 '12 at 13:56
3  
It was just a general point I was making (you mentioned it wasn't that important, so that comment wasn't really directed at you, just at the concept in general and it's flaws). You obviously have a love for whiteboard testing and I was commenting on it. I said it was a good answer in my comment. –  KingOfHypocrites May 18 '12 at 14:19

White board coding is tough. I was never introduced to that until I was interviewed by Disney. Not knowing what to expect and not being able to debug it, I stumbled through it talking it through and solving the problem, but in a pseudo code kinda of way. When they asked could it run.

I mean sure it could you just have to fix the syntax errors, correct. I believe they lost a very good candidate if I was not hired because of the whiteboard. I look at the qualifications and it looks like I am way qualified for the position and can do the job. I excel at the current job I am at and wished I could with them.

Thanks for your input Kate, I read every word. It's just to me as a programmer, white board really doesn't show your skills. I'm a great programmer that work in multiple languages. I knew the language I was asked to program in, but on white board I suddenly forgot.

I build complex integration and credit card processing, but on white board I couldn't remember how to even do proper syntax nothing prompt me.

As an employer I do like the white board testing; however, I am hiring a programmer I want to see their actual skills if they do the job. It's great if they can communicate, but I need to see them be able to solve problems.

share|improve this answer
    
Thanks for the input, seems, it's right about what I was thinking when asking the question -- one can really stuck in a whiteboard code not knowing if it is (already) correct, and having no means to "actually" check it. A tricky solution -- write a whiteboard test! ;) –  mlvljr May 18 '12 at 21:19

When a restaurant wants to hire a chef, the owner doesn't ask him to cook a "pot au feu" with a toothpick and a cap.

Don't ask a developer to code on a whiteboard in an interview.

share|improve this answer
2  
And when asked? –  mlvljr Nov 4 '10 at 13:05
    
During the interview –  user2567 Nov 4 '10 at 17:55

I've done that. At an interview I was asked to implement run-length encoding on the whiteboard, and while I short-cut some of the code (explaining what I was abbreviating) to fit the whiteboard I still came up with a collection of tests for this unit, and ran through one of them to validate my solution and show how the testing would help. I was offered that position so I assume the testing was helpful, or at worst not annoying.

share|improve this answer

I think you've made an incorrect assumption here. There's no way I'd expect a candidate writing up code on a whiteboard to be able to get every ';' perfectly in place. If you're interviewing at a place which does penalise you for that then I suggest they're not an organisation you want to work for :-).

share|improve this answer
1  
I failed one interview because, as they said, I hadn't written perfectly optimised code on the first pass on a pen-and-paper test (being from the get-it-working-with-unit-tests-then-optimise school). Then again, they had no testing framework in place, they just assumed they had coders who did it right first time! –  Julia Hayward Dec 12 at 11:38
    
@JuliaHayward - A Lucky escape for you by the sounds! Can't believe people still do that. –  Martijn Verburg Dec 12 at 13:03

I use this approach when taking tests for school. I first write the function, then off to the side I write a little table of inputs, outputs, and vars. I've caught a few stupid errors this way. Testing, even on-paper/whiteboard testing, is always better than not testing.

I disagree with freaking out over semicolons in a professional setting, though.

share|improve this answer

Paper or whiteboard tests are extremely ineffective. I remember once I had an interview where I had to look for errors in some code on paper. One of them was that the class inherited from an interface but was missing the implementation of a member. I knew this was likely to be one of the errors, I was looking for it and for whatever reason on the spot I just couldn't see it (although I did mention that I was looking for that as one of the issues).

As it happens, I still got that job, but it did make me think about what had happened. In a realistic scenario for that sort of thing I'm going to get squiggly lines the moment something's wrong (this is C# in Visual Studio) and the thing isn't going to compile. I never check for this in real life because it never happens (it is impossible) and hence I'm de-tuned from seeing this sort of thing. Missing semi-colons are an even more extreme example of this - totally unrealistic in the real world unless you're writing in notepad and e-mailing your code to someone else to compile!

If someone asks to use a whiteboard during an interview to support something they want to say then great, but I'd never do it the other way around.

share|improve this answer
2  
Your story seems to prove that your test was effective. Instead of generally asking "How do you review code?" they gave you some to review. You talked out loud and said something like "must make sure it implements everything" and even though you didn't happen to spot the missing one, you showed them that you actually know how to review code for errors, not just answer questions about it. You also probably didn't point out a bunch of non-errors that some folks might have, and perhaps you saw some other errors too. And then you got the job. That sounds effective to me, for everyone! –  Kate Gregory Nov 4 '10 at 16:33
2  
Also, missing semi colons keeps being dismissed as not a real negative. Consistently mistyping the syntax of your preferred language means you are a slower developer than someone who has internalized all that syntax. You are constantly going back and fixing stuff you forgot. There's a good chance you are thrown off your rhythm with the constant nagging from the IDE. In addition, the people who leave off all their semi colons at the whiteboard and don't notice when you prompt them are not at the same level as the good devs who once a week forget to type a semi colon in the IDE and then fix it. –  Kate Gregory Nov 4 '10 at 16:41
    
+1 it's ineffective. It prove absolutely nothing. I'm pretty sure a lot of people that fail the test are better than the average guy that pass it. –  user2567 Nov 4 '10 at 18:22
1  
@Kate - I get where you're coming from, but I disagree - especially as I now sit on the other side of the table. If someone is missing semi-colons regularly I want to see that in the IDE not in an artificial setting. It's like the keycode to my office - I can type in the number without thinking, ask me to write it down with 100% confidence and I'd be struggling. An interview is never going to be 100% realistic so I don't want to go out of my way to make it even less so. –  FinnNk Nov 4 '10 at 22:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.