You have a job description, a date on the calendar and a pile of tabs open. That is the moment to stop treating technical interview preparation as a list of subjects to finish.
The work is to predict the conversations you may face, then practise the parts where your explanation falls apart. A coding prompt can expose how you choose an approach. A system design discussion can expose whether you can name tradeoffs. A project discussion can expose whether you actually owned the decisions on your resume.
Start with the job description and the conversations it suggests.
Why more LeetCode isn’t a plan
Coding practice matters when the interview includes coding. It is a poor substitute for the rest of the loop.
Someone can solve a familiar medium problem alone and still struggle when asked why they chose a hash map, what breaks at ten times the input size or how they would test a boundary case. The missing work is often verbal: stating assumptions, rejecting an approach, checking the result and changing course when a follow-up lands.
Use coding problems as rehearsal material. Before opening an editor, say out loud what you would clarify, what constraints matter and how you will know the first version is correct. Then write the code. The explanation is part of the practice, not a speech added after the solution works.
If you need a place to organise that work across interview types, see interview preparation.
Read the job description for round signals
A job description will not hand you the interview schedule. It does show what the team is likely to spend time probing.
Mark every sentence that asks for a repeated kind of judgment. “Design and operate data pipelines” points to architecture, reliability and tradeoffs. “Partner with product and design” points to decisions made with incomplete information. “Improve latency and cost” points to measurement, constraints and a project story with numbers you can defend.
Then turn each signal into a question you might hear. Do not stop at a topic label such as “distributed systems.” Write the question that would make you reach for your own experience.
A fictional JD to round map
The following is fictional. It is a planning exercise, not a claim about any employer’s process.
Fictional job description: A product team needs a software engineer to build a workflow service used by internal operations staff. The role mentions TypeScript, PostgreSQL, API design, on-call participation, performance work and close collaboration with product managers.
| JD wording | Round to prepare for | What to rehearse |
|---|---|---|
| Build reliable workflow APIs | Coding and API design | Model inputs, idempotency, validation, failure responses and tests. |
| PostgreSQL and performance work | System design or project discussion | Index choices, query measurement, read/write patterns and the cost of a shortcut. |
| On-call participation | Behavioral judgment | A real incident, the first signal, what you changed and what you would do differently. |
| Work with product managers | Project discussion | A requirement that changed, the options considered and how the decision was made. |
This table is small on purpose. Four well-prepared threads are more useful than twenty vague topics.
Prepare the four conversations
Coding
Pick problems that resemble the level and language you expect to use. For each one, rehearse a repeatable sequence:
- Restate the problem and ask one useful question.
- Name a straightforward solution before choosing a better one.
- Explain time and space cost in plain language.
- Test an ordinary case, an empty or smallest case and a case that breaks an assumption.
- Say what you would change if the input or service constraints grew.
Keep a short log after every problem. If you ran out of time because you started coding too early, write that. If recursion made the explanation muddy, write that too. The log should record the failure you can fix next, not whether you got the answer eventually.
System design
For system design, practise choosing a boundary before drawing boxes. Start with the user action, the data that must be stored and the first constraint that changes the design. “Design a feed” is too broad to rehearse well. “Design a feed that shows a team’s latest deployment events within a few seconds” gives you something to reason about.
Work through one design on paper or a blank document. State the simple version first. Add a queue, cache, replica or background worker only when you can name the pressure that requires it. Then ask yourself the follow-ups: What happens when the worker retries? Which data can be stale? What do you measure before adding another service?
For a focused version of this practice, use system design interview practice.
Project discussions
Choose two projects from your resume. For each, make a one-page memory aid with five prompts:
- What problem existed before the work began?
- What did you personally decide or build?
- Which option did you reject and why?
- What evidence told you the change helped or failed?
- What would you change now?
Do not write a polished story and memorise it. Keep notes that bring back the details. Interviewers can ask about an awkward tradeoff, a dependency that delayed you or a metric that moved in the wrong direction. A real answer has edges.
Behavioral judgment
Technical teams also need to know how you make decisions with other people. Prepare examples involving disagreement, a missed expectation, an incident, a change in scope and a decision made with incomplete evidence. The useful detail is your judgment: what you knew then, what you did next and why.
Software engineer behavioral interview practice is a good place to rehearse the words around those decisions before the technical parts of the story get lost in detail.
Rehearse the explanation, not just the answer
A follow-up changes what counts as a useful answer.
Vague answer: “I improved the checkout service by adding caching, so it was much faster.”
Likely follow-up: “What was slow, what did you cache and how did you know the cache was safe?”
Improved answer: “The endpoint spent most of its time loading product eligibility from a service that changed a few times per day. I cached that result for five minutes, but kept payment status out of the cache because it changed during checkout. I compared p95 latency before and after in our existing dashboard, then watched error rate after release because stale eligibility would have shown up as failed orders.”
The improved version is not longer for the sake of it. It gives the interviewer handles: the slow path, the decision boundary, the risk and the check after release. Practise until you can provide those handles without reciting a script.
Run a timed mock before you feel ready
A timed mock exposes a different problem from solo study: context switching. You may need to move from a coding exercise to a project question, then defend a design decision when you are already tired.
Set a timer, remove your notes and use the format you expect. Record where you spend time. Did you ask no clarifying questions? Did your design stay abstract for fifteen minutes? Did you tell a project story without saying what you did?
For an example of a voice-based practice session that presses on those gaps, read AI mock interview practice that feels real. If your target role is AI engineering, use the AI engineer mock interview page to shape the technical topics around that role.
Use the report to choose the next drill
After a mock, do not try to improve everything at once. Read the feedback for one repeated weakness and turn it into the next 30-minute drill.
If the report shows that your coding answers skip edge cases, do two problems where the only goal is a spoken test plan. If your system design answers name tools without constraints, redraw one design and forbid yourself from adding a component without a reason. If your project answers sound generic, rehearse one decision you made and the evidence behind it.
The next drill should be small enough to finish today. You are building a sequence of corrections, not collecting more material.
A seven-day plan before a technical interview
Adjust the order when your interview is sooner. The point is to alternate knowledge work with spoken practice.
| Day | Work |
|---|---|
| 1 | Mark the job description, make the JD-to-round map and choose two projects. |
| 2 | Complete two coding problems aloud. Review the moments where you skipped assumptions or tests. |
| 3 | Design one system from the job’s domain. Write down the first constraint behind each component. |
| 4 | Rehearse both project discussions with follow-up questions. Keep the parts you cannot explain in one sentence. |
| 5 | Run a timed mock with coding, design and behavioral questions. |
| 6 | Choose one weakness from the mock and drill only that weakness. Do a shorter second mock. |
| 7 | Review your notes, prepare questions for the interviewer and stop adding new topics. |
The last day is often where people panic and start another course, another problem set or another system design template. Resist that urge. Review the evidence you already collected about where your answers go thin.
When you want to rehearse the role you are actually targeting, start a voice interview with your job description at Openskill.