Why you wind up doing coding puzzles in interviews

Listen to the podcast of this post!

I’ve seen a number of posts recently (most of them comic) about the differences between interviewing for being a software engineer and actually being a software engineer. They usually start something like this

I’ve been an engineer for 15 years and I’m changing jobs so I decided to forget all of my work experience and dusted off my data structures and algorithms text book from 1998 to get ready for the interview…

or

You’ll never believe what happened at work the other day! A customer walked in and demanded to know the runtime of a bubble sort. It was good I (a senior engineer) was there and knew to tell them they should use merge sort instead…

I agree with the sentiment here — interviewing for a software engineering job is usually pretty different from what you do on the actual job. Interviews often focus on coding puzzles, data structures and algorithms, and computer science fundamentals. The real job focuses on business problems, performance, scalability, and writing maintainable code.

So why do you wind up doing coding puzzles in interviews?

To answer that question let’s talk about a few things I don’t really care about as an interviewer.

I don’t really care what frameworks or languages you’ve used

Sure, maybe every once in a while a job will have really specific framework experience requirements. Maybe you’re interviewing for a team that’s ML/AI focused and you need to know pytorch. Maybe you’re joining a team that insists on prior RoR experience. Maybe you’re joining a team that does embedded systems and needs to know C.

But in general for most teams and jobs I don’t really care what languages or frameworks you’ve used. I want to hire people who can write good code, problem solve, and dialog about the pros and cons of a solution. It doesn’t really matter if you’ve used <insert technology or language here> that my team chose to use right now because tomorrow that could easily change.

Rather than try to hire for specific experience now I’d rather hire someone who knows how to learn new technologies and dig into them.

I don’t really care what projects you’re willing to claim you contributed to

It’s just not helpful information. I’ve worked with people who could claim they participated in a project, but had no material understanding of the goals or tradeoffs we made.

On the flip side of the same coin I’ve had my designs reviewed by people who got very in depth in the details but never wrote a line of code for the project.

The engineer from the first example can claim they contributed to the project and brag about the revenue and impact, but didn’t do anything useful on it. The second engineer can’t claim they contributed, but have enough context to talk about tradeoffs and decisions.

I’d rather hire the second, but if I ask about project contributions they won’t stand out.

I don’t really care about your previous title

I’ve worked with architects who couldn’t explain what a single point of failure was. I’ve worked with directors who could give you useful feedback on a CR. I’ve worked with senior engineers who refused to learn anything new, and I’ve worked with front end developers who could run circles around the other examples.

Your previous title doesn’t prove anything to me. Different organizations have different standards, and I’m not going to base a hiring decision on that.

I don’t really care about your domain knowledge

Every software engineering job involves picking up domain knowledge. I’ve had to learn about insurance, cyber security, health care, and logistics. But I don’t really care if a candidate has that knowledge coming into the job.

I also don’t really care about the domain knowledge that you’ve picked up previously. Sure, I like you to be able to give me some context on your projects, prove that you understand business problems, and provided value, but the exact design of a flux capacitor isn’t relevant to the interview.

I don’t really care about your snark

I’ve seen this a number of times in an interview. Some candidates have the impression that criticizing their previous employer, their technical decisions, or the skills of their previous team will make them sound smart. As if by being smart enough to say something negative they’re proving that they’re smart enough to work on my team.

And I don’t really care about it. It’s good to be able to call out problems, but it’s much easier to see them than it is to fix them.

So what do I care about?

So I don’t care about previous experience, projects, domain knowledge, or snark. And I do care about candidates writing good code, problem solving, and dialoging about pros and cons of a solution.

I need a common denominator between me (the interviewer) and you the candidate that can get you doing those three things. And I need it to happen in less than an hour because we’ll spend a few minutes on introductions, a few minutes doing some behavioral questions, and hopefully most of the time seeing you code.

I can’t ask you domain questions because those will take way, way too long. I can’t give you a starter java web server and expect you to use lombok annotations to create endpoints, because I don’t care about your familiarity with those technologies. And I can’t just trust you to write code relevant to your previous domain and convince me it’s real.

So what am I left with?

Coding puzzles

I’m left with coding puzzles.

Pithy problems that you can read in < 2 minutes, grok in < 5 minutes, explore edge cases in < 5 minutes, and solve in ~20 minutes in a reasonable language.

I need them to force you to write 50–100 lines of code. Not a ton, but enough to show that you can keep a block of code in your head.

It needs to have a couple of solutions. Ideally a really good one (say O(n)), an ok one (say O(n log n)), and a bad one (say O(n²)). And I need to know that you know how good or bad your solution is and be able to communicate it clearly.

That gives me room to ask the question, “What would you improve if you had unlimited time?” And get you to dialog about your solution.

So I agree — coding puzzles are ridiculous. You don’t do anything like them in a real job. But they are an easy way to dig into the skills that do matter for an actual job in a short amount of time.

For anyone hoping they can shame companies into stopping the coding puzzles, I doubt you’ll have much success.