Why would you store analytics data as Parquet rather than CSV or JSON?

What the interviewer wants to hear

• Parquet is columnar, so queries read only the needed columns
• Compression and encoding work better on columns of similar values
• Schema and types are stored in the file
• Row group statistics allow predicate pushdown and skipping
• CSV and JSON are still useful for exchange and raw landing

Model answer

Parquet is a columnar format, so a query that needs three columns out of fifty reads only those three, which cuts I/O dramatically. Because each column holds similar values, encodings like dictionary and run-length plus compression such as Snappy or Zstd shrink the files a lot, often five to ten times smaller than CSV. Parquet also stores the schema and types, so there is no guessing whether a field is a number or text, and nested data is supported. Each row group keeps min and max statistics, so engines can skip blocks that cannot match a filter. CSV and JSON are row-based text: no reliable types, quoting problems and full scans. I still accept them at the landing layer because many systems export them, but I convert to Parquet, usually inside a table format like Delta or Iceberg, for anything people query.

More easy Data Engineer questions

• Describe a data pipeline you built or would build, from source to dashboard.
• What is the difference between an OLTP database and an OLAP data warehouse?
• Explain a star schema and why it is used in data warehouses.
• What data quality checks would you add to a pipeline?
• Why use an orchestration tool like Airflow instead of cron jobs?
• What is a slowly changing dimension, and how do SCD Types 1, 2 and 3 differ?
• What is change data capture (CDC), and why do data teams use it?
• Explain Kafka topics, partitions, offsets and consumer groups to a new teammate.
• What does dbt do in a modern data stack, and what are its main features?