How to Pass a Technical Assessment at Gulf Employers

Most candidates treat the technical assessment like a school exam. They spend three days grinding data structures, submit the first solution that compiles, and wonder why the recruiter at Noon or Aramco's digital division stopped responding. The actual problem isn't the coding — it's the framing.

Technical assessments at Gulf employers aren't pass/fail tests of whether you know a particular language or framework. They're proxies for how you'd behave on the job: do you read instructions carefully, write code other people can maintain, communicate trade-offs, and handle edge cases nobody explicitly listed? Companies use these to filter on engineering judgment, not just syntax.

The same failure pattern appears across companies and roles. Here's what you're actually being evaluated on — and the specific moves that knock experienced candidates out before they ever see a calendar invite.

What Is a Technical Assessment for Gulf Tech Roles?

A technical assessment is a structured, evaluator-designed exercise that filters candidates on applied skill before any live interview takes place. At Gulf employers — from Tabby and Tamara in Saudi fintech to STC and SDAIA in telecom and government data — the format varies significantly more than at Western tech firms. You might face a timed coding test (HackerRank or Codility), a multi-day take-home project, a live pair-programming call, a dry-run system design exercise, or some combination. Some companies run two or three of these formats before you speak to a hiring manager.

The critical thing to understand: a technical assessment isn't graded only on whether the code runs. It's scored on whether it runs correctly per the spec, whether the code is maintainable by someone else, whether edge cases are handled, and whether you demonstrated professional judgment about trade-offs. Many candidates pass the first filter and fail the second.

According to a 2024 HackerRank report, 72% of engineering teams globally now use a technical screen as their first candidate filter. Gulf employers are firmly in that group — with the added wrinkle that assessments here often test localization scenarios, Arabic locale handling, and regional payment logic that candidates relying purely on Western interview prep haven't thought about.

Here's the short version before the full breakdown:

Confirm the format before you receive the assessment — most Gulf technical assessments fall into four types: timed coding test, multi-day take-home, live pair-programming session, or system design exercise. Email the recruiter a day before and ask which format to expect, plus whether there's a preferred language or stack. Most will tell you.

Read the full brief before writing a single line of code. Spec mismatches get auto-filtered before a human reviewer ever sees the submission — code quality doesn't matter if it solves the wrong problem. Write readable code: descriptive variable names, functions scoped to one logical step, edge cases handled or documented.

For take-home submissions, include a README of 200–400 words covering your assumptions, the trade-offs you made, and what you'd do differently with more time. Gulf companies test regional scenarios — Arabic locale, RTL UI, Saudi payment methods — that standard Western interview prep skips. Submit at least two hours before the deadline.

That block is the map. The rest of this is the terrain.

Are You Preparing for the Right Format?

Wrong way: You assume it'll be a timed algorithm test, so you spend your prep grinding LeetCode mediums. The recruiter sends a 48-hour take-home project link and you realise you haven't touched a full feature build in months.

Right way: Before you receive the assessment, email the recruiter. "Is this timed or open-ended? Coding test or project? Preferred language or stack?" Most recruiters will answer. Careem's standard engineering process, for instance, typically starts with a 60-minute HackerRank session focused on data structures, then moves to a take-home system design round. Knowing this changes how you'd allocate the four days before an assessment arrives.

Confirming the format before you receive it is the single most underused preparation move in Gulf tech hiring. Many companies — particularly government-linked entities like SDAIA, SABIC's digital function, and Aramco's digital hiring pipeline — use proprietary or internal platforms that look nothing like the LeetCode interface candidates expect. Walking in cold to an unfamiliar system burns your first 15 minutes.

Preparation varies meaningfully by format. For a timed test, practice under actual time pressure with a clock running. For a take-home, practice project structure, README writing, and making clean git commits. For a live pair-programming session, practice narrating your thinking out loud, not just solving in silence. These require different preparation and candidates who conflate them consistently underperform on the format they didn't prepare for.

Are You Actually Reading the Brief?

Wrong way: You skim the problem in 90 seconds, start coding immediately, and discover 45 minutes in that you misread the expected output format. You submit technically polished code that doesn't match the spec.

Right way: Budget 10–15% of your total time on analysis before writing any code. For a timed test: read the full brief, annotate the edge cases, write your understanding of expected inputs and outputs in plain text first. For a take-home: break the problem into sub-problems, list your assumptions explicitly, and start your README before you open your code editor.

One named scenario: a candidate applying for a backend role at SDAIA submitted a Redis-based caching solution that was architecturally sound. The spec required database-persisted TTLs for audit compliance — a common constraint in Saudi government tech, where data lineage matters for regulatory reasons. The candidate used in-memory TTLs. The submission was auto-filtered before a human reviewer ever saw it.

Reading the full brief before touching the keyboard is the highest-leverage 15 minutes of any technical assessment. No clever implementation recovers from solving the wrong problem. The filter catches spec mismatches before code quality is even evaluated, which means excellent code can fail on the most preventable mistake in the process.

Is Your Code Readable, Not Just Correct?

Wrong way: You write code that passes all tests. Variable names are a, b, tmp2. Your main function runs 140 lines. No comments anywhere. You submit because it runs.

Right way: Correct and readable, in that order. At Gulf employers — particularly SDAIA, SABIC Digital, and Al Rajhi Bank's technology division — your assessor is often a senior engineer who could become your direct manager. They're evaluating your code as if they'll inherit it. Use descriptive variable names. Write one function per logical step. Add comments only where logic would genuinely surprise a future reader.

A 2023 Stack Overflow developer survey found that 71% of developers spend more time reading code than writing it. The engineers reviewing your submission live in that reality. Illegible-but-correct reads as "this person doesn't think about their teammates." Readable-and-correct gets you to the next round.

This distinction matters more at Gulf companies where engineering teams are multilingual and code is maintained across different organisational contexts. Your code's readability is partly a communication skill. An assessor at a Saudi government-linked company looking at your variable names and function structure is also asking: would I be comfortable bringing this person into a team review?

What Do Gulf Employers Test That Others Don't?

This is the blind spot for candidates who've done Western tech assessments before and assume the experience transfers directly. Gulf companies embed regional product context into assessments, and the specifics are testable.

A product engineer assessment at Noon might require handling Arabic locale formatting, right-to-left pagination, and AED rounding rules simultaneously. A backend test at a Saudi fintech company might include a regional payment gateway integration scenario that uses mada or STC Pay semantics. If you've only practiced English-language product exercises, you'll underestimate the scope of what's being tested.

The fastest way to build regional context is to use the actual products yourself. Open Noon in Arabic. Walk through an STC Pay checkout. Browse Tabby's BNPL interface in Safari on your phone. You'll surface the edge cases the assessors already built into the rubric — and you'll stop being surprised by them.

Some roles in government-adjacent sectors also expect awareness of Saudi data localization requirements and Vision 2030 digital infrastructure priorities. This surfaces as system design constraints in assessments, not trivia questions. A candidate who accounts for data residency requirements without being prompted signals exactly the kind of contextual judgment these companies want.

How Should You Structure Your Submission?

Wrong way: You zip up the files, write "Here's my submission" in the email body, and send it.

Right way: For any take-home, include a README of 200–400 words covering four things: the assumptions you made, what you'd do with more time, what you tested and how, and the known trade-offs in your approach. For a live coding session, narrate these things as you work rather than waiting for the interviewer to probe.

Assessors at Tabby and Tamara — two Saudi fintechs with lean engineering teams — have noted that they read the README before running the code. The candidate who writes "I chose Redis for session storage because it handles TTL natively; I'd add Postgres persistence for long-lived sessions where audit trails matter in production" reads like someone who has shipped real software. A well-written README turns a B-grade implementation into an A-grade candidate signal.

The README also gives you natural talking points in the follow-up interview. The assessor who read your trade-off reasoning before the call will ask about it. That's an opening, not a trap — it turns the take-home into a live portfolio piece you can walk through with authority rather than trying to reconstruct under pressure.

Your Pre-Submission Checklist

Before you hit submit on any technical assessment, work through this in order:

• Re-read the original brief and confirm every requirement is addressed
• Run the code from scratch in a clean environment
• All variable and function names are descriptive and reveal intent
• No debug logs, leftover TODO comments, or test stubs remain
• Edge cases are handled or explicitly documented in the README
• README covers assumptions, trade-offs, and what you'd do with more time
• For frontend tasks: tested on mobile viewport and RTL locale where relevant
• You're submitting the correct, most recent version of your files
• Submitted at least 2 hours before the deadline

That last item matters more than it sounds. Automated platforms at some Gulf companies auto-reject late submissions without human review. At others, submitting 4 minutes before the cutoff creates a specific impression about how you perform under time pressure. The pre-submission pass is where experienced candidates lose points they didn't have to lose — not on the algorithm, but on the professional hygiene that signals whether you're ready to operate with minimal supervision.

Most candidates treat the technical assessment as a hurdle to get past. The ones who advance treat it as the first chance to show what kind of engineer they are. Clarify the format early, write code someone could inherit tomorrow, and submit a README that proves you thought past the test cases. That's the standard IntervYou's mock technical rounds are built to pressure-test.

Start a free mock →

Related reading

• How to Prepare for a Careem Interview in 2026
• Interview Prep for Top Employers in Saudi Arabia & the Gulf (2026)
• How to Prepare for a Job Interview in Dubai and the UAE