Preparing for a technical interview so the follow-ups don't break you
Technical interviews are rarely lost on “I don't know it.” They are lost on “I know it but can't explain it,” or on the second question. The work is drilling three levels below each decision.
How to do it
Work backwards from the job description
Paste the JD into “Competency-Based Interview Questions” and ask for one question per competency that can be followed all the way down, plus what each one is testing. You get a competency table: which items you have evidence for and which you can only talk around. The second list is your study plan.
Prepare one system you can actually explain
Take the most complex system on your résumé and use “Breaking Down a Complex System” to split it by boundaries and inputs/outputs rather than details. Aim to cover four things in two minutes: what it solves, where its edges are, how data moves, and where it bottlenecks. If you can't name the bottleneck, you probably never operated it.
Drill five whys into every technical decision
Hand your choices — the queue, the sharding, the cache — to “Five Whys, All the Way Down” and let it push to the mechanism. Why a message queue is level one; why not synchronous is level two; what it costs besides absorbing spikes is level three. The level you can't answer is the item on your list.
Say it out loud and let it find the holes
Write the answer down, or record it and transcribe, then paste it into “I Teach, It Corrects” and require errors only. It reliably catches lines like “we load-tested it” with no target stated. Emptiness is more dangerous than error: an error gets followed up, but emptiness sounds like understanding.
Rehearse the follow-up rhythm
Use “Socratic Questioning” to ask one question at a time, digging from your answer until you run out. What this trains is not knowledge but the ability to state your boundary when you don't know: what I'm sure of, what I haven't verified, how I would verify it. Interviewers weigh that heavily.
Prompts used
FAQ
Should I memorize interview questions?
Memorizing gets you through the first question. It is worth more to take each common question three whys deeper and prepare answers like “I chose A because I lacked information at the time; in hindsight B was right.” Someone who can explain the cost of a choice sounds like they were there.
How do I prepare system design without big-company experience?
Use a system you actually built, even a small one. The advantage of a small system is that you know where every number comes from. Nobody expects you to have run millions of requests; they want to see you draw boundaries, estimate magnitude, and name the bottleneck. A real small system explained well beats a copied architecture diagram.
What if I get a question I truly can't answer?
Say what you are sure of, then state the boundary: to answer this I would need X and Y. Then offer a checkable inference and how you would test it. Improvising an answer is risky in two ways — two follow-ups expose it, and it casts doubt on everything you said before.