As I’ve started to make frequent posts on LinkedIn about hiring and interviewing software engineers, the algorithm has decided I should read posts about this topic too. They usually go something like this:

Many engineers aren’t great at live interviews; I’m sympathetic towards this.⁴ I acknowledge that the interview environment isn’t similar to real world work; no engineer will perform as well as they would in the comfort of their own IDE.

I will concede that most coding interviews questions are bad. They are rarely well written and often not relevant to the role¹⁰. Ok, hopefully all of those disclaimers have gotten you to put down your pitchfork. That being said . . .

You would be surprised how many engineers can’t solve fizzbuzz. A live coding interview acts as a basic filter.

We can extrapolate this to FAANG+ companies too. Their arbitrarily difficult coding interviews filter out good candidates. It is worth taking that loss if it prevents a bad hire. You may hate finding a subtree of another tree, but questions like these accomplish their goal.

Once everyone copied Google’s style of interview and software engineers learned how to do the “algorithm grind,” this inevitably became less effective.

Good engineers understand that interviewing at FAANG+ companies is a game of practice and pattern matching. Gayle Laakmann McDowell quite literally designed these interviews in-house and then went and wrote the book on how to solve them. The cynical would say she installed the lock and then proceeded to sell you the key!⁵

Despite the gamification of these interviews, I think they remain very effective. The type of engineers that are confident and willing to do this grind are great engineers⁶. It is at least a correlation if not a causation.

Data structures & algorithms are everywhere in software engineering. Let’s take a look at a more relevant example for frontend:

If you’ve ever used document.getElementById or document.querySelector in your code, you’re utilizing depth-first search. Every web page is represented by the DOM tree, which is a data structure. To navigate trees, you’ll need a search algorithm.

Say you use a framework like React. It uses a virtual DOM which is also represented by a tree. An important part of writing good React code is understanding how to make efficient updates without impacting all the descendent components in the tree.

One thing that separates great engineers from good ones is an inherent understanding of what is happening “under the hood;” it makes you a better problem solver.

Regardless of difficulty, live coding interviews determine a lot about a candidate. Can they analyze a problem? Do they ask effective questions? Do they work well with others? Do they take suggestions and can listen for hints? How well do they use their resources?

Companies need to know you have critical thinking and problem solving skills. That is what the engineering job is about.

Because live coding interviews are so useful, they will not go away any time soon; even with the advent of AI tools. It is worth your time to practice getting better at this format rather than being frustrated by this status quo.

If that is not enough motivation, there is a much better reason to invest the time to study:

I previously shared how I bombed the Triplebyte interview in January 2020. Two months later, I had an onsite with Google. Not only did I pass the interview, I absolutely crushed it. My recruiter told me that it was a quick and unanimous decision from the entire hiring committee.

I was given an L4 offer with a total compensation of $270K and a signing bonus of $30K¹¹. My last full time role which I left less than a year prior, I was making $105K.

The point of this is not to brag¹. It’s to show the difference that two months of study can make. Looking back on it, I know that time studying genuinely made me a better engineer.

Practicing coding problems taught me to plan out my solution with pseudocode. My early projects at Square were ambiguous and involved deploying to the cloud. I had to try out many strategies and learn about the complex cloud and on-premises environments to accomplish my task. I frequently needed the help of infrastructure teams and my request was always better received when I came with a plan and a list of what I had already tried.

This process is quite analogous to the coding interview. It is tremendously useful if I understand what a candidate is thinking. If they pseudocode out their solution, they are more likely to catch their own mistakes. If they communicate well with me, I’m better able to help them and guide them. If they made a good attempt to debug on their own, I can give them a hint that won’t count against their performance².

I published a few interesting open source projects in my first year at Square. Looking back on this code, I see many good habits that I learned when grinding algorithms:

Solving interesting engineering challenges absolutely requires knowledge of data structures and algorithms. As things scale, thinking about performance is a necessity. But even if you never work on scale problems, this mindset is useful.

A few engineers on Twitter were discussing how they never needed to understand algorithms or time and space complexity in their work and it was silly to learn. Then a different person quote tweeted them and said: “I’ve worked with engineers who had this attitude and they would often break our app.”

The best senior engineers I interview are always thinking about potential bugs. Edge case consideration is something I learned when grinding algorithms. Engineering is more about preventing things from going wrong rather than just focusing on what you plan to go right.

I got promoted to a senior engineer after two years at Square. This was also my first proper software engineering job; I only had a year of adjacent engineering experience³ prior to this. Looking back, it is quite astonishing how quickly I advanced.

I owe a lot of credit to the algorithm grind for teaching me good habits and making me a better engineer. It’s hard to imagine being successful without these fundamentals.

I was always in awe of how skilled my peers were at Square. I believe there is a direct causal relationship to what the interview process tests for.

I wrote this backend / generalist question and have given it to candidates over the past month⁷. The crux of the question is to implement retry logic for sending data to a server.

Around the same time, I built a QR code check-in system for my choir. This involves the client (a web browser) sending data to a lambda / cloud function. When using it in the fall, I noticed that the server would regularly flake.

After watching engineers implement retries on my coding question, I started to wonder why I hadn’t added this to my own code. The flakes were annoying and there wasn’t any reason for users to manually make the request again. So I increased the run time of the lambda and added automatic retries to the client.

I have a number of examples of this from previous questions I wrote at Square. It is the marriage of the fundamentals and the practical knowledge of how good software is written that leads to engineering excellence. The best engineers I interviewed with this question quickly form a deep understanding of the problem. Writing these questions makes me a better engineer by extension.

When I received offers from Square and Google six years ago, people asked me how I did it. I told them that I genuinely enjoyed problem solving. I saw every algorithm problem as a fun challenge. I became addicted.

You don’t have to go quite as far but you should reframe the practice as one that will benefit you, not an obligation the software engineer interviewing world has placed upon you⁸.

If you ask people how they became successful, none of them think they are special or uniquely talented⁹. For every candidate that interviews with me, I take the time to write detailed feedback and advice on how to improve. I do this because I want them to grow and I believe in their ability to do so. I’ll leave you with this excerpt from my rejection email template: