9 Months, 26 Firmware Interviews, 1 Painful Lesson — the 7 Steps That Finally Built Our Dubai IoT Team

The brief was a connected water-metering product for a UAE utility client: battery powered, expected to run five years on a single cell, low-power wireless, and a certification deadline. We needed two firmware engineers. It took nine months and 26 interviews to hire one, and that person left within the year because the role we described was not the role that existed.

The second search, for the same profile, took seven weeks and produced two hires who are both still with the team. The market had not loosened. Dubai still has a thin pool of deep embedded talent, as most cities do. What changed was that we stopped running a software interview for a hardware job. Here is the method, in the order we now run it.

Step 1 — Scope the silicon before writing the spec

Embedded hiring is not like web hiring, where a strong generalist adapts to your framework in a fortnight. The relevant experience is tied to a specific combination of microcontroller family, real-time operating system and connectivity stack. An engineer who has spent six years on automotive controllers with a CAN bus is a poor match for a battery-powered sensor on a low-power radio, however senior they are.

So decide these four things before you write a single line of the job advert:

• The microcontroller family you have committed to, or are choosing between.
• The operating model — bare metal, an RTOS, or an embedded Linux target. These are three different talent pools.
• The connectivity stack: cellular IoT, a low-power mesh, Bluetooth Low Energy, or wired industrial.
• The certification target, if any. Radio and safety certification experience is a specialism in its own right and it is scarce.

Our first advert said “experience with embedded C and IoT protocols”. That describes several thousand engineers with almost nothing in common, which is why we interviewed 26 people to find three who fit.

Step 2 — Write a specification that filters

A good embedded job specification reads like an engineering brief, not a shopping list. Name the constraints, because constraints attract the people who enjoy them and repel the people who do not.

Compare these two lines:

The right-hand column halved our unqualified applications and, more usefully, changed the tone of the conversations. Candidates arrived already discussing the problem.

Step 3 — Screen for debugging ability, not syntax

This is the step that cost us six months. We were opening with a C exercise involving pointer manipulation and bit fields. It felt rigorous. It measured almost nothing that mattered, because writing embedded code is perhaps a fifth of the job. The rest is working out why something misbehaves when you cannot attach a debugger, the fault appears once every few hours, and adding instrumentation makes it disappear.

Replace the puzzle with one open question, asked early: “tell me about the hardest bug you personally found and fixed — how did you narrow it down?”

Listen for the shape of the answer rather than the specific fault:

• Do they describe forming a hypothesis and testing it, or do they describe changing things until it went away?
• Do they mention the instruments — logic analyser, oscilloscope, trace output, current probe — and what each one told them?
• Do they distinguish what they proved from what they assumed?
• Do they say what the root cause turned out to be, in one clear sentence?

Six of our seventeen syntax-passers could do this well. Those six mapped almost exactly onto the people we would have wanted to hire.

Step 4 — Run a bench test, not a coding puzzle

Give candidates something real and ask what they would do next. We use three artefacts, and any one of them works:

1. A logic analyser capture of a bus transaction that fails intermittently. Ask what they notice and what they would check first.
2. A current consumption trace showing a device that should sleep at 8 µA but sits at 340 µA. Ask for their three most likely explanations, ranked.
3. A fault dump from a hard fault handler with a stack trace. Ask them to reconstruct what probably happened.

Keep it to 45 minutes, allow them to ask you questions about the hardware, and score the reasoning rather than the answer. Strong candidates ask what the schematic looks like and whether the fault correlates with temperature or radio activity. Weak candidates guess.

One warning from our own process: do not send this as unpaid homework. Senior embedded engineers in Dubai are interviewing in parallel with three other companies and will simply decline. Run it live, with an engineer from your team present.

Step 5 — Verify field experience explicitly

This is the highest-yield filter in the entire process, and almost nobody asks about it directly. There is a wide gap between engineers who have worked on development boards in a lab and engineers who have shipped devices that then had to survive without them.

Field experience teaches things a lab never will: that firmware updates fail halfway and must be recoverable, that a device in a hot enclosure behaves differently from one on a bench, that a fleet of ten thousand units will surface a one-in-a-million bug every week, and that you cannot reproduce a fault you cannot instrument.

Ask three questions:

• “How many units of something you wrote firmware for are in service today?”
• “What broke in the field that you did not anticipate in the lab?”
• “How did you deliver an update to a device you could not physically reach?”

The third question is the sharpest. Recoverable over-the-air update is where careless embedded work turns into an expensive recovery operation, and anyone who has done it seriously will have strong opinions about rollback and power-loss safety.

Step 6 — Benchmark AED pay against the scarce skill

Do not price the job title; price the specific scarcity. Broad ranges we currently observe for Dubai, gross monthly:

Two contextual points that matter when you present an offer. The UAE levies no personal income tax, so a gross figure here is not comparable to a European gross — make that explicit in writing, because candidates relocating from Europe routinely under-estimate the difference. And roughly 70 percent of senior technology hires in Dubai arrive through international relocation, so a candidate who already holds UAE residency saves you 60 to 90 days of start date. That is worth paying for in a certification-driven programme.

Step 7 — Close within ten days of the bench test

Our first search lost two of the three genuinely qualified candidates to slower decisions on our side. Both accepted elsewhere while we were still arranging a final conversation.

Set the rule before you start interviewing: a decision within ten days of the bench test, and an offer in writing within three days of the decision. Agree who signs off before the first interview, not after the last one. Where the specialism is genuinely scarce, the process speed is a larger factor in your hit rate than the salary band.

A note on the regional picture

Embedded scarcity is not a Dubai problem, which is useful to know when you are deciding whether to widen the search. Our colleagues at HireDeveloper.sg report the same bottleneck in Singapore, where edge-AI work is pulling firmware engineers out of the industrial pool. The team at JapanDev sees the opposite constraint in Tokyo: real depth in embedded talent, but a much smaller pool of engineers able to work in English.

The practical implication for a UAE employer is that relocation from Asia is a live option for mid-level roles, and that the competition for the senior specialists is genuinely global. If you are standing up a broader team rather than filling one role, our guide on how to build an IoT engineering team covers the sequencing and the first four hires.

Frequently asked questions

The bottom line

Embedded hiring fails in a specific and repeatable way: teams run a software interview for a job that is mostly hardware diagnosis, then conclude the talent does not exist. It exists. It is scarce, it is largely passive, and it is filtered out early by the wrong test.

Scope the silicon before you write the advert. Describe constraints rather than requirements. Ask about the hardest bug in the first fifteen minutes. Put a real trace in front of people. Ask how many units of their firmware are in service today. Price the scarcity rather than the title, and decide within ten days. That is the whole method, and it took us nine wasted months to arrive at it.