There may be nothing more nerve-wracking than being handed a dry-erase marker and getting tasked with filling a blank white board with the solution to a complex problem. That can go double for a Skilled interview, especially if you’re feeling unprepared or shy.
Gone are the comforts of our own computer’s IDE. We can’t plug in our headphones, pop open some documentation, and silently work out a novel approach. There’s no linter to hint us to our silliest of mistakes, no StackOverflow to hand us the answer on a silver platter and for a whiteboard interview, no “Run” button to test out the validity of our functions. Instead, a senior engineer who already knows the answer (and may have even created the question in the first place) sits in front of you and picks apart each of your decisions, line by line. Things like: “Why did you do this?”, “Have you considered using recursion?”, or “That won’t work, can you figure out why?”
Many have criticized “Whiteboarding”, claiming the practice is more likely to filter out a good engineer than expose a poor one:
And there’s a point to the criticism. A lot of us are capable of building some pretty great software, but struggle with stage fright, or maybe need to peek at some documentation for a quick syntax check, or are maybe just having an off day.
Still, when you’re looking at it from the employer’s point of view, watching a hiring candidate solve a programmatic problem can be a useful indicator of the way the interviewee’s problem solver’s mind works, and it’s likely that the hirer isn’t looking for the right answer as much as they’re looking for the promise of a future (or current) problem solving rockstar.
Any software you’re likely to work on is nothing more than a big old pile of problems waiting to be solved. A software engineering team needs to work together to decide the best way to solve these problems, they need to think of all of the possible solutions, figure out all of the ways those solutions can go wrong, and agree upon the best course of action. An effective team is more than the sum of its parts; good engineers play off each other, go down rabbit holes, and spec out new approaches together. Conversely, an ineffective team can be less than the sum of its parts; bickering, working in silos / silence, stepping on each other’s toes, and not understanding each other, which can lead to duplicated work, broken or buggy code, or worst of all, bruised egos.
So whether it’s on a whiteboard, through SkilledInc.com, or if the intervieweran interviewer is asking you to simply talk through a programming problem, they aren’t just testing your coding chops, they’re picturing what it would be like to be in a “software foxhole” with you. What if we had a tight deadline to get something done together? Do they communicate clearly? How good are they at understanding questions and asking thoughtful follow-up questions? Are they able to think about new problems and craft their own opinions about how they should be solved? And maybe the more underrated question of all time — Is it going to be fun to work with them, or a chore?
The next time you show up to an in-person or log into Skilled for your interview, keep some of the following things in mind before you start typing up a solution:
- Did I introduce myself? Start some dialogue? Make the interviewer feel like this won’t just be “business as usual” and that today’s interview may be a memorable exchange?
- Do I understand the problems I’m being asked to solve? Did I make the interviewer confident that I understood the question?
- Did I come up with a sound strategy for solving the problem before diving right into solving it? Does it make sense to pseudocode the solution before putting marker to whiteboard?
- As I’m writing out a solution, am I clearly narrating what I’m doing and why I’m doing it?
Your interviews will be a lot more pleasant if the room is filled with dialogue and collaboration as opposed to the sound of a squeaky marker on a whiteboard or keys clacking on your keyboard. Think of your interviews as a showcase not only for your programming skills, but your people skills as well!
Think about the engineer that you want to market yourself as in your interview.
Try to picture or remember your favorite and least favorite people to work with. Whether it was an old coworker, a former teacher, a group-mate in a school assignment, your little league coach or teammate… we are forced to collaborate with others throughout our lives. Some of those people are loud, interrupt you, claim credit for things you may have accomplished, keep important information to themselves, give up too easily when you need them, or just don’t give the same effort that you do. Other support you through difficult problems, communicate with you on a personal level, make you feel as though you are smarter when they’re around, work with you to solve difficult problems, and display leadership when the group needs one.
Find a way to display as many positive aspects about yourself as you can when you’re being put in the spotlight. Show your potential new coworkers that you’ll be a positive influence on their careers, regardless of who has more experience, who has what skills and if you can solve some recursion problem on the fly.
Always get the interview problem right, but make yourself hard to say no to, even if you get it wrong.