How we assess
Every applicant goes through 5 gates: application, an AI-assisted screen, a live technical assessment scored by a practice lead, a client-fit interview, and reference and credential checks. The questions below come from the live assessment. We score answers on reasoning and trade-offs, not on recalling definitions.
20 technical questions with model-answer hints
Questions 1–10 (role-specific)
Question 1: How do you version a public API without breaking partners?
Model-answer hint
additive changes, versioned paths or headers, deprecation windows, consumer contract tests.
Question 2: When do you choose events over request-response?
Model-answer hint
decoupling, fan-out and async processes versus the need for an immediate answer.
Question 3: How do you secure partner APIs end to end?
Model-answer hint
OAuth client credentials or financial-grade profiles, mTLS, scopes, rate limits, logging.
Question 4: Walk through mapping an ISO 20022 credit transfer to a legacy payment format.
Model-answer hint
field mapping, truncation and enrichment rules, validation, error handling.
Question 5: A partner sends duplicate requests. How do you handle it?
Model-answer hint
idempotency keys, a dedupe store, consistent responses.
Question 6: What belongs on a developer portal?
Model-answer hint
OpenAPI docs, sandbox, onboarding, key management, changelog, SLAs.
Question 7: How do you design error handling and retries in integrations?
Model-answer hint
transient versus permanent errors, backoff, dead-letter queues, alerting.
Question 8: How does change-data-capture work, and what are the pitfalls?
Model-answer hint
log-based capture, schema changes, ordering, the initial snapshot.
Question 9: How do you monitor integration health?
Model-answer hint
throughput, latency and error rates per partner, plus business-level reconciliation.
Question 10: How do you migrate from an ESB to API-led integration?
Model-answer hint
inventory, strangler pattern, prioritised flows, coexistence, decommissioning.
Questions 11–20 (Cloud & Complex Systems core)
Question 11: How do you make a service idempotent, and why?
Model-answer hint
idempotency keys, a dedupe store, safe retries under at-least-once delivery.
Question 12: How would you set an SLO for a payment API?
Model-answer hint
success-and-latency SLI, target from history and business need, an error-budget policy.
Question 13: Walk through a zero-downtime database migration.
Model-answer hint
expand and contract, CDC or dual writes, backfill, verification, flag-controlled cut-over, rollback.
Question 14: When do you choose event-driven design over synchronous APIs?
Model-answer hint
decoupling and fan-out versus harder ordering, consistency and debugging.
Question 15: How do you keep Terraform safe across many teams?
Model-answer hint
versioned modules, locked remote state, reviewed plans, policy-as-code, drift detection.
Question 16: What belongs in a good post-mortem?
Model-answer hint
timeline, impact, contributing factors, blameless tone, actions with owners and dates.
Question 17: How do you design for data residency across regions?
Model-answer hint
data classification, region pinning, in-region keys, replication rules, access logging.
Question 18: How do you find the cause of a p99 latency regression?
Model-answer hint
traces, deploy diff, saturation signals, profiling, slow dependencies.
Question 19: Tell us about cutting cloud cost without hurting reliability.
Model-answer hint
rightsizing, commitments, autoscaling, storage tiering, impact measured before and after.
Question 20: How do you evolve an API that external partners depend on?
Model-answer hint
additive changes, versioning, deprecation windows, consumer contract tests.
Interviewer tip: Ask for a real example after every answer. Strong candidates describe what they built, what broke and what they changed.
Practical task
Design and partly implement an account-information API for an Open Banking scenario: an OpenAPI specification, gateway policies for OAuth 2.0 and rate limiting, a mock adapter mapping a legacy account model, and a short note on versioning and monitoring.
How to run it Share the brief 24 hours ahead or run it live. Ask the candidate to talk through trade-offs as they work; reasoning matters more than a finished artefact.
Red flags our practice leads watch for
- Treats API security as an API key and nothing more.
- Has no strategy for versioning or partner communication.
- Ignores idempotency and retries.
- Cannot explain how integrations are monitored in production.
- Universal flag: Vague answers that never reach a concrete system, number or decision the candidate personally owned.
The scorecard we use
Score each dimension 1–4 (1 = no evidence, 2 = partial, 3 = solid, 4 = exceptional):
| Dimension | Weight | What a 4 looks like |
|---|---|---|
| Technical depth, production judgement and security | 40% | Explains how and why, designs for failure and sensitive data, and knows each tool’s limits |
| Practical task and problem solving | 30% | Delivers a working solution with tests and documented decisions |
| Communication and documentation | 20% | Explains clearly to technical and non-technical audiences, in English or Arabic |
| References and regional context | 10% | References confirm the claimed scope; knows the frameworks and data-residency rules that apply |
Pass bar: weighted average of 3.0 out of 4 or higher, with no dimension below 2. The practice lead approves the final result.