Failed the Interview: Learned Stuff Anyway
I recently bombed a technical interview. It was for a role I thought I would be a great fit for. The coding challenge was something simple, something I've done dozens of times before, but I completely choked. The interviewer was super nice about it and surprisingly supportive despite watching me spiral into an hour-long panic. Afterward, I felt defeated, like a total failure who squandered a great opportunity.
If this is your first time reading patchNotes, I'm a career switcher. I came to tech from corporate accounting and finance. In my former career, I conducted tons of behavioral interviews from entry-level to leadership positions and sat for many interviews myself. I thought I knew how to prepare for interviews, but technical interviewing, especially live coding, is honestly a completely different animal. I wasn't ready, and that's ok.
I know that failing a technical interview doesn't make me a bad engineer, but I felt like a bad engineer in the moment. I’m grateful for the experience now. It helped highlight some areas where I can really improve. I wanted to share a few of my takeaways. I hope they might help you prepare for your next technical, or maybe putting this all down in writing is mainly to help me internalize these lessons for myself. 😂 Either way, here we go:
🫣 Blinders Off
Traditional wisdom tells us to find out as much about an interview ahead of time, so we know what to expect. Context cues are great. Most interviewers will share the type of interview you should expect ahead of time, which may be DSA, System Design, a whiteboard, or behavioral. They might even go as far as to tell you, at a high level, the type of problem you will be expected to solve and what technologies you are expected to use, like "implementing API endpoints in express.js" or "creating some React components".
Those clues are invaluable because they help tell us how to prepare. But a trap lurks here: if we over-prepare for a task that is too narrow, then we risk freezing on even the simplest curve ball (like I did).
🧰 Fundamentals
The more I prepare, the more I believe that the best strategy is nailing the fundamentals. Having a solid grasp on our language of choice makes it easier to solve any coding challenge, not just a narrow set of use cases. It sounds so simple, but it is actually very difficult to do. Job descriptions are loaded with frameworks and buzzwords, and it’s easy to get caught chasing new technologies or languages for every job application.
The fundamentals are un-sexy, but knowing your preferred interviewing language deeply is an advantage, and we need every advantage we can get. The key to learning deeply is practice.
🧠 Practice with Purpose
How we practice matters. But the search can be long, and it's easy to let some of our learning best practices slip. To learn effectively, we need to deeply understand a concept and then revisit it routinely to cement it into our brains. Retaining information is easier when we use processes like spaced repetition. Here's how it works:
- Learn something new
- Write quick notes from memory in Q&A format
- Add them to a spaced repetition app (I use Anki)
- Review cards when they are due (the app handles the due dates)
That's it. Adding just a few cards a day adds up over time, and the repetition is built into the software. I open my Anki application daily and review whatever cards are due. Each successive recall of that information extends the time that my brain will retain the information. It's based on some pretty cool brain science!
A common question is what belongs in our cards, and the answer is simple: anything that you want to store in your brain. You don't need to memorize every single method in every library of your chosen language; even the best programmers use documentation and language references. Focus on the fundamentals, and you can slowly expand from there.
🏗️ Build More
One of the most common pieces of advice I hear from experienced developers is that building more software is the fastest way to improve. Having a conceptual understanding of how to build an API is not enough. You need to practice doing it. What silly little problems do you encounter implementing fastAPI, what bugs did you find, and how do you fix them? Practice the types of tasks you expect to do on the job (including testing).
🧑💻 Learn Data Structures and Algorithms (DSA)
As a self-taught dev, my DSA exposure has been limited, and I’ll admit that at first I thought DSA was mostly gatekeeping. You can build software without knowing how to implement algorithms from scratch or solve LeetCode-style questions. But I’ve noticed that the more I learn about the fundamentals of DSA and the more I practice solving obscure problems, the more I feel my code improves. For my part, I'm investing some time each week working on building a deeper understanding of the core data structures and most common algorithms. The side effect is that it also helps me prepare for LeetCode-style interviews!
🔄 Rinse and Repeat
Technical interviewing is a skill. We know that skill improves with deliberate practice. Unfortunately, we can't make an Anki deck for full technical interviews, but we can still do our own spaced repetition by continuing to network and interview consistently. Each interview gives us clues as to the areas we can improve in.
📝 Final Notes
I hope that some of these observations resonated with you. Failing is part of the process, but it doesn't feel good in the moment. I'm trying to lean into that discomfort in hopes that it will make me a better engineer. There are no guarantees, but it’s worked for many people before us. It might just work for us, too!
Cheers,
Ian
P.S. patchNotes is changing, hopefully for the better.
I’m experimenting with broader topics and more casual, less polished writing. If that sounds good to you, stick around. If not, no hard feelings. You can always unsubscribe at the bottom of this email. ✌️