Tue, May 13, 2025

Sometimes education just hurts

Lessons from a failed technical interview

I absolutely crushed my first technical interview.

No. Wait.

Reverse that.

I got absolutely crushed by my first technical interview. And it was completely avoidable. Let’s dissect why.

Every company does technical interviews a little bit differently. This particular company did not test on a bunch of algorithms or complicated data structures. Rather they use a minimally contrived example of work that they might reasonably ask a developer to do. This had some important upsides—it required the kind of reasoning that would be typical for a dev on a normal day and it didn’t require anything extra or out-of-the-ordinary from the interviewer. The downside, at least for me, is that when I bombed the interview it made me look that much worse.

My technical interview started with a working prototype of code that read a file, processed the data, and created an output that aggregated the data in various ways. My goal was to complete five tasks. One was to fix an error in the current code, the data aggregation was wrong. Three other tasks centered around adding to or modifying the existing data aggregations. The final task was to create an additional form of output. Importantly, none of these were particularly difficult problems. None of them really went beyond looping over and munging data. Why then did I fail so terribly?

Glad you asked. Let’s start from the ground up.

Things to do outside the interview

You should realize that the interview starts way before the interview. I don’t mean this from the perspective of the company. It’s not that they are analyzing your every move up until and after the interview itself (although that’s likely true to some degree). Rather, the interview is part of the rest of your day. It’s affected by everything before it and will affect everything after it. So let’s give the outside factors some consideration.

For me, this started the day prior. There were only 16 hours between the scheduling of the interview and the time it started. This wasn’t because the company was being uncaring but because they were trying to accommodate a compressed timeline for me. This was great of them to do but it had an unfortunate downside as I can now see in retrospect. Namely, I did not give myself enough time to prepare.

Not that I needed to grind some more leetcode problems. No, I knew that the interview would be conducted in a language that was not my strongest and that I hadn’t worked with in production in a year or more. Furthermore, I had to rearrange my normal schedule to make the interview. At the time I thought this was reasonable since the company was going out of its way to help me. However, looking back I could have easily asked for a time slot the following day. The company would have agreed and I would have given myself some crucial mental breathing room.

Speaking of which…

Take a moment to breathe

The body follows the brain but the brain also follows the body. Use this to inject some calm before, during, or after the interview. If you’ve got anxiety riding high as I myself did, don’t do what I did and attempt to ignore it. Pause for a literal minute to take slow, deep breaths. Calm breathing makes for calm thinking.

My technical interview was done mostly on my own so using 60 of the seconds that I had to calm my nerves would have been both easy and incredibly beneficial. If you’re with a few interviewers doing a whiteboard session this will likely be harder to swing but you could always ask for a couple minutes to think through the problem. Use one to breathe and the other to think.

Give yourself the best chance possible

If you have the opportunity to choose your interview time make sure that you choose a time where you know that you do your best work. If you like to hit difficult problems first thing in the morning shoot for a 9am interview slot. If you’re a night owl, go as late in the day as possible.

Give yourself the best day possible as well. If your most productive days start with a pour over, a splash of half and half, and a lightly buttered bagel, that’s your interview day routine too. For me, it’s a 4:30am wake up (kids can make you do weird things), exercise, coffee, and then breakfast with the family (eggs and bacon, please and thank you).

Whatever your ideal work day is that’s your ideal interview day as well.

The technical interview is usually not only technical

Before I choked on that first technical interview I was given a short tour of the company and met most of the development team as well as a few corporate higher-ups that happened to be in that day. I spent a minute or two meeting each dev and making a little small talk. This was probably the only good thing to come out of my time there. I had the opportunity to show, even if only briefly, that I also had soft skills.

Don’t sleep on soft skills. Companies want brilliant engineers but teams want a work environment that doesn’t feel like nails on a chalkboard. Show that you can meet and relate well to others. The classics will serve you well here.

  • Give a firm handshake
  • Make eye contact
  • Give a genuine smile
  • Use their name, “Nice to meet you, Fransisco”
  • If you have some small talk, reiterate the pleasure in farewell and use their name again: “It was good to meet you, Fransisco” (that’s fun to say)

This should be the basic template for how you meet absolutely everyone so there’s no reason not to get this down cold.

True story: I was almost painfully shy and socially awkward when I was younger even up until my earliest 20s. It was so bad that when I first met my wife she was put off enough that she wouldn’t speak to me for the next two months. I later had a class that required that I go out for about 2 hours a week and start conversations with people I didn’t know. My wife and I (yeah, I won her over eventually) did this nightly over a couple summers as well. The unsurprising outcome was that I became really proficient at meeting people. Crazy how that works.

The moral: your will make thousands of first impressions in your life. They might as well be good ones.

Things to do during the interview

At this point, we should be well-prepared for killing it in a technical interview (should). What can we do in the interview itself to help us perform the best?

Take a moment to understand the problem fully

It is foolish to answer a question you do not understand.G. Polya, How to Solve It

This is the immediate, but perhaps not the ultimate, cause of my failure. In my haste to get some code out there I did not give myself adequate time to form a good mental model about what was already going on in the code. This is a failure on multiple levels. First, it meant that as I moved through the solutions and improved my understanding of what was already going on I started to question what I had already done. Did I reason correctly about my solution to the first task? Do I have time to go back and check it and fix it if necessary? These are not questions you want to have to ask yourself during a timed interview.

The larger failure is that this is precisely the kind of thing you’ll do all the time as a developer. You will read orders of magnitude more code written by other developers than you yourself will write. Following someone else’s logic in solving a problem is an absolutely essential skill. You need to be able to show that you have that skill.

If I had it to do over again, I would write with pen and paper the flow and form of the data I would be working with. This would both clarify my mental model of the problem and act as a reference when I get lost in some particular aspect of a task later on.

Take the time to understand the problem. It will not be time wasted.

Show what you know

This is the raison d’etre of the interview. It’s the whole point. You want to be able to show (but not show off) what you know. Go about that the best way you can.

Start naively with an unoptimized solution. This is a version of Gayle Laakmann McDowell’s advice to state the brute force solution first. This will help you make sure you understand the problem and convey that same information to your interviewers.

In my case, I knew I would be rusty with the standard methods for certain operations (datetime logic, the proper format for lambda functions, and multiline strings all tripped me up slightly). So my best bet after wrapping my head around the data flow and the problem space would have been to insert logic or pseudocode with comments into the code. Of the five tasks I had before me, I had a basic idea about how to accomplish five of them. What I failed to do was convey that. Commented pseudocode would have been an easy way to show that I understood the problem and understood at the very least the beginnings of a solution even in the absence of concrete, working code.

Don’t be clever though; be clear

One of my favorite solutions to the classic fizzbuzz problem takes a bit of a unique approach. Honestly, I don’t know that the idea for this solution originated with me—I kind of doubt it—but I implemented a version in Javascript. It’s a normal fizzbuzz solution but the catch is this: the code doesn’t include any of the letters in fizzbuzz. It’s not particularly difficult to implement. Using hex character code points and alternative looping patterns will pretty much get you there:

j='\x46\x69\x7a\x7a';
k='\x42\x75\x7a\x7a';
[...Array(100)].map((_,m) => {
    console.log((++m % 3 ? '' : j)+(m % 5 ? '' : k) || m)
})

It’s ridiculous and silly. But that’s why I like it.

That’s also why it makes a terrible answer for fizzbuzz in an interview. It’s a fun and needlessly complicated solution. It’s not code anyone should ever write other than as a joke.

If we are to follow the wisdom of “show what you know” that means our code needs to be readily understood. If you find yourself taking a long time to explain any one part of what you’ve written, you may have over-complicated the problem or over-complicated your code. Cleverness invites complexity.

When I practice implementing algorithms I try not to use convenience methods in a language’s standard library. No .forEach or .map in JS. No for index, value := range in Go. Just plain, boring loops. Refusing to abstract as much as possible forces me to understand on a granular level what’s going on in the algorithm. Code golf is fun and all but getting a job is a lot more fun.

Clear code is easier to explain than clever code. Make it easy on yourself. Write clear code not clever code.

Be an educator

Showing what you know is essentially educational. Teaching what you know is a skill that will serve you throughout your career not least in the technical interview and there are any number of other outlets for this skill:

  • Leading a team of developers
  • Onboarding or mentoring new and junior developers
  • Tech talks
  • Reporting or support for outside stakeholders of a project

Become practiced at explaining yourself. There’s a reason we needed the term rubber ducking in the first place. However, remember this bit of wisdom: you know what you know and by extension the other person knows what they know (groundbreaking right?). What I mean by that is you need to both be confident in the knowledge you have but humble so that you realize you don’t have all the knowledge there is.

No one likes pedantic people and everyone dislikes being on the infuriating end of condescension.

Things to do after the interview

Do a post mortem (or hopefully a post vitam). Whether the interview went well or poorly the best thing you can do is understand why. This, as you may have guessed already, is my post mortem. Writing this out has helped alleviate some of the intense embarrassment of doing something so poorly that I could have done so well.

At the end of the day, code is about iteration. We iterate over input, iterate over dev cycles, and iterate over releases. Iterate over interviews as well. Hone in on what works and what doesn’t. This is not a comprehensive guide on technical interviews but my iteration over the many things I did poorly and the few I did well. Hopefully some of this will be helpful to you, it’s been helpful for me.

In the end, failure is the best teacher. Make sure to learn its lessons or it’ll return again and again.