How to Clarify Requirements

Why Clarification Matters

Amazon interviewers explicitly evaluate your ability to clarify requirements. A candidate who jumps straight into design without clarifying demonstrates poor engineering judgment. In real Amazon projects, unclear requirements lead to wasted sprints, rework, and missed deadlines. Your clarifying phase shows the interviewer you think before you build.

The 2-Minute Rule

Spend the first 2 minutes of your 45-minute interview asking clarifying questions. This is non-negotiable. Interviewers expect it, and it sets up your entire design on the right foundation.

How to start:

"Before I begin designing, I'd like to clarify some requirements to make sure I'm solving the right problem."

This single sentence shows maturity and structured thinking.

FABCD: The Six Dimensions

The FABCD framework ensures you cover every critical dimension of the problem. Use it as a mental checklist during your clarification phase.

Letter	Dimension	What to Ask	Example Questions
F	Features	What are the core use cases?	"Should users be able to search for products?"
A	Architecture	Any existing systems to integrate?	"Does this connect to the existing inventory system?"
B	Boundaries	What's in scope vs out of scope?	"Do we need to handle payments or just the cart?"
C	Constraints	Hard limits and requirements?	"What's the expected latency SLA?"
D	Data	What data exists and its properties?	"What's the data retention policy?"

FABCD Deep Dive

Features (F) — Identify the core functionality.

• What are the 2-3 primary use cases?
• Are there secondary features we should support?
• What does the user journey look like?

Architecture (A) — Understand the technical landscape.

• Is this greenfield or does it integrate with existing systems?
• Are there specific AWS services or tech stacks to use?
• What's the deployment environment (cloud, on-prem, hybrid)?

Boundaries (B) — Define scope clearly.

• What's explicitly OUT of scope?
• Are there admin/management interfaces needed?
• Do we need to handle internationalization?

Constraints (C) — Identify hard requirements.

• Latency requirements (p99 < 200ms?)
• Availability targets (99.9% or 99.99%?)
• Budget or cost constraints?
• Compliance requirements (GDPR, HIPAA)?

Data (D) — Understand the data characteristics.

• What are the data types and sizes?
• Read-to-write ratio?
• Data retention and archival policies?
• Consistency requirements (strong vs eventual)?

The Conversation Flow

A good clarification phase follows this pattern:

1. Start broad (30 seconds): "Let me make sure I understand the core problem..."
2. Drill into features (30 seconds): "For the main user flow, should we support...?"
3. Check constraints (30 seconds): "What are the performance requirements...?"
4. Confirm understanding (30 seconds): "Let me summarize what I've heard..."

Total: 2 minutes. Then move to estimation or design.

Questions by Category

Organize your questions by what they reveal. Not all questions are equal — some fundamentally change your design, while others are nice-to-know details.

Functional Requirements Questions

Question	Why It Matters	Impact on Design
What are the primary use cases?	Defines core architecture	Determines service boundaries
Who are the users?	Defines access patterns	Affects caching and CDN strategy
What's the user journey?	Defines data flow	Determines API design
Should users be able to search?	Adds query complexity	May need Elasticsearch
Do we need real-time updates?	Defines push vs pull	Affects WebSocket vs polling
Are there admin features?	Additional interfaces	Separate admin service

Non-Functional Requirements Questions

Question	Why It Matters	Impact on Design
What's the expected traffic?	Defines scale	Determines sharding strategy
What's the latency requirement?	Defines architecture	Affects sync vs async
What's the availability target?	Defines redundancy	Determines replication factor
What's the data retention policy?	Defines storage	Affects archive strategy
Is the data sensitive?	Defines security	Affects encryption at rest/transit
What's the read:write ratio?	Defines optimization	Affects caching strategy

The Most Important Questions

In practice, these 5 questions cover 80% of what you need:

1. "What are the core features we need to support?" — Forces prioritization
2. "What's the expected scale?" — Users, requests per day, data volume
3. "What are the latency requirements?" — p50, p99, p999 targets
4. "What's the consistency model?" — Strong vs eventual consistency
5. "What's out of scope?" — Prevents scope creep in design

Amazon-Specific Questions

Amazon interviewers particularly value questions about:

• "How does this integrate with existing Amazon services?" — Shows systems thinking
• "What's the cost optimization target?" — Amazon is cost-obsessed
• "Do we need to handle peak events like Prime Day?" — Shows Amazon culture awareness
• "What's the data compliance requirement?" — GDPR, CCPA awareness
• "Should we design for graceful degradation?" — Fault tolerance mindset

Questions to Avoid

Bad Question	Why It's Bad	Better Alternative
"Is this a REST API?"	Too technical too early	"What's the expected latency?"
"Should we use MySQL?"	Premature optimization	"What are the data characteristics?"
"How many servers?"	Implementation detail	"What's the expected traffic?"
"What language?"	Irrelevant to design	"Are there existing tech constraints?"

The Clarification Summary

After asking questions, always summarize:

"Let me make sure I understand correctly. We're building a [system] that [core function] for [users] at [scale] with [consistency] requirements. The key constraints are [constraints]. We're NOT building [out of scope]. Is that correct?"

This summary serves three purposes:

1. Confirms your understanding
2. Shows the interviewer you're organized
3. Creates a natural transition to estimation or design

Scenario 1: Design a URL Shortener

Interviewer: "Design a URL shortener service like bit.ly."

Good Clarification:

"Before I start, let me clarify a few things. For the core features, I'm thinking: (1) given a long URL, generate a short URL, (2) given a short URL, redirect to the original. Should I also support custom aliases, expiration dates, or analytics?"

"For scale, what's the expected traffic? Are we looking at 100M URLs created per day or 1B?"

"For read patterns, what's the expected read-to-write ratio? Typically 10:1 or 100:1?"

"What about consistency — do we need to guarantee the same short URL always maps to the same long URL, or is eventual consistency acceptable?"

"Is this a standalone service or does it integrate with other systems?"

Key Takeaway: Notice how the candidate covers Features (shorten + redirect + custom aliases), Scale (traffic volume), Read patterns (ratio), Consistency (strong vs eventual), and Architecture (standalone vs integrated).

Scenario 2: Design a Chat System

Interviewer: "Design a chat system like WhatsApp."

Good Clarification:

"Let me clarify the scope. For features, I'm assuming: (1) 1-on-1 messaging, (2) group chats, (3) message delivery confirmation. Should I support voice/video calls, file sharing, or read receipts?"

"For users, how many concurrent users are we designing for? Are we targeting global scale or a specific region?"

"What are the latency expectations? For chat, I'd assume sub-100ms for message delivery. Is that correct?"

"For persistence, how long should we retain message history? Indefinitely or for a specific period?"

"Should messages be encrypted end-to-end? This would significantly impact the architecture."

"What about offline support — should users receive messages they missed while offline?"

Key Takeaway: The candidate identifies scope boundaries (1-on-1 vs group vs calls), scale (concurrent users), latency (sub-100ms), data retention, security (encryption), and offline behavior.

Scenario 3: Design an E-commerce Platform

Interviewer: "Design the product catalog for an e-commerce site."

Good Clarification:

"Before I design, let me clarify. When you say 'product catalog,' do you mean just browsing and search, or also the checkout and payment flow?"

"For the product data, what's the typical size? Are we dealing with simple products or complex ones with variants, bundles, and digital goods?"

"What's the expected inventory? 1M products or 100M?"

"For search, do we need full-text search with filters, or is simple category browsing sufficient?"

"What about personalization — should we show recommendations based on user behavior?"

"Are there regional differences? Do we need to support multiple currencies, languages, and tax rules?"

Key Takeaway: The candidate distinguishes between core (catalog) and adjacent (checkout), understands data complexity, identifies search requirements, and considers personalization and internationalization.

Scenario 4: Design a Notification System

Interviewer: "Design a notification system for a mobile app."

Good Clarification:

"Let me clarify the notification types. Are we supporting push notifications, SMS, email, or all three?"

"For scale, how many notifications per day? Are we talking 1M or 1B?"

"What's the latency requirement — should notifications be delivered within seconds or is minutes acceptable?"

"Do we need to handle user preferences? Should users be able to opt out of certain notification types?"

"What about delivery guarantees — do we need at-least-once or exactly-once delivery?"

"Should we support scheduled notifications or just real-time?"

"Do we need analytics — open rates, click-through rates, delivery confirmations?"

Key Takeaway: The candidate covers notification channels, scale, latency, user preferences, delivery semantics, scheduling, and analytics — all critical dimensions for this system.

Anti-Patterns in Practice

Anti-Pattern: Asking Too Many Questions

"What color should the button be? What font should we use? Should we support IE11?"

This wastes time and shows you can't prioritize.

Anti-Pattern: Asking Obvious Questions

"Should a URL shortener actually shorten URLs?"

This shows you haven't thought about the problem.

Anti-Pattern: No Summary
After asking 10 questions, the candidate jumps straight to "So I'll use a load balancer..." without summarizing what they learned.

Good Pattern: Structured and Concise

"Let me clarify a few key things, then I'll move to estimation."

This shows time management and respect for the interview structure.

The Amazon Mindset

Amazon interviewers want to see:

1. Structured thinking — Use a framework, not random questions
2. Business awareness — Ask about users, scale, and impact
3. Technical depth — Ask about consistency, latency, and data
4. Time management — Ask the right questions in 2 minutes
5. Communication — Summarize what you learned before proceeding