Kafka interview questions that separate operators from tutorial readers

Most lists of Kafka interview questions test vocabulary: what is a broker, what is a topic, what is an offset. A candidate who has read a tutorial passes them, and so does one who has run Kafka through a bad night. These eight questions come from the incidents AceMQ handles in production, and each one has a right answer that only experience produces.

1. A consumer group keeps rebalancing after a deploy. Why?

Listen for max.poll.interval.ms. If poll() is not called within it, the consumer is considered failed and the group rebalances to reassign its partitions [1]. A deploy that makes processing slower is the classic trigger. Strong candidates also ask whether static membership is in use, because consumers with a group.instance.id are not reassigned immediately when they hit the timeout [1].

2. Someone proposes adding partitions to catch up on lag. What do you say?

The senior answer asks about keys. If data is partitioned by hash of the key, adding partitions shuffles which partition a key maps to, and Kafka does not redistribute existing data [2]. For keyed events that need per-key ordering, that is a correctness change, not a scaling knob. Bonus point: partitions can be added but Kafka does not support reducing them [2], so the decision is one-way.

3. What does acks=all actually guarantee?

A weak answer says 'every replica has the message'. A strong one explains that with acks=all every in-sync replica must acknowledge, and that min.insync.replicas sets how small the in-sync set may shrink before the producer gets a NotEnoughReplicas exception instead of a success [3]. Ask what they set it to on a three-replica topic and why.

4. How do you avoid duplicates from producer retries?

Look for idempotence: with enable.idempotence the producer ensures exactly one copy of each message is written to the stream, and it is enabled by default when no conflicting settings are present [4]. Strong candidates know it requires acks=all and a bounded number of in-flight requests [4], and that it protects the write, not downstream consumers.

5. Plan a move from ZooKeeper to KRaft.

Kafka 4.0 removed ZooKeeper entirely [5], so any cluster still on it has a migration in front of it before it can upgrade. A strong answer sequences the migration, names the rollback point, and treats client and tooling compatibility as part of the plan.

6. When would you use a share group instead of a consumer group?

Share groups, from KIP-932, let several consumers process records from the same partitions with per-record acknowledgement, and were declared production-ready in Kafka 4.2 [6]. The strong answer names the trade: work-queue scaling beyond the partition count, at the cost of ordering.

7. Lag is climbing on three partitions out of thirty. Where do you look?

Uneven lag points at hot keys or a slow consumer instance, not at cluster capacity. Candidates who reach for more brokers first have usually not debugged this in production.

8. Tell me about the worst Kafka incident you were on.

The most useful question of all. Listen for specifics — the version, the metric that first looked wrong, what they would do differently. Vague answers about 'scaling issues' are a warning sign.