How can I get better at whiteboard interview questions? [closed]

Question

I have sat on interviews and noticed a big disparity between individuals of similar competency at answering questions on a whiteboard during an interview.

Generally, being able to clearly explain your thinking, writing readable code with the dry eraser pen, avoiding long moments of silence tended to result in more favorable reviews of the candidate even though in the end the answers were about equally correct.

How can one can get better at whiteboard interview questions? Are there ways to be better prepared?

Answer 1

You should buy a small whiteboard and practice, practice, practice. Have your friends ask you questions from a book such as Programming Interviews Exposed. Then solve the problem and explain your thought processes to them exactly as you would in the real deal. Your goal is to not sound frantic. You want to articulate clear thoughts. Even if you can't solve the problem, show them that your thought process is intelligent and on the right track.

Writing answers on a whiteboard isn't intuitive. It takes practice. I used to be a teacher for one of those SAT training programs, and we spent hours training with writing on the board and explaining our thought processes. In the beginning of the program, most people stumbled over their words and wrote with horrible handwriting. By the end, we looked like seasoned veterans. You don't want to look like we did in the beginning of the program.

Moral of the story: Don't go to your interview unprepared. Solving problems on the whiteboard is something you should practice.

Answer 2

There are three questions that needs to be answered when you're on a white board interview:

1. Can you solve the problem?
2. Can you communicate clearly about the problem and the solution?
3. Are you able to receive feedback from others?

So the solution is not the point, it is how you got to the solution, and that is what interviewers will asses you on.

Can you get better at it? Yes, you can:

Next time you have to explain something with your peers (other students if you're studying or other co-workers if you're working), do this:

1. Drag them to the whiteboard
2. Pick up the pen and eraser
3. Start explaining the problem
4. ???
5. Profit

Oh, and don't be embarassed. Just assume that your sketches and pseudo code will suck anyway and improvise instead. The goal is to reach the answer together with your peer and always be open to feedback from your peer. Bonus points if you can solve the problems. The more you do it, the better you get at it. Practice makes perfect.

Other than writing code; learn to draw UML diagrams and to talk about them. It's all boxes, circles and arrows and the types that you usually draw are class diagrams, sequence diagrams and (very rarely) use case diagrams. And in all other cases you only need to draw boxes, circles and arrows.

Answer 3

Whiteboards are not just for interviews

That may strike some as a radical notion, but when I ask a candidate a whiteboard question, I am mentally comparing his or her response to the last few times a colleague used a whiteboard to explain something to me or ask me for help. It's not just a test to be administered at interview time, it's a vital day to day communication skill.

So how does that help me prepare for whiteboard questions when I'm being interviewed? I treat it just like solving a problem together with a colleague, rather than a university exam. That means I present my ideas, and when I need more information, I ask. If something doesn't look quite right, I talk it over with the interviewer until I'm satisfied.

If they want you to reverse a linked list and you don't remember what a linked list is, ask. If the end result is better, I will give you higher marks than the guy who knows what a linked list is off the top of his head, but who writes lousy code to manipulate one. It's not like you will start the job somehow magically knowing all our code and other proprietary information, no matter how experienced a programmer you are.

In my opinion, interviews are not something you can cram for, and if you could, it would skew the perception of how good a fit you are for the job, and vice versa. It's pretty easy to tell when someone's just reciting an answer they memorized. That's one reason I purposefully try to push candidates outside their knowledge zone. I want to see how they react to questions they haven't prepared for.

You might think I'm crazy, but I feel so strongly about the benefits of evaluating someone's thinking process vs. their memorization ability, that I've told interviewers when I'm essentially regurgitating an answer I've given to the exact same question at 3 recent interviews, and ask if they would like to pick something more challenging. They always ask me to "humor them" anyway, just in case I'm bluffing I suppose, but at least they are getting an honest assessment of my skills.

Answer 4

I have sat on interviews and noticed a big disparity between individuals of similar competency at answering questions on a whiteboard during an interview. Generally being able to clearly explain your thinking, writing readable code with the dry eraser pen, avoiding long moments of silence tended to result in more favorable reviews of the candidate even though in the end the answers were about equally correct.

I don't remember the last time I worked as an individual when developing software. I always had to coordinate my activities with others, discuss my design and implementation decisions, and work with others to construct software. Demonstrating communication skills in an interview is a huge plus. Interviews can make you nervous, but so can looming deadlines and the pressure of the job.

I would also reiterate my comment. Given the team-oriented nature of software engineering, you have to consider more than technical competence. The ability to speak and write, especially technically, is important for most positions. I would assess the competence of someone on all of the factors relevant to the job, not just their ability to build software.

What are some ways that one can get better at whiteboard interview questions?

Are there ways to be better prepared?

I can think of two reasons why someone might have poor responses to whiteboard questions: they don't have a good grasp of the technical information or they are a poor speaker/presenter. Of course, it could always be both of these.

The way to get better depends on the problem. Technical improvement comes by reading, doing, and asking questions (usually in that order). Poor presentation skills comes through practice, although some people are just naturally good speakers, while others aren't. I think that anyone can develop the communication skills, but personality will play a huge role in how good someone actually is.

Tips for how to proceed during the interview?

It depends.

More detail is always good, even to the point of total "brain dump" to the interviewer. If I wasn't giving enough information, I've had interviewers ask me to explain something in more detail, and they typically asked explicit, to-the-point questions about my design or code.

Spending a couple of minutes thinking through the problem before hand, without saying or doing anything is always a good idea. You can use this time to also ask questions to clarify what the interviewer is looking for. This will not only give you the opportunity to give the interviewer exactly what they are looking for, but also show that you can think your way through multiple possibilities.

Answer 5

Standing up in front of others and giving a presentation is a learnable skill. If you are weak at it, I recommend joining your local chapter of Toastmasters. You will practice some of the "here is a topic you've never seen before, now stand up in front of strangers and explain it" stress that you encounter during interviews, and especially the whiteboard portion (if any).

Answer 6

While others have covered the physical aspects (practice!), I'll touch on the mental aspects. Regardless of how much practice you do, interviewing is a different type of environment. You won't be alone or with your friends - you'll be with someone you've never met who's trying to judge your ability.

When practicing, always keep that environment in mind. You don't have to flatter or suck up to them - your goal is to display your competency and attitude. Speak naturally and explain what's going on in your head. They want to see how you think, so think out loud, talk, discuss, and get them to be involved in your mind.

Another important factor is rebounding. Practice problems always have solutions - when you get stuck, you can check the next step, write it out, understand, and learn. But your interviewer is not a solution manual. They will help you out, but nobody says "the next step is to do x," - they'll say "have you thought of y (which is related to x)?" So practice without always referring to the manual. Have a friend give you some vague but related suggestions, and try to build from there. Explain how their suggestion helped you solve the problem. Always show them how you are thinking.

Hope it helps!

Answer 7

Asking questions and avoiding assumptions is another point for some whiteboard questions. What may seem like, "Hey, I've done something like this before and here is the solution..." is really a question of seeing whether you'd make those assumptions and shoot off your foot. Not that it is intended to be a trick question or embarrass you, but there are generally lots of little things that if you hit any of them it'll show rather easily. A few example areas:

• How specific are the requirements? Are you sure what the result would look like?
• Which complexity metric is more important, time or space, and are some operations worth more considerations than others,e.g. if you are building a data structure there could be the desire for access to be faster than adding or deleting or vice versa?
• How well can you explain why your solution is good?
• Could you walk through an example or two showing how your theoretical solution would work? Testing cases here can be interesting to discover as if there is user input, where is that validated and how are error messages communicated, etc.

There are other areas of course but those are the main ones that I'd consider when analyzing how did I do in a mock interview.