Skip to content
Tech Interview Prep home
Technical interview guide

Schema Evolution & Versioning

Changing a shared schema without breaking every downstream consumer that depends on it.

Read
34 min
Practice MCQs
25
Interview QA
25
Edition
v4
Editorial status
Reviewed
Relevant for
Data Architect

Scope: Apache Avro and Iceberg current specifications, Protobuf edition 2024 guidance, Confluent Schema Registry current compatibility modes, Delta Lake protocol, PostgreSQL 18, JSON Schema 2020-12, OpenAPI 3.1.1, and Parquet logical types current 2026-08-31.

Interview QA

Treat each question like a live interview question: answer out loud first (structure, assumptions, tradeoffs), then open the model answer to spot gaps and rehearse a tighter follow-up.

Curated: · Written: · Reviewed:

QA-1

Plan an additive field change on an event schema.

QA-2

Choose a Schema Registry compatibility mode.

QA-3

Remove a Protobuf field safely.

QA-4

Rename an Avro field safely.

QA-5

Migrate a database column to a new type.

QA-6

Evolve an Iceberg table schema.

QA-7

Enable a Delta table feature safely.

QA-8

Change a field from milliseconds to seconds.

QA-9

Tighten an optional field to required.

QA-10

Add an enum value used by many consumers.

QA-11

Design CI checks for schema evolution.

QA-12

Find consumers before a breaking schema change.

QA-13

Handle old stored records after several schema versions.

QA-14

Evolve a JSON Schema API contract.

QA-15

How do you evolve schemas in streaming and batch pipelines without breaking downstream consumers?

QA-16

Recover from an incompatible schema published to production.

QA-17

Migrate a schema-registry subject naming strategy.

QA-18

Design dual-write during a schema migration.

QA-19

Change a decimal field's precision or scale.

QA-20

Evolve partitioning without changing logical schema.

QA-21

How do you handle default values and schema evolution in columnar storage formats like Parquet and Delta Lake versus row-based formats like Avro?

QA-22

Measure schema-evolution health.

QA-23

Review a schema change proposal.

QA-24

Test schema evolution before production.

QA-25

Decide when to create a new schema version or new resource.