I Hired 3 “Fluent Arabic” Developers Who Broke Our RTL Build: the 7 Screens I Use Now in Dubai

Three times I filled a role that asked for a developer with native Arabic, and three times the Arabic interface shipped wrong. Not badly translated. Wrong in the mechanical sense: sentences reading out of order the moment a Latin-script username appeared inside them, a counter that said the Arabic equivalent of "3 item", a dashboard showing Arabic-Indic digits to Dubai users who expected the Latin ones they see on every bank statement.

The developers were not the problem. All three were fluent, two were native speakers, and every one of them would have passed any conversation-based assessment in the city. The problem was mine: I had screened for the language and assumed the engineering came with it. It does not. Reading Arabic and building for Arabic are separate skills, and only one of them shows up in an interview unless you deliberately test for the other.

What follows is the method I use now. Seven screens, in order, roughly three hours of assessment across a shortlist. Three of them require no Arabic from your side at all, which matters because most hiring managers in Dubai running this search cannot read the language they are hiring for.

Step 1: Decide which of the three Arabic jobs you are hiring for

Before anything technical, separate the roles that get bundled into one advert. There are three and they are genuinely different hires.

1. Arabic-language product work. Building interfaces where Arabic is a first-class language. The reading ability has to sit inside engineering because the person must notice a broken layout without waiting for a review cycle.
2. Arabic-language delivery work. Client-facing engineering with government or regional enterprise stakeholders, where requirements arrive in Arabic in a meeting. Spoken fluency and dialect comprehension dominate, and the technical screens below barely matter.
3. Arabic content and copy work. Writing and reviewing the strings themselves. This is a language role, not an engineering one, and it is routinely and expensively hidden inside a developer requisition.

Nearly every stalled search I have been asked to rescue in this category was asking for all three, budgeting for one, and screening for none. Pick one as primary. Where you genuinely need two, say so and price it, because a developer who can also own Arabic copy review is a narrower market than either role alone.

Step 2: Replace the fluency claim with a written sample

"Native Arabic" on a CV in this market is close to meaningless as a signal, not because anyone is lying but because it describes a dozen different realities: a Gulf national educated in English, a Levantine engineer who writes Arabic daily, a Maghrebi developer whose working language has been French since university.

Ask for 200 words of Modern Standard Arabic on a technical subject the candidate knows, written for a non-specialist. You are assessing register and clarity, not vocabulary. Then pay a native-level reviewer to grade it, because you cannot. Two hours of a qualified reviewer across a shortlist costs less than one mis-hire and removes the single biggest source of guesswork in the process.

One caution learned the hard way: do not grade the sample yourself using a machine translation back into English. Translation flattens exactly the register problems you are trying to detect, and a stiff, over-formal passage will read perfectly well once it comes back in English.

Step 3: Run the bidirectional text screen

This is where the first of my three mis-hires went wrong, and it is the single highest-yield screen in the set.

Give the candidate a realistic string: an Arabic sentence with a Latin-script username and a number embedded in it, of the kind every product in Dubai produces the moment it has user-generated content. Ask them why the rendered order comes out wrong and how they would fix it.

What you are listening for is whether they reach for isolation. The Unicode Bidirectional Algorithm, UAX #9, resolves the order of mixed-direction text, and the isolate characters exist precisely for this case: U+2066 LRI, U+2067 RLI, U+2068 FSI and U+2069 PDI, introduced in Unicode 6.3 in 2013 because the older embedding controls had too strong an effect on surrounding text. On the web the practical equivalents are the <bdi> element, dir="auto" on the interpolated value, or unicode-bidi: isolate in CSS.

Grading is simple:

Step 4: Run the plural categories screen

Ask one question: how many plural forms does Arabic need in an interface? The answer is six, and you can confirm it in a single line in any modern JavaScript runtime. Here is the output on Node 25.3.0 with ICU 78.2 and Unicode 17.0:

new Intl.PluralRules('ar').resolvedOptions().pluralCategories
// [ 'zero', 'one', 'two', 'few', 'many', 'other' ]

new Intl.PluralRules('en').resolvedOptions().pluralCategories
// [ 'one', 'other' ]

const ar = new Intl.PluralRules('ar');
ar.select(0)    // 'zero'
ar.select(1)    // 'one'
ar.select(2)    // 'two'
ar.select(3)    // 'few'
ar.select(10)   // 'few'
ar.select(11)   // 'many'
ar.select(99)   // 'many'
ar.select(100)  // 'other'
ar.select(103)  // 'few'   <-- the one that surprises people

Two details do the screening work. First, a candidate who answers "two" is giving you the English answer, which means they have shipped a counter with a singular and a plural form and nothing else. Second, 103 resolving to few while 100 resolves to other is the detail that distinguishes someone who has read the rules from someone who has memorised the list of six names. The categories follow the remainder, so any string table built on a hand-rolled conditional will be wrong somewhere above 100 even if it looks right from 0 to 10.

What a strong answer sounds like in practice: they do not try to recite the ranges. They say they would never write the conditional by hand, they would let the formatting library resolve the category and keep six message variants in the string table, then show you where that lives in a project they have shipped.

Step 5: Run the digit and locale screen

This one costs nothing and caught a candidate who was otherwise the strongest in the shortlist. Ask which digits an ar-AE interface shows by default.

new Intl.NumberFormat('ar-AE').format(1234.5)   // '1,234.5'
new Intl.NumberFormat('ar-AE').resolvedOptions().numberingSystem  // 'latn'

new Intl.NumberFormat('ar-EG').format(1234.5)   // '١٬٢٣٤٫٥'
new Intl.NumberFormat('ar-EG').resolvedOptions().numberingSystem  // 'arab'

Arabic locales do not share a numbering system. ar-AE resolves to Latin digits, ar-EG to Arabic-Indic digits, and a developer who believes Arabic means Arabic-Indic digits everywhere will hard-code the wrong one, usually in a currency or an invoice, usually discovered by a customer. The inverse mistake also happens: a developer who has only ever worked on Gulf products assumes Latin digits are universal and breaks an Egyptian rollout later.

The answer I now want to hear is that they would not assume either, they would resolve it from the locale and never hard-code a numbering system. Candidates who have genuinely shipped multi-market Arabic products say this immediately and without prompting.

Step 6: Test the mirroring judgement, not the mirroring mechanics

Flipping a layout is a day of work for any competent front-end engineer, and logical CSS properties have made it close to mechanical. Knowing what not to flip is the part that takes experience, and it is what you should be screening.

Show a single screen containing a back arrow, a progress bar, a line chart with a time axis, a media player with play and skip controls, a phone number field and a logo. Ask which elements mirror in the Arabic version and which must stay as they are. Then ask for the reasoning, which is where the signal lives.

The strong answers converge on a principle rather than a list: things that express direction of travel through the interface mirror, things that express an external reality do not. The back arrow mirrors. The progress bar mirrors. A chart whose horizontal axis is time generally does not, because time does not reverse. Media transport controls generally do not, because they map to a physical tape metaphor that users carry across languages. A phone number stays in its own direction regardless of the surrounding text. A logo never mirrors.

Weak answers mirror everything, which is the default a framework gives you, and that default is how you end up with a chart that reads backwards and a play button that looks like rewind. If you want the design-side context before writing the specification, our RTL design guide for Dubai products covers which patterns mirror and which do not in more depth.

Step 7: Check who reviews the Arabic after the hire

This is a screen on your own organisation, not on the candidate, and it is the one that would have saved me the most money.

Before you make the offer, name the specific person who approves Arabic strings in production. If the answer is "the new hire", you have just designed a single point of failure into the role. What follows is predictable: every Arabic string in the company routes through one engineer, their actual work slows down, they become the person who gets interrupted rather than the person who ships, and within a year they leave for a role where Arabic is a skill rather than a tax.

Two structures that work. Either you hire the reviewer separately, even at a few hours a week, and the developer owns only the engineering. Or you accept the bundled role explicitly, write the review time into the job description, pay for it, and cap it so it does not expand into the whole week. What does not work is the unspoken version, where the review load is real, invisible, unpaid and growing.

What this changes in the job advert

The screens are only half the value. The other half is that running them once tells you how to write the specification, and a specification written this way shortens the search rather than lengthening it.

• Drop "native Arabic" as a bare requirement. Say which of the three jobs it is, and which dialect matters for spoken work. Candidates self-select accurately when you are specific and badly when you are not.
• Name the engineering facts. Mentioning bidirectional text handling and locale-aware formatting in the advert attracts the people who have done it and quietly filters the people who have not. It also signals you know the difference, which matters to this particular candidate pool.
• State who owns Arabic review. Strong candidates ask this at offer stage. Having an answer ready has closed hires for me that salary alone would not have.
• Treat Arabic engineering as a premium, not a given. Two of the three skills here are scarce in every market, not just the UAE. Pricing the role as a standard front-end position is the most common reason these searches run past four months.

One last thing worth saying plainly, because it took me three mis-hires to accept it: none of the engineers I hired badly were bad engineers. They were competent people hired against the wrong screen. The screen was my output, and so was the broken build.

Frequently Asked Questions