Whiteboard interviews suck! (but you should practice anyway)

Whiteboard interviews are getting more and more common nowadays. In the past, at least from my first-hand experience, the interview process was:

• recruiter call
• call/video introductory chat with the company
• technical interview
• interview with HR

in the last couple of year it became mostly:

• recruiter call
• a coding challenge at home
• call/video introductory chat with the company
• technical interview
• session of whiteboard coding
• interview with HR

Well, i am fine with formal interview and "informal" chats - I was even invited at lunch from a couple of startups, and while some might find awkward to eat in front of other people that are in fact assessing you, i found that a very effective way of seeing the candidate in the day-to-day company environment, chatting about passions and hobbies, talk about your dreams and goals and often discussing technical stuff ( which for me often is same as way of talking about my passions).

but I really hate coding on the whiteboard:

• I really feel a lot of pressure, the weight of 2 or 3 pairs of staring eyes behind my shoulders
• my calligraphy looks like that of a teenage psychopath
• since I rely heavily on IDE autocomplete features, most of the time I don´t remember the proper syntax or API
• most of the time the task and its constraints are something that I hardly encounter in my daily job.

Why the heck should I now know to parse HTML into markdown - there are tons of NPM modules out there doing that. It would be very stupid to be reinventing the wheel ( same is through for reverting a string or implement a bubble sort ).
If I am writing mostly in a functional approach using map.filter.reduce ( and you expect me to do that if I get the job) why are you forbidding me to use them and want to see how I struggle with writing one loop only and hashmaps?

Don't get me wrong, being aware of the Big O Notation and the impact of chaining map.filter.reduce instead of doing everything in one single loop is very important to avoid leaks or performance issues, but it's more about knowing how they work and when to use what, not about knowing the implementation details.

In fact, I would enjoy a technical chat about how I would implement HTML-markdown converter, the steps to follow, possible different approaches, analysis of time and space complexity, performance optimizations etc, but not actually writing it.
I would also find very interesting to discuss two different libraries that do that, quickly check their implementation and discuss the pros and cons. That, in my opinion, would show that you understand the concept, its implementation and that you would be able to pick the right tool for your task.

Having said all that, we should practice whiteboard coding. Exactly for all the above reasons and especially because it is uncomfortable.
Everything that pushes you out of your comfort zone will make you grow and improve.

Since you are deprived of things you take for granted like autocompletion, code-linting, compile-warnings and fancy helper methods ( that are native or come from other libraries does not matter) you are forced to think and code in a different way. You have to approach the problem in a different way, and there your creativity sparkles.

Furthermore, it is always good to refresh, or learn at all, basic Math and CS skills.
And mostly is good to learn to manage stress while presenting your ideas to others and do it in an ordered and clear way, be it an interview, a presentation o simply a code design meeting.

For a few months, I started meeting once I week early in the morning with a colleague and we give us 15 minutes to solve an easy task from Hackerrank. At the beginning every time it was my turn I felt that I would not be able to hold the marker and my brain started melting.

Now it got better and even if I sometimes struggle with tasks that in the tranquillity of my desk would be a breeze I must say it is lots of fun too.

So, go for it.
Pick some problem from one of the many coding challenge websites and practice. (the one I was solving at the whiteboard above was this)
Challenge yourself and prepare for your next interview!

Comments

[Martin Riedel]

i gladly explain and discuss architecture, concepts, ideas on whiteboards. if a company want me to code on a whiteboard - we're done.

[Davide de Paolis]

yes, but you are cutting yourself off a big chunk of possible employers. i read many articles and many comments about whiteboard interviews and people saying "well, if a company does interviews like that, I don't want to work there". the point is, whiteboard interviews will tell way more about how you approach problems, manage stress, explain your thoughts, that about your coding ability.

[Martin Riedel]

but how you approach problems, explain your thoughts and manage stress can also be examined when you discuss architecture, concepts or ideas. i'm not against that, not at all.
i just consider it a waste of everyones time to code on a whiteboard.

[Davide de Paolis]

definitely. but we - as candidates - have to play by the rules set by the interviewer. of course we always have the right to disagree and leave the room because in the end we don't care about that job or that company.
Honestly, since - we may like it or not - this is the trend now, I forced myself to find positive aspects on whiteboard interviews and I try to grow out of this experience and learn new skills. :-)

[Christopher Smith O'Neal]

in the last couple of year it became mostly:

recruiter call ( you can swap this one with the next one)
interview with HR ( you can swap this one with the first one)
a coding challenge at home
call/video introductory chat with the company
technical interview
session of whiteboard coding <>