Writing Code On Whiteboards Is Hard

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.

Comments (87)

  1. Ian Hanschen says:

    I got a no-hire on shell…but I got an offer from the client group and I really wanted to work on the window manager bits anyway. I didn’t practice the whiteboarding at all(my whiteboard here is usually just doodles or diagrams), and I had a rough time at it..Chris Anderson was really forgiving of the fact that I started on the right side and then continued the same function on the left side of the board. Writing code on a white-board is definately something worth practice.

  2. Wes says:

    Nice post thanks for sharing your ideas.

  3. Dan Shappir says:

    I don’t work for MS nor have I interviewed there, but I have interviewed and been interviewed at other places. Here are my 2 cents:

    1. Make sure you understand exactly what you are asked to do – ask questions if you need to.

    2. Don’t be a showoff, do what you are asked to do

    3. Ask if you can choose the language. Ask if you can use pseudo-code.

    4. Write clearly (don’t write cursive)

    5. It’s OK to stop and think

    An aside: any particular reason you can’t use hash_map for your templatized hash table?

  4. Eric Lippert says:

    Re: tips:

    Good tips.

    Re: hash_map

    I’ve been going back and forth between using hash_map and rolling my own. The former is easier, the latter is perhaps more interesting from a pedagogic point of view.

    In looking at the original script engine code, there are lots of places where we needed something goofy — for instance, JScript name tables are basically hash tables but they use a move-to-front-on-access algorithm to improve performance.

    Given that I’m going for clarity and not perf, I’m starting to lean back towards the STL implementation…

  5. I remember an interview at ObjectSpace (now Recursion Software) years ago and being asked to write code on a whiteboard. It’s the one and only time in over twenty years that I’ve ever been asked to "code-on-demand" and I point-blank refused. It just isn’t a realistic test of people’s abilities, IMO. I was quite happy to whiteboard a UML model (of the game of Monopoly, as I recall) but coding isn’t a "spectator sport" in my book.

    The same interview ended with them sitting me down in a room on my own with a spec and a Windows PC and Visual C++ and being told to "code what the spec says". That was just about the final straw for me. I wrestled with VC++ for five minutes (I had never used it and rarely used Windows at all – and that was not the environment I would have been using in the job they wanted me for anyway as it wasn’t a programming role) and decided it was time to end the interview. I walked out and caught my plane home (to England).

    They’d flown me out for the interview and after I "stormed out in disgust" they called me up and apologized and asked if they could persuade me to take the job anyway(!). I’m very glad that no company since has repeated that particular interview process…

  6. Dan Shappir says:

    Don’t knock STL performance. With a modern optimizing compiler like VC++ youโ€™d be hard pressed to beat it. You may be able to hand-craft a container that is particularly suited for the task at hand, but even then the difference would probably be marginal.

    Given your JScript example, today I’d probably use hash_map (or the less efficient but more portable map) and also maintain a direct pointer to the last item accessed. I’ve actually used such a structure in a recent project:

    We have an application that for historical reasons stores its data in a text file using the ini format. The ini file was getting to be very big and the load time was becoming excessive. I rewrote the loading + parsing code (reads the data into a hash of hashes, and can also write the data back) using STL. The load and parse time for a 12MB ini file (more than 10000 sections) was 1.2 second (2.4GHz Pentium 4 with 500MB RAM using Windows XP).

  7. Dan Shappir says:

    > coding isn’t a "spectator sport" in my book

    Actually I agree. I’ve given people tests where they have sat alone in a room and wrote some code on paper. I’ve never had an interviewee code on a whiteboard in front of me. I have had them use a whiteboard to explain the structure of systems they have designed in the past.

    OTOH isn’t this what pair programming is all about ๐Ÿ˜‰

  8. Eric Lippert says:

    Re: STL maps — the other remaining problem that I’m going to have to look at is the threading model. The script engines use a pretty goofy threading model, but I think for most cases we can probably ensure a single-writer-multiple-reader model.

    Re: Spectator sport: Sure, coding isn’t usually a spectator sport, but DESIGN sure is, and that’s really what I’m after.

    Also, you might be surprised at how overstated some people’s resumes are. I once had a candidate who described themselves as "nine out of ten" C++ programmer who could not write the line of code that determined the absolute difference between two floats. I had a candidate with a solid seven years of programming experience who had only a vague idea of what "recursion" was.

  9. mike says:

    Freaky — Chris Sells says virtually the exact same thing about whiteboard coding in his Channel 9 tour of MSDN: "The board is a terrible place to write code … there’s no syntax completion, there’s no coloring, there’s no IntelliSense …"


  10. Nicholas Allen says:

    It’s probably not necessary to roll-yer-own map classes for the example engine here. Code for structure walking and garbage collection is much simpler when you don’t have to worry about maintaining complex invariants in the data structures. But it would be nice to have some discussion on the data structure design tradeoffs for prototype/slot happy languages like JScript. A lot of the in-depth looks at language implementation hit static scoped, static typed, or compiled languages which is apples and oranges to a project like this.

    Dan, not to knock STL here, but there’s engine code that gets called millions of times per second and it’s important to understand what the compiler is spitting out. I get tired head staring at a pile of maps and iters and templates and trying to figure out if it’s going to spill my registers. I guess I just don’t eat C++ for breakfast.

  11. I’ve been contract programming for many years now and have never been asked to code on a whiteboard during an interview. I agree with the "spectator sport" comment. If asked, I suspect I’d do like Sean and walk out. With a few well chosen questions, you can usually determine a programmers aptitude without resorting to a whiteboard code review.

  12. Writing Code On Whiteboards Is Hard Some Great Interview Ideas from Eric Lippert.

  13. Eric Lippert says:

    > With a few well chosen questions, you can usually determine a programmers aptitude without resorting to a whiteboard code review.


    You’re hiring a juggler for your kid’s birthday party. I show up for an interview.

    Me: "Hi, I’m a juggler."

    You: "Can you juggle?"

    Me: "Yep."

    You: "Three objects? Four?"

    Me: "Yep."

    You: "Five?"

    Me: "I can do a five beanbag multiplexing trick, but not five ball cascade."

    You: "Clubs? Torches?"

    Me: "Yep."

    You: "What is ‘Mills Mess’?"

    Me: "A three ball pattern in which one ball does the forward cascade pattern, one ball does reverse cascade, and one ball does underarm chops, while at the same time crossing and uncrossing the arms. The arms begin crossed. The corresponding pattern without the arm crossings is relatively easy."

    You: "Does ‘Mills Mess’ have an apostrophe?"

    Me: "No. Grammatically, ‘Mills’ is appositive, not genetive. It’s ‘The Lincoln Memorial’, not ‘Lincoln’s Memorial’. Same deal with the Mills Mess."

    You: "Can you do The Mills Mess?"

    Me: "With balls, yes. Clubs, no."

    You: "Who is widely considered to be the greatest juggler in history?"

    Me: "Most people would say Enrico Rastelli, 1896-1931 — who could do eight plates or ten balls or fourteen rings — but I’m personally more fond of WC Fields. Less technical brilliance, more comedic brilliance."

    You: "Super, sounds good. One more thing — here are three rubber balls. Could you do a three ball full shower pattern for me?"

    Me: "In all my years I’ve never been asked to actually juggle at an interview! And such a simple trick! How insulting! I’m out of here!"


    OK, juggling IS a spectator sport, but I hope my point is taken. I don’t know any "well chosen questions" that tell me whether someone can juggle or not.

    Similarly, I don’t know what these magical "well chosen questions" are that tell me whether a person can actually write code; I’d love to hear them.

  14. Blake Winton says:

    It’s interesting how my perspective on whiteboard coding, and programming tests changed when I switched from interviewee to interviewer. I’m sure that the programming test we currently use eliminates some people who are great programmers, but don’t test well. On the other hand, it eliminates far more people who talk a good game, but can’t code their way out of a paper bag, and we’re willing to give up the rare occurance of the former to save a lot of wasted time dealing with the latter.

    On the other hand, Eric, given the state of IDEs these days, do you really care if someone can write code, or are you more interested in their design and problem solving skills? I don’t think anyone would particularly object to designing something on a whiteboard, or to explaining a previous design they worked on, and the rationales behind it (as far as their NDAs would allow, of course).

  15. Eric Lippert says:

    Yes, I do care, very much whether they can write code, but I am also very interested in problem solving skills.

    When I interview experienced "industry" candidates I usually ask a very design-heavy question. The question tests ability to deal with ambiguous situations, make tradeoffs, understand customer needs, deal with existing badly designed infrastructure by finding bugs and working around design flaws. Often we don’t write a single line of code, sometimes we do, but it is pretty high-level.

    I give fresh-out-of-college "campus" candidates a simple mathematical problem that can be solved in two or three lines of C. The question tests attention to detail, ability to reason about the purpose of code rather than just what it does, ability to come up with test cases, etc.

    However, many of my colleagues do not break it down like that, and ask everyone to do a coding problem.

  16. Dan Shappir says:

    > not to knock STL here, but there’s engine code that gets called millions of times per second and it’s important to understand what the compiler is spitting out. I get tired head staring at a pile of maps and iters and templates and trying to figure out if it’s going to spill my registers.

    Way back in 95 I worked as a developer at a small company doing multi-user games. For a Doom-like shooter I developed the 3D rendering engine (over DirectX 1.0). I coded in C, then I had the compiler spit out the assembly code for the internal rendering loop, then I hand-optimized it. The result was a significant performance improvement. Fortunately, thanks to Intel, those days are gone.

    The operation of modern CPUs is so complex that it’s practically impossible to hand-craft optimal assembly code. Instead we must learn to trust our compilers’ optimizers. Assuming you are using a good compiler, such as VC7, the C++/STL combo becomes a very good choice.

    When Stepanov developed STL he realized that C++ programmers would only use it if the code generated was as efficient as the code they would write themselves. In fact, in most cases it’s more efficient and more correct as STL developers are usually very smart people. Using techniques such as template specialization and massive inlining allows the compiler to optimize the code significantly for the particular task at hand.

    For example, STL makes it straightforward to utilize custom memory allocators. Will Eric take the time to add this capability to his templatized hash table?

    All this is not to say that STL is not without it’s limitations:

    1. You must gork the STL way in order to make good use of it.

    2. Since STL make extensive utilization of templates, you need a modern C++ compiler to take full use of it. The STL implementation that came with VC6 for example was limited because of this.

    3. Compiler errors in code that uses STL can be difficult to track down. But this is true for all templatized code.

    4. Debuggers are still mostly ignorant of STL containers, which means that viewing their content can be a pain.

    In addition, you must enable optimizations to get high performance from STL. The ini parsing code I mentioned above that ran in 1.2 seconds, took 2-3 minutes when compiled for debugging.

  17. Eric Lippert says:

    Well, there’s two ways to solve a particular problem — you can solve the particular problem, or you can solve the general problem and then apply that solution to the particular problem.

    As for custom memory allocators — if I roll my own, I’m going to solve my particular problem, not the general problem! I’ll add custom allocators if I need to, but I don’t think I will.

  18. Dan Shappir says:

    > Well, there’s two ways to solve a particular problem — you can solve the particular problem, or you can solve the general problem and then apply that solution to the particular problem.

    STL, now a part of the C++ standard, is obviously a general purpose tool. The beauty of it is that, thanks to generics and specialization, it’s often as efficient as custom code created for a particular purpose.

    For more information on the techniques that make this possible in C++, I highly recommend reading Modern C++ Design by Anderi Alexandrescu.

  19. Mark Schmidt says:

    Wonderful insight. I too have gone the 2 team no-hire route so hopefully the 3rd time is the charm. Do you think you did anything different the 3rd time that you think may have gotten you hired? The 2nd time I interviewed, the recruiter said everyone was impressed but she doesn’t know why they said "no" (it was for Windows core team or whatever you call it). I’ll definately put into practice the things you mention here. Thanks.

    P.S. Want my resume? ๐Ÿ™‚

  20. Eric Lippert says:

    > Do you think you did anything different the 3rd time that you think may have gotten you hired?

    There was no third time. I was extended an offer on the VBA team on the strength of twelve months of internships. Former interns are encouraged to look around, so I interviewed with the Blackbird team (bonus points to anyone who remembers that thing!) and the SQL Server team; both no-hired me.

    > Want my resume? ๐Ÿ™‚

    All I’d do with it is send it to the recruiting department, so you’d be better off just doing that yourself.

  21. Eric Lippert says:

    > everyone was impressed but she doesn’t know why they said "no"

    Sometimes people are good candidates overall but bad fits for a specific team.

  22. NotSelected says:

    When Microsoft flew me out there for an interview I was all prepared to write code on the white board. But when I was asked to write the QuickSort algorithm, that kill all my chances of getting the position. :-/ Not bitter about that, I swear.

  23. Eric Lippert says:

    Why do you think that killed your chances?

  24. mnrp says:

    Have you ever considered using a computer for technical interview coding questions? If you expect the candidate to write c# code, for instance, you could have a machine with VS (and NUnit?) up and running with and a projector. Why not use the tools that are good for coding to test coding ability? I think the way a developer interacts with the dev environment can tell you a lot about how he or she works. Is this person able to use the tools available to solve problems?

    Maybe offer both the white board AND the computer to solve the problem. Now you get to see where the person starts, at what point he or she moves to code or to the board, how and when intellisense and help are used, what questions are best answered on the board or in code, etc.

  25. I am a recent grad and in school we could ONLY use the paper approach! During tests and such we had to have 100% syntax perfect, 100% correct solution.

    I remember one of my MFC exams; we were forced to write a 100% serializable class and GUI system. (The rest of the test was Linux GUI coding).

    Doing this on the white board for new grads will most likely be easier than for long time coders (Just an assumption). Although it is true, a lot of the real world problems are not tackled in school.

    My only downfall is… I live very far away from Microsoftโ€™s HQ. I live in Toronto, most of the Microsoft recruiters probably do not even look at my resume =(

  26. Eric Lippert says:

    Dude, first of all, I grew up in Waterloo, just down highway 401 from you. Second, I have coworkers from Jordan, Bulgaria, France, Italy, South Africa, Russia, Malaysia, China, Japan… and that just one hallway. All of them came from considerably farther away from Seattle than Toronto.

    I assure you that recruiters get and read thousands of resumes A DAY from places farther away than Toronto!

  27. Thanks for the info Eric and by the way Waterloo is a nice place. Of course they read thousands of resumes a day, but the problem with that is they look at experience… look at location… create a *uhh* sound… move on. I know alot of recruiters (not MS) who sometimes skip the skill set information on the resume.

    Microsoft is a great company and I continue to defend it (even during all those Linux open source conferences ๐Ÿ˜‰ ) but some times new grads get better *luck* at smaller companies.

    But I will continue applying for jobs at MS and see what happends!

    Any more insight Eric is much appreciated from us all ๐Ÿ˜‰

  28. Peter Torr says:

    And people from from Down Under!!

  29. Jon Fancey says:

    I find all this stuff v. interesting. Thanks.

    One of the things that intrigues me though, as an experienced (12 years+) developer is being asked to code ‘common’ algorithms (like quicksort) on the spot. A good portion of the MS coding questions I’ve seen seem to revolve around this. Surely the fact that these algorithms are so common, or rather, well known, means that they can be ‘remembered’ in which case this isn’t a test of your coding and reasoning per se, but more on your memory ability (I would guess that’s why you’re more interested in whether people recognise BSTRs etc). For any standard algorithm, I (hopefully) tend to recognise that it’s been written a thousand times before so I can just look it up.

    The skill then becomes recognising a good one and reusing it. The best way to improve your code is to study others’ – not write as much as you humanly can. I think this is a good test of an experienced programmer. The college grad will try and write everything (I think that’s what people do when they start anything) whereas the experienced coder will be aiming for much higher quality & productivity IMHO.

  30. Jon Fancey says:

    So, to get to my point, I would guess that your comment to Mr NotSelected above is an indication that just ‘cos you can’t recall an implementation of every classic CS algorithm (on demand, in an interview) doesn’t ‘prove’ you’re not any good?! I hope this is right as I would hate to judge people myself on such narrow criteria.

  31. Dan Shappir says:

    Coming up with good coding questions for candidates isn’t easy (thus I appreciate Eric’s mention of Schaum’s Programming With C++). At two companies I worked for we used a written test to filter candidates before the technical interview. I wrote a significant portion of these tests, and had a hard time coming up with good questions.

    The test I finally came up with had two segments:

    1. Data structures/algorithms where qsort-like questions were asked (though nothing as common).

    2. Technical know-how questions about specific fields (interviewee could pick area of expertise from a list of Win32, communication, C++, Java, …)

    In both sections I tried to give the candidates the ability to choose questions, say 4 out of 6. This is because I appreciate that a candidate can have a "mental block".

    I can’t say the tests were perfect, but they weren’t meant to be. All they were meant to do was save us time.

    Here is one example of an algorithmic/coding question: come up with the fastest possible code that returns the number of "on" bits in an 8 bit number.

  32. Eric Lippert says:

    > I would guess that your comment to

    > Mr NotSelected above is an

    > indication that just ‘cos you

    > can’t recall … every classic CS

    > algorithm … doesn’t ‘prove’

    > you’re not any good?!

    The comment was _intended_ to ask a question — the candidate thinks that he was no-hired because of something and I don’t understand what he thinks that something is.

    However, I would certainly agree with the general point of your question. I certainly couldn’t tell you off the top of my head what Dijkstra’s Algorithm for finding the shortest path in a graph is. I don’t expect that of candidates. What I do expect is (a) a basic knowledge of fruitful problem solving tools — recursion, depth-first-search, all the stuff that should be in any experienced programmer’s box of tools, and (b) ability to apply those tools to a simple problem.

    That’s why we ask a mix of straight-up computer-science textbook problems and more offbeat problems. People who have "stock" solutions memorized might have a slight advantage, but its really not hard to vary a problem slightly to see if the candidate has any flexibility. (And also, people who spend a lot of time preparing, understanding algorithms, etc, SHOULD have an advantage, no?)

    I personally like asking problems that appear to be offbeat, but actually are stock computer-sciency problems at a deeper level. Candidates who can look at a problem, ask questions, clarify it, think about it for a bit, explore around, try out some designs, and deduce the deeper structure of the problem are likely to be strong hires.

  33. Eric Lippert says:

    > For any standard algorithm … it’s been written a thousand times before so I can just look it up.

    I take your point, but two things come to mind. First, an expert is, according to my working definition, "someone who doesn’t need to look up answers to easy questions."

    Second, on the other hand, I _do_ appreciate and give full credit to the "I’d look it up" answer. Recognizing when a problem has already been solved and thereby knowing how to use the work of others to further your own is a useful skill.

    However, the questions that I ask are technically at a low enough level that you shouldn’t have to look it up.

  34. Eric Lippert says:

    > Have you ever considered using a computer for technical interview coding questions?

    It’s crossed my mind. But like a commenter said above, what that ends up testing is ability to use particular tools.

    Anyone can learn how to use our build system, our compilers, editors, etc. That’s easy, so I don’t want to test that. I want to test something that’s hard to learn: general problem solving skills.

    Also, while I’m at it, I want to point out that yes, writing code on a whiteboard is in a sense "unnatural" but it is also a skill I use all the time in my job. We often get together in meetings and end up writing scraps of code on whiteboards to brainstorm algorithms for various problems. If it gets too complex we find a computer of course, but when its four devs in a room everyone can grab a different colour marker and go nuts writing stuff up and annotating other people’s efforts. Four devs in a room with one computer, it’s a lot harder.

    Interviews are often very much like those ad hoc code design sessions.

  35. Dan: that was an excellent idea to give two types of questions.

    Of course software developers must be able to memorize a lot of information. If you are specialized in C++ then you better know the syntax and the in’s and out’s of ever aspect of object oriented programming (without a doubt).

    When a programmer says he specializes in a certain language, I assume that he knows those things (stated above). But for me, a programmer does not just have to be a text-book coder, but the ability to think OUT-SIDE-THE-BOX!

    This is a very crucial aspect of programming now days. People want innovation, not a repeat of some other companies program at a lower price.

    Microsoft has shown that they want programmers with imagination. This is an excellent quality found in a lot of programmers, but unfortunately some programmers just do not have that quality.

    And thatโ€™s something recruiters cannot see from a piece of paper.

  36. Eric Lippert says:

    "Thinking outside the box" is certainly a useful skill. But too often I see it overemphasized at the expense of the more useful "mastery of the stuff inside the box"!

    We’re not in that box because we’re a bunch of bozos, we’re in the box because by and large, the box is a good place to be.

    Which is why the questions I ask in interviews are not "aha!" questions, but rather realistic questions that can be solved by straightforward application of good design and coding principles.

    I can’t stand those brain teasers about manhole covers and weighing airplanes. Not only do they tell me nothing about whether the candidate can code, often the canonical answers are ridiculous.

  37. I saw on Eric Lippert’s site his post called Writing Code On Whiteboards Is Hard . I have mixed feelings about that style of interview. I’ve used the code-on-paper as well as the code-on-whiteboard style, occasionally combined with mathematical puzzles….

  38. Jonathan Brecher says:

    FWIW, my handwriting is not something you want to deal with. On top of that, I’m left-handed, so my handwriting on a whiteboard is smudged even where it happens to be legible.

    I understand all of the reasons you don’t want to test someone’s skill at using a particular development environment, but an interviewer would learn a whole lot more from sitting me in front of Notepad than standing me in front of a whiteboard. Plus, they’d be able to read it, too.

  39. John Lindsey says:

    > It’s crossed my mind. But like a commenter said above, what that ends up testing is ability to use particular tools.

    Which is exactly what I want to test for in anyone whom I hire, even if they are fresh out of college.

    If I ask a candidate to implement something for me (I’m in java-land) and point her at a dev machine that has various environments available, I’m certainly going to notice if she opens up notepad or gvim vs. eclipse or intellij. I’m certainly going to notice if she can quickly find/configure junit so she can start writing testcases. If she can have a red-bar testcase up and running in intellij within 5 minutes of hearing the problem…well, she’s probably going to be a good developer. But one shouldn’t make absolute judgements based on limited evidence. ๐Ÿ™‚

    All of which runs I guess runs counter to some of the earlier comments. Coding is a spectator sport: though I want the spectating to happen on a screen…not a whiteboard.

  40. John Lindsey says:

    …And I think an even better coding test is giving the candidate a group of red-bar tests and having him make them green; OR giving him a long method with some obvious refactorings and wathching him discover them while learning what the method does.

  41. Jon Fancey says:

    thanks for your comments Eric, you’ve set my mind at rest. A lot of what’s been written here really boils down to identifying talents. Obviously, having a good memory is an essential talent. Active questioning and thinking clearly (esp. under pressure) also are. I completely agree with you that one of the *key* talents is how flexible a person is in applying and bending what they *know* to any particular problem you ask them to solve.

    I would also say that I think whiteboarding is an essential skill. I don’t care whether I’m writing code or drawing pictures on a board; in a room full of people it’s one of the best ways to show people what you’re talking about and to collaborate.

    BTW I hate most brain-teasers too.

  42. Eric Lippert says:

    John Lindsey: If what you’re looking for are experienced people who can be immediately productive in your environment, then clearly it’s a good idea to test for that in an interview!

    But that’s not what _I’m_ looking for. I care very little about _particular_ skills and very rarely am I looking for someone who needs to be firing on all cylinders cranking out code tomorrow.

    I’m interviewing people for the long term, people who are going to work on a huge number of technologies over their careers. I can afford a couple of weeks to ramp someone up on our toolset.

  43. Peter Evans says:

    So Eric are you syaing your looking for an adaptablity measure of a persons apptitudes more than specific skill knowledge when interviewing candidates?

    I would say to others who have comment on this topic, offers of employment are always a risky venture and that is why Microsoft is so rigorous and hard during their interviews.

    Nothing worse on an organization than a incorrect hire.


    What specific advice might you have for long time programmers other than what you just given?

  44. Lee says:

    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.

  45. Eric Lippert says:

    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!

  46. asdf says:

    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?

  47. Eric Lippert says:

    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.

  48. ed says:

    >You’re hiring a juggler for your kid’s birthday party. I show up for an interview.

    Someone has read Peopleware!

  49. Eric Lippert says:

    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.

  50. Jiho Han says:

    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…

  51. Jiho Han says:

    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…

  52. Eric Lippert says:

    > 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.)

  53. D says:

    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.

  54. kodiak says:

    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.

  55. 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.

  56. Steve says:

    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…

  57. Don says:


    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.

  58. David says:

    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.

  59. David Again says:

    … "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.

  60. Eric Lippert says:

    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…

  61. Eric Lippert says:

    > 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.

  62. A Working Programmer says:

    >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.

  63. Eric Lippert says:

    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.

  64. D says:


    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.

  65. ph7 says:


    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).


  66. Eric Lippert says:

    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!

  67. ph7 says:

    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 :).


  68. D says:


    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.

  69. Elaine says:

    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!


  70. Eric Lippert says:

    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.

  71. Elaine says:

    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!


  72. Aaron says:


    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!

  73. Elaine says:

    Hi Eric,

    Thanks for your note. I have checked with my college recruiter. She said I need to wait one year to be re-considered to interview for full time and interns are reserved for full-time college student. However, it was a great visit overall. The process was inspiring as well as challenging. The hardest question was given at lunch and fortunately I was not caught with a mouthful:)

    Well, thanks to the experience that I get to read all these great blogs. Hope to see all of you at Redmond some day:-)

    Best luck, Aaron!

  74. Tirion says:

    .:: Findekano’s Tidbet ::

  75. Biswajit Jena says:

    Hi All,

    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.


    Biswajit Jena

  76. This is realy a good article that include imaginery information in it.

    Thanks for this

    Rana Naveed Khalid


  77. abhidotnet says:

    Hi  Eric,

    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

  78. A Joel On Software reader asked the other day for examples of recursive functions other than old chestnuts

  79. Gosh – I was so wrapped up in The Apprentice that I didn&#8217;t have a chance to post on the in person

  80. I think this is the post that you have all been waiting for! Yup, I finally got to it and now you are

  81. Gosh – I was so wrapped up in The Apprentice that I didn&#8217;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

  82. 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,

  83. Gosh – I was so wrapped up in The Apprentice that I didn&#8217;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

  84. 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,

Skip to main content