Amazon Data Engineer Interviews Split 60/40 Between System Design and SQL—Not Coding

Candidates who've completed Amazon's data engineer loop in the past 18 months consistently report that only 1-2 of their 5 technical rounds focused primarily on algorithmic coding—the rest evaluated data modeling, pipeline architecture, and SQL optimization. That gap between expected and actual evaluation structure explains why so many candidates walk out feeling blindsided despite weeks of LeetCode preparation.

The mismatch happens because most Amazon interview content is written from the SDE perspective, where coding rounds dominate. DE candidates default to the same prep strategy—grinding algorithms, practicing tree traversals, memorizing dynamic programming patterns—because that's what the available content tells them to do. But Amazon's interview structure for data engineers evaluates different technical signals, weighted differently, in rounds that test different skills.

The structural difference matters. If you're allocating 70% of your prep time to coding problems because that's what worked for your friend who interviewed for an SDE role, you're preparing for the minority of your evaluation. The majority of your technical signal will come from rounds you may not have practiced at all.

What the Loop Actually Contains

Amazon's DE loop typically includes five technical rounds split as: two architecture or design rounds, one SQL-focused round, one to two coding rounds, plus separate behavioral interviews. Candidates who completed the loop between mid-2023 and early 2024 consistently report this structure, though the order varies.

The architecture rounds evaluate data modeling and pipeline design—not distributed systems architecture in the SDE sense. The SQL round tests both query writing and optimization thinking. The coding rounds focus on data transformation logic and practical data structure usage, not algorithmic complexity. That distribution means roughly 60% of your technical evaluation happens in non-coding rounds.

To illustrate the difference: an SDE system design question might ask you to design a rate limiter for an API, testing your understanding of distributed systems, concurrency, and infrastructure. A DE system design question asks you to design a data warehouse schema to support product analytics with historical tracking and slowly changing dimensions—testing your understanding of dimensional modeling, query patterns, and data quality constraints. Same round name, completely different evaluation criteria.

What 'System Design' Means for Data Engineers

Frequently reported DE architecture questions include designing star or snowflake schemas for specific business requirements, architecting streaming pipelines that handle late-arriving data, implementing change data capture patterns, and developing partition strategies for datasets at scale. These questions evaluate whether you've made real architectural tradeoff decisions in production environments.

A weak architecture answer describes what you'd build: "I'd use a star schema with a fact table for orders and dimension tables for customers, products, and time." A strong answer explains why and what you're trading off: "I'd use a star schema here rather than a one big table approach because the business needs dimensional flexibility for slicing across multiple hierarchies, and query performance is less critical than schema maintainability given the 10-person analytics team who'll be writing SQL directly against this model. The denormalization cost is acceptable because dimension cardinality is low and we can handle the ETL complexity of maintaining the star model."

That level of specificity requires understanding not just the theoretical difference between schema types, but the practical implications of choosing one over another in a specific business context. It's what separates candidates who've read about dimensional modeling from candidates who've debugged a poorly designed schema at 2am.

The same pattern applies to pipeline architecture questions. When asked to design a streaming pipeline that processes user events, strong candidates discuss Lambda versus Kappa architectures with specific reasoning about exactly-once semantics, late-arrival handling, and reprocessing requirements. They reference real tradeoffs—not textbook definitions.

The SQL Round: Beyond Query Writing

Amazon's SQL evaluation frequently follows a two-part structure, as reported by candidates who completed the loop. First, write a query to solve a problem—often involving window functions, complex joins, or hierarchical data. Then, explain how you'd optimize it if the table had 100 million rows or if query latency became an issue.

The second part separates candidates who can write correct SQL from candidates who understand how SQL executes. Strong answers reference specific optimization strategies: partition pruning, covering indexes, predicate pushdown, or query plan analysis. They demonstrate you've debugged slow queries in production, not just passed a SQL tutorial.

This isn't academic. Data engineer interviews across companies increasingly evaluate whether you understand the performance implications of your queries, because writing correct but inefficient SQL creates technical debt that scales badly. Amazon tests this explicitly.

What Actually Gets Tested in Coding Rounds

Amazon DE coding rounds focus on data transformation logic, ETL patterns, and practical data structure usage. A typical question: given a stream of user events with timestamps, write a function to aggregate events into five-minute windows and identify sessions. This tests data manipulation and windowing logic, not algorithmic complexity.

Most reported DE coding problems fall into LeetCode Easy to Medium equivalent complexity. The evaluation emphasizes correctness and clarity over optimization. Can you parse messy input data? Can you handle edge cases like missing timestamps or out-of-order events? Can you write clean transformation logic that another engineer could maintain?

This differs substantially from SDE coding rounds, which test algorithmic thinking through problems that require recognizing patterns, choosing optimal data structures, and analyzing time complexity. DE coding rounds assume you can code competently and instead evaluate whether you think about data problems the way production data engineers need to think about them.

How This Changes Your Remaining Prep Time

If you have three weeks before your loop and you've been doing primarily LeetCode, you need to reallocate. A more effective split: 40% architecture preparation (dimensional modeling, pipeline patterns, tradeoff frameworks), 30% SQL (complex queries and optimization), 30% coding focused on data manipulation and ETL patterns.

Architecture prep means working through schema design exercises for different business cases, understanding when to use Type 2 versus Type 3 slowly changing dimensions, learning Lambda versus Kappa pipeline patterns with specific tradeoffs, and practicing explaining your reasoning out loud. You need to build the muscle of justifying architectural decisions with specific constraints.

SQL prep means writing complex queries with window functions and self-joins, then explaining how you'd optimize them. Practice reading execution plans. Understand what makes a query slow at scale. Work through scenarios where you'd denormalize for performance versus maintain normalization for data quality.

Coding prep should focus on data transformation problems: parsing structured and semi-structured data, implementing aggregation logic, handling data quality issues, writing ETL patterns. Do enough LeetCode Medium problems to be comfortable with basic data structures and algorithms, but don't optimize for Hard problems you're unlikely to see.

The Behavioral Weight: Ownership Over Innovation

Amazon DE behavioral rounds emphasize Ownership and Deliver Results more heavily than principles like Invent and Simplify. Candidates consistently report interviewers probing for stories about data quality incidents, pipeline ownership, and cross-functional data delivery under ambiguity. The role is about building reliable pipelines and owning data quality—not inventing new technologies.

Strong behavioral stories for DE roles demonstrate you've owned a pipeline end-to-end, debugged data quality issues that affected downstream teams, made tradeoff decisions between perfect data and timely delivery, and coordinated across teams to define data contracts. The specific evaluation criteria for Amazon's DE role weight operational excellence and ownership over pure innovation.

This behavioral focus aligns with the technical evaluation. Amazon wants data engineers who will own the architecture decisions they make in those design rounds, who will optimize the queries they write in the SQL round, and who will maintain the pipelines they build in the coding round. The behavioral bar tests whether you've actually done that before.

What You're Actually Walking Into

If you're walking into an Amazon DE loop with only coding prep, you're prepared for 30-40% of the technical evaluation. The recruiter who mentioned "system design" and "data modeling" wasn't being vague—they were describing the majority of your loop. The architecture rounds will test whether you can design maintainable data systems. The SQL round will test whether you understand query optimization. The coding rounds will test whether you can write clean data transformation logic.

Candidates who misprepare consistently report the same realization: they could have solved the coding problems in their sleep, but they struggled to explain why they'd choose one schema design over another, or how they'd partition a large table, or what makes a query slow at scale. Those are the questions that determine whether you pass.

The conventional wisdom that Amazon interviews are LeetCode-heavy comes from SDE candidates. For DE roles, the evaluation is fundamentally different. Your prep strategy should be too.