Free lesson · Low Level Design Interviews

What Failure Looks Like - and Recovery

Easy11 min readlldinterview-prepoop

What Failure Looks Like and Recovery

Brandon Carter - Principal Engineer, AWS S3. With Olena Marchenko - Microsoft Azure Dev Tools. And Deepika Nair - Staff Engineer, Meta AI Infrastructure.

This is the topic I almost didn't want to write. Talking about how to succeed is comfortable. Talking about how I've failed - and watched others fail - is not. But I think this topic might be the most useful one in this module, because every candidate I've ever spoken to wants to know two things: what happens when it goes wrong, and what to do about it.

I'm going to open with the patterns I see from the interviewer chair. Then Olena will talk about a specific failure mode that broke her for years before she figured out how to compensate. Then Deepika will talk about the most common technical failure I see - being right but too slow - and the methodology she built to fix it. I'll close with what to do in the room, in real time, when you realize the interview is going sideways.

If you're reading this before your first big interview, I hope you'll come back to this topic after the first time something goes wrong. The point of this topic isn't to scare you. It's to give you a vocabulary for what you'll experience, so you can recognize and respond to it.

The five failure modes I see most often

— Brandon

After 300+ interviews, the failure modes are predictable. Most candidates who don't pass fall into one of these patterns. I've labeled them so you can recognize them in your own practice.

The collapsed clarification. The candidate hears the problem, nods, and starts designing within 30 seconds. They design for the problem in their head, which doesn't match the problem I have in mind. We discover the mismatch at minute 25 when their design doesn't accommodate something I thought was obvious. Recovery from this is expensive; sometimes there isn't enough time.

The over-modeled paralysis. The candidate spends 20 minutes drawing classes, hierarchies, relationships. The whiteboard fills with boxes. By the time they're ready to write code, they have 15 minutes left and a structure too complex to implement. The interview ends with elegant diagrams and empty methods.

The pattern-matched delivery. The candidate has memorized this problem (or one very similar). They produce a slick solution that doesn't quite fit. I throw a curveball - a variant requirement that the memorized solution doesn't accommodate - and watch them either freeze or try to bolt the new requirement onto the memorized structure. Memorization doesn't survive curveballs.

The defensive escalation. When I push back on a design choice, the candidate doubles down. They re-explain their original decision, add justifications, and resist engaging with the alternative. The conversation gets stuck. By the time we move on, we've burned five minutes and built a small wall between us. I'm now harder to convince on later questions.

The right-but-too-slow. The candidate is technically capable. Their thinking is sound. But they're slow - methodical, careful, producing correct work at half the necessary pace. At minute 30 they have a beautiful, partial solution. At minute 45 they have a beautiful, partial solution with apology. This is the most painful failure to watch, because the candidate is clearly capable in a low-pressure setting and the time pressure is what beat them.

Each failure mode has a recovery. Each one is preventable with practice. But the prevention starts with recognition - knowing what failure looks like before you're in it.

The failure I almost didn't recover from

— Olena

I want to talk about my eleven rejections.

I didn't grow up writing code. I have an Economics degree from Kyiv Polytechnic. I spent four years as a financial analyst at PwC Warsaw. I learned to code at 26 from freeCodeCamp and The Odin Project. By the time I started interviewing, I had two years of self-taught coding plus a year as a junior developer at a digital agency.

My first eleven tech interviews were all rejections. Every one. Some of them I bombed for obvious reasons - I genuinely didn't know things. But some of them I bombed for a reason that took me three years to understand.

In an LLD-style interview for a senior position at a German startup, the interviewer asked me to design a workout-tracking app. I'd built workout-tracking features before. I knew the domain. I started designing. About 15 minutes in, the interviewer asked: "How would you handle the case where a user wants to define their own custom exercise types?"

I froze.

It wasn't that I didn't know how. I could have answered. The freeze was something else. It was the feeling of being behind - the feeling that this question revealed something I should have anticipated but hadn't. I thought "an experienced engineer would have already designed for this." I felt the gap between me and the engineers I imagined as my peers.

I spent the next four minutes apologizing. "Sorry, I should have thought of that. Let me think." "Sorry, I'm not sure where to put this." "Sorry, I'm a bit slow today."

I didn't get the job.

What I learned over the next two years - what I had to learn deliberately, with help from mentors - is that the apologizing wasn't bad luck. It was a failure mode specific to my background. Engineers from non-traditional paths, especially those who were self-taught or career-switched, are prone to a specific kind of self-doubt: the suspicion that "real engineers" know things we don't, and that any question revealing a gap is proof of inadequacy.

This is wrong. The "real engineers" I work with at Microsoft don't have all the answers. They have the thinking pattern. They don't apologize when they don't know something. They reason through it out loud. They engage with the question.

Important: If you're from a non-traditional background, the failure mode to watch is self-disqualification under pressure.

The interviewer asks something you didn't anticipate. The reflex is to apologize. Don't. Engage. "Interesting - I didn't design for that. Let me think through it." Then think. The pause is fine. The engagement is the senior signal.

The eleven rejections taught me to recognize the freeze before it took over. By interview twelve, I was engaging instead of apologizing. By interview thirteen, I got the offer at Microsoft.

What I want you to take from my story isn't sympathy for the self-taught path. It's specific: the apology reflex is a failure mode. If you find yourself apologizing in interviews more than once per session, you have something to work on. Notice the pattern. Replace the apology with engagement. Practice this until it's automatic.

The methodology I built for being too slow

— Deepika

I have 23 rejection emails from FAANG companies. I kept all of them.

My problem wasn't lack of knowledge. I'd been a backend engineer at Wipro, Freshworks, and Thoughtworks. I knew object-oriented design. I knew patterns. I knew distributed systems. In code review with my peers, my work was strong.

My problem was speed.

In every interview I bombed, I produced correct solutions about 8 minutes too late. My reasoning was sound. My code was clean. My structure was right. But the interviewer's clock had run out, and I was 70% done with a 90-minute version of the problem in a 45-minute slot.

I'm a perfectionist. Under stress, I over-engineer. I want to handle the edge case. I want to make the abstraction right. I want to write the code that I'd be willing to commit to production. None of these are bad instincts. In production code, they're virtues. In interview code, they're killers.

After my fifteenth or sixteenth rejection, I changed my approach. I built a system.

I bought a notebook and started tracking every mock interview. Each entry had:

• The problem
• The time I spent in each phase (clarify, model, design, implement, verify)
• Where I got stuck
• Which patterns I considered and which I picked
• What I'd do differently next time

After 30 mock interviews logged, patterns emerged. I was spending an average of 22 minutes on modeling when I should have been spending 10. I was reconsidering my design at minute 25 when I should have been writing code. I was implementing exception handling and edge cases before the happy path worked.

The notebook became a system. Each mock had checkpoint times. If I wasn't transitioning to design by minute 15, the notebook told me. If I wasn't writing code by minute 30, the notebook told me. The discipline wasn't about thinking differently - it was about enforcing time-boxes on patterns I knew I had.

Four months later, I passed Meta's loop and got an E6 offer, skipping E5. The difference wasn't more knowledge. The difference was that I'd treated my interview performance as a system to be measured and tuned.

Important: If you're the kind of engineer who is excellent in untimed work but struggles in interviews, the answer might not be more knowledge. It might be explicit time-box enforcement.

Treat yourself as a system. Measure where time goes. Identify which phases consume too much. Build in checkpoints that interrupt the patterns you can't break naturally. The discipline isn't about smarter thinking. It's about preventing your own dominant patterns from running too long.

What I want you to take from my story is that interview performance is practiced. The candidates who clear FAANG loops on the first attempt are rare. Most clear them on the third or fourth attempt, after they've built systems for their own failure modes. Yours might be different from mine. But the meta-skill - recognizing the failure mode and building a counter-measure - generalizes.

Recovering in the room

— Brandon

The most useful thing I can teach you about failure is what to do when you realize, mid-interview, that something is going wrong.

This is the moment most candidates panic. They sense the interview is sliding sideways. The interviewer's questions feel sharper. The candidate's structure isn't holding. The clock is moving faster than the design. The candidate's instinct is to speed up, to push through, to hope the next minute makes it better.

This is wrong. The recovery move is to slow down and name what's happening.

The recovery script:

"Let me pause for a second. I think my current approach has a problem - specifically [the problem]. Can I take a minute to reconsider?"

That sentence does several things. It demonstrates self-awareness. It acknowledges the issue explicitly rather than hoping the interviewer didn't notice. It requests space to recover. Most interviewers respond well to this - far better than to a candidate plowing through a failing design.

After you've paused, the recovery follows one of three patterns:

Pattern 1: Refactor. You realize part of your structure is wrong. Refactor it. "I think I conflated two responsibilities in this class. Let me split them." Five minutes of focused refactoring can restore a design.

Pattern 2: Scope down. You realize you can't finish what you started in the time remaining. Tell the interviewer: "I don't think I can finish all of this. Let me focus on the core [X] and stub the rest. I'll explain how the stubbed parts would work."

Pattern 3: Restart small. Rarely the right call, but sometimes necessary. "I think this approach isn't working. Can I restart with a simpler structure?" The interviewer will usually allow this if you're clearly self-aware about why. They won't penalize the restart; they'll evaluate the new approach.

What you don't do: keep going as if nothing is wrong. The interviewer has already noticed. Hoping they didn't makes it worse. Acknowledging it and recovering shows engineering maturity - the same maturity you'd want from a teammate who realized a design wasn't working in production.

The signal of an L6+ candidate isn't that they never make mistakes. It's that they recognize mistakes early and recover deliberately. Real engineering involves recognizing when something is going wrong. The interview is, in microcosm, the same skill.

What we want you to take from this topic

Three of us wrote this topic together because the failure stories matter more than the success stories. Most prep material focuses on what to do when things go well. The skill that's actually rarer - and more valuable - is the skill of handling when things go wrong.

The patterns we've described:

• Brandon's five failure modes - recognize them in your own practice
• Olena's apology reflex - replace it with engagement
• Deepika's right-but-too-slow - measure your own pace and enforce checkpoints
• The in-room recovery - slow down, name what's happening, refactor or scope down

None of us cleared FAANG loops on the first try. Brandon failed Google twice. I had eleven rejections. Deepika had twenty-three. Across the three of us, that's somewhere around forty rejections before the offers we hold today.

The reason we're telling you this isn't false modesty. It's because the path is recoverable. Rejections aren't terminal. They're data. The candidates who eventually get the senior offers are the ones who study their own failures with the same rigor they bring to their craft.

Important: Failure is information. Every rejection is data about a gap you can close.

The candidates who eventually pass FAANG loops aren't the ones who never fail. They're the ones who treat each failure as a debugging exercise - what specifically went wrong, what's the underlying cause, what's the counter-measure for next time.

Common mistakes

Warning: The recurring failure-handling mistakes:

Apologizing instead of engaging. Self-disqualification on questions you didn't anticipate.

Speeding up when things go wrong. Trying to outrun the problem rather than acknowledging it.

Hoping the interviewer didn't notice. They did. Pretending otherwise makes it worse.

Defending failing designs. Doubling down instead of refactoring or scoping down.

Treating rejections as terminal. Each rejection is data; engineers who debug themselves get past it.

Not measuring your own patterns. Without measurement, you can't see your dominant failure modes.

Try It

Exercise: Failure-recovery practice:

1. Log your last five mock interviews. Where did you spend the most time? What phase did you collapse? What was your specific failure mode?

2. Identify your apology reflex. Watch a recording. How often did you apologize? Replace each apology with engagement.

3. Practice the recovery script. "Let me pause for a second" should feel natural. Practice it until it doesn't feel like surrender.

4. Build a checkpoint system. What time-boxes do you need? Where do you typically drift? Build your version of Deepika's notebook.

5. Study your last rejection. What specifically went wrong? What's the counter-measure for next time?

6. In your next mock, deliberately introduce a problem mid-interview (have your friend interrupt with a curveball). Practice the in-room recovery.

Closing - what comes next

This module has established the framing. The LLD interview is testing something specific (1.1). Interviewers are listening for specific signals (1.2). The 45 minutes have a shape (1.3). Strong performance has specific characteristics (1.4). Failure has recognizable patterns and recoveries (this topic).

The next modules cover how to do the work. Module 2 covers clarification - how to make ambiguous problems definite. Module 3 covers modeling - how to identify the entities and relationships. Module 4 covers design - how to make the structural decisions. Module 5 covers implementation - how to write the code that evidences your design. Module 6 covers communication - how to be visible to the interviewer throughout.

The framework you've built in this module - knowing what the interview is, what's being evaluated, how time flows, what strong looks like, what failure looks like - is the foundation. The methodology in the remaining modules is how to actually execute on that foundation.

Good luck. We've been where you are.

— Brandon, Olena, Deepika

Back to Low Level Design Interviews