Reversing a binary tree and other great interview questions

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

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?

Would you like to help fight youth unemployment while getting mentoring experience?

Develhope is looking for tutors (part-time, freelancers) for their upcoming Data Engineer Courses.

The role of a tutor is to be the point of contact for students, guiding them throughout the 6-month learning program. The mentor supports learners through 1:1 meetings, giving feedback on assignments, and responding to messages in Discord channels—no live teaching sessions.

Expected availability: 15h/week. You can schedule the 1:1 sessions whenever you want, but the sessions must happen between 9 - 18 (9 am - 6 pm) CEST Monday-Friday.

Check out their job description.

(free advertisement, no affiliate links)

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:

Remember to share on social media!
If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.

If you want to contact me, send me a message on LinkedIn or Twitter.

Bartosz Mikulski
Bartosz Mikulski * MLOps Engineer / data engineer * conference speaker * co-founder of Software Craft Poznan & Poznan Scala User Group

Subscribe to the newsletter and get access to my free email course on building trustworthy data pipelines.