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.

  • ... "these sorts of “real world“ considerations" ...

    Microsofts "real world" and everyone elses "real world" are completely different entities. Microsoft has different goals, different methods, and different considerations when designing software. To assume a candidate will just know what is important to Microsoft design because it is the correct thing to know is at best arrogant and at worst just plain wrong.

    I realize you want someone who can fit in to the Microsoft way, but the Microsoft way is something a talented candidate will be able to learn.
  • Are you an "industry" (several years experience) or "campus" (fresh out of college) candidate?

    Either way, I would not say that there are any _particular_ algorithms you should "brush up" on. You should have some facility with all the standard tools in the developer toolbox: recursion, tree traversal, hashing, sorting, pointer arithmetic, etc. It's unlikely that someone is going to say "what's the Shell Sort algorithm?" What's more likely is that someone will give you a problem that can be easily solved with one of those tools.

    For example, one of the problems I was given when I interviewed for FTE was to describe algorithms I might use to store a Scrabble dictionary optimized for rapid lookup. That's not a "standard" algorithm you can brush up on in a book, but if you have a good working knowledge of tools used to design algorithms, a bunch of ideas pop right out. (eg, sort the list by word length FIRST and then by alpha order. Since anagrams are important, maybe it would be sensible to store words based on their letters in alpha order, eg, list BADE as ABDE, list STOP, POTS, SPOT and OPTS under OPST, etc.)

    Come across as passionate, smart, gets things done. Be ready to talk through your past work in detail, and don't be afraid to give opinions on where it was badly designed and where it worked well. Ask questions (but don't try to take over the interview!) -- I am deliberately vague because I want candidates to show me that they can deal with ambiguity.

    And please don't try to bluff your way through a question if you really have no clue -- just say that you have no clue and try to get some clarity. We don't expect that everyone will be an expert in every technology, so ask if you don't understand something. I've had candidates try to convince me that they know what a "delegate" is, for example, and I can tell when you know and when you're guessing.

    And relax! Easier said than done, I know...
  • > Microsofts "real world" and everyone elses "real world" are completely different entities.

    Really? do the "real worlds" of other software companies not include testing, security, interoperability, correcness, robustness, performance, maintainability, debuggability, portability, extensibility and meeting customer needs?

    Because that's what I meant when I said "real world concerns". I learned about NONE of those when I was in school except for "correctness".

    Like I said, I am willing to hire people who don't know about those things -- smart people can learn them. I sure did. But I am obviously more impressed by a candidate who already realizes that just writing bug-free code is far, far from the last word in good software design.
  • >Really? do the "real worlds" of other software companies not include testing, security, interoperability, correcness, robustness, performance, maintainability, debuggability, portability, extensibility and meeting customer needs?

    actually, yes. sometimes, it's "just get the damn thing working and out the door so we don't lose the account." in the real world (the world where there are not infinite amounts of money) speed is sometimes the most "correct" attribute to have. sad, but in to todays world of rapidly failing tech companies, it is what rules the day.

    try telling the CEO of a mid-to-small sized company "i need to make this more robust for all cases" when millions of dollars and peoples jobs are at stake. my guess is you won't get the extra 2 weeks to make it so.

    you have some luxuries working at microsoft that many of us do not have. time and money being the biggest.
  • Actually, what you're describing is a skill that Program Manager interviews test for, much more so than dev interviews.

    If you think that Microsofties don't face schedule pressure and never have to make difficult tradeoffs amongst the eleven things I mentioned (and a few dozen others I didn't -- see my essay on changing lightbulbs for more!), think again!

    We make those same tradeoffs EVERY DAY, and in our case, the accounts represent billions of dollars and the software products are going to affect hundreds of millions of people. We take those tradeoffs very, very seriously because our customers take them very, very seriously.

    What you're describing is ANOTHER part of developing software in the real world, but that's the part that we delegate to PMs. PM interviews have all kinds of questions about how you deal with schedule pressures and limited budgets and whatnot.
  • David,

    In preperation for your interview make sure you can do all of the basic stuff, linked list, trees, DF search BF search etc.

    Then think about the boundary conditions, how do I copy a linked list, copy a linked list that is circular. Insert elements in sorted order in a circular linked list, reverse a list etc.

    Take in problem and practices it by making it harder take away space constraints. Do things in place. Also make sure you under stand the running time / complexity of the algorithm you create.

    The goal of the MS Dev interview is to make sure you can do the basic stuff then see what happens when you get a monkey wrench thrown into the problem. Think about limited memory issues and how to make your algorithm fit in a fixed amount of space.

    As allways write clean code and make sure you solve the problem before you start writing code. Explain the solution to the interviewer then walk through the solution as you are writing the code.

    If you have sloppy handwriting make sure you take the time to write neatly.

    Practice on your own before you get there. Look at any programming book and get on a white board or piece of paper and implement it. Good practice is to then take that code and type directly into an ediitor and see if it compiles. You will be surpised at the amount of mistakes you make.

    Good luck.
  • D,

    I see you mentioned moving from a PM position to a Dev position. Could you expand on the reasons behind this decision? I'll be starting as a SDE at MS in September and I thought about moving into a PM position later on.
    Regarding the interview process (I interviewed for two days...), whiteboard coding is bad enough but solving problems at lunch (which I had to do in the second day) while the interviewer is eating is even worse...OTOH, my impression was that interviewers are aware of the limitations of the interview process and they are looking more at the general approach of the problem (it's like judging a pianist, you can tell in the first five minutes if he/she can play or not).

  • Its quite unusual to be asked problem solving questions over lunch!

    In most interviews, the candidate does 90% of the talking, but at lunch obviously both people have to eat. I use the lunch interview as an opportunity for the candidate to ask _me_ questions.

    Congratulations on getting an offer!
  • Hi Eric,

    Well, the interviewer was "nice" and repeatedly invited me to eat, but the problem was on the paper sheet in front of my eyes all the time and I didn't know if he was testing my eagerness to solve it in the most "unusual" conditions or not. I was supposed to code it after returning to his office. I still don't remember what was the meal :) and I shudder to think what the waitress and people around us were thinking about me...

    I'm still interested to find out more about the PM <-> Dev migration issues.

    Thanks for the congrats :).

  • ph7:

    I moved from PM to dev because I wanted to be closer to the code. There are alot of cool things about the PM job. However if you enjoy coding you may be unhappy in a PM role. PM's work on writing the functional specs but every one participates in the spec (Dev, PM and test). PM is responsible for getting all the right stuff in the spec. Some people think that as a PM you get to design the spec then have people implement it (I thought that). However the PM is more of the facilitator around making things happen and making sure the spec is accurate.

    Either way you go long term (PM,Dev or test) I think you should really think about what you are passionate about. Do you go home after coding all day and start writing code one of your own projects? Or do you want to get away from code as soon as possible? Most PM... I shouldn't say most a lot of PM's don't want to be involved with code at all, espcially when you PM's who are working on more UI centric stuff.

    In going from PM to dev I still had to interview. I went through about 6 hours of interviews and wrote code on the whte board etc. I do see more people going from test or dev to PM. Very rarely do people go from PM to dev. I haven't seen anyone go from PM or dev to test.

    Hope this helps.
  • Hi Eric:

    Thank you for the insights on "coding on whiteboard".

    Only wish I had a way of reading these words at the time of my interview at MS :). I had an "off" interview after 5 people interviewed me in early April for a SDE position. My college recruiter said they would reconsider interviewing me next year for Full Time.

    You mentioned before that you got an internship after no-hire, which later extended to an full-time offer. Do you think it is feasible for me to apply for an internship now?

    Again, great post!

  • Hey Elaine,

    Thanks, that's a nice thing to say.

    Before I answer your question I want to clear up a misunderstanding. Sorry if I was unclear. The timeline was:

    * I was an intern for a total of twelve months in three four-month chunks separated by four month school terms.

    * When I was about to graduate, the VBA team extended me a job offer. They also encouraged me to interview elsewhere in the company. Interns are encouraged to look around and figure out where is best for them.

    * I did so, and the two other teams I interviewed with no-hired me. I also interviewed with some other companies, but eventually accepted the VBA team's offer.

    But anyway, your question is "is it feasible to be an intern after a no-hire for FT?"

    Beats the heck out of me. I'm the wrong person to ask. Try Gretchen and Zoe, they're the experts.
  • Hi David:

    If you arrive the night before the interview day, please treat yourself a decent dinner and have a good night of sleep, esp. when you come from east coast with the time difference. I woke up at 2:30am because I felt hungry (yeah, i don't believe it too :). Next morning, I had two cups of coffee and they help sustain the interview day until late in the afternoon. However, by the time I saw the dev lead, I rushed onto the whiteboard after giving a problem. I have no idea why I did it and it is not me.

    And try not to get too excited or nervous, make yourself comfortable and remember the only one to compete against is yourself. What's more, MS wants the "true" you. So, just be yourself :)

    Best luck to you!

  • Gah,

    I have an interview at microsoft in a few days and this post is alternatively stressing me out and pumping me up.

    Thanks for all the information everyone!
Page 5 of 6 (87 items) «23456