Hiring a Retail POS Developer in Dubai: the 8 Checks I Wish We Had Run Before Go Live

The call I get most often from retail and food and beverage operators in this market does not start with a hiring question. It starts with a store manager’s complaint: the till froze at peak trading, the queue backed up, and nobody could explain why the day’s takings did not match the system the next morning. By the time I am on the call, the company has usually hired two perfectly competent web developers and discovered that competence in web development does not transfer to a machine that has to keep taking money when the network is gone. Below is the method we now use to hire for this, written as eight checks in the order you should run them.

Why Retail Systems Hiring Breaks Normal Interview Loops

A web application that loses connectivity can show a spinner. A till cannot. It has to complete the sale, print something the customer accepts, hold the record locally, and reconcile later without charging anyone twice when the connection comes back. That is a different engineering discipline from the one most interview loops test for, and it is the reason a strong generalist can fail badly in this role while an unremarkable CV turns out to be exactly right.

Dubai adds a second layer. Stores here trade through long peak hours, often across multiple brands and multiple mall landlords, with receipts that need to read correctly in Arabic and English and a finance team that wants the tax line to be unambiguous on every transaction. None of that is exotic engineering. All of it is the kind of detail that surfaces in week three of a deployment rather than in an interview, unless you deliberately put it in the interview.

Check 1: Write the Requisition Around the Failure Mode, Not the Stack

Open the job description with the condition the system must survive, not the technologies you happen to use. Compare these two openings.

The one that attracts the wrong candidate: “We are looking for a full stack developer with React, Node.js and PostgreSQL experience to work on our retail platform.” Every generalist in the market applies and none of them self-select out.

The one that works: “Our tills must complete sales and print receipts with no connectivity for up to four hours, then reconcile without duplicate charges. You will own that path across 40 stores.” The application volume drops and the quality rises, because engineers who have not done this read it and move on, while the ones who have read it and recognise their own last two years.

Write the stack as a secondary paragraph. A competent systems engineer learns your framework in three weeks. Nobody learns reconciliation thinking in three weeks.

Check 2: Separate the Three Engineering Surfaces

Retail systems work is three jobs that get written as one. Decide which you are hiring before you source.

If you only hire one person, hire for the integration layer. It is the surface where mistakes become money, it is the hardest to interview for, and it is the one you cannot credibly outsource and then forget about, because the knowledge of how your stores behave at peak lives there.

Check 3: Fix the Domain Constraints Before You Source a CV

Write a one-page constraint sheet and have your finance and operations leads sign it before sourcing starts. Six lines, and you will use every one of them in interviews:

• Offline tolerance. How long must a till keep trading with no connection? Four hours and four minutes are different architectures.
• Peak throughput. Transactions per minute per store at your worst hour, not your average. Operators almost always know this number and are almost never asked for it.
• Tax presentation. How the tax line must appear on the receipt and in the export your finance team reconciles. Agree the format in writing, because retrofitting it is a data migration rather than a change.
• Bilingual receipts. Arabic and English on the same printed output, with right-to-left handling that does not mangle totals. Easy to specify, painful to discover late.
• Payment estate. Which terminals and providers, and whether you are integrating at the device level or through a gateway. This single line determines half the candidate profile.
• Rollout shape. Twenty stores in one weekend or two stores a week for five months. It changes who you hire, not just when.

Our guide to the Dubai retail technology landscape covers the surrounding stack in more detail, and the UAE payments overview is worth reading before you fill in the payment estate line.

Check 4: Source From Operators, Not From Product Companies

The instinct is to look for people who have worked at a POS software vendor. It is not wrong, but it is a small pool and an expensive one, and vendor engineers have often only ever seen their own product.

The deeper pool in this market sits inside the operators and the layer around them: retail and food and beverage groups that run their own in-house systems teams, payment processors and acquirers, ERP implementation partners who have done retail rollouts, and logistics companies whose warehouse and delivery systems have the same offline and reconciliation shape. Candidates from that last group are consistently undervalued, because their CVs do not contain the words “point of sale” and keyword screening discards them.

Practical sourcing note: these people move through referral and direct approach, not applications. Budget time for outreach rather than for advert spend, and expect the strongest two candidates in your process to be people who were not looking. Our e-commerce engineering talent page and .NET developer page cover two of the common backgrounds we draw from, since a large share of installed retail estate in this region runs on .NET and SQL Server.

Check 5: Screen With a Reconciliation Exercise, Not a Coding Puzzle

This is the check that replaced three interview rounds for us. Forty minutes, no code required, and it separates the field faster than anything else we have tried.

Give the candidate this scenario in writing, then talk it through:

A till loses connectivity at 19:40 on a Friday. It keeps trading and records 83 transactions locally, 11 of them card payments that the payment terminal authorised independently. Connectivity returns at 21:15. The next morning, the store report shows 79 transactions and the finance export shows a total that is 640 dirhams higher than the till. Walk me through how you would find the discrepancy, and then how you would design the system so this cannot happen again.

What you are listening for, in order of importance:

1. Do they ask what the source of truth is before proposing a fix? Candidates who start designing immediately are the ones who will patch symptoms in production.
2. Do they reach for idempotency keys and a transaction log unprompted, or do they describe a nightly comparison script? The second answer is not wrong, it is just a decade behind.
3. Do they separate the two failure classes: records that never arrived, and records that arrived twice? People who have lived this separate them instinctively because the fixes are opposite.
4. Do they mention the store manager at all? The best answers include a human procedure for the night it happens anyway, because every real reconciliation design has a manual fallback and someone has to be able to run it at 23:00.

We score each of the four from zero to three and do not advance anyone below seven. The exercise also doubles as a strong signal for the candidate: engineers who want this kind of work find the conversation energising, and the ones who do not withdraw themselves, which saves everybody a round.

Check 6: Interview the Integration Half Properly

Once a candidate clears the reconciliation exercise, the integration interview is where you find out whether they have worked with systems they did not control. Four questions, each with a tell:

• “Describe an API you had to integrate with that behaved badly. What did you do?” The tell is whether they built a defensive boundary or whether they adapted their own domain model to somebody else’s bad schema. The second answer means your codebase will inherit the vendor’s mistakes.
• “How do you test an integration you cannot call freely?” Strong candidates talk about contract tests, recorded fixtures and a sandbox strategy. Weak candidates talk about testing in production with care.
• “A payment authorises but your record of it fails to save. What happens next?” This is the single most important question in the loop. There is no clean answer, and the quality of the candidate is entirely in how they reason about which inconsistency they would rather have.
• “Who found your last production integration bug, and how?” If the answer is always a monitoring alert, probe harder. If the answer is sometimes a store manager, you are talking to someone who has actually run a retail system and listened to the people using it.

Keep this interview to one hour with two people, one engineer and one operations representative. The operations person contributes more than you expect, because they can tell within ten minutes whether a candidate treats store staff as users or as a nuisance.

Check 7: Choose the Engagement Model, and Write the Handover Clause First

Three models work for retail systems in this market, and the right answer depends on how long the system will outlive the project.

The hybrid we recommend most often for a mid-sized operator: one in-house engineer who owns the integration layer permanently, plus a dedicated team for the terminal and reporting work during the rollout. It gives you throughput against a deadline without carrying four salaries into the following year, and it keeps the irreplaceable knowledge inside the business.

Whichever you choose, write the handover clause before you sign anything, not at the end. A handover that is negotiated in the final week of a project is always worse than one agreed in the first, because by then the leverage has moved. Specify the acceptance test, the runbook, and who answers the phone for the first sixty days after the last store goes live.

Check 8: Onboard Against the Store Rollout Calendar

The last check is a sequencing one, and it is where most otherwise good hires lose their first quarter. Retail has freeze windows: peak trading periods when nobody is allowed to touch a production till, and in this market those windows are long and they are not negotiable. If your new engineer starts two weeks before one, they will spend their ramp-up period unable to deploy anything.

Build the onboarding plan backwards from the rollout calendar:

1. Weeks 1 to 2: a store shift. Put the engineer behind a till for two full shifts, including a peak evening. Every engineer we have done this with has come back with at least one architectural opinion they did not have before, and it permanently changes how they treat store staff in bug reports.
2. Weeks 3 to 4: own one reconciliation cycle. Not observe it. Own it, with supervision. This is the fastest route to the domain knowledge that makes the integration layer safe.
3. Weeks 5 to 8: one non-critical surface, end to end. A reporting change or a peripheral integration, shipped to a single pilot store. Small scope, real deployment, before any freeze window.
4. Week 9 onward: into the rollout. By this point they have seen a peak, run a reconciliation and deployed once. That is the minimum competence bar for touching a production estate during a rollout.

If a freeze window lands inside the first eight weeks, move the start date rather than the plan. A two-week delay on a start date is cheaper than an engineer whose first deployment experience is during a rollout they do not yet understand. For the rest of the onboarding mechanics, our retail loyalty build guide is a useful companion, since loyalty is usually the first integration a new retail engineer is handed.

The Eight Checks, in One List

1. Write the requisition around the failure mode, with the stack as a secondary paragraph.
2. Separate the terminal, integration and back office surfaces, and hire for integration first.
3. Fix the six domain constraints on one page, signed by finance and operations, before sourcing.
4. Source from operators, processors, ERP integrators and logistics teams, not only from POS vendors.
5. Screen with the forty-minute reconciliation exercise and score it out of twelve.
6. Run a one-hour integration interview with an engineer and an operations representative.
7. Choose the engagement model and write the handover clause before you sign.
8. Build onboarding backwards from the rollout calendar, starting with two shifts behind a till.

Six to ten weeks, and the single compression lever is check five: prepare the exercise before you open the role. Every team I have watched improvise it after the first candidate reached final stage ended up assessing each candidate against a different bar and restarting the process.

FAQ: Hiring POS and Retail Systems Developers in Dubai

Method notes: the three-surface model, the forty-minute reconciliation exercise and its scoring, the four integration questions, the engagement model comparison and the eight-week onboarding sequence are our own hiring method, developed from the retail and food and beverage systems roles we recruit for in the UAE. The scenario in check five is illustrative and constructed for assessment purposes. Scarcity assessments describe the candidate pools we source from in this market and are not survey data. Any constraint figures in your own requisition should come from your finance and operations leads rather than from this article.