The rejections, and the round I thought I had failed

In the third round of one loop, a system design interview for a real-time fraud detection system, the head of engineering told me my design was “very basic.” Earlier in that same round I had volunteered, unprompted, that I had not done high-level design in a while. Afterwards I reconstructed the interview with Claude and asked how badly it had gone. The verdict was that it was likely not a pass, and I agreed.

That company made me an offer.

A few weeks later I finished the third round of a different loop, a mix of ML system design, a code review and a modeling question, feeling reasonably good. The debrief agreed: a pass, though closer to the line than the previous round. That company rejected me.

This post is about the four companies that said no and the one I was sure would. It covers where in the process each rejection happened, what each one taught me, and the uncomfortable conclusion that my read of a round, and my AI coach’s read, was a poor predictor of what happened next. It is part 8 of the 35 companies, 8 offers series.

The short version:

• Rejections: 4 of the 32 companies that interviewed me
• Where they happened: one at the recruiter screen, one after a first round, one after a single strategy round, one after a three-round loop
• Post-round reads: wrong in both directions on final rounds, including the one that became an offer
• What changed: I stopped using debriefs to predict outcomes and used them only to find the next fix

Background: interviews are noisy, and so is your read of them#

Two pieces of data reframed rejection for me before I had many of my own.

Performance is volatile. An analysis of repeat candidates by interviewing.io found that only about a quarter of people performed consistently across technical interviews; even strong candidates often scored very differently from one interview to the next. A single interview is a noisy sample of a person.

Self-assessment is weakly related to outcome. A second analysis of 254 interviews found only a weak correlation (an R-squared of 0.24) between how candidates thought they did and how interviewers rated them, with a visible tendency for candidates to rate themselves lower than their interviewers did.

Both are small samples, and both match my experience. Neither makes a rejection feel better. Both make it more useful, because they shift the question from “what does this say about me” to “what is the specific, fixable thing in this round.”

I am naming the companies below because they are part of an honest account. This is not a complaint about any of them, and several of the lessons came directly from their interviewers.

Where the rejections happened#

The four rejections came at four different stages, which made each one teach something different.

graph LR
    A["Recruiter screen"] --> B["First round"]
    B --> C["Middle rounds"]
    C --> D["Final round"]
    A -.->|"rejected"| G["Glance"]
    B -.->|"rejected"| N["Nykaa"]
    B -.->|"rejected"| S["Sequoia"]
    D -.->|"rejected"| M["Almedia"]
    D -.->|"felt failed,<br/>got offer"| F["AI Fiesta"]

    class A,B,C,D gray
    class G,N,S,M red
    class F green

The four rejections#

Glance: rejected at the screen#

I applied for a machine learning engineer role on Glance’s recommendations team and was rejected at the recruiter screen on three grounds: seniority, depth in recommendation systems, and scale. I disagreed with at least one of the objections, so I wrote back and argued the case: production two-tower retrieval, cold-start handling for users with no history, and a measured lift in click recall.

The argument on recommendation depth was fair. The argument on scale was not winnable. Glance’s platform runs across hundreds of millions of devices, which is well beyond anything I had served. The pushback email acknowledged that gap and leaned on transferable systems design, and the answer stayed no.

The lesson: you can sometimes argue past a skills objection at the screen, because skills are about evidence. You rarely argue past a scale objection, because scale is about history. Target roles where your scale is credible, or lead with work that is visibly independent of scale.

Nykaa: rejected after the first round#

The first round for a machine learning scientist role on Nykaa’s ranking team covered coding plus linear algebra, probability and statistics. My preparation for it was the most thorough of any first round in the search; it produced five general theory documents I reused all the way to Google.

The debrief showed a clean split. I was strong on two-tower retrieval, on the geometry of L1 and L2 regularization, and on the bias-variance trade-off. I struggled on two probability puzzles and on the internals of keys and values in transformer attention. The delivery problems were familiar: sentences starting with “So,” conclusions at the end, and, on the puzzles, narrating my confusion out loud rather than reasoning in steps.

The lesson: probability puzzles are a separate skill from probability knowledge. Knowing the theory did not help when I had no practiced way to attack an unfamiliar puzzle. I later wrote a recovery protocol for exactly this situation: say what you do know, name the class of the problem, derive rather than recall, and ask one scoped clarifying question. Narrating confusion scores nothing; structured partial reasoning scores something.

Sequoia: rejected after a strategy round#

Sequoia’s round was a one-hour strategy and problem-solving conversation, closer to a case interview than to anything else in my search. It ended in a rejection.

The lesson: I had a preparation system for ML, coding and behavioral rounds, and nothing for a case-style round. When a format appears that your system does not cover, either prepare for it specifically or accept that you are going in cold. Going in on the strength of general ability, as I did, is the worst of both.

Almedia: rejected after the final round#

Almedia’s founding data scientist role in Berlin had three rounds: an introductory call, a case discussion with a staff data scientist, and a final round with ML system design, a code review and a modeling question. I passed the first two. In the second, the interviewer had to lead me toward the framing the problem needed, which was a warning I underweighted.

The final round had one strong section and two weaker ones. My recommendation systems discussion carried it. The code review showed the right instincts (memory handling, missing deduplication, a table creation that would fail on a rerun) but missed precision: a SQL injection risk from building a query by string concatenation, and the one-line idempotent fix for the table creation. On the modeling question, I proposed “log loss” for a regression target and defended it twice under follow-up before reaching mean squared and mean absolute error, with a log transform on the skewed target.

I pushed back on that last point in my own debrief, because I did reach the right answer with the right reasoning. The coach’s response was fair: the problem was not the first word; it was defending the wrong term twice, which made a slip of vocabulary look like a gap in understanding.

The lesson: when you misspeak, correct it immediately and explicitly. “Sorry, log loss is for classification; for this I’d use MSE on a log-transformed target” costs five seconds. Defending a wrong term under follow-up costs the round. And code review rounds need their own practice: security basics and idempotency are not things you reason your way to under time pressure.

The round I thought I had failed#

The offer that surprised me came from AI Fiesta, after three rounds. The second was a design problem: a router that sends each query to one of several foundation models to minimize cost while keeping quality. My debrief rated it around a B: a clean restatement of the trade-off and a useful semantic caching idea, but a weak answer on offline evaluation and a closing that felt neutral rather than enthusiastic.

The third was the fraud detection design with the head of engineering. My clarification phase was strong and my model choices were sound, but the high-level design was underdeveloped, I left out a key layer until prompted, and I volunteered a weakness nobody had asked about. “Very basic” was a fair summary.

I still do not know exactly why it became an offer. The likeliest explanation is the one the debrief itself raised: a final round is weighed together with the earlier ones, and the parts of the round that went well (clarifying the problem, choosing models for the right reasons) may have mattered more to that interviewer than the parts that went badly.

The lesson: the round is not the unit of evaluation; the loop is. A bad round inside an otherwise solid loop is often survivable, and a solid round inside a loop with earlier warning signs is not guaranteed.

How wrong my reads were#

The table below compares the read after each round, mine and my coach’s, with what happened next. It covers the non-Google rounds; the Google rounds are in the post on running prep on Claude.

The reads were right about direction on the easier calls and wrong on both final rounds, which are the ones that mattered. That matches the interviewing.io data: the correlation between how you think you did and how you did is weak, and it is weakest exactly when you most want to know.

Results#

Four rejections out of 32 companies that interviewed me is a low rate, and I do not think it reflects unusually strong interviewing. It mostly reflects that I stopped 20 processes myself, many before they reached the stages where rejections happen.

What the rejections changed was concrete. I wrote the recovery protocol for unfamiliar questions after the probability puzzles. I started correcting misspoken terms immediately after the final-round regression question. I treated code review as its own practice area. And I stopped asking any debrief, mine or the coach’s, to predict an outcome.

What I’d do differently#

Apply where my scale is credible. The screen rejection was predictable from the job description. Time spent on roles where a hard requirement is out of reach is better spent elsewhere.

Prepare for every format, or skip it. The case-style round was the only format I walked into with no preparation at all. That was a choice I made by default rather than on purpose.

Practice puzzles and code reviews as separate skills. Both look like extensions of knowledge I had. Both turned out to need their own reps.

Take warning signs in earlier rounds seriously. An interviewer leading me toward the right framing in a middle round was a signal about the final round, and I treated it as a pass.

Conclusion#

Rejections are expensive to collect and cheap to learn from, provided you look for the specific, fixable cause rather than a verdict on yourself. Each of mine pointed at something concrete: a scale gap, a puzzle-solving method, an unprepared format, a defended slip. None of them pointed at the thing I feared after each one, which was that I was not good enough.

Your read of a round is a weak signal. A debrief is a strong one, as long as you use it to find the next fix and not to predict the email.

Part 8 of the 35 companies, 8 offers series. I join Google as a Software Engineer III, AI/ML, in October 2026.