Hiring Kafka Engineers in Dubai: the 7 Screens That Separate Operators From Tutorial Graduates

Event streaming has an unusual property as a hiring subject: the vocabulary is small, public and easy to memorise, while the competence is almost entirely about failure modes you only meet in production. A candidate can define topics, partitions, offsets, consumer groups and delivery guarantees perfectly and still have no idea what your dispatch pipeline does at three in the morning when a broker goes away. This guide is the screen we use to tell those two people apart, in the order we run it.

Step 1: Write Down Your Workload Before You Write the Advert

Almost every weak streaming requisition I see lists technologies. Almost every strong one states numbers. Before sourcing anybody, write down five things:

• Throughput: events per second at normal load and at your worst hour.
• Message size: typical and maximum payload, because a 2 KB event and a 2 MB event are different engineering problems.
• Ordering requirement: what must be processed in order, and at what scope. Per customer? Per account? Globally?
• Retention: how far back you need to replay, and whether that is a recovery requirement or an audit requirement.
• Latency tolerance: the end-to-end delay at which somebody downstream notices and complains.

Those five numbers do two jobs. They tell you whether you need a dedicated streaming engineer at all, and they give you a concrete basis for every interview that follows, because you can ask candidates to reason about your situation rather than about a generic one. A requisition that cannot state them is not ready to go to market, and in my experience that single omission is responsible for more wasted interview cycles on this profile than any other cause.

Step 2: Screen for Delivery Semantics, Not Vocabulary

The question that does the work here is not “what are the three delivery guarantees?”. Everybody answers that. The question is: on your last pipeline, what did at-least-once delivery actually mean for the business, and what made your consumers safe to run twice?

A real answer names a business object and a key. Something like: payments could arrive twice, so we deduplicated on the provider transaction reference before writing, and the write was conditional. Or: we could not deduplicate reliably, so we made the downstream operation idempotent by keying the update on the event identifier. Both are good answers because both describe a decision with a cost.

The answer that should slow you down is a fluent description of the three guarantees with no reference to any system they have worked on. That is a documentation answer, and it is the single most common way an unqualified streaming candidate passes a first-round screen.

Step 3: Test Rebalance Behaviour

This is the highest-yield question in the whole sequence, and it is one sentence: what do your users experience while a consumer group rebalances?

Somebody who has operated a consumer group under load will tell you about processing pausing while partitions are reassigned, about duplicate work when a consumer dies after processing but before committing, about a poll timeout they had to tune because a slow handler kept triggering rebalances, about the difference it made when they moved to incremental cooperative rebalancing. They will probably tell you about the time a deployment caused a rebalance storm because the consumers all restarted at once.

Somebody who has only read about it will tell you rebalancing is handled automatically by the client library. That statement is technically true and operationally useless, and it is the clearest single signal in the interview. I have never met an engineer who had run this in production and answered that the experience was “nothing”.

Step 4: Probe Schema Evolution and the Day It Broke

Ask: you needed to add a required field to an event that four services already consume. Walk me through it.

This separates people who have maintained a streaming system from people who have built one and left. The good answer involves compatibility: you cannot add a required field under a backward compatibility rule without a default, so either it goes in with a default, or it goes in as an optional field that becomes required once every consumer has been updated, or you publish a new version of the event and run both for a migration window. Expect a mention of a schema registry and of the compatibility mode they ran.

The answer that should concern you is a plan that requires all consumers to deploy simultaneously. That is a coordinated outage dressed as a migration, and it tells you this candidate has worked only where they controlled every consumer, which is almost never the case in a business of any size.

Step 5: Ask for Operational Evidence, Not Architecture Diagrams

Streaming failures are usually silent. A dropped message does not raise an exception in a user’s face, a slow consumer does not return a 500, and a pipeline can be quietly losing data for a week while every service reports healthy. That property makes monitoring the single most reliable proxy for real production experience, because a team only builds this instrumentation after being hurt by its absence.

So ask for specifics: what did you alert on, at what threshold, and what did you do when it fired? Strong candidates talk about consumer lag per partition rather than in aggregate, because aggregate lag hides a single stuck partition. They talk about the difference between lag that is growing and lag that is high but stable. They mention dead letter topics and, more tellingly, what they did with the messages that landed there, since a dead letter queue nobody reads is just a slower way of dropping data.

If a candidate has no monitoring story at all, treat that as the most serious gap in this list. An engineer who cannot see a pipeline cannot run one, and on this profile the absence of observability instinct is a better predictor of future incidents than any gap in their configuration knowledge. For the adjacent skills this touches, our pages on data engineers and platform engineers set out where the responsibility boundaries usually sit.

Step 6: Run One Paid Scenario Exercise With a Deliberate Trap

Three to four hours, paid at a fair rate, on a scenario that resembles your actual workload. Give them the five numbers from step 1 and ask for a design with the trade-offs written down.

Put one contradiction in the brief. The version I like: require strict per-customer ordering, then describe a partitioning scheme or a volume distribution that cannot deliver it, such as partitioning by product category while one enterprise customer generates a third of all events. The brief is now internally inconsistent, and what the candidate does about that is the entire point of the exercise.

Three behaviours emerge. The strongest candidates name the contradiction, explain why the two requirements cannot both hold, and propose the trade-off they would take to you. The acceptable middle group misses it initially but finds it immediately when you ask what happens to ordering for your largest customer. The group to decline silently designs around it and presents a confident architecture that does not do what the brief required, which is precisely the failure mode that produces a reconciliation problem in your business six months after they join.

Pay for this exercise. In a narrow market, unpaid multi-hour assignments are declined by exactly the employed senior engineers you are trying to reach, and the goodwill from paying is disproportionate to the cost.

Step 7: Close With a Scoped Offer and a 30 Day Deliverable

The failure mode at offer stage for this profile is not money. It is vagueness. “Own our event streaming platform” sounds like a mandate and reads, to an experienced engineer, like an invitation to be responsible for something they do not control.

Write three things into the offer conversation. The specific pipeline or domain they own first. The on-call expectation, stated honestly, including what the rotation actually looks like today rather than what you intend it to become. And one measurable deliverable inside thirty days, chosen so it is achievable without a quarter of platform work first: an alerting baseline on consumer lag, a documented replay procedure that has been tested once, a dead letter topic with a defined triage owner.

That last item does more for retention than a salary adjustment. Engineers in this specialism leave vague mandates, and they leave quickly, because the role gives them accountability for outcomes with no authority over the system producing them. If you want the full sequence around compensation and approvals, our write-up on project management in Dubai covers how to keep an approval path short enough to close a scarce candidate.

FAQ: Hiring Event Streaming Engineers in Dubai