Death of a Whiteboard: How to crush any technical interview
Today was not quite a typical day at the code school where I teach. Instead of helping students work through lessons, today, teams of four students pitched the MVPs of apps they had been working on to our big room of students, faculty and staff. After a long week of prep, I was excited to be helping my class put the finishing touches on their AngularJS and Android apps. The room was buzzing with energy, and many groups presented work with built out capabilities and beautiful user interfaces that look as market-ready as their ideas.
I have been teaching at a code school for two years now, and my students are frequently quite diverse, in both age, gender, and background: They are veterans, they are undocumented, they are first generation immigrants whose first language is not English. They are transgender. They are gender non-binary. Over 50% of them are women.
They love solving problems.
They love building things.
They’ve completed hundreds of hours of practical, hands on training, and they are hungry for their first real tech job.
BUT:
They are super intimidated by whiteboarding — solving problems on a whiteboard with no computer, and technical interviews, where candidates get grilled on technical topics — because they know that despite their awesome, proven skills, they are especially disadvantaged by being nontraditional backgrounds and being minority students. And they aren’t alone: Many developers, whether they are from underrepresented groups or not, are intimidated by these kinds of interviews.
But what is important to know is the following:
Whiteboarding is not about how well you can code, it’s about how well you can think and explain. That’s a fantastic opportunity, if you use it right.
And so today, I want to share with you some of the tips and techniques we practice with our students to allow them to show up well in whiteboarding interviews. These are not language, platform, or technology specific.
Just the same way as there are reasonable approaches to succeeding on standardized testing, there are strategies you can use to improve your ability to make a good impression in any technical or whiteboarding interview you come across.
Let’s jump right in.
Know your acronyms
One of the easiest ways to flunk any technical interview is to not know your acronyms backward and forward.
Work with the material: If you are asked an acronym question, or a question featuring an acronym, be sure to spell out that you know what it stands for.
Why?
If you are only used to talking about REST or JSON, you might balk at being asked to speak on the finer points of “State Transfer” or “JavaScript Object Notation”.
Work with the setting: When you are nervous, your brain doesn’t work very well. Pointing out that API stands for Application Programming Interface might very well jog your memory.
Make a point of learning and knowing commonly used acronyms in your field of study.
Get your setup right for phone screenings
If you are like me, and talking on the phone is your version of one of those paralysis nightmares, you’ll feel better if you are getting your setup right. Prepare for it like the interview that it is. Make sure you are in a quiet, private environment with a good phone connection. Have a hands-free headphone situation with you so you can speak freely. Have a computer station nearby, as well as a pen and paper.
Work with the setting: Take advantage of the fact that you are not visible during the interview. Pace, do savasana, or sit on the floor if it calms you down. Have paper notes, or sit at a computer. Have your teddy bear, dog, or grandpa in the room with you. Whatever helps, helps.
Work with the material: Write down the person’s name who you are speaking to so you don’t forget it by the end of the call. Show interest. Ask questions. Write notes.
Evaluate and Communicate: Ask yes/no questions to buy time and clarify contexts
If you are asked to explain a technical concept or perform a whiteboarding exercise, make sure you ask any clarifying questions before you begin.
Let’s look at an example:
Write a function that accepts the following input:
let inputNamesArray = [“Dench, Judy”, “Mirren, Helen”, “Andrews, Julie”, “Jolie, Angelina”]and returns the following output:
let outputNamesArray = [“Dame Judy Dench”, “Dame Helen Mirren”, “Dame Julie Andrews”, “Dame Angelina Jolie”];You might ask the following of your interviewers before you begin:
- Will the input array will always have a length of 4?
- Currently, the list isn’t sorted. Is this intentional?
- Can I write the solution in pseudocode?
- Can I assume that there will never be duplicate names in the array?
And so on.
Work with the material: Clarifying things before you begin shows you understand the complexity of the problem. Also, can likely rule out unexpected nuances that might trip you up later.
Work with the setting: Asking clarifying questions gives your brain an opportunity to start warming up, before you begin responding or writing down code. It also kills a little bit of time, which is a good thing.
Never say “I don’t know”. Also Never: Make Stuff Up
When you panic, hit a wall after being asked a tough question, and blurt out “I don’t know” , you’d be forgiven to think you are just given an honest response. In reality, you might be showing your too much, and you are not giving your interviewer much to work with to turn things back around. Not knowing the answer is not necessarily a dealbreaker, not handling stress or pressure appropriately might well be. So stay cool.
Whatever you do:
Resist. The Urge. To. Allow. Streams. Of. Nonsensical. Rubbish. To. Exit. Your. Face.
A crappy answer will be memorable in a bad way. Find a different way that shows you in a better light.
This is how you get out of this pickle when you point blank don’t know: Take a deep breath. Calm your mind, and ask a few questions.
Work with the material: If you thoughtfully ask your interviewer to clarify, specify, let you know concretely, or any other phrase you should practice beforehand, you may well get some useful information.
It also, again, gives your brain some time to catch up. Congrats, you just showed grace under pressure.
Work with the setting: If your interviewer seems friendly and casual, you might be able to carefully admit to not knowing the answer to a question. How you handle this situation is more important than not knowing.
Verbalize and prioritize, plan, execute
When you are asked to whiteboard a solution to a problem, you should verbalize what you are going to do before you do it, and write down a list of actions you are going to perform.
Yes, with the pen you are holding.
Let’s return to our earlier example: Write a function that accepts the following input:
let inputNamesArray = [“Dench, Judy”, “Mirren, Helen”, “Andrews, Julie”, “Jolie, Angelina”]and returns the following output:
let outputNamesArray = [“Dame Judy Dench”, “Dame Helen Mirren”, “Dame Julie Andrews”, “Dame Angelina Jolie”];Given that we have an array, it seems like we will
- probs need a loop
- must declare and init outPutNamesArray outside of loop
- split our array element in some way
- remove comma
- fix order
- prefix with “Dame”
- push to outPutNamesArray
- return at the bottom.
Cool. Now you have a plan, as opposed to running around like this guy.
Work with the setting: Talking through your plan allows you to take the temperature of the room before you are wrangling lines of code. If your interviewer spots an error, they may give you a tip you can use to clarify your approach.
Work with the material: You have a whiteboard and a pen — use them! Write the list down as you verbalize it — then, check things off as you code. Keep explaining out loud. Don’t make the interviewer guess your thoughts.
Whiteboarding interviews are not about writing perfect code — they are about communicating your thought process as you solve a problem. So do just that!
Wrap Up
Give these tips and tricks a whirl. While you are still going to be nervous, having a structure and ideas in place can help you feel like they have options and maneuvering room as opposed to being painfully exposed in front of a giant empty whiteboard with no plan.
Remember: Nobody expects perfect syntax, but they do expect you to show that you can communicate well. Don’t sweat the small stuff, focus on the big picture. Prepare as best you can, hydrate, and practice these tips before you dive in.
Good luck — and feel free to share how things went! Perry Eising
