Cohere Health Software Engineer Interview Guide

The 60-second brief

Cohere Health builds software for healthcare. Descriptions of the Software Engineer role place engineers on the infrastructure and platforms that sit between healthcare providers and payers, supporting clinical decision-making and moving large volumes of healthcare data. The domains named for the role are Payment Integrity, BI and AI, and the work is described as involving distributed systems, API design and data processing pipelines. The descriptions also tie the role to the reliability and security expectations of the healthcare industry. In practice that means backend services, the data flows behind them and the APIs that connect them.

This guide is for candidates interviewing for a Software Engineer position at Cohere Health, with the most weight on Senior and Staff loops, where candidates report system design being emphasised. It covers the four reported rounds, the thirteen reported technical questions (concepts, design and coding), the coding and design topics candidates describe, and a plan you can follow in a week. It also covers the cultural fit stage, since candidates report a round dedicated to it.

Candidates report four rounds over roughly three to five weeks: Recruiter Engagement, Technical Evaluation, Cultural Fit Assessment and Final Technical Evaluation. Some accounts stretch to six weeks, and the number of rounds can shift with seniority and the hiring team.

Focus areas

• System Design
• Backend Engineering
• API Design

Overview

The reported work is backend-heavy. Role descriptions mention distributed systems, API design and data processing pipelines across Payment Integrity, BI and AI. The reported questions follow the same split: concept questions (scaling an API, data injection and abuse, availability in microservices, consistency, database trade-offs), design questions (a claims-data system, low-latency clinical decision support, observability, failure in a cloud-native environment) and coding questions (optimising a processing task over a dataset, debugging a snippet, a binary-related algorithm problem, an API endpoint with complex input validation).

Candidates describe the coding area as practical. The topics listed are time and space complexity, clean and testable code, and asynchronous operations with race conditions. Example scenarios include fixing a bug in an existing codebase while changing as little as possible, and writing a performant data transformation. Practise both habits: reading unfamiliar code and making a small, safe change, and writing a fast solution for a data-shaped problem with edge cases named out loud. The system design area is described as covering sharding and partitioning, SQL versus NoSQL by access pattern, caching, handling many concurrent API requests, and logging and monitoring for a distributed service.

The healthcare setting changes the requirements you should state in a design answer. In the industry, payment integrity generally means catching incorrect or duplicate payments on claims, so a claims pipeline needs idempotent processing, an audit trail, replay after a bad batch and tight access control on sensitive data. Candidates list healthcare experience and familiarity with privacy rules such as HIPAA as nice-to-haves rather than requirements, so the goal is to show you can learn business rules and fold them into a design, not to recite regulations.

One practical warning comes from candidates: some report a gap between the skills they expected to be tested and the focus of the interviews. Say early, in the recruiter screen, whether your strength is frontend, backend or architecture, and ask which rounds are coding and which are design. Then prepare for both a live coding stage and a whiteboard-style design stage, because the loop reportedly includes technical rounds at the second and fourth positions.

The Cohere Health interview process

Candidates describe the four stages below in this order. Each entry says what is reported about it and how to prepare; the reported questions are grouped by type, not tied to a specific round.

Recruiter Engagement

Candidates describe Recruiter Engagement as the first contact: a conversation with a recruiter about the role and whether you fit it. Candidates also advise stating your track clearly here, because some report being interviewed on a skill set that differed from the one they expected. Treat the call as the place to settle which rounds are coding and which are design, and whether the loop is adjusted for your seniority.

What to demonstrate

• Fit for the Software Engineer role as discussed with a recruiter
• How clearly you describe your background and your strongest area (frontend, backend or architecture)

How to prepare

• Write a short summary of your backend, distributed systems and cloud experience, with two or three concrete projects you can expand on, since those are the listed must-have skills.
• State your strongest track explicitly and ask how it maps to the technical rounds, so you are interviewed for the right one.
• Ask which rounds are coding and which are design, whether the round count changes with seniority, and what the team builds (Payment Integrity, BI or AI work).
• Read up on what a claims or payments platform has to guarantee, so your questions to the recruiter show you have thought about the domain.

Technical Evaluation

Candidates describe the Technical Evaluation as an assessment of technical aptitude and architectural skills through coding challenges. The coding topics reported for the loop are complexity analysis, clean and testable code, and asynchronous operations with race conditions, with scenarios such as fixing a bug in an existing codebase while minimising changes and writing a performant data transformation. Approach it by asking clarifying questions before you write anything, then stating a brute-force solution, an improved one and the edge cases.

What to demonstrate

• Working code on a coding challenge, with time and space complexity stated
• Readable, testable code and handling of edge cases
• Care with asynchronous operations and race conditions

How to prepare

• Practise the coding questions candidates report: a function that optimises a processing task over a dataset, a binary-related algorithm problem (cover bit manipulation, binary search and binary trees), and an API endpoint with complex input validation.
• Practise the minimal-change bug fix: read the snippet, reproduce the failure, change the fewest lines, and explain why that was the safest fix. Add a test that fails before the change and passes after.
• Be able to explain a race condition you have seen, such as a check-then-write on shared state, and the fix: a lock, an atomic update or a version check.
• Rehearse a clarifying-question routine: input size, ordering and duplicates, invalid input, and whether memory or latency matters more.

Cultural Fit Assessment

Candidates describe the Cultural Fit Assessment as an evaluation of alignment with potential teammates and the organisation. The role as described involves working with product managers and clinicians, reviewing code, mentoring junior engineers and joining architecture discussions, and candidates report that explaining technical ideas to non-technical colleagues matters. Candidates also describe the team as knowledgeable and professional, so a clear, concise and respectful style suits the room.

What to demonstrate

• Alignment with potential teammates and the organisation, as the round is described
• Communication of technical ideas to non-technical people
• Collaboration across engineering, product and clinical colleagues

How to prepare

• Write three stories with a decision, a trade-off and a result: a code review disagreement, a time you mentored someone, and a time you worked with a product or domain expert on requirements.
• Practise explaining a design trade-off, such as why a cache is acceptable here and not there, in two sentences a product manager could repeat.
• Prepare one story about learning unfamiliar business rules in a regulated or domain-heavy area, since healthcare experience is a nice-to-have, not a requirement.
• Prepare a story about a deadline you met by deferring something on purpose, including how you recorded and bounded what you deferred.

Final Technical Evaluation

Candidates describe the Final Technical Evaluation as a broad assessment of technical and design skills. The reported design areas are sharding and partitioning, SQL versus NoSQL based on structure and access patterns, caching, handling a high volume of concurrent API requests, and logging and monitoring for a distributed service. Approach it as a full design conversation: requirements and scale first, then components, data model, failure handling and observability, with the trade-off for each choice stated.

What to demonstrate

• Design of scalable, resilient systems, as the final round is described
• Choice of storage, partitioning and caching for the access pattern
• Reasoning about trade-offs, including why you chose a database or an API shape

How to prepare

• Design the end-to-end claims data system aloud: ingestion, validation, a queue, processing workers, storage, a serving API, a dead-letter path and replay.
• Design the low-latency decision-support service: where a cache sits, what is precomputed, how you handle a cache miss and a downstream outage.
• Prepare a monitoring and logging plan for a distributed service: request rate, errors and latency, structured logs with a correlation id, traces across services, and alerts tied to a service-level objective.
• Practise drawing architectures on a whiteboard or digital canvas and narrating the why behind each box.

Where candidates lose points

Answering the API scaling question with a list of buzzwords (add a cache, add more servers) without locating the bottleneck

Open with measurement: where is time spent, is the database or a downstream call saturated, what do p95 and p99 latency look like. Then scale in order of cost: stateless horizontal scaling, query and index fixes, caching with an invalidation rule, rate limiting, pagination and moving slow work to a queue.

Saying 'eventual consistency' for the whole system without naming which data can be stale

Split the data. A claim's payment state needs a single source of truth, idempotency keys and conditional writes, while dashboards and BI views can lag. Name the mechanism for each: transactions within a service, an outbox or saga across services, and a version check for concurrent edits.

Designing the claims-processing system for the happy path only, with no bad-record handling, replay or access control

Add a validation stage that quarantines bad records into a dead-letter store, make every processing step idempotent so a batch can be replayed, keep an audit trail, and restrict and encrypt sensitive fields. Say how each choice supports the HIPAA-style concerns candidates list as nice-to-have knowledge.

Rewriting a whole snippet when asked for a minimal-change bug fix, or starting to code before the requirements are clear

Ask about input size, invalid data and expected behaviour first. For the debugging task, reproduce the failure, find the smallest change that fixes the cause, add a regression test and explain what you chose not to touch.

Choosing a database by brand name instead of by access pattern

Start from the queries: lookups by key, range scans, joins, write volume, consistency needs and growth. Then compare a relational store, a document or key-value store and a search or analytics store against those queries, and say what would make you switch.

Questions & practice

Given a dataset, write a function to optimize a specific processing task.

Medium · Coding & Problem Solving

Approach

1. Clarify the dataset and the task: size (fits in memory or not), format, whether it is sorted, duplicates and nulls, and the exact output. Then state the naive solution and its complexity out loud.
2. Find the dominant cost. Typical wins: replace a nested-loop lookup (O(n*m)) with a hash map or set built once (O(n + m)), sort once and do a single pass (O(n log n)) instead of repeated scans, and use a heap for top-k (O(n log k)).
3. Watch memory and I/O as well as CPU: stream records with a generator or chunked reads instead of loading everything, batch database or API calls instead of one call per row, and avoid building intermediate copies.
4. Keep it readable: small pure functions, clear names, and a test for the empty input, a single record, duplicates, malformed rows and a large input to check performance.
5. Mention what you would profile (cProfile or timing the hot loop) to confirm the bottleneck before optimising further, and where vectorised or parallel processing would help.

Follow-up

• The dataset no longer fits in memory. How does your solution change?
• Your hash map approach is slower than expected on real data. What could explain it?
• How would you make this function safe to rerun on a partially processed dataset?

Solve a binary-related algorithmic problem, prioritizing both readability and performance.

Medium · Coding & Problem Solving

Approach

1. Clarify which 'binary' it is: binary search over a sorted array or a monotonic answer space, bit manipulation, or a binary tree. The technique differs completely, so confirm before coding.
2. Binary search: keep a clear invariant (for example a half-open range [lo, hi)), compute mid as lo + (hi - lo) // 2, and decide whether you want the first index where a condition holds (lower bound) or an exact match. That runs in O(log n) time and O(1) space; test empty arrays, one element, duplicates and targets outside the range.
3. Binary search on the answer: when a predicate is monotonic (for example 'can this finish with capacity x?'), search the smallest x for which it is true. The cost is O(log(range) * cost of the check).
4. Bit manipulation: n & (n - 1) clears the lowest set bit (so a positive n is a power of two when it equals zero), x ^ x = 0 finds the single unpaired number in O(n), and counting set bits by repeatedly clearing the lowest one costs O(number of set bits).
5. Binary trees: choose recursion or an explicit stack, state O(n) time and O(h) space for the height h, and handle the empty tree and a skewed tree, where h equals n.

Follow-up

• Your binary search loops forever on some inputs. Why, and how do you fix it?
• How does your bit trick behave with negative numbers in your language?
• Could you solve it iteratively to avoid deep recursion?

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

How do you approach scaling an API to handle increased traffic?

Medium · Technical & Domain Knowledge

Approach

1. Measure before scaling: find which resource saturates first under load (CPU, database connections, a slow downstream call) using p50/p99 latency, error rate and throughput. A cache does not fix a missing index.
2. Keep the service stateless so it scales horizontally behind a load balancer. Sessions go in a token or a shared store, and autoscaling keys off a saturation metric, not request count alone.
3. Take reads off the database: cache-aside with a TTL for hot, rarely changing reads, read replicas for the rest, a connection pool sized against the database's max_connections, and indexes that match the slow query plans.
4. Move slow work off the request path. Accept the request, put it on a queue, return 202 with a status resource, and process it with workers that scale separately.
5. Protect the system at the edge with per-client rate limits (token bucket), pagination caps and request size limits, and return 429 with Retry-After instead of letting overload cascade.

Follow-up

• How do you keep the cache consistent after a write, and what happens if one key gets most of the traffic?
• Read replicas lag. How do you handle a client that writes and then reads its own data straight away?
• Which metric would make you shard the database rather than add more replicas?

What strategies do you use to identify and mitigate malicious data injection or system abuse?

Medium · Technical & Domain Knowledge

Approach

1. Separate the threat classes: injection (SQL, NoSQL, command, template), stored XSS through data rendered later, abuse of valid endpoints (scraping, credential stuffing, enumeration) and broken object-level authorization, where a valid user reads another user's records.
2. Against injection: bind parameters or an ORM for every query, never string concatenation. Validate input against an allowlist schema with types, lengths and enums. Encode output for the context it is rendered in, and never pass input to a shell or eval.
3. Against abuse: authenticate every call, check object-level ownership on every record fetch, rate limit per user, per key and per IP, cap request and payload sizes, and avoid sequential guessable identifiers where enumeration matters.
4. Detection: structured audit logs of who accessed which record, alerts on anomalies such as one account reading thousands of records or a spike in 4xx/401 responses, plus a WAF rule set for common payloads, which is a backstop and not the fix.
5. When the data includes health records, say how least privilege, encryption at rest and in transit, and access auditing limit the damage when a control fails.

Follow-up

• A user uploads a CSV that is later opened by an internal analyst. What can go wrong, and how do you neutralise it?
• How do you tell an aggressive but legitimate integration partner from a scraper?
• Your parameterized queries are in place. Where can injection still get in?

How do you ensure high availability and performance in a microservices architecture?

Medium · Technical & Domain Knowledge

Approach

1. Start from an SLO per user-facing path and do the availability arithmetic: serial dependencies multiply, so three services at 99.9% each give about 99.7% for a call that needs all three. That is the case for reducing synchronous hops.
2. Remove single points of failure: several instances across availability zones, health checks that separate liveness (restart me) from readiness (stop sending me traffic), and rolling or canary deploys with automatic rollback.
3. Contain failures between services: a timeout on every remote call, retries only on idempotent operations with exponential backoff and jitter plus a retry budget, circuit breakers that fail fast, and bulkheads (separate pools) so one slow dependency cannot use up every thread.
4. For performance, prefer asynchronous messaging where the caller does not need the answer now, cache at the right layer, avoid chatty N+1 calls between services (batch or aggregate endpoints), and watch p99, not the mean.
5. Plan degraded modes: serve stale cached data, hide a non-essential feature, or queue writes for later, and decide this per endpoint before an incident.

Follow-up

• Retries made an outage worse. What happened and how do you prevent it?
• How do you decide whether a call between two services should be synchronous or event-driven?
• How would you test that the circuit breaker settings actually work?

Explain how you would handle data consistency in a distributed system.

Medium · Technical & Domain Knowledge

Approach

1. Decide what consistency each piece of data needs. A balance or an authorization decision may need strong consistency, while a dashboard can tolerate seconds of staleness. Use CAP and PACELC to frame the trade-off: under a partition you pick availability or consistency, and otherwise you trade latency against consistency.
2. Inside one service, keep invariants in a single database transaction, and use optimistic concurrency (a version column checked in the UPDATE's WHERE clause, with a zero row count treated as a conflict) to catch lost updates.
3. Across services, avoid two-phase commit where you can, because a coordinator failure blocks participants. Use a saga instead: local transactions plus compensating actions, either orchestrated by one coordinator or choreographed through events.
4. Solve the dual-write problem with a transactional outbox. Write the state change and the event in the same transaction, relay the outbox to the broker, and make consumers idempotent (dedupe on event id), because delivery is at least once.
5. For replicated stores, explain quorum settings: with N replicas, read quorum R and write quorum W, R + W > N makes read and write sets overlap. Add read-your-writes techniques such as routing a user's reads to the leader for a short window after a write.

Follow-up

• A saga step fails after an earlier step has already notified an external party. How do you compensate?
• How do you detect and repair data that has drifted between two services?
• Events for the same entity arrive out of order. What do you do?

What are the trade-offs between different database technologies for your specific use case?

Medium · Technical & Domain Knowledge

Approach

1. Anchor the answer in one concrete use case and its access patterns: read/write ratio, query shapes (point lookups, range scans, joins, aggregations), consistency needs, data volume and growth, and the team's ability to run the system.
2. Relational databases such as PostgreSQL give ACID transactions, joins, constraints and mature indexing, and they handle semi-structured fields through JSONB. They are the default until a measured limit, usually write throughput or a single node's size, pushes you off.
3. Document stores fit aggregates read and written as one unit with a varying shape. Wide-column stores such as Cassandra fit very high write volumes with query-driven partition keys but weak ad hoc querying. Key-value stores fit caches, sessions and counters.
4. Analytical and reporting workloads belong in a columnar warehouse fed by a pipeline, not in the transactional database: columnar storage scans few columns over many rows cheaply, and row stores fit point reads and writes.
5. Name the cost of each choice: operational burden, losing joins or transactions, modelling around a partition key you cannot change later, and running more than one store with a sync path between them.

Follow-up

• When does a JSONB column stop being a good idea compared with proper tables?
• Your relational database is at its write limit. What do you try before switching technologies?
• How would you migrate a live table to a new store without downtime?

Design an end-to-end system for processing large-scale healthcare claims data.

Medium · System Design & Architecture

Approach

1. Clarify inputs and outputs first: how claims arrive (batch files such as X12 837 submissions over SFTP, or API calls), daily volume and peaks, latency needs (nightly batch or near real time), and who consumes the results (adjudication, analytics, payment review).
2. Pipeline: land raw files unchanged in immutable object storage, parse and validate into a canonical claim model, send rejects to a dead-letter store with reasons, enrich (member, provider, code lookups), run rules, and write to an operational store plus an analytics warehouse.
3. Make every stage idempotent and replayable. Key records on a stable claim identifier plus version so reprocessing a file does not double-count, treat corrected or voided claims as new versions rather than overwrites, and keep raw data so a parser fix can be backfilled.
4. Scale with a partitioned queue or stream keyed by claim or member id, which keeps ordering per entity while allowing parallelism. Batch large files into chunks with checkpointing so a failure resumes instead of restarting.
5. Health data controls: encryption in transit and at rest, least-privilege access, audit logs of who read which record, PHI kept out of logs, and data quality metrics (reject rate, late files, row counts per stage) with alerts.

Follow-up

• A malformed file arrives halfway through a batch. What happens to the records already processed?
• How do you backfill six months of claims after a rules change without disturbing live processing?
• Two versions of the same claim arrive out of order. Which one wins and how?

How would you architect a service that requires low-latency responses for clinical decision support?

Medium · System Design & Architecture

Approach

1. Set a latency budget for the calling workflow (say a p99 target) and split it across hops. Every synchronous dependency on the path has to fit inside it, which drives the rest of the design.
2. Keep the hot path small: rules or models loaded in memory and versioned, reference data and patient context precomputed or cached close to the service, parallel calls where they cannot be avoided, and no writes on the response path. Audit records go to a queue asynchronously.
3. Control tail latency: tight timeouts per dependency, hedged requests for idempotent reads, connection reuse, warm instances (no cold starts) and load tests that report p99/p999, not averages.
4. Choose the failure behaviour explicitly. In a clinical workflow a timeout should return a clear 'no recommendation, route to manual review' rather than a guessed answer, so define fail-safe defaults per decision type.
5. Make decisions traceable: record the input snapshot, rule or model version and output for each response so a recommendation can be explained and replayed later.

Follow-up

• Cached patient data is stale when a decision is made. How do you bound the risk?
• How do you roll out a new rule version without a latency spike or inconsistent answers?
• One downstream source is slow 5% of the time. What do you do?

Explain your strategy for observability and monitoring in a production environment.

Medium · System Design & Architecture

Approach

1. Start from what users experience: define SLIs and SLOs per critical path (availability, latency at p99, correctness), and alert on SLO burn rate rather than on every CPU spike.
2. Cover the three signals with a clear job each: metrics for trends and alerting (RED for services: rate, errors, duration; USE for resources: utilization, saturation, errors), structured logs with a correlation id for detail, and distributed traces (for example OpenTelemetry) for cross-service latency.
3. Control cost and noise: avoid high-cardinality metric labels such as user id, sample traces (keeping all errors and slow requests), set log levels and retention deliberately, and give every alert a runbook and an owner.
4. In a regulated data setting, keep PHI and secrets out of logs and traces through scrubbing at the logger, and restrict who can read raw logs.
5. Close the loop: dashboards per service, synthetic checks for critical endpoints, and postmortems that add the missing signal when an incident was found by a user rather than an alert.

Follow-up

• An alert fires at 3 a.m. and the on-call engineer cannot tell whether it matters. What do you change?
• Latency is up but every service dashboard looks green. How do you find the cause?
• How would you instrument an asynchronous queue-based workflow end to end?

How do you design for failure in a cloud-native environment?

Medium · System Design & Architecture

Approach

1. Assume every component fails: instances, a whole availability zone, managed services, the network between them. List the failure modes per dependency and decide the behaviour for each.
2. Redundancy and statelessness: run across zones, keep state in replicated managed stores, autoscale on saturation, and use immutable deploys with health-checked rollouts and fast rollback.
3. Isolate failures with timeouts, bounded retries with exponential backoff and jitter, circuit breakers, bulkheads, and queues that absorb bursts and let consumers catch up. Make handlers idempotent, since retries and redelivery will happen.
4. Plan for data loss and disaster: set RPO and RTO per dataset, take backups and actually test restores, and decide whether cross-region failover is worth its cost and consistency trade-offs.
5. Prove it: run game days or fault injection (kill an instance, add latency to a dependency), and verify alerts fire and degraded modes work before a real incident tests them.

Follow-up

• How do you avoid a retry storm when a dependency recovers?
• What is your RPO and RTO for the most important data, and what does meeting them cost?
• How would you handle a managed queue or database being unavailable for an hour?

Implement an API endpoint that handles complex input validation.

Medium · Coding & Problem Solving

Approach

1. Define the contract first: request schema with types, required and optional fields, formats, ranges and enums, plus the error response shape (for example RFC 9457 problem details with a field path and message per error).
2. Validate in layers: syntactic validation at the boundary with a schema library (Pydantic, JSON Schema or similar), then semantic and cross-field rules (end date after start date, a code valid for the given type), then checks that need the database, such as whether a referenced record exists and belongs to the caller.
3. Return all field errors at once rather than the first, use 400 for malformed requests and 422 for well-formed but invalid content (or one convention consistently), and never echo back raw input that could be rendered unsafely.
4. Harden the endpoint: reject unknown fields or ignore them explicitly, cap body size and array lengths, normalise input (trim, canonical case and dates) before validating, use bind parameters for queries, and support an idempotency key on create operations so retries do not create duplicates.
5. Keep validation testable: pure validator functions with table-driven tests for each rule, boundary values, missing fields and wrong types, separate from the handler.

Follow-up

• A validation rule depends on data that can change between validation and write. How do you avoid acting on stale checks?
• How do you evolve the schema without breaking existing clients?
• Where would you put a rule that several endpoints share?

Debug a snippet of code and explain the most efficient way to resolve the issue.

Medium · Coding & Problem Solving

Approach

1. Reproduce first: find the smallest input that shows the wrong behaviour, and state expected versus actual output before touching the code.
2. Read the snippet for the usual bug classes: off-by-one errors in loops and slices, wrong comparison or boundary conditions, mutable default arguments in Python (a list default is shared across calls), mutating a collection while iterating over it, integer or float precision issues, and unawaited or racing asynchronous calls.
3. Confirm the hypothesis cheaply with a targeted print, assertion or debugger breakpoint at the point where the state first goes wrong, rather than changing several things at once.
4. Make the smallest fix that addresses the root cause rather than the symptom, explain why it works, and add a regression test with the failing input.
5. Then mention complexity or design problems seen along the way, such as a quadratic loop or shared mutable state, separately from the bug fix.

Follow-up

• The bug only appears under concurrent requests. How do you find it?
• How do you know your fix did not break another caller of this function?
• If you could change more than the minimal fix, what would you refactor?

Suggested practice checklist

The plan follows the four reported rounds and the thirteen reported questions: the recruiter conversation first, then concept questions, design, failure and observability, coding, and finally the cultural round with a full mock. Each day ends with something you can reread before the loop.

Day 1 — Map the loop and write your track statement

• Write out the four reported rounds (Recruiter Engagement, Technical Evaluation, Cultural Fit Assessment, Final Technical Evaluation) and note which one you feel least ready for.
• Write a short statement of your strongest track (backend, frontend or architecture) with two projects that show distributed systems or cloud work.
• Write the questions you will ask the recruiter: which rounds are coding and which are design, whether the loop changes with seniority, and what the team builds.

Deliverable: A one-page loop map, a track statement with two projects, and a list of recruiter questions.

Day 2 — Scaling an API and availability in microservices

• Write a bottleneck-first scaling ladder for an API: measure, fix queries and indexes, scale stateless instances, add caching with an invalidation rule, rate limit, paginate and move slow work to a queue.
• Write an availability checklist for a microservice call chain: timeouts, retries with backoff and jitter, circuit breakers, bulkheads, health checks, redundancy across zones and a service-level objective.
• Answer both questions aloud and record yourself, then cut anything that is a buzzword without a mechanism.

Deliverable: Two one-page answer outlines (API scaling, microservice availability) and a recording of each spoken answer.

Day 3 — Consistency, databases and abuse prevention

• Build a table of three data types a claims platform handles, with the store you would choose, the consistency each needs and the query that drove the choice.
• Outline a consistency answer: idempotency keys, an outbox for cross-service events, a saga for multi-step workflows and optimistic version checks for concurrent edits.
• List defences against malicious data injection and abuse: input validation and parameterised queries, schema checks at the edge, rate limits, authentication and per-client quotas, anomaly alerts.

Deliverable: A storage-choice table, a consistency outline and an abuse-defence list, each tied to a claims example.

Day 4 — System design: claims pipeline and low-latency service

• Design the end-to-end claims data system on paper: ingestion, validation, queue, workers, storage, serving API, dead-letter path and replay, with a partition key and the query it makes expensive.
• Design the clinical decision support service for low latency: what is precomputed, where the cache sits, the behaviour on a miss and the fallback when a dependency is down.
• Narrate each design aloud, naming one trade-off per component.

Deliverable: Two annotated diagrams, each with scale numbers you assumed, failure paths and a trade-off list.

Day 5 — Failure design and observability

• Write an observability plan for the claims pipeline from day 4: request rate, errors and latency metrics, structured logs with a correlation id, distributed traces and alerts tied to a service-level objective, with no sensitive fields in logs.
• List the failures a cloud-native service must survive (instance loss, zone outage, slow dependency, bad deploy, poison message) and the response to each: retries, circuit breaking, graceful degradation, rollback and dead-lettering.
• Practise answering both questions in a few minutes each, with one concrete incident example from your own work.

Deliverable: A one-page observability plan and a failure-mode table for the day 4 design.

Day 6 — Coding: data processing, debugging and validation

• Solve a data-processing optimisation problem: state the brute force, improve it with a hash map or sort, give time and space complexity, and list edge cases (empty input, duplicates, huge input).
• Take a buggy snippet, reproduce the failure, make the smallest fix and add a regression test. Solve one binary-related problem each in bit manipulation, binary search and binary trees.
• Implement an API endpoint with complex validation: type checks, cross-field rules, a consistent error shape and tests.

Deliverable: Working code with tests for the data task, the bug fix, the binary problems and the validated endpoint, each with a complexity note.

Day 7 — Cultural fit stories and a full mock

• Write three stories in situation, decision, trade-off, result form: a code review disagreement, mentoring an engineer and meeting a deadline by deferring something deliberately.
• Run one full mock design (claims pipeline or low-latency service) aloud from clarifying questions to observability, then list what you skipped.

Deliverable: Three written stories, a recorded mock design and a list of the three gaps to fix before the loop.

Stories for the cultural fit round

Candidates report a Cultural Fit Assessment with potential teammates. The role as described includes working with product managers and clinicians, reviewing code, mentoring junior engineers and joining architecture discussions, so stories from those situations transfer best. Each story should show a decision you made, the trade-off you weighed and what happened, with your own part clear.

1. Tell me about a time you explained a complex technical trade-off to a non-technical stakeholder. What did they decide?
2. Describe a disagreement with a teammate in a code review or design discussion. How did it end, and what would you change?
3. Tell me about mentoring a junior engineer through a hard problem. What did you leave them to own?
4. Describe a time you had to learn unfamiliar business rules to build the right thing.
5. Tell me about a deadline you met by deferring something on purpose. How did you bound the risk and record it?
6. Describe a production incident you owned from detection to follow-up. What changed afterwards?

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach

1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.

Follow-up

• Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
• The author says clients cannot handle a 409. How do you check whether that is true?

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

• How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
• Their handler calls an external endpoint before recording that it did. What do you tell them to change first?

Ship under a deadline and bound the debt you chose

Medium · pagination · technical debt · tradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach

1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.

Follow-up

• At what page depth does the offset version breach your latency budget, given your page size and row counts?
• What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?