Interview guide

The Technical Mock Interview Guide for Software Engineers

Coding interview practice fails for the same reason gym plans fail: no clock, no scoring, no review. This guide covers the five rounds an engineering loop actually contains, the rubric each one is graded against, and a two-week mock interview plan you can run end to end inside Interview-Prep-Pal.

Why solo practice under-prepares you

Most engineers prepare by grinding problems in a sandbox that autocompletes their code, with no timer and no one listening. Real loops score three things that this never touches: how you scope an ambiguous question, whether you narrate your reasoning while you type, and how you respond when the interviewer changes the constraints halfway through. A mock interview reproduces those conditions - a question you have not seen, a running clock, and a written critique at the end.

The practical rule: if a practice session did not produce a score and a list of gaps, it was studying, not interview practice.

The five rounds and how each is scored

1. Coding / data structures · 45 minutes

One or two problems on arrays, hash maps, trees, or graphs. Correctness matters, but so does how you narrate your thinking.

Typical question: Given a stream of log lines, return the top K endpoints by p95 latency in the last 5 minutes.

Scored on: Clarifying questions before coding, a stated brute-force baseline, complexity announced up front, working code, at least two edge cases tested by hand.

2. Algorithms deep dive · 45-60 minutes

A harder single problem with follow-ups that change the constraints - larger input, streaming input, or a distributed variant.

Typical question: Design an LRU cache, then extend it to expire entries by TTL, then make it thread-safe.

Scored on: Choosing the right structure the first time, handling the follow-up without rewriting from scratch, honest reasoning about locking and contention.

3. System design · 60 minutes

An open-ended distributed system. The interviewer is testing scoping and trade-offs, not whether you memorised an architecture diagram.

Typical question: Design a URL shortener that serves 50k redirects per second with analytics.

Scored on: Functional and non-functional requirements written down, back-of-envelope capacity numbers, a clean high-level diagram, one deep dive, explicit trade-offs and failure modes.

4. Practical / take-home review · 45 minutes

Walking through code you wrote, or debugging an unfamiliar codebase live.

Typical question: Here is a service with a memory leak under load. Find it and propose a fix.

Scored on: A hypothesis-driven search, reading before guessing, and a fix that includes how you would verify it in production.

5. Behavioral for engineers · 30-45 minutes

Conflict, ownership, and shipping under pressure - scored just as strictly as the technical rounds at most companies.

Typical question: Tell me about a technical decision you made that turned out to be wrong.

Scored on: A specific story in STAR form, the signal that changed your mind, and a quantified outcome.

A repeatable coding round structure

Clarify (2-3 min) - input size, value ranges, duplicates, memory limits. Write the constraints down where the interviewer can see them.
Baseline (2 min) - state the brute-force solution and its complexity, then say why you are improving on it.
Design (5 min) - name the data structure and the target complexity before writing a line of code.
Implement (20 min) - narrate as you type. Silence for more than 30 seconds reads as being stuck.
Verify (8 min) - trace one normal case and two edge cases by hand, then state the final time and space complexity.

A repeatable system design round structure

Requirements - separate functional from non-functional; get the interviewer to confirm the list.
Estimates - QPS, storage per year, read/write ratio. Rough numbers are fine; missing numbers are not.
High-level design - clients, API, services, stores, queues. Keep it to six or seven boxes.
Deep dive - pick the component the estimates say will break first: sharding, caching, or the hot write path.
Trade-offs and failure modes - consistency versus availability, what happens when a shard or region dies, and how you would detect it.

A two-week mock interview plan

Day 1 - Paste the company's careers URL into Interview-Prep-Pal, generate the JD for your target level, and run a Coding round cold to get a baseline score.
Day 2 - Review the rubric feedback and the ideal answers. Rewrite every solution you scored below 70 on, from scratch.
Day 4 - Run an Algorithms deep dive at a harder difficulty. Compare pass probability against day 1.
Day 6 - First System Design round. Expect to run out of time; that is the lesson.
Day 8 - Second System Design round on a different problem class (write-heavy instead of read-heavy).
Day 10 - Behavioral round. Prepare eight distinct stories, not one story told eight ways.
Day 12 - Back-to-back Coding + System Design to rehearse fatigue, the way a real onsite loop feels.
Day 14 - Re-run your weakest round one final time and read the gap analysis on your role dashboard.

Start a technical mock interview →

Mistakes that cost strong engineers the offer

Coding before clarifying. A correct solution to the wrong problem scores zero.
Going silent while thinking. Interviewers score the reasoning they can hear.
Jumping to microservices and queues in system design before anyone has estimated the load.
Never testing the code. Hand-tracing two edge cases moves a borderline round to a pass more often than any optimisation.
Practising only algorithms. Above mid-level, system design and scope negotiation decide the level you get offered.

Frequently asked questions

What is a mock interview?

A mock interview is a timed rehearsal of a real interview round. You get a question, answer it under the same clock and constraints as the real loop, and receive a scored critique afterwards. For engineers this usually means a coding round, an algorithms round, or a system design round.

How many mock interviews should I do before a real loop?

Six to ten timed sessions spread over two weeks is enough for most engineers: roughly four coding sessions, three system design sessions, and two behavioral sessions. Quality of review matters more than volume - always re-run a round after acting on the feedback.

How do I practise coding interviews on my own?

Solve out loud against a timer, type into a plain editor with no autocomplete, and state your complexity before you run anything. Recording or transcribing the session is what turns solo practice into real interview practice, because most rejections come from communication gaps rather than wrong answers.

How is a system design mock interview scored?

Interviewers score requirement gathering, capacity estimation, a clear high-level design, one or two deep dives, and explicit trade-offs. Naming bottlenecks before the interviewer does is the single strongest signal at senior level.

Are mock interviews useful for senior engineers?

Yes. Senior loops weight system design and scope negotiation far more heavily than raw algorithms, and those are the hardest skills to self-assess. Timed design sessions with a written critique surface gaps that solo problem grinding never touches.