There is a failure mode in system design rounds that does not get written about, because the people who experience it tend to misattribute it. The technical answer was right. The diagram was clean. The candidate knew the material. The candidate still got rejected. I want to write about this failure mode because I lived it, and the postmortem with the recruiter was clarifying in a way I did not expect.

The loop was a senior backend role at a Series C scale-up in the developer-tooling space, around 300 engineers, four onsite rounds. I was rejected after the loop and the recruiter (kind enough to give me a real debrief, not a templated one) told me the design round was the round that pulled the packet down. The other three rounds were lean-hire to hire. The design round was no-hire, despite my draft answer being technically defensible. Here is what happened.

The prompt and my first 15 minutes were the strongest part of the round

The prompt, paraphrased: "Design a build-cache service. Assume a moderately large engineering org, builds happen on developer machines and on CI. Cache hits should be fast (low-millisecond), cache writes should be deduplicated by content, and the system should tolerate a regional outage."

I knew this material. I had built one of these in a previous role. I drew the diagram cleanly:

Clean first pass (15 min in)
  client (build tool) -> nearest cache POP -> regional cache cluster
                                 |                     |
                                 v                     v
                          local SSD tier        S3-class object store
                                 ^                     ^
                                 +----- async fill ----+

The interviewer was engaged. We discussed the content-addressed write path (SHA256 of the artifact, dedupe at upload, no need for cache invalidation because the key is the content). We discussed the read path (POP-local SSD checked first, miss falls through to regional, regional miss falls through to object store, async backfill on the way back). We discussed the regional-outage path (cross-region read on miss, write quorum to two regions, backpressure on writes during outages). All of that was clean. At the 15-minute mark the interviewer said, "Okay, this looks good. Let's go deeper on one piece."

That is where the round started going wrong, but I did not notice for another 20 minutes.

The failure mode: I kept relitigating my own answers

The interviewer asked me to go deeper on the cross-region replication path. I gave a clean answer: write to local region first, async replicate to a partner region, conflict-free because the key is content-addressed, partner region serves reads on local-region outage. That is a defensible answer. I should have stopped.

Instead I started explaining why I had picked async over sync. Then I explained the latency cost of sync replication. Then I started talking through what would happen if the partner region was the one with the outage. Then I started explaining the failure modes of the failover detection logic. Then I started questioning my own earlier choice of write quorum versus single-region write with async replication. Each thread was technically reasonable. Each thread surfaced a real tradeoff. The collective effect was that I had now offered three different positions on the replication strategy in five minutes, and the interviewer had no idea which one I actually believed.

I realized this in real time, around minute 22. I tried to recover by saying, "Let me commit to a position. I think single-region write with async cross-region replication is the right call here, because the cache is not the system of record and the regression mode of a missing artifact is a slow build, not a data-loss event." That was the right answer. I should have given it the first time. By giving it the third time, after publicly walking through two other positions, I had demonstrated that my first answer was not load-bearing. I was now visibly uncertain.

Where it got worse: I did the same thing on the next sub-question

The interviewer, gracious, moved us forward. "Walk me through the dedupe-on-write path." I gave a clean answer (client computes SHA256 locally, sends a HEAD-style probe, server responds present-or-absent, client uploads only if absent). I should have stopped.

Instead I started talking through the race condition where two clients upload the same artifact simultaneously. Then I talked through whether the dedupe should be at the regional layer or the POP layer. Then I started explaining why the SHA256 might not be collision-resistant in adversarial settings. Then I started talking about whether content-addressing should use a different hash entirely. Each detour was real. None of them was the answer the interviewer was waiting for, which was a one-sentence affirmation of the dedupe strategy and a willingness to move on.

A small piece of code that, in retrospect, would have been the right artifact to anchor the dedupe answer (and stop talking after producing it):

def upload_artifact(content: bytes) -> str:
    digest = sha256(content).hexdigest()
    # HEAD-style probe is cheap. Skip the upload if we already have it.
    if cache.exists(digest):
        return digest
    # Race is benign: if two clients upload the same digest concurrently,
    # the second write is a no-op against an immutable, content-addressed key.
    cache.put(digest, content)
    return digest

If I had drawn that in 90 seconds, said "the race is benign because the key is content-addressed and the value is immutable," and then asked the interviewer what to look at next, the round would have moved on.

The recruiter's debrief was specific and clarifying

A week later the recruiter called. The phrasing they used, paraphrased: "The panel said your technical answer was strong. The concern was that you walked the panel through three or four positions on the same question before landing, and that pattern repeated. The senior level here requires that you can defend a call without re-arguing it. Your stated answers were good. We were not sure they were the answers you actually held."

That is the failure mode. The technical content was right. The presentation revealed a lack of conviction the technical content did not deserve. The interviewer was grading whether I could be the senior engineer who picks a path and runs it, and I had given them evidence that I was the senior engineer who would relitigate the path mid-implementation. That is not a senior engineer.

The two things I changed for the next loop

First, I started practicing with a stopwatch and a hard rule: when I give an answer, I get 60 seconds to elaborate, and then I stop and ask the interviewer where they want to go next. That rule alone would have saved this round. The answers were correct. The continuation was the failure.

Second, I started explicitly naming the tradeoff space at the start of a sub-discussion, and then committing to a position. The shape is: "There are three options here: A, B, C. I am picking B. Here is why. What do you want to pull on?" That structure gates the elaboration. Without the gate, I will keep elaborating, and elaborating reads as uncertainty even when each individual elaboration is correct.

The round I sat next was a senior infra loop at a different company. I cleared it with a hire on the design round. The diagram was less clean than the one I drew at the Series C scale-up. The conviction was much higher. That was the round that taught me what "strong hire on design" actually graded.