Where Data Lives: Beginner

When you hear these in an interview, this is the concept being tested

• ▸"Why Parquet over CSV?"
• ▸"Row-oriented vs columnar: explain the difference."
• ▸"How does a columnar format speed up queries?"

After your initial answer, expect these probes

• ▸"When would you NOT use Parquet?" Transactional workloads (inserting single rows). Human inspection (CSV is readable). Very small files (Parquet overhead outweighs benefits under ~10 MB).
• ▸"How does compression work better in columnar?" A column of country codes (US, US, US, CA, US) is just 2 unique values repeated. Compression algorithms love that. A row mixing strings, numbers, and dates compresses poorly.
• ▸"What is predicate pushdown?" The engine reads column statistics (min/max per chunk) and skips chunks that cannot match the query filter. 'WHERE revenue > 1000' skips any chunk where max(revenue) < 1000.

When you hear these in an interview, this is the concept being tested

• ▸"What compression do you use and why?"
• ▸"Snappy vs Gzip: when do you use each?"
• ▸"How does compression affect query performance?"

After your initial answer, expect these probes

• ▸"Why not always use the highest compression?" CPU cost. Gzip takes 5-10x more CPU to decompress than Snappy. On interactive queries, decompression time dominates. You trade smaller files for slower queries.
• ▸"Does compression affect write performance?" Yes. Higher compression = slower writes. For streaming ingestion, use Snappy or LZ4 to keep write latency low.

When you hear these in an interview, this is the concept being tested

• ▸"How do you partition this table?"
• ▸"What is partition pruning?"
• ▸"What happens if you over-partition?"

After your initial answer, expect these probes

• ▸"What is the small file problem?" Over-partitioning creates thousands of tiny files. Opening 10,000 files of 1 MB each is far slower than 10 files of 1 GB, even though total data is the same. Per-file overhead dominates.
• ▸"How big should each partition be?" Target 128 MB to 1 GB per partition. If partitions are smaller, coarsen the partition key (hourly to daily) or add compaction.
• ▸"Can you partition on two columns?" Yes, but be careful. date + region creates (365 x number_of_regions) partitions. If that is too many, partition by date only and use Z-ordering or sorting on region.

When you hear these in an interview, this is the concept being tested

• ▸"Data lake vs warehouse: what is the difference?"
• ▸"When would you use a lake instead of a warehouse?"
• ▸"What is a lakehouse?"

After your initial answer, expect these probes

• ▸"What is the lakehouse and why is it popular?" Lake cost + warehouse features. Add Delta Lake or Iceberg on top of S3 files and you get ACID transactions, schema enforcement, and time travel without paying for a separate warehouse.
• ▸"Would you use JUST a lake or JUST a warehouse?" Almost never. Raw data lands in the lake (cheap, flexible). Query-ready data is served from the warehouse or lakehouse (fast, governed). Both have a role.
• ▸"What is a data swamp?" A lake with no governance: no schema documentation, no ownership, no quality checks. Data goes in but nobody knows what is there or whether it is correct.

When you hear these in an interview, this is the concept being tested

• ▸"What is Delta Lake?"
• ▸"Delta vs Iceberg vs Hudi: what is the difference?"
• ▸"How do you get ACID on object storage?"

After your initial answer, expect these probes

• ▸"Which would you choose?"'Depends on the engine. If we are on Databricks, Delta. If we want flexibility across Spark, Trino, and Presto, Iceberg. I would not choose based on features alone; ecosystem fit matters more.'
• ▸"What is time travel?" Query the table as it existed at a specific timestamp or version number. Useful for debugging, auditing, and reproducing ML training data.
• ▸"Can you migrate between formats?" Yes. In-place migration adds new metadata on top of existing files (fast, limited). Full rewrite reads and rewrites all data (slow, complete).