Mock Interviews
Technical Mock Interviews: How to Practice Coding and System Design Rounds
By the Upinterview team · Published · 9 min read
Solving a problem and passing a technical interview are not the same thing. In the interview you are being judged on how you get there as much as on the answer, and that part is easy to neglect when you practice alone with a problem set. A technical mock interview trains the part that solving problems in silence never does: explaining yourself while you work.
What interviewers are actually looking at
Different companies weigh things differently, but most technical interviewers are watching for the same handful of things.
- Whether you clarify the problem before touching the keyboard.
- Whether you describe an approach first, and can say why you picked it over another.
- Whether the code works, and whether you check it yourself with an example before being asked.
- Whether you know the time and space cost of what you wrote.
- How you respond when the interviewer offers a hint or points at a bug.
- Whether they could imagine working next to you.
A common way to fail a technical round is not being unable to solve the problem. It is solving the wrong version of it, or writing a correct solution in total silence, or freezing at the first hint. All three are fixable with practice, and none of them show up when you grind problems alone.
A coding round, roughly minute by minute
A 45-minute coding interview tends to split like this. It is not a rule, but knowing the rhythm helps you notice when you are behind.
| Time | What should be happening |
|---|---|
| 0 to 5 min | Read the problem back in your own words. Ask about input size, edge cases and what a valid input looks like. |
| 5 to 12 min | Talk through a simple approach, then a better one. Agree on a direction with the interviewer before you code. |
| 12 to 35 min | Write the solution, narrating as you go. Keep names sensible and functions small. |
| 35 to 42 min | Run an example through it by hand. Fix what breaks. |
| 42 to 45 min | State the complexity and mention what you would improve with more time. |
Practice with a timer and stop when the time is up, even if you are one line from done. Getting comfortable with unfinished is part of the skill.
Practice out loud, in a plain editor
Narrating while you code feels strange at first, like commentating on your own game. Do it anyway. Say what you are about to write before you write it. When you get stuck, say what you are stuck on. Silence is the thing interviewers find hardest to read.
If your real interview will use a shared document or a basic online editor, practice there. Autocomplete and a debugger are wonderful, and you will probably not have them. Try a session where you write on paper or in a plain text file at least once, so it is not a shock.
System design rounds
System design prompts are deliberately vague: design a URL shortener, a chat service, a notification system, a rate limiter. Nobody expects a finished architecture. They want to see how you handle ambiguity. A workable order for the hour looks like this:
- Start with requirements: who uses it, what it must do, how many users, and what matters most, whether that is speed, cost or consistency.
- Work out some rough numbers, such as requests per second and data size. Ballpark only, but show your working.
- Sketch the interfaces and the data: the main API calls and what you store.
- Draw a simple design that works, with no more than five or six boxes.
- Pick the hardest part and go properly into it: the database choice, the queue, the cache.
- Finish on trade-offs and failure. What breaks first, what you gave up, and what you would change at ten times the traffic.
Practice with a friend who can play the interviewer and push with "why not just use X?" The point is being made to defend your choices, not to recite a blog post.
Debugging and code review rounds
More companies now give you a small piece of broken or unfamiliar code and ask you to find the problem, or to review a pull request. To practice, pick an open source project with a small bug fix, read the change without the description, and explain out loud what it does and what you would question. It is a different muscle from writing code from scratch.
How to review a mock technical interview
After each session, spend ten minutes on these questions instead of moving straight to the next problem.
- Did I ask questions before I started coding?
- Was there a stretch longer than about thirty seconds when I went silent?
- Did I test with a concrete example, or just say it looked right?
- Could I state the complexity without hesitating?
- What did I do when I got stuck, and was it a good move?
For a practice partner, a free mock interview with an AI interviewer covers technical questions, and expert mock interviews put an experienced interviewer opposite you. For a broader overview of the formats, see what a mock interview is.
Frequently asked questions
How long should I prepare for a technical interview?
It depends on your starting point. Many candidates spend several weeks, mixing problem practice with a handful of full mock interviews. What matters is regular practice and reviewing each session.
Should I practice with an AI or a human interviewer?
Both are useful. AI is good for volume and repetition at any hour. A human interviewer is better for realistic pressure and for judgment on how your reasoning comes across.
Can I use any programming language in a technical interview?
Usually yes, but confirm with the recruiter beforehand. Pick the language you are most fluent in, since you will be writing and explaining under pressure.
What if I get stuck during a coding interview?
Say so, explain what you have tried, and ask a clarifying question or propose a simpler version to work through first. Interviewers care about how you handle being stuck as much as the final answer.