Lakehouse Table Formats Interview Questions for Data Engineers

01

The 2 kinds of Lakehouse Table Formats question

Two kinds: explain how it works, then use it on a stated problem. Each card gives the answer to say out loud, the answer most people give, and where the interviewer goes next.

• 25ConceptualWhat a table format adds to a folder of Parquet files. How an Iceberg snapshot finds its files without listing a directory, what the Hudi timeline records, what copy-on-write and merge-on-read each cost, and how two writers avoid overwriting each other.Iceberg metadata: snapshots & manifests · Hudi timeline & file groups · Copy-on-write vs merge-on-read · ACID & concurrent writers→
• 25Scenarios & DesignPick the format for a stated workload: CDC upserts every five minutes, BI scans over five years, GDPR deletes by customer. Then fix what goes wrong once it runs: small files, slow reads after a million updates, a storage bill that grows from expired snapshots.Iceberg vs Hudi vs Delta · Upserts, CDC & deletes · Compaction & small files · Snapshot expiry & orphan files→

02

The ones that keep coming up

Answered here, in short. The full reasoning, the wrong answer and the follow-up are one click away.

1. 01What is Apache Iceberg, and what problem does it solve?Iceberg is an open table format: a specification for tracking which data files make up a table, with snapshots, schemas and partition specs in metadata files on object storage, so many engines can read and write the same table with atomic commits. It solves the correctness and planning problems of Hive tables on S3 — partial reads, lost writes, directory listing, and schemas and partitions that cannot change safely.→
2. 02What is Apache Hudi, and why is it used?Hudi is an open table format and set of table services, built at Uber, for applying upserts and deletes to data lake tables efficiently and letting downstream jobs read only what changed. It adds a timeline of commits, record keys with indexes, copy-on-write and merge-on-read table types, and built-in compaction, clustering and cleaning.→
3. 03What is the difference between copy-on-write and merge-on-read?Copy-on-write applies an update by rewriting the affected data files, so writes are expensive and reads are plain. Merge-on-read records the change separately — delete files or deletion vectors in Iceberg, log files in Hudi — so writes are cheap and readers merge the changes until compaction rewrites them in.→
4. 04What is time travel in a table format, and why is it useful?Time travel is querying a table as it was at an earlier version or timestamp, which works because the format keeps older snapshots and their files. It is used to debug a bad load, reproduce a past report, audit a change, or roll back — and it only reaches as far back as snapshot expiry, vacuum or cleaning allow.→
5. 05What is a data lakehouse, and what makes it different from a data lake?A lakehouse keeps data as open files on cheap object storage like a data lake, but adds a table format — Iceberg, Delta Lake or Hudi — that gives warehouse-style transactions, schema enforcement, updates and time travel. Several engines then query the same tables instead of copying data into a warehouse.→
6. 06What is the difference between Apache Iceberg, Delta Lake and Apache Hudi?All three add transactions, schema evolution and time travel to Parquet on object storage by tracking which files make up each table version. Iceberg is a snapshot-and-manifest specification with the widest engine and catalog support; Delta is a transaction log centred on Spark and Databricks; Hudi is built around keyed upserts, indexes, incremental reads and built-in table services.→
7. 07What is data compaction, and why does a data lake need it?Compaction rewrites many small or fragmented files into fewer larger ones so queries open fewer files and plan less metadata. In table formats it also means applying accumulated deletes or logs to data files, as Iceberg's `rewrite_data_files` and Hudi's merge-on-read compaction do.→
8. 08What is schema evolution, and which changes are safe?Schema evolution is changing a table's schema — adding, dropping, renaming, widening or reordering columns — without breaking existing data or readers. Additive changes and type widening are safe; renames and drops are safe only where the format tracks columns by id; narrowing a type or changing its meaning needs a new column and a backfill.→
9. 09What is an upsert, and how is it done on a data lake table?An upsert updates a row if its key exists and inserts it if not. On a lake it needs a table format, because files are immutable: `MERGE INTO` in Iceberg or Delta, or Hudi's `UPSERT` operation, finds the affected files and either rewrites them or records the change for merging at read time.→
10. 10What does VACUUM do in Delta Lake, and what is the equivalent in Iceberg and Hudi?`VACUUM` deletes data files that no table version within the retention window references (7 days by default), which ends time travel before that point. Iceberg splits the job into `expire_snapshots` for unreferenced files and `remove_orphan_files` for files no commit ever referenced; Hudi's cleaner removes old file slices after a configured number of commits.→

03

What Lakehouse Table Formats interviews actually cover

• 01Why table formats exist
• 02Iceberg metadata: snapshots & manifests
• 03Hudi timeline & file groups
• 04Copy-on-write vs merge-on-read
• 05ACID & concurrent writers
• 06Upserts, CDC & deletes
• 07Hidden partitioning & partition evolution
• 08Schema evolution
• 09Time travel & rollback
• 10Compaction & small files
• 11Snapshot expiry & orphan files
• 12Catalogs (REST, Glue, Hive, Nessie)
• 13Hudi indexing & record keys
• 14Incremental reads & change feeds
• 15Iceberg vs Hudi vs Delta

04

Learn it, then practise it