How to practice system design interviews when you have nobody to practice with

Aditya Shukla — Fri, 18 Sep 2026 13:09:21 +0000

System design is the round people most often fail, and it is also the round that is close to impossible to practice alone. With DSA you at least get a green checkmark telling you that you were right. System design has no checkmark. You draw some boxes, you feel reasonably good about them, and you have no idea whether an interviewer would have shredded you in minute nine.

I have been on both sides of this round, and the gap between people who practice alone and people who practice out loud is bigger here than anywhere else in the loop. Here is what actually works when you do not have a partner, and what to do about the part that genuinely needs one.

Why solo system design practice quietly fails

Reading system design content feels productive. You finish an article about how Instagram handles the feed fanout, you understand it, and you file it away as knowledge. Then in the interview someone says "design a notification service" and you freeze, because understanding an explanation and generating one under time pressure are different skills that share almost nothing.

The specific things that break in a real round:

You do not state assumptions, because alone in your head the assumptions were obvious. The interviewer now thinks you did not consider them.

You go straight to the fun part. Most people jump to the database schema or the sharding strategy, because that is the part they read about. The interviewer wanted requirements first, and quietly marked you down before you drew a single box.

You cannot defend a choice. It is easy to write "use Kafka" on a diagram. It is very different to answer "why not just poll the database every five seconds" without saying "because Kafka is better."

You have no sense of pacing. Forty five minutes disappears far faster than people expect. Alone, you never practice the triage of what to skip.

What you can genuinely do alone

Narrate out loud, to an empty room. This feels ridiculous and it is the single highest leverage thing on this list. Set a timer for forty five minutes, pick a prompt, and talk through the whole thing as if someone is listening. If you cannot fill forty five minutes talking, you have found the gap.

Record yourself and watch it back. Painful, effective. You will catch the rambling, the long silences, and the moments you asserted something with no justification. You will catch things a friend would be too polite to mention.

Write the requirements section before touching the design. Functional requirements, non functional requirements, scale estimates. Force yourself to spend the first ten minutes there. Most people's instinct is to rush this, and in an interview it is where a lot of the signal lives.

Interrogate your own diagram. After you finish, go back through every component and ask why it exists, what happens when it dies, and what it costs. If you cannot answer, that is exactly where the interviewer will push.

Pick prompts with real constraints. "Design Twitter" is too vague to be useful practice. "Design Twitter's timeline for 300 million daily users where a celebrity has 100 million followers" forces the actual tradeoff, which is the fanout problem.

The part that genuinely needs another person

Everything above makes you better at producing a design. None of it prepares you for the thing that actually decides the round, which is someone pushing back on you in real time.

A real interviewer interrupts. They ask why you picked that datastore. They say "your service just got ten times the traffic, what breaks first." They follow the thread you were hoping they would not notice. You cannot simulate that alone, because you cannot surprise yourself, and you will never ask yourself the question you do not want to answer.

Options, honestly assessed:

A friend who is also interviewing. Free and underrated, with one real problem: friends are bad at being blunt. Fix it by asking for a hire or no hire verdict and three specific failures, rather than "how did I do."

Paid platforms. interviewing.io and similar will put you in front of experienced engineers. Genuinely good, genuinely expensive if you want volume.

Peer platforms. You take turns, so you interview someone else and then get interviewed. The underrated part is that interviewing other people is itself excellent practice, because watching someone else flail teaches you what flailing looks like from the other chair.

I ended up building one of these, Practick, because the free peer option kept shrinking and I wanted it to still exist. It matches you with another engineer automatically and includes an interviewer guide on each question, since the usual failure mode of peer practice is that the person interviewing does not know what to push on. That one is mine, so discount it accordingly, but the general category matters more than which one you pick.

A practice loop that works

If I had to compress this into a weekly routine:

Two solo sessions, timed and narrated out loud, recorded. Focus on requirements and pacing.

One session where you are the interviewer for someone else. You will learn more than you expect.

One session where you are the candidate and someone pushes back.

Then, importantly, write down the specific question that broke you each time. After a month you will have a list, and that list is your actual study plan, not whatever generic topic list you started with.

The uncomfortable summary

Most people preparing for system design are optimizing the part that feels like studying, because it is comfortable and measurable. The round is decided by the part that feels uncomfortable, which is talking through a design while someone questions it.

You can do a surprising amount alone if you are willing to talk to an empty room and watch the recording. But at some point you need someone on the other side who is willing to ask the question you have been avoiding.

How interviewers actually ask Two Sum, and the four follow ups that matter more than the answer

Aditya Shukla — Thu, 17 Sep 2026 12:05:21 +0000

Two Sum is the first problem almost everyone learns, and most people stop preparing for it the moment they can write the hash map solution in their sleep. That is a mistake, because nobody who has actually interviewed candidates asks Two Sum to see if you know the hash map trick. They ask it because it is a five minute warm up that opens the door to four follow ups, and the follow ups are where you are actually being scored.

The four follow ups

1. "What if the array is sorted?"

This is checking whether you default to the same tool every time or whether you actually look at the input before reaching for a hash map. A sorted array means two pointers gets you O(1) space instead of O(n), and an interviewer wants to see you notice that on your own, not after a hint.

2. "What if there are duplicate values?"

This is checking whether your solution quietly breaks on an edge case you did not think about out loud. Walk through what happens to your hash map when the same value appears twice before you get asked, not after.

3. "What if I asked you to return all pairs, not just one?"

This changes the shape of the problem. Your early return solution now has to become a collection step, and the interviewer is watching whether you can adapt an existing solution instead of throwing it out and starting over.

4. "Can you do it without extra space?"

For an unsorted array this is often impossible in less than O(n log n) time, and the correct answer is to say so and explain the tradeoff, not to awkwardly force a bad solution. Interviewers use this one specifically to see if you will push back on a constraint that does not make sense, which matters more in a real job than getting every question right.

Why this matters more than grinding more problems

None of these four follow ups require knowing a new algorithm. They require having sat across from someone who asks them, often enough that reacting to a follow up feels normal instead of stressful. Reading the follow up in a blog post and living through it live are different skills, and only one of them is what actually gets tested.

That is the gap that solo practice cannot close, and it is why I ended up building Practick, a free peer to peer mock interview platform. You get matched with another engineer, one hour you are the candidate and one hour you are the interviewer, so you spend time on both sides of exactly this kind of exchange instead of only ever answering.

DEV Community: Aditya Shukla