31 Candidates, 4 Real Platform Engineers — the 7-Step Filter I Wish I Had Before Our First Dubai Kubernetes Hire

Our first Kubernetes hire in Dubai was, on paper, excellent. Certified, articulate, six years of cloud experience, sharp in the interview. Nine months later we had a cluster nobody but him could upgrade, a bespoke deployment abstraction with no documentation, and an engineering team that filed tickets to deploy. He was a good engineer. He was the wrong hire, and the mistake was entirely ours.

We ran the search again a year later, screened 31 candidates, and made two hires from four genuinely strong finalists. What follows is the method that produced that ratio, in order, including the exercise that did most of the work.

Step 1 — Decide whether you need a platform engineer or a DevOps engineer

This is not a semantic argument. It is the decision that determines whether your hire succeeds, and most job descriptions in this market blur the two deliberately because blurring them widens the applicant pool.

A DevOps engineer is measured on keeping things running and unblocking specific teams. Success looks like fast incident response, working pipelines, and being the person who knows how everything fits together. It is fundamentally a service role, and a good one is enormously valuable.

A platform engineer is measured on something almost opposite: how quickly and safely every other engineer can ship without asking them anything. Success looks like their own inbox getting quieter over time. The users of their product are your developers, and the product is a set of paved paths.

The reason our first hire failed is that we wrote a platform job description, interviewed for DevOps signals, and then measured against platform outcomes. He optimised, entirely rationally, for being indispensable. That is exactly what a service role rewards and exactly what a platform role must not.

A rough heuristic that has held up well: below roughly 25 engineers, you want DevOps. Above roughly 50, you want platform. Between the two, you want DevOps with an explicit mandate to start paving paths — and you should say so in the job description.

Step 2 — Write the role around the developer experience you want, not the tools you run

Most Dubai platform job descriptions I read are tool inventories: Kubernetes, Terraform, Helm, ArgoCD, Prometheus, service mesh, and so on. This attracts people who collect tools, which is not the same population as people who reduce friction.

Rewrite the description around outcomes a developer would recognise. “A new service goes from empty repository to production with monitoring and alerting in under two hours, without a ticket.” “Any engineer can roll back their own deployment in one command at 2am.” “Cluster upgrades happen quarterly and nobody notices.”

This shift has a useful side effect at the top of the funnel: it repels candidates who want to build interesting infrastructure for its own sake and attracts those who think in terms of their users. In our second search, changing the description alone reduced applications by about a third and raised the strong-candidate rate substantially.

Step 3 — Source where operators actually are

Strong platform engineers are rarely on job boards, because they are rarely looking. The pool in Dubai is real but small, and it concentrates in a few places.

What has worked for us, in order of yield: engineers currently at regional companies running genuine scale — logistics, fintech, e-commerce — who have hit the ceiling of a small infrastructure team; contributors to the tooling ecosystem, findable through issue threads and conference talks rather than profiles; and relocating candidates from markets where the platform discipline matured earlier, for whom the tax position and the scale of regional projects are a genuine draw.

What has not worked: generic job boards, and recruiters who search on the keyword rather than the outcome. Both produce volume dominated by people who have used Kubernetes rather than run it.

Step 4 — Screen with a failure diagnosis, never with certifications

This is the step that did most of the work, and it takes forty-five minutes.

Prepare a small cluster with a realistic, layered failure. Ours: a deployment stuck partway through a rollout, where the surface symptom is failing readiness probes, the intermediate cause is a misconfigured resource limit triggering the out-of-memory killer under load, and the root cause is a config map change made three deploys earlier that nobody linked to the symptom. Give the candidate read access and screen sharing, and ask them to talk you through what they are doing.

You are not scoring whether they find it. You are scoring the order in which they look at things. Strong candidates converge quickly on a narrowing sequence: describe the resource, check events, check recent changes, check limits against actual usage. Weaker candidates start applying remedies — restart it, scale it, bump the limit — and only investigate when the remedies fail.

Of our 31 candidates, 19 reached for a remedy before they reached for evidence. None of those 19 would have been good hires, and several had impeccable certifications. That is the entire case against using certification as a filter: it measures knowledge of the object model, and the job is dominated by judgement under uncertainty.

Step 5 — Test cost and data residency judgement explicitly

Two constraints dominate platform work in the UAE and neither is usually interviewed for.

The first is cost. Ask the candidate to sketch a production setup for a described workload and then estimate what it costs per month. Do not grade the number — grade whether they can produce one at all, and whether they reason about the drivers: node sizing, data transfer, managed service premiums, idle capacity. An engineer who has never had to defend an infrastructure bill will design something correct and unaffordable, and you will discover it in month four.

The second is data residency. Regional clients frequently require that data stays in-country, which constrains which managed services are available and often forces self-run components that a candidate from another market would never consider. Ask directly: what changes in your design if this data cannot leave the UAE? The answer separates people who have actually delivered in this region from people who have delivered elsewhere and assume the menu is the same.

This is also where a platform hire intersects with security and compliance obligations. Teams that treat those as an afterthought end up re-architecting; our colleagues covering the European market at WebGuard Agency document the same pattern in regulated sectors, where residency and evidence retention are decided far too late.

Step 6 — Plan the visa and the on-call structure into the offer

Two practical points that lose candidates when they are handled late.

Visa timing. For a UAE resident, 45 to 60 days from open role to first day. With relocation and a new employment visa, 75 to 100. Begin document collection in parallel with final interviews. Employers who start after the offer routinely lose people to competitors who did not.

On-call. Senior platform candidates will ask, and vague answers read as red flags because they usually are. Have a concrete answer: how many people in the rotation, what the escalation path is, what compensation or time off attaches to it, and what the actual page volume has been over the last quarter. If your honest answer is “there are two of us and it is rough”, say that and explain what the hire changes. Candidates forgive difficulty; they do not forgive discovering it in month two.

Step 7 — Close on autonomy and platform ownership

Compensation gets you into the conversation; it rarely finishes it at this level. As of 2026, mid-level platform engineers in Dubai typically land at AED 25,000–33,000 per month, and seniors who have run multi-tenant production clusters at AED 38,000–55,000. Present the take-home arithmetic explicitly rather than comparing headline figures against European offers, because the tax position is a material part of the package and candidates frequently under-weight it.

What actually closes strong platform candidates is a credible answer to one fear: that they will be hired to build a platform and then spent on tickets. Every experienced platform engineer has lived this, and they are listening for it.

The commitments that work are specific and falsifiable. A named percentage of time protected for platform work. A defined intake process for requests, so interruptions are queued rather than ambient. And an explicit statement of who decides the platform roadmap — if the answer is not substantially them, say so honestly, because they will find out in week three either way.

One question worth adding to every loop

Late in our second search we added a single question that has since become the one I would keep if I could only keep one: tell me about an abstraction you built that your users did not adopt. What did you do next?

Every experienced platform engineer has one. The answer separates three types of person cleanly. Some have never built anything anyone declined to use, which usually means they have not yet built a platform. Some blame the users — the teams were not disciplined, they did not read the documentation. And some describe going to find out why, discovering the abstraction solved a problem their users did not actually have, and deleting it.

Only the third answer describes someone who will treat your engineers as customers rather than as an obstacle. In a role whose entire output is leverage on other people’s work, that disposition is not a nice-to-have.

A note on the wider market

Platform engineering demand across the Gulf has outpaced supply for two years, and government-led technology programmes are accelerating that. Similar dynamics are visible across Asia-Pacific — teams recruiting in Singapore face state-backed training pipelines reshaping supply, while employers in Tokyo compete against large national infrastructure investment. The practical implication for Dubai employers is that a slow, careful platform search is still the right call, but a slow, careless one now costs you the candidate.

If you are earlier in the journey, our guides on hiring remote developers in Dubai and building technical products in Dubai cover the structuring and sourcing groundwork this article assumes.

Frequently asked questions