Writing Code On Whiteboards Is Hard

Writing Code On Whiteboards Is Hard

  • Comments 87

Work has been crazy lately and I haven't had much time to work on SimpleScript.  It's a lot of work starting from scratch! Right now I'm writing a templatized hash table for the binders and other lookup tables.  I haven't written templatized C++ for a loooong time and its slow going.  I hope to have the named item logic done over the weekend, so that I can explain how the module system works next week.

Until then, here's an article I wrote a while back on interviewing that I never got around to putting up on the blog before now.

Writing Code On Whiteboards Is Hard

As I've mentioned before,  I occasionally interview candidates for development positions on my team and occasionally 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 people 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 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 method 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 function that takes an array of integers and returns the maximum, minimum and average.
  • implement a template for generating stack classes
  • 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 targetting 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.

  • I don't really agree with whiteboard coding. It's the most unnatural act you can ask of a developer. What we do at our company is send out some programming problems testing the developers bug fixing skills and also their coding skills (building a feature from scratch). We want them to have access to the internet, intellisense, books etc... Then we review the code before they even set foot in the door;if we like what we see we invite them for an interview to discuss their test.
  • Re: specific advice: I'm sure that I'll write more blogs on interviewing; the coding question is just one part of the interview. Also, you should read Gretchen and Zoe's blog, as they will talk about the interview process quite a bit.

    Re: unnatural act -- I disagree; I write code on whiteboards all the time when I am trying to figure out a particularly tricky algorithm. Pseudocode mostly, to be sure.

    If you have an approach that works for you, more power to you. Your approach sounds reasonable.

    The point of my blog entry was not really to debate the merits of the technique but rather to inform people that you WILL have to write code on whiteboards if you interview with me, so be prepared!
  • I never code on whiteboards or on paper. All the times I've needed to flesh out something, I'll open up metapad and start typing. Coding on a whiteboard seriously affects the way I program because I don't do things linearly. I often add stuff to the beginning and end of a block or rearange lines and I make heavy use of cut and paste. And after I'm done I'll usually clean the code up some more.

    What would you say to a candidate that brought a laptop or paper and refused to do it on a whiteboard?
  • I don't know what I'd do, to tell the truth. If it ever happens, I'll report back. My gut feeling is that generally speaking, such a candidate would not do well at Microsoft and hence would be a no hire. However, reasoning from the general to the specific is not a good idea when interviewing -- I'd have to actually see the candidate in action.

    But the point of the exercise, as I've mentioned several times now, is not to get working code out of the candidate. It's to see how the candidate thinks on their feet.

    Many devs seem to have this crazy idea that its writing the code that's the hard part. Writing code is easy; knowing what code to write to solve a customer problem is hard.
  • >You're hiring a juggler for your kid's birthday party. I show up for an interview.

    Someone has read Peopleware!
  • You're the second person to mention that to me.

    No, I've never read "Peopleware". Why, do they use this analogy as well?

    I used this analogy because (like many cs geeks!) I'm a decent amateur juggler. It struck me as whimsical comparison to make.

    I also considered making an analogy to piano playing, but when I remembered that ridiculous thing about Steven Mills making a point of there being no apostrophe in "Mills Mess" I couldn't resist.
  • I actually find writing on the whiteboard or on a piece of paper clarifies and simplifies my thought process regarding the problem at hand.

    I'll usually get a spec and start writing code in my favorite(or not!) IDE only to have to come back to my college-ruled notepad or walk into an empty room with a whiteboard after realizing that the problem is more complex than I had originally thought and I had been going at it from the wrong point of view with wrong assumptions(aha!). Sometimes I realize this early before I get too deep into the spaghetti and have to scrap the whole thing and start anew, sometimes I don't. It's a shame but most of my projects are quite small in nature so it doesn't happen often. In any case...

    I do find that when facing a piece of blank paper or a whiteboard, my mind clears up and the distractions - google, so many blogs to read including this one, newsgroups, the dude next to me, etc. - disappear and I can focus on the problem at hand. And something that is not easily done on computer is possible: drawing freehand diagrams. Visio is cool and all but it still cannot compare to the power of freehand drawing that a piece of paper or a whiteboard facilitates. Besides, I've recently realized that I am a very visually-oriented guy. I tend to understand things better when those things are visually(graphically) presented rather than in textual format. I wish there were a visual language - no, not Visual Basic, no no -, that truly lets a person "code" with drawings. I can dream, can't I? A picture paints a thousand words they say...
  • Oh yeah, I hate it when I get asked algorithm/data structure questions - basically standard CS type questions. I solve a lot of business problems daily but almost never have to write my sorting routines or hash algorithms, string functions, etc. I'm not a computer scientist and I don't pretend to be one. If you tell me the algorithms in words, I can turn them into codes :) Unless the job is regarding writing libraries for things like that, I would stay away from those. There has got to be a better way to measure the candidate's ability...
  • > There has got to be a better way to measure the candidate's ability...

    I'm not following your point.

    If what you're saying is that my interview criteria is bad because we'd no-hire you, I respectfully disagree. I'm sure you're very good at your job, and a smart guy, but we absolutely positively must hire people who can build algorithms without being told the steps. That's what we do every day!

    Let me pick two random examples from last week.

    1) Consider an object model that consists of a block of text, and a collection of subranges of that block. Subranges may overlap in any way. There can be zero-length subranges. A zero-length subrange starting at character 3 is different than one starting at character 5. Design and implement an algorithm which takes a particular subrange and changes its text to any arbitrary value, including empty, WITHOUT also changing the text of overlapping subranges.

    2) Consider a set of n arbitrary nonempty unique Unicode strings. Create a new set, such that there is a one-to-one mapping between the two sets, and such that (a) every member of the new set is a legal identifier in C#, and (b) every member is unique, and (c) the mapping "feels right" to users, ie, you can't map "Hello Dolly" to "ArgleBargle1234565" without a really good reason.

    These are not particularly tricky problems, but they're tricky enough that for both of them we did extensive whiteboarding of the algorithms both before and after we implemented them.

    Candidates who can't do that for simple, standard problems based on well-known, well-studied algorithms certainly won't be able to come up with new algorithms and justify their correctness.

    (The first problem is data bound bookmarks in Word, the second is view class generation on arbitrary documents.)
  • I currently work for MS and recently went from a PM role to a Dev role. The first interview loop I had I was asked several fairly easy problems to solve on the white board. Unfortunately I did not practice writing code on the white board and I had not brushed up on my algorithms. I got a no hire. However it made me realize where my weaknesses were. I then spent 2 months preparing and I was able to get an SDE position on another team. I also thought white board coding was kind of silly but it really makes you a better developer to sit down and write out the code with out the compiler and editor and all of the fancy tools. There is a very good reason for writing code on the white board and I fully believe in it now.
  • I suppose I have a bit of bias on this one, because I did not have true CS education, so if you ask me crazy algo questions, I will in turn, look at you like you are crazy. I have tried to distill my questions down to a couple seemingly difficult problems, that have simple answers if the person really thinks about the problem.
    1) Implement a method to generate the fibinacci sequence until a number greater than 10000 is generated.
    2) Reverse the tokens of a string in C.
    3) Reverse the tokens of a string in Java.
    4) Implement merge sort in Java.

    You can see that these are not hard, but require you to have good coding skill, good library knowledge and that you can get something done. I don't work on the linux kernel, so I don't care if you are the next Alan Cox. I want someone who can write working code, work within a team and admit when they cannot solve a problem.
  • I believe the disconnect here, is that many of us are your traditional Business Application Developer (grab some data from a data store and render it to a user) while Eric Lippert is your traditional White Labcoat Computer Scientist Widget Builder. The skill sets between the two disciplines do not necessarily overlap.
  • I interviewed @ MS and it was not good on my part. I screwed the whole thing up because I was too nervous. I couldn't remember anything when I was up at the white board! Oh well, at least I made it out there...
  • Brian,

    I think you are right about IT developers vs. developers at software companies. The problem is that most IT developers started as something other than computer science types. Most probably fell into IT development and never learned basic algorithm design, just enough skill to get the job done. Because just getting it done is all that IT shops care about. This is why the outsourcing movement is getting so bad. Business execs see that IT devs just get the job done and attempt to outsource IT. Finally to my point. Most of the places where IT is getting outsoureced to are countries that have a lot of comp sci folks, and they have just a big disconnect going from comp sci to building real world solutions. IT devs reallly need to focus on knowing what the business rules are where MS devs don't have business rules to deal with we are focused more on creating generic products and tools that others can use.
  • I am interviewing at MS for an SDE position in a couple of weeks and you have all made me sufficiently paranoid.

    For those who have gone through the ringer, what should I be looking at to prepare for my interview? From what I can gather reading this, I should at least brush up on algorithms (what particular algorithms? sorting algorithms?)

    As far as whiteboard coding, I would never take it as an insult and walk out in a huff, and I would never hire anyone that did. From my experience, a brilliant but arrogant diva is the worst type of co-worker to have.
Page 4 of 6 (87 items) «23456