Reversing a binary tree and other great interview questions
Software engineering Recruiting

Reversing a binary tree and other great interview questions

We do not like being asked to write an algorithm on a whiteboard during job interviews, but is there a better way?
Bartosz Mikulski
Bartosz Mikulski – 5 min read

I saw an old tweet by Max Howell, who complains about recruiters who have ignored his achievements.

Table of Contents

  1. What do recruiters want?
  2. Reversing binary tree and other questions
  3. The problem with whiteboard interviews
  4. Producing code is not enough
  5. Sad truth about your GitHub projects
  6. Learning the basics

Firstly, I thought, “Yeah! Exactly!”. I understood his outrage because similar behavior convinced me to quit my previous company when they had decided that I could not be promoted. Nobody likes it when they are ignoring everything you have been doing for the last three years and make a decision based on a 20-minute long interview.

If the recruiters had looked at Max Howell’s GitHub account, they would have concluded that Max is a very competent programmer. Let’s look at the numbers: 1k contributions in the last year, (very) active on GitHub since 2009, the most popular repository has 7k+ “stargazers.” Impressive.

Can we blame recruiters for ignoring real experience and focusing on performing structured interviews with reality-unrelated questions? Is there at least one good reason to conduct a whiteboard interview?

What do recruiters want?

When a recruiter asks you to solve a problem on a whiteboard, they do not want to see a solution. They do not want to know whether you managed to memorize a few algorithms! Seriously.

So what do they want?

They want to check whether you can explain a solution to others and reason about code without running it. That ability is beneficial. Do you know anyone who cannot say a word about code if they do not run it and check what the code is really doing? Isn’t it annoying?

Things get more interesting if you do not know how to solve the problem. In such a case, you can show that you can ask for clarification, understand a problem you are not familiar with, and create a working solution. Isn’t it precisely like a programer’s daily job? The set of problems is different, but the required skills are exactly the same.

Reversing binary tree and other questions

Now we must pretend we are hiring a programmer. We have already decided to base our decision solely on the candidate’s ability (or inability) to finish some tasks. Should we hire a person who cannot solve a problem?

As a matter of fact, the task does not matter. It makes no difference if the recruiter asks you to reverse a binary tree, sort an array, write the binary search algorithm, etc. In my opinion, they ask such questions because we don’t know the answer. Nobody learns such algorithms because we can google them in 5 minutes when we need them. That’s why such tasks are perfect for verifying whether the candidate can figure out a solution independently.

The problem with whiteboard interviews

The problems begin when the interviewers expect perfect code written on the whiteboard. That’s ridiculous. It happened to me once or twice. The interviewer complained about missing semicolons in my code written on the whiteboard. Seriously? Will you compile and run that code?

For me, “whiteboard coding” is all about solving the problem. You don’t even need to use an actual programming language. You don’t need to remember function names. You can say that you need a function to do X, but you don’t remember the name or the required parameters, so you write doX() and continue solving the problem.

The other problem I had seen (as a job candidate) is the struggle with verifying the solution. Once, I was interviewed by a person who claimed that my solution (written on the whiteboard) does not work but could not explain a situation when it fails. I was under the impression that he spent 5 minutes googling the correct solution, and my code looked differently. Therefore, he assumed it was wrong.

Producing code is not enough

Sadly, we need interviews to filter out people who can only copy-paste code and talk a lot about their “achievements” (which are, in fact, achievements of their coworkers) instead of doing things. We need a way to test whether a person is capable of thinking and problem-solving.

Should we give up and test only how fast an interviewee can find some information using a search engine? Is it really the only skill we need?

I worked with a man who could produce code only if it had been posted somewhere on the Internet. Usually, he was sitting next to someone else. It was his way of “pair-programming.” The other person was doing all of the thinking and coding. He was sitting next to the screen, staring at the window and eating potato chips.

If I must write an algorithm on a whiteboard to avoid such co-“workers” in the future, I will gladly do it.

Sad truth about your GitHub projects

Your GitHub account does not count as much as you wish it was. You can be sad because of that or get mad at me. You can start yelling, rage-tweeting, sobbing, or stamping your feet, but it will not change anything.

It would be great to discuss our GitHub projects with recruiters, but no one has time to review our code before a meeting. The only thing recruiters can do is checking whether we commit a lot of code on Github. Unfortunately, using the number of Github commits as a criterion for recruiting someone is a terrible idea. People who cheat during Hacktoberfest prove it every year.

Learning the basics

If you want to be prepared for a whiteboard interview, you do not need to study at a university for five years. In fact, you do not even need a book. You can find a textbook on Amazon, read its table of content, and google the topics on your own.

Remember, your goal is to be familiar with the topic, not to learn it by heart.

I recommend to start with those two books:

Older post

The importance of documenting things

What happens when someone asks you about your code and you cannot answer because you have no idea how it works? That happened to me… again.

Newer post

Scalar 2017

Scalar Conference 2017 — everything I liked

Related Posts

Software engineering

Query string validation in Fastify

How to validate query parameters using Fastify
Published on: 25 Jan 2019

Software engineering

Assert object pattern

The easiest way to make your tests more readable and easier to maintain
Published on: 12 Dec 2018

Software engineering

A "known bug" is still a bug

What does a "known bug" or an update say our users?
Published on: 05 Oct 2018

Are you looking for an experienced AI consultant? Do you need assistance with your RAG or Agentic Workflow?
Schedule a call, send me a message on LinkedIn. Schedule a call or send me a message on LinkedIn

>