Technical Interview Prep: How to Practice Coding and System Design

A technical interview is a strange test. You're asked to solve a problem you've never seen, in a limited time, while explaining your thinking to a stranger who's taking notes. Being a good engineer helps, but it isn't enough. The skill being tested is partly engineering and partly performance under observation.

The good news is that both parts are trainable. Candidates who prepare with a plan, practicing patterns instead of random problems, rehearsing out loud, and learning a repeatable system design structure, consistently do better than equally skilled candidates who don't.

This guide covers the formats you'll face, how long to prepare, an eight-week study plan, a six-step framework for live coding, a system design method with a worked estimation example, and the behavioral round most engineers underprepare for.

What a technical interview actually tests#

Most companies score technical interviews against a rubric. The exact labels vary, but nearly all rubrics measure some version of the same four or five dimensions. Knowing them changes how you practice.

Notice that only one row is about writing code. A candidate who finds the optimal solution in silence can score below one who reaches a slightly slower solution while clarifying requirements, explaining trade-offs, and testing carefully.

Why the bar is high#

Technical interviews guard some of the best-paid jobs in the labor market, so employers invest in screening. The Bureau of Labor Statistics reports a median annual wage of $135,980 for software developers in May 2025, and projects 10% employment growth for the occupation from 2025 to 2035.

Across all computer and information technology occupations, the BLS median was $109,470, about double the $50,980 median for all occupations. High pay attracts many applicants, and employers respond with multi-round technical loops.

Technical interview formats you'll face#

Before you study, find out which formats your target companies use. Recruiters will usually tell you if you ask, and many companies publish prep guides. Amazon's guide for mid-level software engineers, for example, describes an online assessment with two coding questions in 90 minutes, followed by a loop of four 55-minute interviews covering technical and leadership competencies.

Technical interviews outside software engineering#

"Technical interview" doesn't only mean algorithms. Data, infrastructure, security, and support roles all have technical rounds with their own flavor.

If you're targeting one of these roles, adapt the plan below: swap some algorithm practice for the format your role uses, and keep the communication framework, because it applies everywhere.

Questions to ask your recruiter about the format#

Recruiters want you to do well, since their success depends on hires. Before you plan your study time, ask:

• How many rounds are there, and what does each one cover?
• Will I write code in a shared editor, an IDE, or on a whiteboard? Can it run code?
• Can I choose my programming language?
• Is there a system design round, and how senior is the expected depth?
• Is there a take-home, and how long are candidates expected to spend on it?
• Are AI assistants or documentation allowed in any round?

Write the answers down. They tell you how to split your time between coding, design, and behavioral prep.

Preparing for a SQL or data technical interview#

Data interviews usually test whether you can turn a vague business question into a correct query and a sensible metric. Practice writing queries by hand, then explaining the result in plain language. Expect joins, aggregations, window functions, date handling, and at least one question about how you'd define or validate a metric.

How long to prepare: pick your timeline#

The right timeline depends on how recently you've solved interview-style problems and whether you need system design. Be honest about your starting point.

An 8-week technical interview study plan#

This plan assumes about eight to ten hours a week and a mid-level target role with both coding and system design rounds. Shorten or stretch it to match your timeline.

1. Week 1: Fundamentals. Arrays, strings, hash maps, sets, stacks, queues. Re-implement each core structure once. Solve easy problems to warm up your coding fluency.
2. Week 2: Linear patterns. Two pointers, sliding window, prefix sums, binary search. Start an error log of every problem you miss.
3. Week 3: Trees and graphs. Tree traversals, BFS, DFS, topological sort. Draw every problem before coding it.
4. Week 4: Heaps, intervals, and greedy. Priority queues, merging intervals, scheduling problems. First timed mock interview at the end of the week.
5. Week 5: Recursion and dynamic programming. Backtracking, memoization, and bottom-up tables. Start system design: read the framework and the building blocks.
6. Week 6: System design practice. Design two systems end to end, out loud, with a timer. Keep two coding sessions a week to stay sharp.
7. Week 7: Mixed practice and behavioral. Random problems from all patterns, two mock interviews, and six to eight engineering stories written in STAR form.
8. Week 8: Simulate and taper. Full mock loops, re-solve your error log, and reduce volume in the final days so you arrive rested.

The chart below shows how one candidate might spread time across the three areas. It's a model, not a requirement; shift hours toward your weakest area.

What a good practice session looks like#

A 90-minute session beats a scattered evening. Use the same structure each time:

• Warm-up (10 minutes): re-solve one problem from your error log without looking at your old answer.
• New problem, timed (30 minutes): talk out loud as if an interviewer were present.
• Review (20 minutes): compare with a strong solution and note the pattern and your specific mistake.
• Second problem, same pattern (25 minutes): lock in the pattern while it's fresh.
• Log (5 minutes): record the pattern, the mistake, and a date to re-solve it in three to five days.

How to practice coding problems the right way#

The most common prep mistake is volume without reflection. Solving 300 problems and forgetting why each solution worked builds less skill than solving 100 and reviewing each until you can explain it.

Learn patterns, not problems#

Interview problems are built from a limited set of patterns. When you see a new problem, your job is to recognize which pattern it resembles. This table lists the core patterns and the signals that point to each.

Use the 25-minute rule#

If you've made no progress after about 25 minutes, read a hint or the solution. Struggling longer has diminishing returns. Then close the solution, wait a day, and re-solve the problem from scratch. The re-solve is where the learning happens.

Keep an error log#

An error log turns practice into progress. Every time you miss a problem or need a hint, write one line about why. After a few weeks, patterns emerge: maybe you consistently forget to handle empty inputs, or you reach for brute force on every graph problem. Those patterns tell you exactly what to drill.

Practice in conditions that match the interview#

Many interviews use a shared editor without autocomplete or a debugger. Amazon's prep guidance, for example, asks for syntactically correct code rather than pseudocode and suggests practicing without an IDE. If your interviews will be like that, do at least half your practice in a plain editor, and get used to tracing code by hand.

To see which technical skills a given posting emphasizes, the technical skills generator groups the tools and concepts common to your target role, which helps you decide what to review beyond algorithms.

How to think out loud: a 6-step live coding framework#

Interviewers can't score what they can't hear. A fixed sequence keeps you talking productively, and it gives you something to fall back on when nerves hit.

1. Clarify. Restate the problem and ask about input size, data types, edge cases, and what to return. Two or three questions is usually right.
2. Work an example. Walk through a small input by hand, including one edge case. This often reveals the pattern.
3. Propose an approach. State the brute-force solution first, give its complexity, then improve it. Get the interviewer's agreement before coding.
4. State the complexity. Give time and space for your chosen approach, briefly.
5. Code. Narrate at the level of intent ("Now I'll slide the window forward"), not every keystroke. Use clear variable names.
6. Test. Trace your example through the code line by line, then try edge cases: empty input, one element, duplicates, very large values.

What it sounds like#

Here's a sample narration for an original problem: return the IDs of users who logged in three or more times within any 10-minute window.

Phrases that keep the interview moving#

What to do when you get stuck#

Getting stuck is normal and expected. What matters is how you respond:

• Go back to your example. Solve it by hand slowly and notice what your brain does. That's often the algorithm.
• Change the data structure. Ask yourself whether a hash map, a heap, or sorting would make the slow step fast.
• Solve a simpler version. Drop a constraint, solve that, then add the constraint back.
• Take the hint well. If the interviewer offers a nudge, acknowledge it and build on it immediately. Using hints well is a skill they score.

How to prepare for system design interviews#

System design interviews ask you to architect a system, such as a chat service, a news feed, or a ride-matching platform, in 45 to 60 minutes. There's no single right answer. You're scored on structure, reasoning, and trade-offs.

Use a four-step structure#

The open-source System Design Primer describes a widely used approach: clarify use cases and constraints, sketch a high-level design, detail the core components, then address scaling bottlenecks. A practical time split for a 45-minute round looks like this:

• Requirements (5–8 minutes): functional features, scale, latency, consistency needs, and what's out of scope.
• Estimation (3–5 minutes): users, requests per second, storage, and bandwidth, roughly.
• High-level design (10 minutes): clients, APIs, services, data stores, and how data flows between them.
• Deep dives (15 minutes): two or three components the interviewer cares about, such as the data model, caching, or the feed generation strategy.
• Bottlenecks and trade-offs (5 minutes): what fails first at 10 times the scale, and what you'd change.

Practice back-of-the-envelope estimation#

Estimation shows you can reason about scale. Round aggressively; the goal is the right order of magnitude, not precision.

Know the building blocks#

You don't need to be an expert in every technology. You do need to know what each building block is for and what it costs you:

• Load balancers spread traffic and remove single points of failure.
• Caches cut read latency and database load, at the cost of staleness and invalidation complexity.
• Relational vs. NoSQL databases trade strong consistency and joins against flexible schemas and easier horizontal scaling.
• Replication and sharding improve availability and scale, while complicating consistency and queries.
• Message queues decouple services and absorb spikes, at the cost of eventual consistency.
• CDNs serve static content close to users.
• Rate limiting protects services from overload and abuse.

Questions that open a strong design round#

The requirements phase is where many candidates lose points by rushing. Interviewers deliberately leave the prompt vague to see whether you'll scope it. For a prompt like "Design a notification service," good opening questions include:

• Which channels are in scope: push, email, SMS, in-app?
• Roughly how many notifications per day, and how spiky is the traffic?
• Do some notifications need to arrive within seconds, while others can wait?
• Can a user receive the same notification twice, or must delivery be exactly once?
• Do users control preferences, such as quiet hours or opting out by type?
• What happens if a downstream provider, like an SMS gateway, goes down?

Each answer changes the design. "Exactly once" pushes you toward idempotency keys and deduplication. "Spiky traffic" points to a queue that absorbs bursts. Saying those connections out loud is precisely what the interviewer is listening for.

What's expected at each level#

Take-home assignments and pair-programming rounds#

Some companies replace or supplement live coding with work that looks more like the real job. These formats reward professional habits more than algorithm speed.

How to approach a take-home assignment#

Treat it like a small production project, scoped to the time the company suggests. Going far over the suggested time can backfire if the reviewers notice an over-engineered solution.

• Read the instructions twice and list every explicit requirement
• Ask clarifying questions by email early if anything is ambiguous
• Commit in small, logical steps with clear messages
• Write tests for the core logic and at least two edge cases
• Include a README with setup steps, design decisions, and trade-offs
• Note what you'd do with more time, so reviewers see your judgment
• Run it from a clean clone before submitting

Pair-programming and debugging rounds#

In these rounds, you work in an existing codebase with an engineer. Read before you write: skim the structure, run the tests, and ask how things are organized. Narrate your hypotheses when debugging ("I think the bug is in the date parsing, so I'll add a test there first"). Collaboration is being scored as much as the fix.

Don't skip the behavioral round#

Engineers often spend 95% of their prep on algorithms and wing the behavioral interview. That's a mistake, because many loops include at least one behavioral round, and it can veto an otherwise strong performance. Amazon's prep guide, for instance, asks candidates to prepare behavioral stories using the STAR method with metrics.

Engineering stories to prepare#

Write six to eight stories using the STAR method and practice them out loud. Cover these themes:

• A technical decision you made and the trade-offs you weighed
• A production incident or bug you diagnosed under pressure
• A disagreement with another engineer or a product manager
• A project that failed or slipped, and what you changed
• A time you improved a process, tool, or codebase without being asked
• A time you mentored someone or helped a teammate get unblocked

For more prompts and sample answers, see the guide to behavioral interview questions. The STAR method answer generator can help you structure a story you know is good but tell badly.

Questions to ask your technical interviewers#

Each round usually ends with a few minutes for your questions. Engineers on the panel can tell you things a recruiter can't, so ask about the work itself:

• "What does code review look like on this team, and how long does a typical change take to reach production?"
• "What's the biggest source of technical debt you're dealing with right now?"
• "How are on-call duties shared, and what does a typical on-call week look like?"
• "How does the team decide between building something and buying or adopting a tool?"

These questions show you think like someone who'll own production code, and the answers help you compare offers. More options are in the guide to questions to ask in an interview.

Mock interviews and performing under pressure#

Here's the uncomfortable finding behind the advice to practice with an audience. In a study at North Carolina State University, researchers found that candidates solving a problem on a whiteboard while being watched performed about half as well as those solving the same kind of problem privately. Stress and cognitive load were significantly higher in the observed condition.

The study was small, with 48 computer science students, and the researchers called for larger follow-ups. But the practical lesson is clear: if you only practice alone, you're training for a different test than the one you'll take.

Ways to get realistic practice#

• Peers: trade mock interviews with another candidate and use a shared editor and a timer.
• Mentors or former colleagues: ask a senior engineer to run a system design session and push back on your choices.
• Recording yourself: narrate a timed problem and watch it back, listening for silences and unclear explanations.
• AI practice: the mock interview practice tool can run behavioral and technical-discussion questions with follow-ups. The guide on AI mock interviews explains how to get useful feedback from these tools.

Score yourself with a simple rubric#

After each mock, rate yourself from 1 to 4 on the five rubric dimensions from the first table: problem-solving, coding, verification, communication, and design judgment. Track the scores weekly. Your lowest score tells you what to practice next.

Your technical interview day checklist#

Most of the setup for a technical interview is the same as for any interview, which the interview preparation checklist covers in full. These items are specific to technical rounds:

• Confirm the format, the coding platform, and whether you choose the language
• Open the platform link in advance and test that code runs, if it allows execution
• Have a pen and paper ready for drawing examples and diagrams
• For system design, know which whiteboard tool you'll use and practice once in it
• Close notifications, chat apps, and extra browser tabs
• Keep water nearby; long loops are tiring
• Review your error log and two system designs, nothing new

For remote rounds, the camera, lighting, and audio advice in video interview tips applies directly.

Common technical interview mistakes#

Most failed technical interviews come down to a handful of avoidable errors:

• Coding before clarifying. Solving the wrong problem quickly is still solving the wrong problem.
• Going silent. Long silences leave the interviewer with nothing to score and no way to help.
• Skipping the brute force. Stating a simple solution first proves you can solve it and gives you a fallback.
• Ignoring edge cases. Empty inputs, duplicates, and overflow are where interviewers look first.
• Arguing with hints. A hint is the interviewer helping you pass. Take it.
• Memorizing system designs. Reciting a prepared architecture without tying it to the stated requirements is easy to spot.
• Neglecting your resume. Interviewers ask about the projects you listed, so be ready to discuss every one in depth.

That last point is worth fixing before your interviews start. Your resume sets the agenda for many technical conversations, so make sure each project shows your role, the stack, and the outcome. The guides on the software engineer resume and projects on a resume show how.

Next steps: start your plan this week#

Technical interview performance improves with structured, observed practice. Pick your timeline, put sessions on your calendar, and start with the fundamentals even if they feel easy, because fluency is what lets you think clearly under pressure.

• This week: choose your timeline from the table, set up your error log, and solve two problems from week one of the plan.
• Within two weeks: do your first timed mock interview with another person watching.
• Before your loop: write and rehearse six engineering stories, and re-solve every problem in your error log.
• After each interview: note every question you were asked in the interview tracker, and send a short thank-you note using the thank-you email guide.

If your target is a specialized role, pair this plan with the matching resume guide, such as the data scientist resume or DevOps engineer resume, so your resume, your stories, and your technical preparation all point at the same job.