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?

Subscribe to the newsletter and join the free email course.

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.

We may be annoyed by being asked to do such things over and over again. On the other hand, imagine what we could accomplish if we spent half as much time learning the fundamentals of computer science as we do complaining about “irrelevant” interview questions.

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 “coworkers” 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 is not going to change anything.

It would be great if we could discuss our GitHub projects with recruiters, but no one has time to review our code before a meeting.

Learning the basics

You do not need to study at a university for five years. All you need is a book or two books. In fact, you do not even need a book. You can read its table of content for free on Amazon 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.

Would you like to have a call and talk? Please schedule a meeting using this link.

Bartosz Mikulski
Bartosz Mikulski * data/machine learning 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.

Do you want to work with me at riskmethods?

REMOTE position (available in Poland or Germany)