I bombed my first technical interview. Not in a polite way — in a “the interviewer was visibly uncomfortable” way. They asked me to reverse a linked list and I started by asking what a linked list was. Three years and roughly fourteen interviews later, I’m reasonably good at this now, and I want to write down what I’d tell myself if I could go back to the version of me who was about to walk into that first one.

The first thing I’d say: technical interviews aren’t a single thing. There are at least four different formats and they reward almost completely different preparation. If you walk in trying to be ready for all of them, you’ll be properly ready for none. So step one is figuring out which one you’ve got.

The four flavours

The classic algorithmic whiteboard interview — reverse a string, find the duplicate, balance the parens — is what most online prep is aimed at. It’s still common at large tech companies and at any company that copy-pasted its hiring playbook from one. If you’re applying to a 200-person SaaS company in your hometown, you’re probably not getting this one. If you’re applying to a global firm or a well-funded startup, you probably are.

The “build a small thing” take-home is increasingly common at smaller and mid-sized companies. They send you a brief, you have a few hours or a few days, and you submit a working application. These have largely replaced the algorithm screen at companies whose hiring managers think the algorithm screen tests the wrong skills. I happen to agree with them.

The pair-programming interview is having a moment. You share a screen, the interviewer gives you a small problem and a starter repo, and you write real code while talking. The thing they’re testing isn’t your knowledge of any specific algorithm — it’s whether you can actually code in front of another person without falling apart, and whether you can communicate while you do it.

And then there’s the system design interview, which they almost never give you for an entry-level role, but some places do something gentler called a “design discussion” — show me how you’d structure the data for a to-do app, that kind of thing.

What to actually study

For the algorithmic style: pick one platform and grind it for two to three weeks. I used LeetCode’s NeetCode 75 list. The point isn’t to memorise solutions — it’s to recognise patterns. After thirty problems you start to see that two-pointer, sliding window, hash map for counts, and binary search cover something like 70% of what gets asked. Don’t go past 100 problems for your first interview. The marginal return falls off a cliff and you should be using the time on the other formats.

For the take-home: practice by building the kind of thing a take-home asks for. A small REST API with one entity and CRUD endpoints. A frontend that hits a public API and renders a list with filtering. A CLI tool that takes a CSV in and writes a JSON out. Time yourself. The biggest mistake on take-homes isn’t writing bad code — it’s spending eight hours on a four-hour task and sending in something over-engineered that screams “I don’t know how to estimate.” A clean, working, tested, slightly-smaller-than-asked-for solution beats a sprawling one almost every time.

For pair programming: practice talking through code with a friend or, honestly, with a rubber duck and a screen recorder. You will be amazed how different “I know how to do this” feels from “I can explain what I’m doing while I do it.” The interviewers I’ve spoken to on the other side of the table all say the same thing — they care about how you think and how you respond to hints, not whether you produce the optimal solution.

The day-of stuff

A few practical things that took me too long to learn. Know how to use the IDE you’ll be in. If they say “we’ll be in CoderPad” or “we’ll be using a shared VS Code Live Share session,” go and try it the day before. Don’t try to learn the tool in front of the interviewer.

Read the question, then say it back. “So I’m going to take this list of integers and return the index of the first duplicate, and if there isn’t one I return -1. Is that right?” This sounds basic. It saves entire interviews. The number of candidates who solve a slightly different problem from the one being asked is genuinely high.

Talk before you type. Even if you immediately know the answer, walk through your approach for thirty seconds. If you’re stuck, talk about what you’d try. Silence is the enemy. The interviewer can’t help you and can’t grade you if they don’t know what’s in your head.

When you’re stuck and you’ve been quiet for a minute, just say so. “I’m trying to figure out whether to use a hash map here or sort the array first — I think the hash map’s better because we want O(n), but I’m second-guessing myself.” That’s a green flag. Pretending you’re not stuck is a red flag.

If you want a second view on the algorithmic side that isn’t pure grinding, the MDN reference on JavaScript data structures is a good calm read for the language-specific quirks that catch people out — what []==[] returns, what typeof null is, why the for-in loop over an array is usually a bad idea. Interviewers ask this stuff partly to see if you’ve actually read the documentation or just absorbed habits from Stack Overflow.

The interview I bombed at the start of this post: the company didn’t hire me. The next interview after that, with a smaller team for a position I cared about more, I did fine. The one after that, I got the offer. Your first interview is almost never the one you get the job from. Treat it like cheap practice with someone who’ll give you free feedback, and the actual stakes drop in a way that makes you better at the rest of them.