A Field Guide to Cracking DSA and Technical Interviews
“You don't crack an interview in the room. You crack it in the two hundred problems nobody ever watched you solve.”
Written directly to whoever is preparing for their own interviews — the exact things I wish someone had told me plainly, without the vague encouragement that fills most advice on this topic.
- 01
Start with the shapes, not the problems
There's a genuinely small number of underlying patterns behind the enormous volume of practice problems online: two-pointer techniques, sliding windows, breadth-first and depth-first traversal, dynamic programming built on overlapping subproblems, backtracking. Organize your early practice explicitly around recognizing these shapes underneath unfamiliar descriptions. Pick a pattern, work a cluster of problems on that pattern until recognition is automatic, then move on. Random practice feels productive; structured, pattern-first practice builds transferable recognition far faster.
- 02
Talk out loud, every time, starting now
Silent problem-solving and narrated problem-solving are genuinely different skills, and an interview only tests the second. Record yourself narrating a solution occasionally and listen back — almost everyone is surprised how much less clear their spoken reasoning is than it felt inside their own head.
- 03
Get comfortable being wrong in front of someone
You will take wrong turns in real interviews. Everyone does. What separates a strong outcome from a weak one is whether you can notice it, say so calmly, and correct course without your composure visibly collapsing. Practice the specific language: "I'm noticing this approach won't handle this edge case cleanly, let me reconsider" — said calmly, is a skill in itself.
- 04
Understand tradeoffs, not just labels
An interviewer asking about complexity is rarely testing whether you can name it. They're testing whether you understand why it is what it is, and whether you can identify a different approach with a different tradeoff if the constraints changed. Practice by asking what happens to your solution's complexity if the input were ten times larger, or if memory were far more constrained than time.
- 05
Mock interviews are not optional
The specific pressure of being watched while thinking has to be practiced directly, the same way public speaking does even by someone who knows their material cold. The discomfort of doing this a handful of times in low-stakes practice is dramatically cheaper than experiencing it for the first time in an interview that actually matters.
- 06
Treat rejection as data, not verdict
I did not pass every interview I ever sat for. Nobody who has interviewed extensively has. The engineers who improve fastest extract a specific, actionable lesson from a rejection rather than absorbing it as a broad judgment about their overall ability.
- 07
Don't skip system design and behavioral rounds
At a first-job level, system design rounds test whether you can reason clearly about tradeoffs at a small, honest scale — not whether you can architect a global platform. Behavioral rounds test whether you can describe a real situation honestly, with a clear account of what you did and learned. Prepare two or three genuine stories, even from college projects, and tell them clearly rather than searching for a more impressive one.
Next guide
A Field Guide to Landing Your First Job
Open to the next thing
I don't know what I'm building next. I know exactly how I'll start — badly, immediately, and without waiting to feel ready.
If you're hiring for something senior and technical, want a sole owner's eye on your product, or just want to talk about charts that lag, I read every email myself.