Not theory. The actual log. What the strong candidates did in the opening that the weak ones skipped and the pattern that nobody is teaching at the senior level in 2026.
After the eleven-interview piece I wrote in May went up, my inbox filled up with messages from backend engineers who wanted mock sessions. Most of them were already in the market. A few were not, and wanted to be ready when they were. I said yes to thirty of them over June, July, and the first half of August.
Each session was a forty-five-minute mock system design round. I gave them a prompt, played interviewer the whole way, and took notes during. After every session I wrote down what I would have scored them, what the pivotal moment had been, and what the candidate would most need to fix before a real loop.
In mid-August I read all thirty notes files in one sitting.
What I found was the same thing I had found in my own interview log, except clearer because I was watching it happen to other people instead of doing it to myself. In twenty-four of the thirty sessions, the outcome was decided in the first ninety seconds. Before any box had been drawn. Before any technology had been named. Before the candidate had touched the marker.
The strong candidates did four specific things in the opening. The weak ones did one thing, and it was always the same wrong thing.
This is the log. Ten representative sessions from the thirty. Each entry is the candidate’s level, the prompt, what they did in the first ninety seconds, and the outcome that ninety seconds produced.
If you are preparing for system design rounds right now, the entire pattern is in the first four entries. The other six are confirmation.
The setup
Thirty engineers, all backend. Most had three to seven years of experience. Five were targeting staff roles. Two were targeting principal. The rest were mid-to-senior.
The tech stacks varied. Java and Spring Boot dominated, then Python and Go, then a handful of Node and Kotlin engineers. The system design prompts I used were the standard ones the industry has been running for ten years. Design a URL shortener. Design a notification system. Design a chat backend. Design a video streaming service. Design a rate limiter. Nothing exotic. The prompt was rarely the variable.
The variable was the candidate.
I am writing this because the engineers I mock-interviewed were not weak. They knew the technology. They could discuss Redis and PostgreSQL and load balancers and partitioning and replication competently. If the interview had been a knowledge test, all thirty would have passed. The interview was not a knowledge test, and most of them did not realize it.
Mock 1 — Senior backend, 6 YOE, Java/Spring. Prompt: design a notification system. First 90 seconds: he picked up the marker. Outcome: would not have passed.
I said the words “design a notification system.” He uncapped the marker and started drawing.
His first box was an API gateway. His second was a queue. By second forty he had drawn six boxes and was talking through retry logic. Everything he drew was correct. Every technology he named was the right kind of technology. He was demonstrating real knowledge.
By minute eight he had to start erasing boxes because the architecture he had drawn for “general notifications” did not fit the use case he eventually settled into, which was real-time alerts with delivery guarantees. He had to redraw. He defended the redraw. He spent the rest of the session in catch-up mode.
I wrote in the notes: Strong knowledge. Drew before he understood the problem. Could not recover the impression after the opening.
This is the most common pattern I saw across the thirty mocks. The candidate has the technical knowledge. The candidate also has years of conditioned reflex from tutorials and practice problems that say when someone asks you to design X, draw X. That reflex is what most of them are bringing to the interview. It is the wrong reflex.
Lesson from mock 1: in a real senior loop, by the time you are erasing your first whiteboard, you have already lost the room. The interviewer is no longer evaluating your architecture. They are evaluating your retrospective scrambling, which is not a senior signal.
Mock 2 — Senior backend, 7 YOE, Python. Prompt: design a URL shortener. First 90 seconds: he asked five questions. Outcome: would have passed comfortably.
Same prompt category, different opening. He did not pick up the marker. He sat with his hands in his lap and asked five questions in roughly sixty seconds.
What is the scale we are designing for, roughly?
What is the read-to-write ratio?
What is the most important property: read latency, write throughput, or analytics?
Should I assume we own the domain or that we are running on top of an existing service?
Is there anything you want me to explicitly not focus on?
I answered the questions. He nodded, said “okay, given that, I’d prioritize read latency and I’ll defer the analytics conversation unless you want to come back to it.” Then he said what he was going to cover, in what order, and started drawing.
The architecture he drew was, at the technical level, similar to mock 1’s architecture. The technologies were similar. The boxes were similar. The result was not similar at all, because by the time he started drawing he had told me what problem he was solving and what tradeoffs he was making, and I was scoring him as someone who had already demonstrated the entire skill the interview was supposed to test.
Lesson from mock 2: the architecture is usually the easy part. The architecture also tends to look similar across candidates with the same level of experience. The difference between passing and failing is what happens in the ninety seconds before the architecture starts.
Mock 3 — Senior backend, 5 YOE, Go. Prompt: design a chat backend. First 90 seconds: he started listing technologies. Outcome: would not have passed.
Without picking up the marker, he started narrating. So we’d need WebSockets for the real-time part, probably with a Redis pub-sub layer for fan-out, and then we’d need to think about persistent storage, so we’d use something like Cassandra or DynamoDB for the message history, and then for read models…
He was three minutes in by the time he asked a clarifying question. The question was is this one-on-one chat or group chat? Which is a question that should have been first, not fourth.
By the time he started drawing, the design he had committed to in his head was incompatible with the actual requirements I would have given him if he had asked earlier. He had pre-decided.
This is the pattern I came to call knowledge-dumping. It looks like the candidate is being thorough. It looks like they are demonstrating their range. It is actually them showing off the inventory of patterns they have memorized, in a way that is invisibly committing them to a design before they have understood the problem.
Lesson from mock 3: listing technologies you know is not the same as engaging with the problem. The first move that signals seniority is not breadth. It is restraint.
Mock 4 — Staff candidate, 8 YOE, Java/Spring. Prompt: design a video streaming service. First 90 seconds: he made it look easy. Outcome: would have passed at staff level.
This was the cleanest opening I saw in the thirty.
He started by saying before I think about architecture, I want to make sure I understand what we’re optimizing for. Streaming is a broad term. Could you tell me whether we’re talking live streaming, video-on-demand, or both?
I said video-on-demand, like Netflix. He nodded.
Okay, then a few things matter more than others. Storage cost is going to dominate the bill. Cold-start latency matters less than steady-state quality. Global delivery matters a lot. Is that consistent with what you’d want to optimize for?
I said yes.
Then here is how I’d like to structure this. I’ll spend a few minutes on requirements and scale. I’ll then sketch the high-level architecture. I’ll go deep on the storage and delivery layer because that is where most of the interesting decisions are, and I’ll deliberately skip the recommendation engine unless you specifically want to discuss it. Does that work?
I said yes.
Total elapsed time before any box was drawn: about seventy seconds.
Lesson from mock 4: this was someone running a rehearsed structure. He had clearly practiced the opening. It was not improvisation. The opening was a script he had drilled until it was boring. And the script was the entire difference between him and mock 3, who had similar years of experience and similar technical knowledge but had never practiced the ninety-second opening as its own skill.
The turn — what I noticed reading the notes back
By the time I had completed about fifteen of the thirty mocks, the pattern was visible to me. It was four things, in roughly the same order, that every passing candidate did and every failing candidate did not.
The four things, as I came to write them down:
One. Clarify scope before architecture. Ask about scale. Ask about traffic patterns. Ask about what matters most. The questions are not for you. They are for the interviewer, so that the interviewer knows you are scoping rather than guessing.
Two. State your priorities and the tradeoff you are making. Out loud. Before drawing. Given that scale and that requirement, I’d prioritize X over Y. This is the single sentence that demonstrates senior judgment. Engineers who skip it never recover the impression, even with a strong technical answer.
Three. Explicitly say what you are not going to cover. This is the move that signals restraint. I’ll skip the recommendation engine unless you want me to cover it. I’ll skip authentication. I’ll skip the admin tooling. The candidate is showing that they can scope an open-ended problem down to a solvable one. This is exactly what senior engineering is in the real world.
Four. Sequence the answer out loud. I’ll spend a few minutes on requirements, then move to high-level architecture, then go deep on the area I think is most interesting. Does that work for you? The candidate is offering the interviewer a structured contract for how the next forty minutes will go. The interviewer can agree or redirect. Either way the candidate has demonstrated that they can structure a conversation under ambiguity.
The four moves together take roughly ninety seconds. They are not a personality trait. They are not seniority radiating off the candidate. They are a sequence the candidate has practiced until it is automatic.
Now back to the log, with the pattern in mind.
Mock 5 — Senior backend, 6 YOE, Java/Spring. Prompt: design a rate limiter. First 90 seconds: he did three of the four things. Outcome: would have been borderline.
This one is interesting because he did most of the framework but missed one element, and the missing element changed the outcome.
He asked clarifying questions. He stated priorities. He sequenced his answer.
What he did not do was explicitly say what he was not going to cover. He left the problem space open, which meant by minute fifteen he was getting pulled into discussions about distributed coordination across regions that he had not budgeted time for. He ended the session not having gone deep on the core algorithm. He had spread thinly across too much surface area.
Lesson from mock 5: scoping in is not the same as scoping out. You have to do both. The strong candidates explicitly named what they were skipping, which forced the interviewer to either accept the skip or specifically pull them into that area. The borderline candidates only said what they would cover, which left the surface area unbounded, which led to time pressure later.
Mock 6 — Senior backend, 4 YOE, Node. Prompt: design a notification system. First 90 seconds: he tried to apply the framework but was too rehearsed. Outcome: still failed, in an interesting way.
This was a candidate who had clearly read advice similar to what I have just written down. He opened with scoping questions. He stated priorities. He named the skips. He sequenced his answer.
It was all mechanical. He sounded like he was reciting a script he had not metabolized. The interviewer (me) could feel it. When I pushed back on his stated priority, he did not adapt. He defended his original prioritization with the same words he had used the first time, because he had not understood the prioritization, only memorized it.
Lesson from mock 6: the framework is not a script. It is a structure for thinking. If you run it as a script, the interviewer will catch the difference within thirty seconds. The discipline of system design is to actually scope, actually prioritize, and actually hold those priorities adaptively when challenged. Running the framework without engaging with it is worse than not running it at all, because it looks like preparation but produces brittleness.
Mock 7 — Staff candidate, 9 YOE, Java/Spring. Prompt: design a feed system. First 90 seconds: he handled my pushback gracefully. Outcome: would have passed at staff level cleanly.
By minute one he had done the four things. By minute three I tried to disrupt him.
Why are you prioritizing latency over consistency? I would have said the opposite for a feed.
The weak candidates’ reflex here is to defend. The strong candidates’ reflex is to invite. He did the second.
That is a good challenge. Let me think about it for a second. If consistency mattered more, I would design the fan-out differently, and the read model would look like X instead of Y. Are you imagining a use case where users see different versions of the feed across devices and that is a problem?
I said yes.
Okay, then I would actually agree with you. Let me redo the priority statement.
He revised. The architecture he ended up drawing was slightly different from what he would have drawn under his original priorities. The interview ended having shown me not just an architecture but an engineer who can update his model in real time when a constraint changes. That is what staff engineering looks like.
Lesson from mock 7: the fourth thing the strong candidates did was invite correction. Not just say it once at the start. Maintain the posture through the whole interview. Engineers who present and defend lose. Engineers who present and revise win, because the interviewer is looking for someone they could work with under ambiguity, not someone who is right at minute one.
Mock 8 — Mid-senior, 5 YOE, Python. Prompt: design a URL shortener. First 90 seconds: he had practiced. Outcome: would have passed comfortably.
This was someone who had clearly drilled the opening. He told me at the end of the session that he had been practicing the first ninety seconds out loud for two weeks before the mock, on a timer, because he had read advice that this was the differentiator.
His opening was almost identical to mock 4. The cleanliness was the same. The pacing was the same. The four moves were all there.
What was different from mock 6 (the over-rehearsed Node candidate) was that he had practiced the underlying judgment, not the script. He had spent the two weeks thinking about how to actually prioritize tradeoffs in real systems, and the opening was the surface expression of that thinking. When I pushed back, he adapted, because the framework was a tool to him, not a performance.
Lesson from mock 8: drill the opening, but drill it on real problems with real tradeoffs, not as a memorized speech. The drilling makes the opening automatic. The thinking behind the drilling is what makes it adaptive.
Mock 9 — Senior backend, 7 YOE, Go. Prompt: design a chat backend. First 90 seconds: confident, smart, no framework. Outcome: would not have passed despite being technically strong.
This candidate was technically the strongest of the thirty. He could go deeper on distributed systems than I could. He had clearly worked on real chat systems at scale.
He skipped the framework. He started immediately, jumped to architecture, and was, technically speaking, almost certainly going to land in a correct place.
But he did not signal scoping. He did not signal restraint. He did not signal the willingness to revise. The interviewer (me) was scoring him not on the architecture, which was strong, but on whether I could work with him in an actual production context where the requirements would shift weekly. The signal was this is someone who would lecture rather than collaborate.
He would have failed. Not because of the architecture. Because the signal of seniority that the interview is measuring is not technical depth alone. It is technical depth plus the disposition to scope, prioritize, and revise. The thirty mocks made this clearer to me than any postmortem could have.
Lesson from mock 9: being technically the strongest in the room is not the same as being the hire. The interview is filtering for working compatibility, not raw skill. The framework is partly a tactic and partly an honest expression of an engineering disposition. The candidates who win can do both at once.
Mock 10 — Staff candidate, 8 YOE, Java/Spring. Prompt: design a video streaming service. First 90 seconds: textbook. Outcome: would have passed at staff level.
I am including this one because the opening was identical to mock 4 and the architecture that followed was different but equally strong. The framework is not a single architecture. It is a stable opening that allows different architectures to be defended cleanly.
What was distinctive about mock 10 was the closing. With about five minutes left, he stopped and said if you want, I can also briefly cover the parts I skipped at the start. The recommendation engine and the analytics pipeline both have interesting tradeoffs but I deferred them. Should I do a quick pass?
I said yes. He did a sixty-second sketch of each that demonstrated he had understood the deferred areas, not avoided them.
Lesson from mock 10: the strong candidates close the loop on the things they explicitly skipped. The opening promise (I will skip X unless you want me to cover it) is also a closing offer (do you want me to cover X now?). Engineers who deliver on both have demonstrated the entire arc of a senior conversation.
What the log adds up to
Twenty-four of the thirty sessions, the outcome was clear to me by minute two. Six were genuinely close calls that played out across the full forty-five minutes.
The twenty-four were not decided by knowledge gaps. They were decided by what the candidate did in the opening ninety seconds, before the actual architecture was on the board. The candidates who scoped, prioritized out loud, named what they were skipping, and sequenced their answer were passing in my notes by the time they touched the marker. The candidates who reached for the marker first were paying for it in the next forty minutes, no matter how technically correct their final design ended up being.
In 2026, the system design interview is not a knowledge test anymore. Industry has had ten years to figure out how to filter on knowledge. AI has compressed the cost of knowledge access to near zero. What the interview is filtering for now is whether you can navigate an ambiguous, open-ended problem under pressure in a way that the team can work with. The ninety-second opening is the cheapest, fastest signal of that.
You cannot fake the opening. You can drill it. There is a difference. Drilling means practicing the ninety seconds on twenty different prompts, out loud, on a timer, until the scoping question, the priority statement, the explicit skip, and the sequence offer come out without you having to think about them. The first time you do this it is uncomfortable. The tenth time it is automatic. The twentieth time it is invisible to you and visible to the interviewer.
That is the work. There is no shortcut. You can read every system design book on the market and pass zero interviews if you have not practiced the opening on a timer. You can have mediocre knowledge and pass interviews if you have drilled the opening.
I am not being dramatic. The thirty-mock log is the evidence.
The one thing to do tonight
Pick a prompt. Design a notification system will do. Set a timer for ninety seconds. Run the four moves out loud, with no whiteboard, no notes.
The scoping questions. The priority statement. The explicit skip. The sequence offer.
Do it. Now. Then notice how it feels.
The first time, it will feel artificial. The third time, it will feel less so. The tenth time, you will not be able to start an interview any other way.
That is the entire fix. The next interview, before you open any prep material, do this for ninety seconds with a different prompt. Then do it again. Then again.
I wrote down the complete framework, including the exact phrasing I use for each of the four moves, the eight prompts I drilled myself on before I went into a real loop, and the verbatim transcript of the ninety-second opening that produced my offer. It is on Gumroad as System Design Interview Bible for twenty-nine dollars. It is what I wish I had bought before my first system design round instead of assembling the framework painfully across four rejections.
If you want the broader library, the System Design Interview OS bundle collects six interview systems for forty-nine dollars, including the design framework, the four-beat incident structure, the behavioral stakes-action-outcome shape, and the staff-level interview module. Most of what I learned across the eleven interviews and the thirty mocks is in there.
The Substack version
The Medium version is the log. The Substack version is the autopsy.
I am publishing the deeper companion piece on Substack this week. It includes the verbatim transcripts of three of the strongest openings from the thirty mocks, the four phrasings I drill myself on for each of the four moves, the deeper analysis of why mocks 6 and 9 failed despite each being strong in one important dimension, and the specific behavioral pattern I now look for first when I am on the interviewing side.
You can subscribe at devrimozcay1 on Substack.
If you are preparing for system design rounds right now, you are probably, like most of the thirty engineers I mock-interviewed, preparing for the architecture and walking blind into the opening that is actually filtering you out. Drill the ninety seconds. Track the four moves. Practice on prompts until the framework is invisible to you.
I would genuinely like to read your own ninety-second opening in the comments. The exact words you would say in the first ninety seconds of design a notification system. The strong ones will be obvious to everyone reading. So will the weak ones.
One opening at a time.
Devrim Özcay is a backend engineer based in Istanbul. He writes about production systems, technical interviews, and the operational reality of Java and Spring Boot in real environments. The thirty mock interviews are the source material for most of his recent writing on system design.
I Mock-Interviewed 30 Backend Engineers on System Design. The First 90 Seconds Decided 24 of Them. was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
