Iceberg & Lakehouse Interview Questions cheat sheet
Snapshots, catalogs, compaction, hidden partitioning, and the Iceberg versus Delta questions lakehouse interviews now ask.
Why a table format
What problem does Iceberg solve that a directory of Parquet files does not?- Atomic commits, snapshot isolation, and schema evolution by column identity. Readers never see a half-written table, time travel is a metadata operation, and a rename does not rewrite files. 'It is just better Parquet' is the weak answer; the catalog pointer swap is the actual mechanism.
Walk through what happens on a single Iceberg commit.- The writer creates new data files, writes a manifest listing them, writes a manifest list, writes a new metadata.json, then atomically updates the catalog to point at that metadata file. Readers opened against the previous snapshot keep seeing it. If the catalog swap fails, the new files are garbage, not a corrupt table.
What is hidden partitioning?- Consumers filter on a timestamp column; Iceberg derives the partition (day, hour, bucket) internally. You do not add a partition column to the table schema, so you cannot forget it in a query and scan everything. Partition evolution can change the spec for new data without rewriting old files.
How does Iceberg prune files without opening them?- Manifests store per-file column min/max and partition values. A WHERE ts >= ... drops whole manifests, then whole files, before any Parquet footer is read. This is why a well-maintained Iceberg table beats a Hive-partitioned directory even with the same files.
What is a snapshot versus a snapshot log versus a manifest?- A snapshot is a consistent table state. The log is the list of snapshots. A manifest is a list of data files belonging to a snapshot, with stats. Interviewers use the vocabulary to see if you have operated a table or only read a blog post.
Catalogs
Why does Iceberg need a catalog at all?- The catalog holds the pointer to the current metadata.json. Without an atomic compare-and-swap there, two writers corrupt the table. The files can live in S3; the authority cannot. This is the most important sentence in an Iceberg interview.
REST catalog versus Glue versus Hive metastore versus Nessie?- REST (Polaris, Lakekeeper, Unity's Iceberg endpoint) is the interoperability bet for 2026. Glue is the AWS default and fine for reads, weaker for multi-engine writes. Hive metastore is legacy. Nessie adds Git-like branches over tables. Name the writer-isolation story, not just the product list.
What goes wrong if two engines write the same table through different catalogs?- Each catalog has its own idea of the current snapshot. You get lost updates or unreadable metadata. One catalog, one writer at a time, is the cardinal rule. Multi-engine read is the feature; multi-engine uncoordinated write is an incident.
What is credential vending and why do catalogs do it?- The catalog hands the engine short-lived storage credentials scoped to the files it needs, so you do not grant the compute role the entire bucket. It is the practical way to do least privilege on a lake. Without it, every engine role can read every prefix.
Maintenance
Why do Iceberg tables get slow if you never run maintenance?- Streaming and frequent MERGE produce thousands of tiny files and a long snapshot history. Planning time grows with manifest count. rewrite_data_files (compaction) and expire_snapshots are operational, not optional. 'Iceberg is zero-ops' is a lie that shows up in interviews as a trap.
What does expire_snapshots actually delete?- Metadata and data files that belong only to expired snapshots, after the retention window. Time travel older than that window is gone. Teams that set retention to forever eventually have planning and storage problems they blame on Iceberg.
When do you rewrite manifests versus rewrite data files?- rewrite_manifests is cheap and helps when many small manifests exist. rewrite_data_files is the real compaction and costs compute. Start with manifests if planning is slow and files are already a reasonable size; compact data when file count per partition is in the thousands.
How do you think about file size in an Iceberg table?- Target 128 to 512 MB. Below 32 MB you are paying list and open overhead; above a couple of GB you lose parallelism and make compaction painful. Streaming writers will undershoot this every time, which is why compaction is part of the pipeline, not a quarterly chore.
What is position delete versus equality delete?- Position deletes mark a row by file path and row number and are cheap to apply at read. Equality deletes mark by column values and are more expensive because every file must be checked. Merge-on-read uses these; copy-on-write rewrites the file instead. Know which your table is using.
Schema and evolution
How does Iceberg survive a column rename without rewriting data?- Columns have integer field IDs independent of name and position. Readers map IDs, not names. Hive-style Parquet that is name-or-position based cannot do this safely. That is the concrete difference, not a slogan about 'schema evolution'.
Which schema changes are safe, and which need a rewrite?- Add a nullable column, rename, reorder: safe. Drop is metadata-only but readers of old snapshots still see it. Widen types is often safe. Narrowing a type, changing the meaning of a field, or making a column required on existing nulls is a rewrite or a two-step migration.
How do you add a partition field to a table that already has data?- ALTER TABLE ... ADD PARTITION FIELD. Old files keep the old spec; new files use the new one. Queries still prune both. You do not have to rewrite history, which is the point of partition evolution and the answer interviewers want.
Iceberg versus Delta on schema enforcement?- Both can enforce a schema on write. Delta's schema evolution is mature inside Databricks; Iceberg's is more portable across engines. The real question is which engines your readers run. Pick the format your least-flexible consumer already speaks well.
Iceberg versus Delta versus Hudi
When do you choose Iceberg over Delta?- When more than one engine must write or when you refuse a Databricks-centered catalog. Snowflake, Trino, Flink, and Spark all have first-class Iceberg support. Delta inside Databricks is still the smoother day-to-day experience. UniForm and Iceberg REST from Unity blur this, so say so.
When is Hudi the better fit?- High-frequency record-level upserts and a CDC-shaped workload, especially if you already run Hudi. Copy-on-Write versus Merge-on-Read is a first-class choice. The ecosystem is smaller, so you are buying upsert performance and paying in hiring and tooling.
Do you need a table format under a few hundred gigabytes with one engine?- Often no. A warehouse table or a well-partitioned Parquet dataset is simpler. Table formats earn their complexity at multiple writers, time travel requirements, or multi-engine reads. Adopting Iceberg for a 40 GB analytics extract is ceremony.
How do you migrate Hive tables to Iceberg without a long outage?- Migrate in place with snapshot metadata over existing Parquet where the layout allows, or shadow-write to a new Iceberg table and swap the catalog pointer. Dual-read during validation. The risky path is a one-shot rewrite of a 200 TB table with no rollback.
Operations
A reader started seeing 'metadata file not found'. What do you check?- The catalog points at a metadata.json that lifecycle policies or a vacuum deleted. Retention on metadata must exceed the longest-running job. This is the same class of bug as Delta VACUUM under a streaming checkpoint.
How do you debug a query that scans far more files than it should?- Query the metadata tables: files, manifests, partitions. Check whether the filter matches a partition field or only a data column without stats. Stale manifests after a failed compaction are another cause. EXPLAIN plus metadata tables beats guessing.
What SLOs do you put on a lakehouse table?- Freshness of the latest snapshot, file-count per partition, and planning time. Not just 'job succeeded'. A pipeline that writes 80,000 tiny files a day is green in Airflow and red in production.
How does time travel interact with GDPR deletes?- A delete is a new snapshot; old snapshots still contain the row until you expire them and rewrite files that held it. Compliance retention and time-travel retention are in tension. You need a process that expires snapshots and rewrites, not just a DELETE statement.
From DataLane — tutorials at/blog, practice SQL live in theplayground.