Writing code on whiteboards is hard

I got an email from a reader in India recently asking me to talk a bit about thoughts on technical interviews. Here’s a rerun of my 2004 article on that subject. (Note that this was before I was on the C# team, so this has a very C++ flavor to it.)

Next time on FAIC I’ll post another rerun on the same topic.

I occasionally interview candidates for development positions on my team and other Visual Studio teams. Plenty of people have written plenty of web pages on interviewing at Microsoft, so I won’t rehash the whole story here. What I wanted to mention today was some words of advice for candidates for development positions. This is by no means complete — I want to concentrate on one important aspect of the interview.

Dev candidates: if you’ve done any reading at all, you know that most of your interviews will involve writing some code on a whiteboard. A word of advice: writing code on whiteboards is hard. Practice!

It’s hard in part because you don’t have IntelliSense or syntax colouring or any of the other tools at your disposal that you normally do when writing code. I know that, and I’ll take that into account. I don’t care if you write memset(&b, cb, 0x00) when you mean memset(&b, 0x00, cb) — I don’t remember that stuff either. I don’t care if you forget semis or make other syntactical gaffes. I’m not looking for people who can spit out syntactically perfect code at the drop of a hat; that’s not the point of the coding exercise at all. I’m trying to find out how you solve problems. Do you:

  • rush right in and start coding without thinking the problem through first?
  • find areas where the problem is ambiguous and clarify them, or do you make a bunch of assumptions?
  • break the problem down into pieces?
  • do the easy pieces, paint yourself into a corner, and attempt to handwave your way out of the situation, or work on the hard stuff first?
  • have any confidence that your solution is correct?
  • do anything to prove to yourself and me that it is correct?

It would be wise to make it easy for me to see that you’re a well-organized person with good problem solving skills. Leave lots of space — you might need to stick in some extra lines. Write slowly and clearly. Explain what you’re doing as you do it. If the code is clear, well-organized, legible, and at least vaguely syntactically correct, it will be a lot easier on both of us to tell whether the code is well designed and bug free. Walk through some simple test cases — don’t just dash down some code and say “yep, that’s correct!”

The vast majority of the coding problems that interviewers pose do not require any “aha!” insights or rocket-science algorithms. No one is going to ask you to implement a 4-5 Runge-Kutta differential equation solver. We’re going to ask you to implement a hash table or replace every instance of “foo” in a string with “bar”. Eric Carter [my then manager and co-author] has a copy of Schaum’s Programming with C++ in his office because that thing is a gold mine for interview questions. Got a technical interview coming up? Pick up a copy of any introductory programming text, pick a few problems at random, and solve them on a whiteboard. Heck, I’ll flip through it at random right now. Here are some sample problems taken from various places in the book:

  • implement a function which determines how many characters the string pointer must be incremented to point to the trailing null.
  • implement the less-than operator for a class representing rational numbers as (numerator / denominator) pairs of integers
  • implement a function that takes an array of integers and returns the maximum, minimum and average.
  • implement a template for a “stack” abstract data type
  • implement a program that shuffles an array into a random order

Any of those would be a highly typical coding question. And before you say “that’s easy!” about any of them, think about what’s missing from those problem statements before you write the code:

That string pointer: What encoding is it pointing to? 7-bit ASCII chars, UTF-8, UTF-16, some ANSI encoding? Are you going to ask the interviewer, or are you going to assume that you’re writing C code for some operating system that existed in the Before Time when there were no strings that contained Chinese characters? Hint: Microsoft writes very little C code targeting PDP-11 machines. Ditto for programs that never have to deal with non-Roman character sets.

That less-than operator: Do you have to handle nonreduced fractions like 2/4 ? Illegal fractions like 2/0? Can you assume anything about the size of the integers?

That array you’re shuffling: do we care if a hacker can predict the sequence? Do we need crypto-strength randomness, or reproducible pseudo-randomness? Is this for an online poker game for real money or a test case for a sort algorithm?

And so on. None of these problems is well-defined enough that I’d feel comfortable writing production quality code without at least some clarification.

Candidates often make the mistake of concentrating on the code, like the code exists in a vacuum for its own sake. That’s a very unrealistic assumption! Code not only has to be well engineered and correct, it has to be maintainable, testable, and solve a real customer problem. In your interview, when you’re done writing the code, think about:

  • how would a tester attack it? Is the design even testable?
  • does it handle stuff that hostile/buggy callers are going to throw at it? null pointers, large denominators, huge arrays?
  • does it work well with other technologies? that is, does it use the conventions of COM or ATL, or does it work against them?
  • is it correct, robust, maintainable, debuggable, portable, extensible?
  • how would you know whether this was the code the customer wanted or not?

Now, this is not to say that someone who automatically thinks char * when they hear “string” is an automatic no-hire. But I am a lot more inclined to believe that “experienced in COM programming” on your resume if you acknowledge the existence of BSTRs! Also, I recognize that fresh-out-of-school candidates often have very little experience with these sorts of “real world” considerations; I cut them some slack in those areas and concentrate on their raw intellectual horsepower, coding talent and long-term potential.

Finally, let me reiterate that technical interviews are hard, and even bright people screw up on them sometimes. Two teams no-hired me when I interviewed for full-time positions here! But that’s another story.

13 thoughts on “Writing code on whiteboards is hard

  1. One of the most logical behaviors in such situation is to pick the easiest case (e.g. TCHAR* or even char* in the first example case) in order to write the cleanest code. It’s a good behavior.
    If the algorithm actually requires thought, one might treat code as nothing more than a demonstration for the algorithm and maybe not even attempt to make it clean. That’s what I did on an entrance exam on programming. Granted, I wasn’t good at clean code anyway back then.
    Accounting for cases like integer overflows wouldn’t make sense to do unless it’s required.
    Why all that? Because it’s not real code, it’s a demonstration code! Just like you wouldn’t start with BSTR examples in a students book, you won’t write code with BSTR to interviewers.
    So, the point is: yours are wrong expectations for an interviewer to have. They rely heavily on one’s interviewing experience rather than pure programming competence. What I described above is how a programmer like myself who’s never been to such interviews would act, regardless of programming experience. And yes, he’ll just silently write the code and say “something like this”.

  2. Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1872

  3. GrayFace,

    You assume Eric is only looking for pure programming experience. What I got from this post is that Eric is also looking at how you go about solving problems.

    To take your example of accounting for overflows; how do you know it’s not required? Did you ask? Were you told? If you were not told, nor you asked for it, what makes you think overflow handling is not required? An OS developer will likely think you’re insane if you implicitly assume a BSOD is a proper response to an overflow.

    Just as cultural fit is an important part of the interview, so is getting a feel of how you go about solving problems.

    • But problem solving is an essential part of programming.
      I’d know what is required from the nature of the project, or by asking if it isn’t clear. In the real world that is.
      In an interview there’s no project and thus I’d assume no extra requirements. I’d try to stay domain-agnostic whenever possible. Just an algorithm, no domain-specific extra code. Who writes extra code on a whiteboard?

      • Ah, I see a flaw in my logic, because most often an interview is in fact for a specific project. In that case yes, the considerations are legitimate. Interviewers should make it clear anyway that the code should be done like it’s done for that project.

        • Interviewers sometimes leave out important requirements deliberately, precisely to see if the candidate will ask about them or merely make an assumption.

          As an interviewer, if a candidate proactively tells me about a reasonable assumption they are making, then I’m usually okay with it, because it indicates to me that they actually understood than an assumption was being made (and hence that it might not always be true). We might have a discussion about when that assumption is or isn’t reasonable, but so long as they haven’t circumvented the core of my question I’ll usually let them go with whatever they pick.

          On the other hand, if I candidate just plows forward and writes a bunch of code which makes unstated assumptions, I give them less benefit of the doubt. Why didn’t they ask beforehand? Did they even realize that they were making an assumption until I pointed it out?

          One mark of a stronger developer is that you understand the assumptions and tradeoffs you’re making, and that these explicitly come to mind both before and as you’re writing the code, not just in retrospect. Demonstrate that to the interviewer.

  4. Pingback: Dew Drop – June 2, 2015 (#2026) | Morning Dew

  5. “Two teams no-hired me when I interviewed for full-time positions here! But that’s another story.”

    That would be an interesting story! I’d love to read it.

  6. Pingback: 在白板上写代码是有难度的 - 腊八粥

  7. Pingback: 在白板上写代码是有难度的-紫金星程序员教程网

  8. In the interview, there is a time element, about 10 minutes, if the interview lasts an hour. This is because, there will be other questions to answer, other than this programming/design problem. So, limiting your thinking is OK. If anything, a good interviewer, if he expects good solid pseudo-code, should give you the main details. If not, then most of the time to write your code will will be spend discovering the details. If the candidate asks, what are the limitations, then, the interviewer should be knowledgeable enough to fill them in. After you’re done, you can think about the items in the last bullet list, if there is time, but, you should have spend your time in the up front part, asking the simple questions of what is expected and the final code.

  9. Pingback: 在白板上写代码是有难度的 - 我爱互联网我爱互联网

  10. I don’t see the huge divide between “programming” and “computing” that others see. Of course, the student programming that I see is all problem solving, not rote exercises. Students can fail at the programming in many different ways (poorly chosen data structures, poorly chosen program organization, poorly chosen algorithms, incorrect coding of algorithms, bad documentation, non-idiomatic use of the programming language, …). I see very high correlations between these different failure modes—I don’t have large enough samples to do factor analysis, but I suspect that I would see primarily one factor for programming skill, with a minor second factor for completeness of documentation. I doubt very much that I’d be able to associate one factor with “programming” and another with “computing”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s