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 tree1, 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 showcase how a candidate approaches an unfamiliar problem, breaks it down, and explains their thinking. That sounds good, but problems like these usually assume knowledge of rarely used data structures or techniques. Most engineers learn them in school and then forget with disuse, like calculus. Some self-taught engineers, like me, never studied them at all.

Coding in a simulation

After the layoff, 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 encountered my first typical software engineer interview.

This is not what I had in mind.

I failed my first few interviews with algorithm problems. I sighed, practiced interview questions, and started passing. I was not a better programmer, I was just better at solving interview questions.

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? Of course not, but they sure know their trees and algorithms because that’s what they just finished studying.

Reality is a simulation

A common suggestion is that technical challenges should be as close to real-world problems as possible. Well, I also inexplicably failed a couple easy real-world problem based challenges2. It wasn’t that I didn’t satisfy the requirements, but there was some other hidden criteria that I had violated. I will never know what they were.

Sometimes realistic challenges fall into an uncanny valley. They try to simulate a real-world assignment, but the code candidates write will not be like production code. Candidates don’t know your team’s preferences, philosophies, and life choices. They don’t know how rigorously you want them to 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.

Just right

Thankfully, many good companies had problem solving sessions that were more balanced and didn’t assume a formal education in computer science. They were still challenging and required creative thinking, but also more inclusive of engineers with alternative backgrounds. 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 the engineers encountered on the job, which means it’s relevant but still challenging. Many “real-world” exercises are simply about execution (and meeting some hidden criteria) with little creativity.
  • 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.

Notes

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 were trying to get into Facebook or Google it would probably be worth paying for, but I am not.
  • Interview Cake walks you through common concepts that come up and gradually reveals hints if you need them. Kind of studying to the test, but generally it covers practical knowledge.

  1. Not the wooden kind. Trees are an all-purpose data structure in programming. They are very good for specific problems, but I have never had to use one in my life.

  2. At this point you might be wondering if I'm actually just bad. M... maybe?