Table of contents
| Read No. | Name of chapter |
|---|---|
| 30 | Whiteboard Advice |
| 30 | 7 tips to ace a programming interview |
Whiteboard Advice
Whiteboard-style interviews are ubiquitous in the tech industry. For those who not had the pleasure, whiteboard interviewing is the practice of asking candidates to solve technical questions on a whiteboard, piece of paper, or computer during the interview. This kind of environment can feel like a pressure cooker and cause even the most competent engineer to fall apart.
The Advice: Communicate!
The best piece of technical interview advice I have received and can impart upon you is to communicate, communicate, communicate! This may seem like an anti-climactic piece of advice, but I hope to be able to demonstrate to you that it’s actually the most important skill to prepare prior to an interview.
What Do You Mean Communicate?
Let’s say you are in the interview and your interviewers throw you a whiteboard question. Do you step up to the whiteboard and feverishly start solving the problem?
No!
That tends to be everyone’s instinct, but it’s definitely not the right way to go. Even if you think you understand the problem, you should take some very important steps before moving forward.
First, Restate the Question
Do you understand what they’re asking you to do? Prove it. Restate the question for them and seek affirmation. You might actually be surprised to find you don’t fully understand what they’re asking for — perhaps the question is similar, but not the same, as a practice problem you have completed in the past.
The interview should give you affirmation or, perhaps, your understanding is incorrect and they will help you understand. There is no situation in which restating the problem will hurt you — it shows you can articulate a problem and gives you time to think it through a bit while you discuss. Furthermore, starting the discussion this way will help quell some nerves that might otherwise manifest while trying to solve the actual challenge.
Ask About Edge Cases
It’s still not time to dive right into coding the solution. Think for a bit about the inputs and expected output and think about potential edge cases to the problem. Ask about them. In many cases, the interviewer hasn’t even thought about edge cases and will make something up. That’s great — it shows you’re analytical and will work hard to try to prevent bugs.
Ask About Test Cases
This is free and you should take advantage of it. Simply ask if there are any test cases that the function should pass. Your interviewer might be expecting you to ask this question, so it might be necessary. But it’s also possible the interviewer was not expecting the question and will think “ah, this candidate knows about testing!”
Write Pseudocode and Ask If It Makes Sense
Again, you don’t actually want to start writing code in an actual language. You’ll find yourself constrained by trying to remember the methods or other idiosyncrasies of the language rather than trying to come up with the correct logic. Instead, let your interviewer know you’re going to start by writing pseudocode and fill in the actual code later.
Here’s the kicker: you can ask if your pseudocode makes sense to the interviewer. It’s possible they will be the type that doesn’t want to “give you hints,” but it’s also possible they’ll be more interested in how you think and want to discuss your pseudocode with you. When I interview candidates, I’m more interested in the latter — rarely do we ever actually develop software in a vacuum.
In other words, in the worst case the interviewer will tell you to continue without actually offering feedback. In the best case, the interviewer might actually point out logical flaws in your pseudocode that will give you some serious benefit when transitioning to actual code.
Write the Actual Code and Ask if it Looks Good
You should now convert your pseudocode into actual code. You don’t even need to remove the comments. At this point, you just need to plug the appropriate code for your language in. If you forget some syntax or a method name, you should be able to ask your interviewer for this information without too much grief. If they give you trouble, just say you’ll leave it as pseudocode for now.
Stuck? Ask for Help!
If you’re having trouble along the way, it’s not illegal to ask for some help. Just phrase it conversationally. For example:
“I’m a bit stuck here, do you have any tips to nudge me in the right direction?”
The answer might be “no, I’d like to see if you can solve it from here on your own,” but it also very well might be a “yes” with a useful tip!
7 tips to ace a programming interview
1) Take a few minutes.
Speaking as an interview coach, this is one misstep that I see all the time during mock interviews. The canonical tip that everyone gives is, “talk more!”. What most of those well-meaning advice-givers overlook, however, is that talking and thinking at the same time is extremely hard. Nervous interviewees will jump straight into talking, passing up a great opportunity for concentrated thought.
Don’t waste precious minutes trying to fill the silence by saying everything you’re thinking, while simultaneously trying to solve the problem in your head.
Instead, wait until the interviewer is done explaining the problem. Ask any clarifying questions, and then tell your interviewer:
“Okay, got it. If it’s okay with you, I’m just going to take a minute or two here and think about the problem, and then I’ll start talking.”
Shut your eyes, stare at the ceiling, scribble on the whiteboard — whatever it takes. Think through the basics of the problem, and decide on an approach. Then re-engage the interviewer, and let him know what you’ve concluded. Don’t forget to provide your reasoning!
2) Write down the steps of the solution.
Even after you have an idea of how to attack the problem, don’t start writing code down. Write down the general steps of how you will solve it on one side of the whiteboard, where it’s visible but won’t get in the way. You don’t need to be verbose, just get the steps in order and somewhat readable.
Write pseudocode first.
Time to write code? Nope. Take a “dry run” at writing the code by writing some pseudocode. Often we run into problems halfway through writing the code, and there’s no point wasting time over syntax when you might have to throw the code away. Instead, write some half-baked code-looking stuff that lays out the structure of how your code will work. Do it over on the side of the whiteboard, so you have space left to work.
4) Don’t sweat the small stuff.
Programming interviews are not about how well you’ve remembered your semicolons, nor are they about being able to remember all of the flags on a TCP packet. They’re about demonstrating depth and breadth of knowledge, personality strengths, and problem-solving abilities. If you make a mistake, it’s okay. Brush it off and move on.
If you can’t remember something like this, it’s often acceptable to say that you’d look it up.
“…and here, I’d use whatever the list.contains() equivalent is in JavaScript. I know it’s not contains, but I can’t remember the method name right now, so we’ll call it contains() for now and I’d look it up right now if I were coding this.”
Let’s be honest, half of being a programmer is knowing how to Google stuff and how to interpret search results. We use the internet as a giant cache for all the information that we “almost” remember but don’t bother to, since we can just look it up at any time. It’d be hard to fault an answer like the one above. So don’t waste time memorizing keywords in your interview prep. Focus on the big picture.
5) Sit down. Be humble.
A programming interview isn’t just a written exam. It’s an assessment of your programming abilities, and there are plenty of things that fall into that category beyond mere coding prowess. For example:
- Are you able to express your ideas and solutions clearly and effectively?
- Do you treat the interviewer with respect?
- How do you accept criticism (technical, constructive or otherwise)?
- Are you able to collaborate with others to come up with solutions?
- Do you communicate in a way that demonstrates empathy?
- Are you honest (especially about yourself)?