Kafka engineer behavioural interview questions

As asked

Describe a significant Kafka outage or incident you were responsible for resolving. Walk me through what failed, how you diagnosed it in real time, what you did to restore service, and what you changed afterward to prevent a recurrence.

Sample answer outline

Strong answers use a clear timeline, quantify the impact (messages lost, lag accumulated, SLA breach), name the specific Kafka metrics or broker logs that pointed to the root cause, describe the recovery steps taken under pressure (e.g., preferred leader election, increasing replica timeout, rolling restart), and articulate a concrete post-incident change (runbook, monitoring, config fix). Vague answers that say 'we fixed it' without specifics are weak.

Expect these follow-ups

• What monitoring gap allowed this incident to go undetected for as long as it did?
• If you had to do it again, what would you do differently in the first 15 minutes?

As asked

Tell me about a time consumer lag built up on a critical Kafka topic and the business was directly impacted. How did you diagnose the root cause quickly, what did you do to catch up, and how did you prevent it from recurring?

Sample answer outline

Strong answers quantify the lag (messages and time), identify the bottleneck (CPU-bound processing, database slow queries, insufficient parallelism), describe the immediate fix (horizontal scaling of consumers, adding partitions, optimizing the hot path), and show they communicated status to stakeholders during the incident. Lasting fix might be capacity planning, adding alerting at lower thresholds, or pre-scaling before known traffic spikes.

Expect these follow-ups

• What trade-off did you make in the moment that you later had to revisit?
• How did you know when lag was fully cleared and it was safe to declare the incident over?

As asked

Describe a situation where a producer team deployed a schema change that broke one or more consumer services. What was the change, how did the breakage surface, and how did you coordinate the fix across teams?

Sample answer outline

Strong answers identify the specific incompatible change (field removal, type change), describe how the consumer failure manifested (deserialization exception, silent data corruption), and show cross-team communication skills. Bonus if they mention that Schema Registry with a compatibility check would have prevented it, and that they instituted that process afterward. Avoid blame-shifting; the focus should be on the systemic fix.

Expect these follow-ups

• How did you prioritize fixing this versus other work in flight?
• What governance change did you put in place to prevent this class of problem?

As asked

Have you ever had to make a case for using Kafka when others in the team or organization preferred a different approach? Describe the situation, the competing options, how you made your case, and how the decision played out.

Sample answer outline

Strong answers show ability to articulate specific Kafka advantages (durability, replay, decoupling, throughput) in terms the audience cared about (reliability, operational cost, time to market), acknowledge the valid objections (complexity, operational overhead), and describe how the outcome affected the team. Weak answers just say 'I convinced them Kafka was better' without showing the reasoning process or respecting the opposing view.

Expect these follow-ups

• Looking back, were there aspects of the resistance that turned out to be valid?
• What operational costs surprised your team after adopting Kafka?

As asked

Describe a situation where you mentored or paired with a junior engineer who was struggling with Kafka concepts. What concept was difficult for them, how did you explain it, and how did you know it clicked?

Sample answer outline

Strong answers show a concrete concept (e.g., the difference between consumer group offsets and partition offsets, or why ordering breaks across partitions), describe an analogy or hands-on experiment used to explain it, and show observation of the junior engineer successfully applying the concept. Avoid generic mentoring platitudes; the best answers reveal deep pedagogical awareness of which Kafka concepts trip up newcomers.

Expect these follow-ups

• What is the single Kafka concept that you find consistently causes confusion for engineers new to it?
• How do you decide when to explain a concept versus pointing someone to the documentation?

As asked

Tell me about a time you had to migrate a Kafka topic in production: changing its configuration (retention, replication factor, partition count, or schema) without taking downtime. What was the migration plan, what could have gone wrong, and what actually happened?

Sample answer outline

Strong answers have a migration plan with stages (dual-write or shadow copy, validation, cutover), specific risk mitigation for each stage (schema compatibility verification, lag monitoring during dual-write), and an honest description of any friction during the cutover. Common risks: partitions added mid-stream break key routing for existing messages; increasing replication factor requires enough brokers; schema changes require consumer updates first (BACKWARD) or producer updates last (FORWARD). Strong answers mention rollback criteria.

Expect these follow-ups

• At what point in the migration did you feel confident enough to remove the old topic?
• What would have caused you to roll back and how quickly could you have done it?

As asked

Describe a situation where traffic or data volume exceeded what your Kafka cluster was designed for. How did you discover the capacity issue, what short-term and long-term actions did you take, and what would you do differently in the planning phase?

Sample answer outline

Strong answers describe the specific metric that revealed the capacity issue (disk fill rate, broker CPU saturation, network throughput ceiling), the triage steps (identifying which topic or partition was the culprit), and the short-term fix (adding brokers, triggering partition reassignment, compressing high-volume topics). The retrospective should include a structured capacity review process: modeling growth curves and building in headroom. Avoid dismissing the miss; show accountability and learning.

Expect these follow-ups

• How did you communicate the issue and resolution to stakeholders?
• What capacity review process did you put in place afterward?

As asked

Tell me about a time you disagreed with a colleague or manager about a Kafka durability or reliability setting (for example, replication factor, acks, or retention). How did you make your case, how was the disagreement resolved, and what was the outcome?

Sample answer outline

Strong answers frame the disagreement around data, not personality. For example: advocating for acks=all with min.insync.replicas=2 against a colleague who wanted acks=1 for throughput. Show that you quantified the throughput cost and the durability risk, proposed a benchmark to resolve the disagreement empirically, and respected the final decision even if it was not yours. Weak answers describe a 'win' without showing how you engaged the other person's perspective.

Expect these follow-ups

• In hindsight, was the decision you made (or accepted) the right one?
• How do you handle ongoing disagreement on architectural decisions in your team?

As asked

Tell me about a situation where business requirements forced you to choose between higher throughput and stronger durability guarantees in a Kafka pipeline. What was the context, how did you make the decision, and how did you document or communicate the risk?

Sample answer outline

Strong answers describe a specific scenario (e.g., clickstream analytics where losing some events is acceptable, vs. payment events where durability is non-negotiable), show that the decision was made with explicit stakeholder sign-off rather than unilaterally, and that the relaxed durability settings were documented and had a review date. Weak answers describe choosing acks=0 without mentioning risk acceptance or treating all data as equally valuable.

Expect these follow-ups

• What was the process for getting stakeholder sign-off on the relaxed durability?
• Did you ever revisit that decision and change the settings later?

As asked

Tell me about a time you were paged for an incident involving consumer groups rebalancing repeatedly (a rebalance storm). How did you diagnose what was causing continuous rebalancing, what did you do to stop it, and what was the root cause?

Sample answer outline

Strong answers describe the symptoms observed (messages not being consumed, constant rebalance in logs, consumer-group-rebalance metric), the diagnostic steps (checking heartbeat timeouts vs max.poll.interval.ms, GC pause times, consumer thread counts), and the fix (increasing max.poll.interval.ms, reducing poll batch size, fixing a slow processing step). Root causes often include a downstream database call that took longer than max.poll.interval.ms, causing the consumer to be kicked out and triggering a rebalance loop.

Expect these follow-ups

• How would you tune the consumer to detect this class of problem before it causes a full outage?
• What is the relationship between max.poll.interval.ms and session.timeout.ms and why do they have different defaults?

As asked

Describe a time a Kafka Connect connector was intermittently failing in production: errors appeared sporadically and the connector would restart but eventually fail again. Walk me through your debugging approach and what you found.

Sample answer outline

Strong answers show a systematic debugging approach: checking Connect worker logs for stack traces, reviewing the offset commit log for the connector, checking the DLQ topic for bad records, monitoring the sink system health (e.g., database connection pool exhaustion). Common causes for intermittent failure include upstream schema changes that the connector is not configured to handle, transient network issues caught by retry limits, and resource exhaustion in the sink. The resolution should include both the immediate fix and a config change to improve resilience.

Expect these follow-ups

• How did you reproduce the intermittent failure in a non-production environment?
• What monitoring would you add to catch this class of connector failure earlier?