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: Define SLI, SLO and SLA and how they relate.
Model-answer hint
the measurement, the internal target and the contractual commitment with consequences.
Question 2: How do you choose an SLO target?
Model-answer hint
user expectations, historical performance, cost of each extra decimal of availability, business input.
Question 3: What happens when the error budget runs out?
Model-answer hint
an agreed policy: pause risky releases, prioritise reliability work, review with product.
Question 4: How do you design alerts that do not burn out on-call?
Model-answer hint
alert on symptoms and burn rate, not causes; runbooks; ruthless noise tuning.
Question 5: Walk through how you run incident command.
Model-answer hint
clear roles, communication cadence, mitigate before root cause, timeline, hand-offs.
Question 6: What makes a post-mortem useful?
Model-answer hint
blameless, contributing factors, actions with owners and dates, follow-up review.
Question 7: How do you plan capacity for a seasonal peak?
Model-answer hint
historical trends, load tests, headroom, autoscaling limits, dependency capacity.
Question 8: How would you introduce chaos engineering safely?
Model-answer hint
hypothesis, non-production first, small blast radius, abort conditions, game days.
Question 9: What is toil, and how do you decide what to automate?
Model-answer hint
manual, repetitive, no lasting value; prioritise by frequency and risk.
Question 10: How do OpenTelemetry traces help find latency problems?
Model-answer hint
end-to-end spans, critical path, slow dependencies, correlation with logs and metrics.
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
Using dashboards and logs from a payment API that breached its latency SLO during a traffic peak, identify the likely cause and write a short incident timeline and post-mortem. Then propose 2 SLO-based alerts and one chaos experiment to prevent a repeat.
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
- Targets 100% availability without discussing cost or trade-offs.
- Alerts on every metric, causing pager fatigue.
- Blames individuals in post-mortems.
- Cannot write code to automate operational work.
- 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.