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 ?"

  • 13
    Quite reasonable IMHO (and would have prevented some pretty bad hires at my former employer, if only it were implemented). Nov 11, 2011 at 9:26
  • 3
    It is a really depressing thing to do from the interviewer perspective. How can people who claim 5 years programming experience not have these basic skills? and 90% do not. (thats 90% after weeding out 70% of CV's immediately, and a 70% failure rate at telephone interview) Nov 11, 2011 at 9:49
  • 18
    We're not looking for perfect syntax. makes it reasonable, in fact I'd say recommended! It is unreasonable to criticise syntax errors on whiteboard coding.
    – Qwerky
    Nov 11, 2011 at 10:11
  • 16
    also don't expect perfect handwriting. Whiteboard writing is a skill most people don't have, and most programmers in my experience have atrocious handwriting to put it mildly, writing vertically only makes that worse.
    – jwenting
    Nov 11, 2011 at 10:58
  • 3
    Appropriate, yes. Effective, no. The one weak developer I've personally hired did brilliantly at a whiteboard.
    – pdr
    Nov 11, 2011 at 21:18

13 Answers 13


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.

  • 1
    thanks for the feedback ptolemy. much appreciated. you're answer describe exactly what i'm looking for as well as how I'd approach helping the candidate through the problems. But as you also pointed out, I'm flabbergasted by the number of people applying for 5+ year roles who can't do this. Nov 11, 2011 at 9:34
  • 1
    The biggest danger in this, is that frustration sets in, and you offer a job to someone who has failed the programming task but did well on the other apsects of interview like a technical test. The reality is, these candidates have read a book and have a good memory. Are you recuiting people to read books? or to write programs? Nov 11, 2011 at 9:38
  • @EoinCampbell, if communication skills are important to you, then this is entirely appropriate.
    – user1249
    Nov 11, 2011 at 21:10
  • 1
    so, as a candidate, you make a mistake, I then a little later (not straight away) bring that mistake to your attention. You will feel under pressure at that point. This is a key part of the interview seeing how do you respond? Can you cope with the pressure of a typo at an interview? If you melt under that pressure, what are you going to do when we as a team are under pressure to deliver software to a deadline? Feb 21, 2014 at 10:29
  • 1
    I've used whiteboard coding, the positive part is that it finds really good junior programers. The negative of whiteboard coding is the high failure rate, but those people aren't very good to start with. I've asked people to write as little as one line of code on the board and still had very high failure rates. On the other side I have been asked whiteboard questions as an interviewee and I've always found the questions reasonable. I much prefer whiteboard coding to listing off peoples favorite algorithms for specific problems. Jan 13, 2015 at 17:23

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.

  • I deliberately do not use a computer in interviews because of the intelisense effect. An inexperienced candidate programs by pressing the . and selecting something from the list. A whiteboard makes this very obvious... Nov 11, 2011 at 12:13
  • 5
    @Ptolemy: Do really think so? For a typical whiteboard-exercise like "program a depth-first search through a tree", what use would Intellisense be?
    – nikie
    Nov 11, 2011 at 13:02
  • 2
    Whiteboards/papers don't crash, and everyone knows how to write on them. If you give me IDLE to solve a problem I'm going to assume you're an idiot, and if you give me Eclipse I'm going to spend half my time fighting the default keybindings.
    – user23679
    Nov 11, 2011 at 13:38
  • 7
    Intellisense (and other IDEs' autocomplete features, too, I'm sure) can be turned off. Or you can give them Notepad (or a nicer alternative such as Notepad++ which does syntax highlighting but has no autocompletion or the like). Sure, it can crash, but realistically: how many showstopper bugs have you encountered in Notepad?
    – user
    Nov 11, 2011 at 15:39
  • 4
    Even if it's just notepad.exe it's so much easier to work with than paper or a whiteboard. You can insert or delete lines, which is a huge pain on physical media. Mar 22, 2013 at 10:14

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.

  • 6
    If part of your recruitment process is to offer a standard fixed term contract for 3 months, how many people would really resign from a perm role to take up your offer? Nov 11, 2011 at 12:06
  • 1
    I meant last in the sense that it was the last item on my list. I mix up the order of things in the interview depending on how the conversation part has progressed and where I think their strengths and weaknesses are. As for offering them a short term contract... that's just not realistic in a real world small company. I don't have the time/resources to be taking 3 month punt-risks on people who might not work out and as Ptolemy pointed out, I doubt the candidates would be too keen either. Nov 11, 2011 at 14:45
  • "The greater share of the person's brain is busy constantly inspecting how they're coming off -- only few can hold the nerves." I always felt like this is important to note, especially with some new folks in or coming out of college. I know I was a wreck in my first few interviews, worrying about that to the point that I messed up some of the easiest questions just cause I was so nervous. Granted, there's not much you can do. All I could do was just move onto the next interview, eventually becoming comfortable with the process.
    – The Jug
    Nov 11, 2011 at 15:45
  • 1
    @TheJug completely agree and we'll be alot gentler with Juniors & Grads to make sure they're not overwhelmed by the process but we've had senior (7-8 yrs exp) devs struggling with this. Nov 11, 2011 at 16:27
  • 1
    "Hire them for a very tiny (but realistic) project..." - do you suggest you should "hire" e.g. three of the candidates who applied for a position, even if you only plan to keep one? This seems very unfair to me! It probably wouldn't improve team spirit, either.
    – nikie
    Nov 11, 2011 at 18:23

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.

  • 7
    I don't know that guy, because he wasn't hired. Nov 12, 2011 at 15:52
  • 5
    @kevincline to the company's detriment, unless you earn money by having people hold their nerves.
    – JayPea
    May 4, 2013 at 0:16
  • 1
    @JayPea: how do I know a person is brilliant coder if I can't seem them code? The only alternative would be a recommendation from someone already on staff. Everyone loves to hire on trusted recommendations, but that is a pretty small group. May 6, 2013 at 15:24
  • 1
    @kevincline Read my answer, I'm not saying you shouldn't do whiteboard coding at developer interview. May 6, 2013 at 20:47
  • @JayPea I'm pretty sure that having employees who don't get nervous in high-stress situations is an important factor in many companies' financial success. Dec 4, 2014 at 18:46

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.

  • 1
    Whiteboards are immutable? You just wipe something off and rewrite it on a whim, that's what makes them useful, especially teaching. You must live in an alternate universe. Dec 4, 2014 at 23:52
  • Maybe immutable is the wrong word (I took it from medium.com/dima-korolev/… - who thinks it's an advantage). Still, compared to an editor it's hard to add something you haven't left space for.
    – iGEL
    Dec 5, 2014 at 10:45

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)

  • well it's more than communication. they need to be able to comm, sure, but they also need to be able to tell me their solution to the simple problem. Nov 11, 2011 at 14:43

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.

  • "it should already have been established/determined that the interviewee can program" - how? Either you have a pre-interview, in which case the OP's question becomes whether whiteboard coding is appropriate in a pre-interview, or you effectively take the candidate's word for it, which is inviting disaster. Recruiters and CVs can (and do) lie, blogs and github repos can be plagiarised. Jan 13, 2015 at 13:53
  • @JuliaHayward: Establishing a candidate's basic coding abilities in a pre-interview is a different thing. You don't actually have to invite somebody on site to do that. You can send them a small problem that they can solve. Possibly discuss that solution (or github code) in person. Most imporantly: It's highly unlikely you will find a candidate able to gracefully master the type of problem I suggest, while not being able to solve fizzbuzz type problems. The interview should be used to determine how able the candidate is to deal with the complexity typical of real world problems.
    – back2dos
    Jan 13, 2015 at 15:25
  • You may not have to have someone on site, but at least you should be on the phone to the candidate talking through their coding exercise, whatever you use. Just handing out a question and waiting for a zip file to be sent in still has all the risks of impersonation; as an extreme example I did the test for FooCorp one time, then just out of interest googled "FooCorp coding test" afterwards - and found someone had published a pretty good solution. Jan 13, 2015 at 16:04
  • @JuliaHayward: If you give every applicant the same problem, then of course the response becomes google-able. Not surprising, is it? But again, my answer remains: do not do whiteboard coding on fizzbuzz level in an interview. It just shows that you didn't bother preparing a good and interesting problem. As you have said yourself, there are ways to establish basic programming abilities way before you invite the candidates to your whiteboard.
    – back2dos
    Jan 13, 2015 at 23:37

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.

  • is this only your opinion or you can back it up somehow?
    – gnat
    Feb 21, 2014 at 5:40
  • 2
    @gnat I'm just posing a question. The latter half of the answer is my opinion, yes, but that should be pretty clear by the language used. Furthermore, the question itself starts off by acknowledging that it's subjective, and specifically requests opinions on the matter. I don't think the downvote was warranted.
    – Kevin C.
    Feb 21, 2014 at 6:02
  • @Kevin C. I think that regardless of your wording, you are making a very good point here. Whiteboard coding is different from computer coding. Is this an opinion? Certainly not, as long as whiteboards are unable to run code. Jan 13, 2015 at 21:09

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.


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.


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.


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.


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.

  • 1
    "Mostly or all interviewers do this thing" it's pretty rare IMO. Nov 11, 2011 at 9:11
  • I guess everyone does that. It's rare that they present with a PC or a laptop just to check whether you solve a particular coding problem. But maybe, things are different in ur place. If you want i can edit this thing in the answer ?? Nov 11, 2011 at 9:14
  • see i'd agree it's pretty rare... I've held 4 jobs in the last 9 years and never been asked to write code on paper/wb. Any coding has been at a IDE. which is why I'm wondering is it inappropriate. I'd expect a dev to be able to bang out "Reverse a string" code in a couple of minutes at most without IDE/Intellisense assistance. Nov 11, 2011 at 9:16
  • I have made the edit based on your experience. At two interviews i had been too, they gave me a pen and paper to write how to print a Fibonacci series and algorithm for mergeshort. So, i thought mostly things go in this way :-) Nov 11, 2011 at 9:20
  • Should point out I've never had to write code at a computer; I've had to write code on paper twice (both when I was a junior) and I had to draw an architecture diagram on a whiteboard once. That's out of around 20 interviews... Nov 11, 2011 at 9:22

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