Handling Interruptions

Why Interviewers Interrupt

Amazon interviewers are trained to interrupt. It's not rude — it's a deliberate signal-gathering technique. They want to see:

1. Adaptability: Can you adjust when requirements change?
2. Composure: Do you stay calm under pressure?
3. Depth: Can you go deeper when asked, not just stay at surface level?
4. Listening: Are you actually hearing their questions, or just continuing your script?
5. Flexibility: Can you hold multiple design alternatives in your head?

The 5 Types of Interruptions

Type 1: Clarifying Questions

These come early and help the interviewer understand your thought process.

Examples:

• "When you say 'high scale,' what numbers are you thinking?"
• "Does this need to support real-time updates?"
• "Is this a new system or are we redesigning an existing one?"

Your response: Answer directly, then continue your design. Don't treat these as disruptions — they're part of the conversation.

Type 2: Direction Changes

The interviewer pivots the discussion to a different area.

Examples:

• "Actually, let's focus on the database schema instead of the API layer."
• "Let's skip the queue discussion and talk about caching."
• "Forget the read path for now — let's focus on writes."

Your response: Acknowledge the pivot, mentally bookmark where you were, and follow their lead.

Type 3: Constraint Additions

The interviewer adds a new constraint to your design.

Examples:

• "What if we can't use a cache?"
• "Now assume we need to support 10x more traffic."
• "What if the database can only handle 10K QPS?"

Your response: Acknowledge the constraint, explain how your design changes, and show you can think on your feet.

Type 4: Deep-Dive Requests

The interviewer wants you to go deeper on a specific component.

Examples:

• "Tell me more about the database schema."
• "How would you handle the cache invalidation?"
• "Walk me through the failure scenario for the database."

Your response: Zoom in on that component. This is an opportunity to show depth.

Type 5: Challenge / Pushback

The interviewer questions your design choice.

Examples:

• "Why not use a relational database here?"
• "That seems like a lot of complexity — is it necessary?"
• "What happens when this component fails?"

Your response: Acknowledge the challenge, explain your reasoning, and be open to changing your mind if their point is valid.

The Acknowledge → Adapt → Continue Pattern

For every interruption, use this 3-step pattern:

Step 1: Acknowledge

• Show you heard them: "That's a good point" or "Great question"
• Don't argue or get defensive
• Don't ignore and continue your monologue

Step 2: Adapt

• Adjust your design based on their input
• Explain what changes and why
• Show flexibility in your thinking

Step 3: Continue

• Resume your design from where you left off
• Or follow their new direction
• Don't dwell on the interruption

Handling Direction Changes

Interviewer: "Actually, let's focus on the database design instead of the API."

Good response:

"Sure, let's switch to the database. So for our schema, we have three main entities..."

Bad response:

"But I haven't finished the API layer yet..."

Why it's bad: You're fighting the interviewer's direction. They're guiding the conversation for a reason.

Strategy: When the interviewer pivots, say "Sure" or "Good point" and follow their lead. You can always come back to your previous point if needed:

"I'll set aside the API discussion for now and focus on the database. We can come back to the API layer after we nail down the schema."

Handling Constraint Additions

Interviewer: "What if we can't use a cache?"

Good response:

"Without a cache, we'd need to optimize the database layer more aggressively. I'd consider: 1) adding read replicas for read scaling, 2) denormalizing the schema to reduce joins, 3) using a CDN for static content. The latency impact would be..."

Why it's good: You acknowledge the constraint, explain the adjustments, and show you can design under different conditions.

Bad response:

"We really need a cache for this to work."

Why it's bad: You're not adapting to the constraint. The interviewer wants to see flexibility.

Handling Deep-Dive Requests

Interviewer: "Tell me more about the database schema."

Good response:

"Let me go deeper on the schema. We have a Users table with partition key userId, and a Orders table with composite key (userId, timestamp). The reason for this composite key is..."

Strategy: When asked to deep-dive, zoom in but maintain structure:

1. Restate what you're going to cover: "Let me go deeper on X."
2. Provide the details: schema, indexes, access patterns.
3. Connect back to the bigger picture: "This supports the main use case of Y."

Handling Challenges / Pushback

Interviewer: "Why not use a relational database here?"

Good response:

"That's a fair question. I chose DynamoDB because our access pattern is key-value lookups by userId, which DynamoDB handles very efficiently. However, if we needed complex joins or transactions across multiple tables, a relational database like PostgreSQL with RDS would be better. The tradeoff is..."

Why it's good: You explain your reasoning, acknowledge the alternative, and discuss tradeoffs.

Bad response:

"DynamoDB is better for NoSQL."

Why it's bad: No depth, no reasoning, no tradeoffs.

Strategy for pushback:

1. Acknowledge the challenge: "That's a good point" or "Fair question"
2. Explain your reasoning: "I chose X because..."
3. Acknowledge the alternative: "If we needed Y, I'd switch to Z"
4. Discuss tradeoffs: "The tradeoff is..."

Interruptions Are Normal

Expect 3-5 interruptions in a 45-minute interview. This is by design. If you're not being interrupted, the interviewer may not be engaged.

Mental model: Treat interruptions as collaboration, not disruption. The interviewer is helping you build a better design.

Don't Get Flustered

Signs you're getting flustered:

• Speaking faster than normal
• Repeating yourself
• Forgetting where you were in your design
• Getting defensive about your choices
• Going silent for extended periods

Recovery techniques:

• Take a breath before responding
• Restate the question: "So you're asking about X..."
• Summarize where you are: "Let me recap where we are..."
• If you're lost, ask: "Can we go back to the high-level architecture?"

Holding Multiple Design Alternatives

When the interviewer adds constraints, you may need to hold 2-3 design alternatives in your head simultaneously.

Technique: Use mental "what-if" branching:

Main design: DynamoDB + Redis cache
  ├── What if no cache? → DynamoDB + read replicas + CDN
  ├── What if 10x traffic? → DynamoDB + elasticache cluster + sharding
  └── What if strong consistency needed? → PostgreSQL + RDS Multi-AZ

Practice this by designing one system and then asking yourself "what if" questions.

Pacing After Interruptions

After an interruption, you may lose track of time. Use these checkpoints:

• After clarification: Am I still on track for estimation?
• After direction change: Do I need to adjust my timeline?
• After deep-dive: Am I running low on time? Should I skip the queue discussion?
• Before wrap-up: Have I covered the key points?

The 10-Second Rule

When interrupted, take 10 seconds before responding:

1. Seconds 1-2: Listen fully to the question
2. Seconds 3-4: Process what they're asking
3. Seconds 5-7: Formulate your response
4. Seconds 8-10: Begin speaking clearly

This prevents knee-jerk reactions and shows thoughtfulness.

Common Interruption Scenarios and Responses

Scenario	What to Say
"Let's focus on X instead"	"Sure, let's pivot to X. [Continue on X]"
"What if we can't use Y?"	"Without Y, I'd adjust by [alternative approach]. The impact is [tradeoff]."
"Tell me more about Z"	"Let me go deeper on Z. [Detailed explanation]"
"Why did you choose A over B?"	"I chose A because [reason]. B would work if [condition], but A is better here because [reason]."
"That seems too complex"	"Fair point. We could simplify by [simplification]. The tradeoff is [what we lose]."
"What about failure scenarios?"	"Great question. Let me walk through failures for each component..."
"We only have 10 minutes left"	"Understood. Let me summarize the key design decisions and tradeoffs."

Amazon-Specific Expectations

Amazon interviewers specifically test for:

1. Customer Obsession: Do you keep the user's needs in mind even when interrupted?
2. Bias for Action: Do you continue making progress, or get stuck?
3. Learn and Be Curious: Do you engage with the interruption as a learning opportunity?
4. Deliver Results: Do you still reach a complete design despite interruptions?
5. Earn Trust: Do you acknowledge limitations and tradeoffs honestly?

Practice Exercise

Design a URL shortener while having someone interrupt you every 3-5 minutes with:

• "What if we need to support 10x traffic?"
• "How does the database schema look?"
• "What happens if the cache fails?"
• "Let's focus on the analytics feature instead."

Practice responding gracefully to each interruption while maintaining your design coherence.