Amazon Data Scientist Interview Cheatsheet 2026

Amazon Data Scientist interviews test whether you can turn messy data into a product decision you can defend. You need SQL or pandas fluency, experiment design, metric judgment, ML fundamentals, and clear communication when the prompt is underspecified.

This post is a condensed, blog-friendly version of the PracHub Amazon Data Scientist interview cheatsheet, focused on the parts that tend to separate candidates who have done real analysis from candidates who only know textbook definitions.

What Amazon is usually testing

The interview loop can cover several areas:

• Data manipulation with SQL and Python
• Product analytics and root-cause analysis
• A/B testing and statistical inference
• Machine learning fundamentals and evaluation
• Applied ML system thinking, including RAG
• Behavioral answers mapped to Amazon Leadership Principles

The bar is not "can you recite a formula?" It is closer to: can you define the right metric, compute it correctly, explain your assumptions, catch validity problems, and recommend an action?

Python and pandas: show that your metrics are trustworthy

For pandas questions, interviewers want analysis-grade data manipulation. Expect messy inputs, duplicate rows, mixed date formats, joins across tables, missing values, and business logic hidden in the prompt.

Common pattern:

df.groupby(keys).agg(
    revenue=("revenue", "sum"),
    orders=("order_id", "nunique"),
    customers=("customer_id", "nunique")
)

That code is easy. The interview is about whether the aggregation is valid.

Before grouping, ask:

• What is the row grain?
• Are there duplicate events or repeated order lines?
• Are timestamps in the same timezone?
• Are we joining many-to-one, one-to-many, or many-to-many?
• Do we need currency normalization before summing revenue?
• How should ties be handled in rankings?

A good answer sounds like this:

"I would first validate the grain. If this table is order-line level, I should not count rows as orders. I would count distinct order IDs, normalize currency through the exchange-rate table, then aggregate by customer and month."

That shows you know metric code can be syntactically correct and still wrong.

Useful pandas tools to have ready:

• pd.to_datetime() for date cleanup
• .dt.date, .dt.to_period("M") for time buckets
• merge() for lookup joins
• drop_duplicates() for business-key dedupe
• rank(), sort_values(), cumcount() for within-group ranking
• np.where(), pd.cut(), boolean masks for segments

The biggest mistake is aggregating before fixing grain. Once duplicate rows flow into your metric table, every chart and model downstream inherits the error.

A/B testing: do not jump straight to p-values

Amazon-style experimentation questions usually ask you to design or analyze an online controlled experiment. The interviewer is testing causal reasoning, metric design, statistical mechanics, and judgment.

Start with clarification:

• What is the randomization unit: user, session, product, request?
• What is the primary metric?
• What are the guardrails?
• Is the assignment stable?
• Is the analysis window long enough for delayed outcomes?
• Are users counted once or multiple times?

For a binary metric, such as conversion, you may compute:

• Control rate: x_c / n_c
• Treatment rate: x_t / n_t
• Absolute lift: p_t - p_c
• Relative lift: (p_t - p_c) / p_c
• Confidence interval for the difference
• Two-proportion z-test, if sample size assumptions are reasonable

But a better interview answer does not stop there.

Before inference, check validity:

• Sample ratio mismatch
• Exposure logging gaps
• Duplicate users
• Bot or internal traffic
• Pre-period balance
• Metric denominator consistency
• Unit mismatch between randomization and analysis

A weak answer is:

"Treatment conversion is higher and p < 0.05, so launch."

A better answer is:

"I would first verify the planned traffic split and user-level assignment. Then I would estimate absolute and relative lift with a confidence interval. I would launch only if the lift is statistically and practically meaningful, guardrails such as latency and refund rate are neutral, and the result is stable across major pre-specified cohorts."

That last part matters. At Amazon scale, a tiny lift can be statistically significant. It still may not be worth shipping if it harms customer trust, latency, complaints, or downstream outcomes.

For sample size questions, ask for:

• Baseline conversion rate
• Minimum detectable effect
• Alpha
• Desired power
• Number of variants
• Metric type: binary, continuous, ratio-based, clustered

Then define the decision rule before the data arrives. For example:

"Ship if the 95% confidence interval excludes zero, the lower bound is above the practical threshold, and guardrail metrics stay within agreed limits."

Product metrics and root-cause analysis: build the metric tree

Product analytics questions often start with a vague movement:

• "Revenue dropped."
• "CTR is down."
• "Search conversion changed."
• "A dashboard metric spiked."

Do not start with random theories. Start by defining the metric and decomposing it.

For revenue, a simple tree might be:

Revenue = Traffic × Conversion Rate × Average Order Value

Then break each branch down:

Traffic:
- visits
- unique customers
- channel mix
- device mix

Conversion:
- product views
- add-to-cart rate
- checkout start rate
- order completion rate

Average Order Value:
- item price
- units per order
- discounts
- shipping or fees

Good root-cause analysis usually follows this flow:

1. Confirm the metric definition.
2. Check data quality and pipeline changes.
3. Compare time windows correctly.
4. Segment by product, geography, device, customer type, traffic source, or cohort.
5. Separate correlation from causal claims.
6. Use visualizations that match the question.

Dashboard tooling can mislead if joins, filters, and aggregation grain are wrong. If a Tableau chart says revenue dropped, you still need to know whether it uses order date or shipment date, whether canceled orders are included, and whether currency conversion happened before or after aggregation.

RAG questions: treat it as an ML system, not "add a vector database"

Retrieval-augmented generation is now fair game for Data Scientist interviews. The DS angle is less about serving infrastructure and more about evaluation, tradeoffs, and risk.

A typical RAG pipeline has:

• Document selection
• Chunking
• Embeddings
• Vector retrieval
• Optional lexical retrieval such as BM25
• Reranking
• Prompt construction
• Generation
• Post-generation validation

If asked to design or evaluate a RAG system, frame the use case first:

"What corpus are we answering from? How fresh is it? What is the cost of a wrong answer? Do we need citations? Are out-of-scope questions common?"

Then split evaluation into retrieval quality and answer quality.

Retrieval metrics:

• Recall@k
• Precision@k
• MRR
• nDCG@k

Answer metrics:

• Correctness
• Faithfulness to retrieved context
• Citation accuracy
• Coverage
• Refusal quality
• Helpfulness
• Latency and cost per query

A key distinction: an answer can be true but unsupported by the retrieved context. For factual systems, that is still a failure.

Know the RAG vs fine-tuning tradeoff:

• Use RAG when facts change often, citations matter, or the corpus is large.
• Use fine-tuning for tone, output format, intent classification, or consistent task behavior.
• A strong system may use RAG for grounding and fine-tuning for behavior.

For Amazon-like catalogs, policies, seller docs, and support content, hybrid retrieval often makes sense. Dense retrieval handles semantic similarity. BM25 helps with exact product IDs, policy names, rare entities, and error codes. A reranker can improve the final passage list, though it adds latency and cost.

Behavioral answers still matter

For Amazon, technical strength is not enough. Prepare STAR stories tied to Leadership Principles. Your stories should be specific: what you owned, what tradeoff you made, what data you used, what changed because of your work.

Avoid generic claims like "I am customer obsessed." Show the decision.

For example:

"We had a metric discrepancy between two dashboards. I traced it to different order-date logic, aligned the definition with finance, backfilled the metric table, and added validation checks so the issue would not recur."

That kind of story connects ownership, data quality, and business impact.

How to practice

Use timed practice. For each question, force yourself to produce:

• Clarifying questions
• Assumptions
• A clean solution path
• Edge cases
• A recommendation or decision rule

You can find related prompts in the PracHub interview question bank.

If you want the full topic map, examples, and practice cards for this role, use the Amazon Data Scientist interview cheatsheet on PracHub as your prep checklist.