Intelligence usually has nothing to do with how you do in coding interviews. I’ve seen many intelligent programmers do poorly in interviews. I’ve seen brilliant engineers struggle with thinking things through clearly.
Good programmers freeze in front of the whiteboard. It is not home! Home is their favorite IDE in dark mode.
Before I talk about the whiteboard, let me address some issues that lead up to the freeze, and what you can do about it.
Here are 5 things to watch out for –
This is counterintuitive. You are there for the job. That’s what you’re spending your time doing — trying to get the job. But, you cannot worry about getting the job.
Would you worry about losing a friendship when you introduce yourself to someone new for the first time?
The worry makes you do 3 things —
It makes you unable to read the room,
It makes you unable to understand the questions clearly.
It makes you work harder than you need to.
Left to their own devices and given some time, good programmers can figure out anything. Then why do they have trouble doing the same thing during an interview?
The ability to understand the question and cut through to the core of the basic problem is harder than it sounds.
Part of the problem is that the clock is ticking, and there is pressure to impress.
That’s the first wrong turn.
Don’t try to impress the interviewer(s). If you relieve yourself of that burden you’ll immediately free up a whole lot of energy that you can then focus on listening to what is being asked and to solving the problem.
Nothing is more uncomfortable in an interview than
Watching someone solve something in silence.
Watching someone absorbed in their own world like we don’t exist.
Watching someone delete everything they worked on in the last 15 minutes without telling us why.
Watching someone respond to our questions with short phrases as they are fixated on the problem.
Talk your problems through. It’s not important if you don’t finish your solution on time. Your talking through your thought process gives the interviewer valuable clues as to how you think.
If you’re going off track, we can tell you early on. If you’re making a mistake then chances are other people might have gone down that erroneous path.
We can save you time by diverting you away from it. But, only if you keep an open channel of communication.
How you think is one of your most valuable assets. When you’re hired you’d be working on completely different problem sets and not the interview questions.
I’ve had people with 6 page long resumes and a great track record take up valuable time during the interview to impress their excellent track record.
An interview is not a chance to clarify your resume unless you’re specifically asked about it.
The resume got you the interview so its job is done and now you can forget about it. It’s the past and we are interested in what we can do together in the future.
I’ve found that people will usually start to talk about their resumes when they start to feel that they are failing.
When you feel like the interview is going south, stop talking, and start listening. Everybody screws up but one screw-up doesn’t define the whole interview.
Failure is a great chance to show the interviewer how you can recover from it.
The feeling of failure kicks in when you are unable to answer a question on a topic that you claim to be an expert on, or you feel that you took too long and you should’ve had the answer on your fingertips.
Remember that the room only starts to get a sense that you’re failing only when you start to show that you feel like you’re failing.
This is where a little dose of self-confidence and self-compassion would come in handy. The interviewer wants you to do good. If we can find the right person quickly then we can get done with the interview process and get back to work.
Every person we interview, like Morpheus in The Matrix, we hope that they are ‘the one’. Finding someone quickly keeps our recruiting costs down. We’ll help you to carry on if you stumble a bit.
When I ask a thought-provoking question, I fully expect the candidate to take their time and design a solution.
Interviewers don’t use their candidate as a google search bar. Unless you’re fresh out of college or applying for a junior level programming job, you won’t be asked trivia questions like what is a virtual function.
Good engineers are interviewed for their ability to solve tough problems. To that end, many interviews will have some common components like coding on a whiteboard, questions about algorithms, data structures, and design!
I get the algorithms, design and data structure but whiteboard coding feels like it is the most unnecessary. This is 2019. Who is coding on a whiteboard?
Every programmer knows how to use an IDE so much so that they take pride in knowing the keyboard shortcuts.
You get autocomplete and reminders about semicolons so you can focus on the logic.
Early on in my career, I went in for an interview for a company that did defense projects. They were looking for a programmer with knowledge of OpenGL.
During the interview, it was clear that my lack of experience with DoD(Department of Defense) regulations could be a problem. I came from the world of commercial software development.
The interview was pretty much over when one of the guys asked me to solve an OpenGL problem on the whiteboard anyway. I think they were trying to be nice.
At the time, I was immersed in OpenGL. All I had to do was squeeze the sponge and it poured out on the whiteboard.
I got the job. About the regulations- they changed their mind. Suddenly they were confident that I’d learn those on the job and it’d be fine.
How did the whiteboard save me? Because I could focus on the code and not worry about the correct environment set up on a test PC if they were to give me one on the spot.
If you program in your language enough, you should know the tools of the language available to you like STL and algorithms in C++.
The whiteboard shouldn’t scare you rather it should be another platform to put down your thoughts.
Many great mathematical problems were solved on a bar napkin.
That’s what the interviewer is looking for — domain knowledge, and problem-solving skills.
Sure you may forget the exact name of a function or the order of the parameters but as long as you refer to it on the whiteboard, we know that you know.
The whiteboard is perfect to convey a sense of the outline of your logic in your language, the choice of your data structures in your language, and your design.
If you don’t put down a binary tree on the whiteboard when it’s needed then chances are that you don’t know about it and you won’t bring it in into your program when you’re coding away on your IDE either.
The choices that you make are important clues for your interviewer.
Don’t try to impress
Don’t be silent. Speak up. Show and tell what you’re thinking
Be confident. Own your power.
Get ready to code on a paper or a whiteboard. If you know what you’re doing it’s not that difficult. No one is judging you for missing semicolons.
You may or may not get the job for a number of reasons that has nothing to do with you. But, you don’t have to be that reason.
Good programmers get rejected all the time and then end up getting hired at the same company later on down the line.
Good luck and if you have a particular challenge with interviews, I’d love to hear it. Please share it below in the comments section.
Edited by Debashis Biswas