Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
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:
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:
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:
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 am not sure, if this is the right forum. Recently, I was recommended for second round interview with Microsoft IT for business analyst position. I browsed through website for some information on responsibilities of a BA, questions I can expect in interview and so on. Didnt get any clue.
May I request you all, if anyone know can point me to the right place to search for ?
I really need your help.
This is realy a good article that include imaginery information in it.
Thanks for this
Rana Naveed Khalid
Thanks for all the excellent advice and pointers on whiteboarding .
The discussions revolving around white boarding is what brought me here.
I couldn't agree more with your statement -
" 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.".
The crux of any software development work is to understand the problem, think through it before attempting to write a SINGLE line of code.
I'm not sure about other devs. but at least at my end I find it a little nerve wracking(almost like deer and headlights) to white board with the pressure of an interviewer leaning over my shoulder.
Do you have any tips to get over this phobia and or how to keep your calm during white boarding ?
I'm interviewing for an SDE/T position soon. Any tips/ guidance will be much appreciated.
P.S. You webcast on type inference in LINQ was very insightful
A Joel On Software reader asked the other day for examples of recursive functions other than old chestnuts
Gosh - I was so wrapped up in The Apprentice that I didn’t have a chance to post on the in person
I think this is the post that you have all been waiting for! Yup, I finally got to it and now you are
Gosh - I was so wrapped up in The Apprentice that I didn’t have a chance to post on the in person interviews at Microsoft! Excuses, excuses, excuses.... I do have a good pointer for those that are interested in the SDE and SDE in Test positions
I think this is the post that you have all been waiting for! Yup, I finally got to it and now you are about to embark on the adventure of what a typical interview day is like at Microsoft. While these are our thoughts on what you need to do to be prepared,