Whiteboard coding interview: After action report
So I finally had a whiteboard coding interview. I’d applied for a junior developer position at a small startup company in the Boston area. Before the whiteboard session, I had an hour interview with two of the engineers. After a brief intermission and a changing of the guard, two new engineers asked more questions. Then came the whiteboard question.
Thus ended the easy part. After that, I was faced with solving a problem in a domain I had only passing familiarity. Fortunately, I hints were offered eventually whenever I got stuck. Ultimately I arrived at a solution.
In the future, I need to better vocalize what I am thinking. Often I stared off into space in silence, half hoping the pain would stop. Solving a problem in real-time, under pressure is unnerving, to say the least. It was suggested I solve a specific instance of the problem, then naturally I could generalize the solution. It’s an approach I will take in the future.
If I could offer any specific thoughts, they are:
- Write the name of the language you’re using on the board if given a choice
- Write the inputs your function will receive
- Write the outputs your function will receive
- Write down any assumptions you can safely make
- Draw pictures, graphs, scribbles, whatever helps grasp the problem
- Solve a specific instance of the problem, then generalize it
- Check to see if there are any edge cases your general solution fails for
For my interview, we didn’t look at the performance implications of the solution, but understanding big O notation is worthwhile nonetheless.
While whiteboard coding can feel daunting, taking a methodical approach and decomposing the problem into manageable chunks can help. If all else fails, take a deep breath and ask your interviewer for a hint. Watching you struggle is likely not enjoyable for him or her either.