I Screened 23 Developer Relations Candidates in Dubai and 19 Failed the Same Test: the 7-Step Method I Use Now

The first developer relations search I ran in Dubai took four months and produced a hire who gave excellent talks and moved no numbers. That was my fault, not theirs. I had written a job advert that described a speaker, interviewed for charisma, and then handed the person a product whose quickstart had been broken since the previous release. Twenty-three candidates and three searches later, the process below is what I actually use. The single change that mattered is in step 4, and it costs ninety minutes.

Step 1: Decide Which of the 3 DevRel Jobs You Are Funding

“Developer relations” bundles three jobs that happen to live near each other, and no single person leads all three well. Name yours before you write a word of the advert.

• Documentation and SDK engineering. Quickstarts, reference docs, sample applications, client libraries, the error messages a developer meets at 2am. Output is measured in time to first successful call.
• Community and field. Talks, workshops, hackathons, forum answers, the slow accumulation of people who trust you. Output is measured in qualified inbound and in who shows up.
• Product feedback loop. Turning what developers struggle with into prioritised engineering work, which means sitting in roadmap conversations with evidence. Output is measured in shipped changes that came from outside the building.

Fund one as the primary mandate. Name the other two explicitly as secondary in the advert. This single decision removed most of the noise from my shortlists, because candidates self select hard on it: the SDK engineer who hates stages will not apply to a field-led mandate, and that is the outcome you want.

Then run the diagnostic, which takes an afternoon. Pull three numbers: signups, first successful API call, and still-active-at-day-fourteen. If the leak sits between signup and first call you have a documentation problem, which is scoped work a two to three month engagement closes faster than a permanent search. If developers reach a working call and vanish in week two you have an adoption problem, and that needs somebody in the room when the roadmap is set. I have watched three companies budget for the second while suffering from the first.

Step 2: Build the Scorecard From Your Own Funnel, Not a Template

Most DevRel scorecards are inherited from a job board and score things like “community building” and “content creation” on a five point scale. Those are categories, not signals. Replace each line with a question tied to a number you already track.

Mine has five rows, and every row names a funnel step: can this person shorten time to first call, can they write a reference page an engineer trusts, can they diagnose why week two churns, can they get a change onto the roadmap, and can they be the public face of the product without supervision. Each is scored out of four with a written justification, and the justification is the part that matters, because it forces the interviewer to point at evidence rather than impression.

One row I now weight above the others: can they write the thing that admits a weakness. The best developer relations work in this market is candid about what the product does not do yet, because developers can tell within a page whether they are reading marketing. A candidate who cannot write a limitation section will not be trusted by your audience, however good the talk is.

If your documentation itself is the deliverable, the adjacent role is worth knowing well: our notes on hiring a technical writer for developer documentation in Dubai cover where the two briefs overlap and where they genuinely do not.

Step 3: Source Where the Evidence Is Already Public

This is the one role where you can read the work before you speak to the person, and most searches start on a job board anyway. The evidence is public by construction:

1. Merged pull requests on documentation repositories. Look for people who improved somebody else’s docs without being asked, especially the unglamorous ones: a fixed code sample, a corrected error message, a missing prerequisite.
2. SDK changelogs. A maintained client library over eighteen months is a stronger signal than any portfolio, because it proves the candidate kept going after the launch.
3. Conference talk archives from the region. Not the headline keynotes. The workshop tracks, where somebody stood in front of forty people and debugged live.
4. Answered questions in public forums. Read the tone. You are hiring the way this person talks to a frustrated stranger, because that is most of the job.
5. Only then, job boards and referrals. With the first four in hand, your outreach can reference a specific thing the person built, which in my experience roughly doubles the reply rate in this niche.

Dubai adds one constraint worth naming early. The regional developer community is tight, so a candidate already visible in it brings a network you cannot hire in from outside, while a candidate relocating in brings reach but needs two quarters to be trusted locally. Both are valid and they are different purchases: choose deliberately rather than discovering it after the offer.

Step 4: Screen With a 90-Minute Artefact Exercise, Not a Talk

This is the step that changed my results, and it is where 19 of 23 candidates fell over. Give the candidate one real, genuinely undocumented endpoint from your product. Ask for two things:

1. A quickstart that gets a reader who has never seen your product to a working call. Any format. Their choice of language.
2. A short note, half a page, on what they would change about the endpoint itself.

Pay for the time, cap it at ninety minutes, and say the cap out loud, because the discipline of shipping something incomplete on time is part of what you are measuring. Then read the note first.

The quickstart separates competent from incompetent. The note separates the hire from the near miss. Most candidates write a diplomatic paragraph praising the design. A small number write something like: the error response does not tell me which field failed, your pagination cursor is not documented in the response shape, and the required header is not mentioned until the third section. That person has read your API as a developer rather than as an applicant, and they will do the same thing in a roadmap meeting six months from now.

Of my 23 candidates, 19 wrote the diplomatic paragraph. Two refused the exercise, which is a legitimate position and told me something useful anyway. Two wrote the critical note, and the one we hired is still the only person in that company who gets API changes reversed before release. If you have no undocumented endpoint to hand, any public API works: the signal transfers. Our notes on API design practice in the UAE cover what a good critical note tends to catch.

Step 5: Interview the 2 Failure Modes Separately

This role fails in two directions, and a blended interview panel averages them into a false pass.

Failure mode one: the engineer nobody listens to. Technically excellent, writes correct documentation nobody reads, cannot hold a room, will not push back in a roadmap meeting. The product gets accurate docs and no adoption.

Failure mode two: the communicator engineers do not respect. Excellent on stage, warm in forums, cannot open a pull request your team would merge. Your own engineers quietly route around them within a quarter, and the feedback loop dies.

Run two loops. The engineering credibility loop is staffed by the engineers who would actually review the candidate’s pull requests, and it asks them one question: would you merge this person’s work without rewriting it. The communication loop is staffed by someone who has watched real developers fail at onboarding, and it asks whether this person can explain a hard thing to a frustrated stranger without condescending.

Score the two loops independently and record both numbers. Refuse to average them. A candidate who is 4 and 1 is not a 2.5, they are a no, and the averaging is how both of my early mis-hires passed.

Step 6: Price the Role Against Both Markets It Straddles

Here is the structural problem with this title in Dubai, and it is not about Dubai specifically: a developer relations engineer sits in two salary markets at once. Benchmarked as a senior engineer who also communicates publicly, the band follows your backend or platform engineering band. Benchmarked as a technical marketer who also codes, it follows your marketing band, which in most companies here is materially lower.

Both benchmarks are defensible. What is not defensible is the common sequence: advertise against the marketing band, interview against the engineering bar, then lose the candidate at offer and conclude the market is irrational. The market is not irrational. You ran two different processes.

So do three things in order. Benchmark both bands separately from your own recent offers. Decide which band you are competing in and write down why. Then set the walk-away number before the first call and record which band it came from, so that six weeks later nobody can quietly move it. Our notes on building a Dubai salary benchmark cover assembling those numbers from offers you have already made rather than from published surveys.

Then ask candidates directly which band they consider themselves in. In my experience they answer honestly and immediately, and it saves a fortnight of mutual guessing.

Step 7: Write the 90-Day Measurement and the Kill Criteria Before the Offer

Developer relations is the easiest role in a company to keep for three years without anyone being able to say what it changed. Activity is highly visible: talks given, posts published, events attended. Outcomes are slow and attributable to a dozen causes. That asymmetry is why these roles get cut first in a downturn, and it is unfair to the person doing the work.

Fix it before the offer, in writing, in three parts.

1. The one number they own. Pick a single funnel metric from step 2. Time from signup to first successful API call is the usual honest answer. Not followers. Not published pieces.
2. Leading indicators for the first 90 days. Because the owned number will not move in a quarter. Quickstart rewritten and tested on three strangers. Top ten support questions answered in the docs. One API change proposed with evidence.
3. Kill criteria. The conditions under which you would conclude the role was the wrong answer. Writing these down is uncomfortable and it is the most valuable paragraph in the document, because it converts an open ended mandate into a bet with a review date.

Share all three with the candidate before the offer is signed. Two of my four finalists pushed back on the owned number and were right both times, which is itself a signal: a person who negotiates their own metric has done the job before. Our notes on retaining senior developers in Dubai cover why an explicit review date reads as respect rather than as a threat.

The 3 Mistakes I Have Made Myself

Hiring a speaker for a documentation problem. My first search. The quickstart was broken, I hired someone for the stage, and the stage brought developers to a door that did not open.

Letting the panel average the two loops. The most common way a known-bad candidate gets through. Record two numbers, never one.

Treating the follower count as the portfolio. It is the most visible number attached to a DevRel candidate and the weakest predictor of anything in the scorecard. A maintained SDK with eighteen months of commits told me more than any audience figure, every time.

FAQ: Hiring a Developer Relations Engineer in Dubai