I recently went through a full software engineering job search. I had a system — applications on Notion, notes on each company in Apple Notes, and Claude open in another tab to prep for every round. I'd copy-paste my notes in, ask it to quiz me, and feel reasonably ready.
Some interviews went well. Others didn't, and I knew exactly why the moment I walked out.
Here are the five things I kept getting wrong, and what I'd actually do differently.
1. Talking about tools I didn't fully understand
In two different system design rounds, I mentioned Kafka as part of my architecture. In one of them, the interviewer asked me to go deeper — how does Kafka handle consumer group rebalancing? What are the trade-offs between at-least-once and exactly-once delivery?
I knew enough to name-drop it. I did not know enough to defend it.
The same happened with Temporal for workflow orchestration. I'd read about it, seen it come up in design discussions, and included it in an answer. The follow-up questions exposed exactly how thin my understanding was.
What I'd do differently: If you're going to include a technology in your design, make sure you can answer two levels of "why." Why did you choose this over alternatives? And what are its failure modes? If you can't answer those, don't put it in your design. It turns a strength into a liability.
2. Defaulting to one architecture style without being able to defend it
I got comfortable with event-driven architecture. It's elegant, it scales well, and I'd used it in real projects. So I started applying it... everywhere. E-commerce platform? Event-driven. Ride-sharing backend? Event-driven. Notification system? Obviously event-driven.
The problem wasn't that I was wrong — sometimes it was the right choice. The problem was I couldn't articulate why it was right for this specific problem versus the alternatives. Interviewers noticed.
What I'd do differently: Pick your preferred architecture, but make it a habit to also sketch the simpler alternative. A CRUD-heavy REST API might solve 80% of a problem with a fraction of the complexity. When you choose the more sophisticated path, you should be able to say: "Here's what we lose with the simpler approach, and here's why that trade-off matters for this use case." That's what senior engineers sound like.
3. Not writing enough actual code before LLD and machine coding rounds
This one hurt the most because it was so preventable.
I'd done plenty of system design practice, but for Low Level Design and machine coding rounds, I thought my general coding ability would carry me. What I underestimated was how rusty I was with specific patterns — building a thread-safe cache in Java, implementing a rate limiter from scratch, working with concurrent queues.
I knew these concepts. I had used them. But I hadn't written them from scratch in a while, and it showed in the round. I was reaching for library internals I couldn't quite recall, hesitating on edge cases I should have nailed immediately.
What I'd do differently: In the two weeks before any LLD-heavy loop, write the classics from scratch. LRU cache. Rate limiter. In-memory pub-sub. Task scheduler. Not to copy solutions — to get your hands fluent again. The gap between "I know this" and "I can build this under pressure" is wider than it feels until you're in the room.
4. Solving DSA problems instead of understanding them
For most of my prep, my workflow was: read the problem, think through it, look at the solution if stuck, understand the solution, move to the next one. Progress felt linear. My solve rate was going up.
What wasn't improving was my ability to generalize. I'd practice sliding window for a week and still get tripped up by a variation I hadn't seen before.
The shift that actually worked: after solving any problem — or even after reading a solution — I'd open a conversation with an LLM and ask it to break down why the solution works at a conceptual level. What invariant does the sliding window maintain? Why does this greedy choice work here but not in a similar-looking problem? What would break if I changed this constraint?
Getting a green tick is not the same as understanding the problem. The conversation after the solve is where the learning actually happens.
What I'd do differently: Cut the number of problems and double the time per problem. For every problem solved, have a five-minute conversation about the underlying pattern. Ask: what's the minimum insight required to recognize this problem type? What are three variations where this approach fails? That kind of deliberate practice compounds much faster than raw volume.
5. Not knowing how to use AI well in the prep process
I was using AI constantly. But I was using it passively — paste notes, ask for a quiz, accept whatever came back.
The underrated skill I should have been developing is knowing how to direct AI effectively. That means two things in an interview context:
First, being specific about what you want. "Help me understand why Raft uses randomized timeouts" gets a much better answer than "explain distributed consensus." The quality of what you get back is a direct function of how precisely you can articulate what you need.
Second — and this one matters for using AI during actual interviews at companies that allow it — learning to constrain it. AI is enthusiastic. Ask it to write a rate limiter and it will write a production-grade, fully-commented, edge-case-handled implementation that goes three levels deeper than the problem requires. In an interview, that's noise. You need to be able to say: "Write only the core logic for X, assume the happy path, skip error handling" and get something useful.
Being able to use AI well is itself a technical skill now. Like any tool, using it poorly can make your output worse, not better.
The pattern underneath all of this
Looking back, every one of these mistakes has the same root: I was optimizing for coverage over depth. More companies applied to, more problems solved, more topics touched. What I should have been doing was going deeper on fewer things — and tracking where my understanding was actually thin.
The note-taking I was doing in Apple Notes was better than nothing. But it was scattered, unstructured, and completely disconnected from what I was doing in Notion and what I was asking Claude. I couldn't see patterns across interviews. I couldn't track that I'd gotten the same Kafka follow-up question twice without a good answer. I couldn't see that my confidence on distributed systems questions had been low for two months.
That's the gap I eventually built Lytmus to fill — one place to track every application, every round, every question, and let the data show you where you're actually weak. The AI coach in Lytmus doesn't give generic prep advice. It reads your actual confidence scores and targets the specific gaps in your history.
If you're in an active job search, give it a try. It's free.