Learning · August 25, 2026 · 6 min read

10 data engineering cheat sheets: the concepts every pipeline interview assumes

Data engineering interviews rarely ask for syntax. They probe whether you hold the core distinctions: ETL vs ELT, batch vs streaming, star vs snowflake, idempotent reruns. Here are 10 free one-page references that cover the conceptual layer every pipeline conversation assumes.

By D8A Academy

Data engineering interviews have a strange shape. They rarely ask you to write much code. Instead they probe distinctions: what actually separates ETL from ELT, when streaming is worth its cost, why a retry loaded every order twice. These are one-page ideas, which makes one-page references the right way to hold them. Here are 10 free cheat sheets covering the conceptual layer that every pipeline interview, and every real pipeline, quietly assumes you have.

The 10 sheets at a glance:

Architecture: the four decisions behind every stack

Every data platform is a stack of choices, and interviewers love asking you to defend them. These four sheets are the decisions themselves.

ETL vs ELT

One question decides your tooling, your costs, and who shapes the data: does Transform run before or after loading? The full comparison, and where dbt fits.

Where Transform runs

Batch vs streaming

Nobody needs real-time; they need a freshness number nobody asked for. The one question that settles the choice, the honest cost gap, and the micro-batch middle.

The freshness question

Warehouse, lake, lakehouse

Schema on write vs schema on read drives everything else. What separates the three architectures, the questions that pick between them, and the data swamp trap.

Storage showdown

OLTP vs OLAP

Why the database that runs your app is the wrong place for dashboards. Row vs column storage, and the prod-DB trap that slows production.

Rows vs columns

Read them as a set: ETL vs ELT, batch vs streaming, warehouse vs lake vs lakehouse, and OLTP vs OLAP. Together they let you sketch a defensible architecture on a whiteboard, which is precisely what design rounds ask for.

ETL vs ELT cheat sheet: where Transform runs, what it changes for tooling and cost, and where dbt fits — The ETL vs ELT sheet: the one decision that shapes the rest of your stack.

The question behind the question

When an interviewer asks batch or streaming for this pipeline, they are not testing tool knowledge. They are testing whether you ask for the freshness requirement before choosing the expensive option. Almost every architecture question in these four sheets has that shape: the right answer starts with a question, and the sheet tells you which one.

Modeling: how warehouses are actually shaped

Modern tools automate the plumbing; nobody has automated the decision of what your tables should look like. Modeling questions are where pipeline interviews get concrete.

Star vs snowflake

The two classic warehouse shapes, when each wins, and the vocabulary interviewers expect, with diagrams. Star is usually faster; here is exactly why.

Schema shapes

Fact vs dimension

The two-question test that sorts any column into fact or dimension in five seconds, and the join pattern behind every BI query.

Five-second test

Keys, explained

Primary, foreign, surrogate, composite: the four kinds of keys, why surrogates win the primary-key job, and what ON DELETE CASCADE really deletes.

What connects it all

The set: star vs snowflake, fact vs dimension tables, and database keys explained. Design a schema for an online store is a near-universal interview prompt, and these three pages are the complete answer: a fact table of orders, dimensions for customers and products, surrogate keys tying it together.

Star vs snowflake schema cheat sheet: the two warehouse shapes with diagrams, when each wins, and the vocabulary interviewers expect — The star vs snowflake sheet: the whiteboard answer to the design-a-schema prompt.

Pipelines and practice: what production actually demands

The last cluster is what separates people who have run pipelines from people who have read about them: reliability and workflow.

Idempotency

One timeout, one retry, every order loaded twice. Why plain INSERT is a loaded gun, and the three patterns, MERGE, partition overwrite, run-id dedupe, that make reruns free.

Safe reruns

dbt basics

Models as SELECTs, ref() and the DAG it builds, two-line data tests, and the three materializations that cover real projects. dbt on one page.

Modern transform

Git for data

The daily loop, branches, the three ways to undo, and the .gitignore hygiene that keeps 2 GB CSVs and API keys out of your public repos.

Version control

Start with idempotency; the question what happens when your pipeline runs twice is the single best filter interviewers have for real experience. Then dbt basics, because dbt is now the default transform layer in ELT stacks, and git for data, because your pipeline code is only as trustworthy as its history.

Idempotency cheat sheet: why plain INSERT breaks on retries, and the MERGE, partition overwrite, and run-id dedupe patterns that make reruns safe — The idempotency sheet: the answer to the best interview filter in data engineering.

Ask a candidate what happens when their pipeline runs twice. People who have operated real systems flinch, then answer in patterns. People who have only watched courses say it runs again.

The interview filter that never misses

How to use these sheets so they actually stick

Ten one-pagers can be skimmed in an evening, and skimming will get you almost nothing. Concepts feel understood long before they are usable. Use the sheets in three passes.

1
Read for the distinction
Each sheet is built around a single distinction. Your first pass is done when you can state it in one plain sentence, the way you would to a colleague.
Questions to ask
- One sheet, one core contrast
- Say the difference out loud in one sentence
- If you can't, reread just that part
2
Drill with recall, not rereading
Reproduce the star schema diagram, the ETL vs ELT table, the three idempotency patterns from a blank page. The gaps you find are the actual studying.
Questions to ask
- Close the sheet
- Redraw the diagram or table from memory
- Note what you missed, retry tomorrow
3
Build something that forces the concepts
A pipeline that survives a double run teaches idempotency better than ten rereads. And it becomes the story you tell when the interviewer says walk me through something you built.
Questions to ask
- A small end-to-end pipeline on real data
- Modeled, tested, version controlled, rerunnable
- Public, so an interviewer can open it

That third step is the honest one. Cheat sheets cover the layer interviews assume; they do not create the experience interviews reward. These concepts only start counting once they exist inside a project someone can open: a scheduled ingest, a star schema, dbt models with tests, a repo with a clean history. If you need a concrete starting point, our list of data portfolio project ideas includes engineering-flavored builds, and the DA, DS, DE, BA breakdown helps if you are still choosing the engineering path at all. Learn the distinctions from the sheets. Then go build the thing that proves you own them.

Frequently asked questions

What concepts should I know for a data engineering interview?

Four clusters come up constantly. Architecture: ETL vs ELT, batch vs streaming, warehouse vs lake vs lakehouse, OLTP vs OLAP. Modeling: star vs snowflake schemas, fact vs dimension tables, and how keys connect everything. Pipeline reliability: idempotency, why reruns must be safe, and how retries create duplicates. Tooling literacy: dbt and git. Interviewers rarely ask for tool syntax; they probe whether these distinctions are actually clear in your head.

What is the difference between ETL and ELT and why does it matter?

Both move data from sources to a destination; the difference is where the Transform step runs. ETL transforms before loading, on separate infrastructure, and dominated when warehouse compute was expensive. ELT loads raw data first and transforms inside the warehouse with SQL, which cheap cloud compute made the modern default. It matters because the choice decides your tooling, your costs, and who gets to shape the data: engineers only, or every analyst who can write SQL.

Do data engineers need to know data modeling?

Yes, and it is one of the most tested areas in interviews. Even in modern ELT stacks, someone has to decide what becomes a fact table, what becomes a dimension, and how keys link them, otherwise the warehouse degrades into a pile of tables nobody trusts. Expect questions like design a schema for an e-commerce store, where the expected answer is a star schema with a clear fact table, conformed dimensions, and surrogate keys.

Can I become a data engineer without experience?

Yes, but not with certificates alone, because data engineering is judged on systems you have built. The credible route is a portfolio pipeline: ingest real data on a schedule, model it into facts and dimensions, transform it with dbt, keep it in version control, and make every step safe to rerun. A project like that exercises all ten concepts in this article and gives you concrete stories for the interview, which is exactly what beats candidates who only watched courses.