My first encounter with software engineer interviews

I just finished a job search and I’m very happy to have found a great company to join. I’m also happy to be done with interviews. This was my first time encountering the typical software engineer interviews that I’ve heard so much about.

I was recently laid off, all the R&D positions were being moved to other countries with three months’ notice. Many of the affected engineers started practicing with each other to prepare for technical interviews. Curious, I sat in on some sessions. I was horrified. Do companies actually ask candidates contrived algorithm questions, asking them to balance a tree¹, find palindromes, or navigate a grid to map out islands?

Oh wait, that last problem is the one we gave to our candidates. For some reason, I wasn’t given an algorithm question when I interviewed there. In fact, I had somehow gone 15 years without answering a single algorithm interview question.

Problem solving sessions are meant to test how a candidate approaches an unfamiliar problem, breaks it down, and explains their thinking along the way. That sounds good, but often problems like these assume knowledge of rarely used data structures or techniques. Most engineers learn them in school and forget them over time, like calculus. Some self-taught engineers, like me, never studied them at all.

Coding in a simulation

In my unemployment, I learned to bake bread, slept in, and read a lot of books. Several months passed until I was ready to join another company. I started interviewing and promptly encountered my first typical software engineer interview.

I failed my first few interviews with algorithm problems. After some self-loathing, I mindlessly practiced algorithm problems online. I started passing. I was not a better programmer, I was just better at solving interview questions.

Soon after, I spoke to a former coworker who wanted some advice on hiring. He was surprised that developers fresh out of school were doing much better on their problem solving sessions than senior ones. Are freshly minted developers better at programming than ones who have been working in industry for many years? Probably not, but they sure know their trees and algorithms because that’s what they just finished studying.

Reality is a simulation

A common suggestion for making interviews better is to make the problems as realistic as possible. Well, I also inexplicably failed a couple easy real-world based problems². It wasn’t that I didn’t satisfy the requirements, but there was some other hidden criteria that I failed. I will never know what they were.

Sometimes realistic problems fall into an uncanny valley. They try to simulate a real-world task, but the candidate’s code is not exactly like production code. Candidates don’t know your team’s preferences, philosophies, and life choices. They don’t know how completely they should test something, or if you just want to see if they can write “reasonable” code.

I started asking for explicit evaluation criteria for these types of challenges, but I never received specific answers. I don’t know why some companies approved and others didn’t, maybe they just liked or disliked my style.

Simulating the simulation

Thankfully, many companies had problem solving sessions that were able to overcome the uncanny valley with practical concessions. They were still challenging and required creative thinking, but they didn’t require special knowledge. Here are some attributes they had in common:

• If there was an algorithm involved, it was explained in the problem. I could demonstrate understanding and ability with algorithms given a description. Data structures and fundamental programming were tested along the way.
• The problem was based on a tough real problem that you may encounter on the job, which means it is relevant, but still challenging. Many bad real-world exercises are simply about execution (and meeting some hidden criteria) with little creativity, like creating a class or re-implementing a common library.
• I used my own local developer environment instead of a janky web editor environment.
• The interviewer asked clarifying and probing questions if I was not on the right track. An interview is an artificial environment, interviewers should serve as bumpers to keep the candidate from going off the rails. You don’t get (much) signal by watching someone go down a rabbit hole.

The best preparation was practicing to code in an interview-like setting so I didn’t feel as nervous.

• Pramp is free, it pairs you up with another person and you will take turns interviewing each other. It’s hit or miss with partner quality, but I still found the practice useful.
• interviewing.io has one or two free sessions. If I wanted to get into Facebook or Google, it would probably be worth paying for, but I do not.
• Interview Cake walks you through common concepts that come up and gradually reveals hints if you need them. It feels like studying to the test and I didn’t like a few exercises, but it generally covers practical knowledge.