Capital City Talent Solutions Software Engineer Interview Guide

The 60-second brief

Candidates describe Capital City Talent Solutions as an employer whose engineering work sits on healthcare data infrastructure. The reported work includes backend services that analyse large datasets spanning thousands of healthcare providers, and AI-driven workflows that automate medical review. The Software Engineer role is described as owning the architecture of those services and working with product leadership on technical direction. No specific product names or customers are reported, so prepare against the kind of work described: high-volume clinical data, external data sources, automated review steps, and the reliability, security and performance demands that come with them.

This guide is for engineers preparing for the Software Engineer loop at Capital City Talent Solutions. The requirements candidates describe list six or more years of backend experience, Python or TypeScript, deep AWS knowledge and a history of designing distributed systems; healthcare or AI/ML integration experience is described as a bonus. It covers the three reported rounds, all ten reported questions with the structure a strong answer takes, a seven-day plan, behavioral prompts and a short FAQ.

Candidates report three rounds spread over roughly three to five weeks: Recruiter Screening, Technical Deep Dives and Leadership Discussions. Formats, durations and interviewers within each round are not reported, so confirm them with your recruiter.

Focus areas

• Distributed Systems
• System Architecture
• AWS

Overview

The work candidates describe is backend engineering where mistakes are expensive: clinical records arriving from many external providers, services that analyse them at volume, and automated review steps driven by AI. For preparation this means reliability questions deserve concrete answers. Know what happens to a record when a consumer crashes, when a provider sends it twice, when a dependency is slow, and when a model output is wrong. Reported topic areas are distributed systems, system architecture, AWS, production-grade backend engineering and Python.

The ten reported questions fall into two groups. Five are design and technical questions: fault-tolerant design on AWS with low latency, trade-offs between database architectures for clinical data, meeting compliance and security requirements in code, real-time processing of medical data from thousands of external providers, and an AI-integrated workflow that needs high decision accuracy. The other five are experience questions: optimizing a service for throughput, handling failure states without data loss, navigating technical ambiguity, raising the engineering bar through design reviews or mentorship, and influencing product strategy through technical insight. Several are phrased as "have you done this" rather than "design this", so answers need real production examples with numbers you can defend.

The requirements candidates describe stress seniority: six or more years of backend work, a record of scalable distributed systems, and product sense. Make your resume and stories show distributed systems and scaling work specifically, since generic backend experience is described as not enough for the level.

The Capital City Talent Solutions interview process

These are the three stages candidates describe, in the order they report them. Confirm formats and who you will meet with your recruiter, because those details are not reported.

Recruiter Screening

Candidates report this first stage as a recruiter conversation about how your background lines up with current openings and about your past experience. Candidate-facing advice says to be ready to discuss earlier projects in detail, because they come up again in later rounds. Treat it as the place to set up your strongest stories: pick the projects where you owned a distributed system, a scaling problem or a mentoring outcome, and be able to say what you built, the numbers involved and your own part in it.

What to demonstrate

• How your experience maps to the openings that are currently available
• Your account of past projects and what you personally owned
• Your goals and what you want from the next role

How to prepare

• Write a two-minute career narrative that ends on backend and distributed-systems work, plus one honest sentence on why healthcare data interests you.
• List five projects with scale, your role and one measured result each, and note which of the ten reported questions each could answer.
• Confirm with the recruiter whether you will code in Python or TypeScript and how the later rounds are structured.

Technical Deep Dives

Candidates describe Technical Deep Dives as in-depth technical interviews covering your technical capability and product sense. Reported technical themes include distributed systems, AWS, system architecture and production-grade backend engineering. The design questions here are open-ended, so the work is to structure them: requirements and failure modes first, then components, then trade-offs. The design and technical questions candidates report (AWS fault tolerance, database choice, compliance, provider ingestion, the AI workflow) are the ones to rehearse for this stage.

What to demonstrate

• Technical capability on backend and distributed-systems problems
• Product sense: tying a technical choice to its user or business effect
• Ability to explain trade-offs while designing

How to prepare

• Rehearse the provider-ingestion design end to end: intake, durable buffer, validation, idempotent processing, storage, replay and monitoring.
• Prepare the database-architecture answer as access patterns first, then relational versus key-value versus document versus analytical stores, with consistency needs for clinical data.
• Practise writing clean Python or TypeScript without autocompletion, including async pitfalls such as un-awaited calls and unhandled errors in tasks.
• Prepare a concrete answer on compliance and security: encryption, least-privilege access, audit logging and keeping sensitive fields out of logs.

Leadership Discussions

Candidates describe Leadership Discussions as conversations about how you work in a fast-paced, collaborative team. The reported behavioral and leadership questions cover technical ambiguity, raising the engineering bar through design reviews or mentorship, and influencing product strategy through technical insight; candidate-facing advice recommends the STAR structure. Expect your stories to carry the stage, so prepare each as a specific decision with a result, not a general philosophy.

What to demonstrate

• Ownership of projects and the quality of your team's output
• Mentorship and design-review practice
• Working with product partners and handling shifting priorities

How to prepare

• Write five STAR stories and tag each to the reported prompts: ambiguity, raising the bar, influencing product, throughput, and a failure-handling incident.
• For each story, prepare the numbers (before and after), the person you disagreed with or helped, and what you would change now.
• Prepare two questions about how engineering and product decide technical direction and how design reviews run.

Where candidates lose points

Answering the fault-tolerance question on AWS with a list of services instead of failure modes

Start from what can fail (an instance, an availability zone, a dependency, a region) and what the user sees when it does. Then pick services, and say what redundancy costs in latency: cross-zone hops, synchronous replication and retries that inflate tail latency.

Promising zero data loss without defining it

State the durability point (success is returned only after a replicated write), your recovery point objective, how retries stay idempotent, and what you cannot cover. Add reconciliation to detect loss that slipped through.

Naming a database before the access patterns in the clinical-data trade-off question

Lead with read and write patterns, consistency needs, query shapes, audit and retention needs, and volume. Then compare relational, key-value, document and analytical stores against those, and say where you would combine them.

Treating the AI-integrated workflow question as only a model-quality problem

Design the decision path: confidence thresholds, routing uncertain cases to human review, an audit trail of inputs, outputs and model version, accuracy measured on labelled cases, and a safe fallback when the model is unavailable.

Telling leadership and throughput stories with no baseline, no named person and no result

Open each story with a measurable before state, say what you personally decided or did, name the colleague or stakeholder involved, and end with a concrete after state and one thing you would change.

Questions & practice

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?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

1. Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
2. Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
3. Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
4. Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

• The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
• The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

1. Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
2. For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
3. Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
4. Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

• 90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
• A dashboard runs this for 40 owners in one page load. What changes about the design?

How have you designed fault-tolerant systems on AWS to ensure low latency?

Medium · Technical and Domain Expertise

Approach

1. Anchor the answer in one real system. State the latency target as a percentile (p99, not the average) and the failures you designed for: a single instance, an Availability Zone, a downstream dependency, or a whole region.
2. Describe the redundancy layer. Stateless services run in an Auto Scaling group across at least two AZs behind an Application Load Balancer with health checks. Data sits on RDS or Aurora Multi-AZ (a synchronous standby with automatic failover) or on DynamoDB, which replicates across AZs. Say what still breaks: a failover drops in-flight connections, so clients must reconnect and retry.
3. Explain how you kept latency low while things were failing. Set per-call timeouts inside the caller's latency budget. Retry with exponential backoff and jitter, and only on idempotent operations. Add a circuit breaker to fail fast on a sick dependency, and separate connection pools so one slow dependency cannot exhaust every thread.
4. Cover the read-path latency levers and their costs. ElastiCache read-through with a TTL means bounded staleness. Read replicas mean replica lag. CloudFront only helps cacheable responses. Multi-region active-active cuts user latency, but it adds conflict handling and roughly doubles the infrastructure.
5. Close with how you proved it worked: CloudWatch alarms on p99 latency and error rate, load tests at peak traffic, and fault injection (AWS Fault Injection Service or a game day where you kill an instance or block a dependency), including the metric that moved.

Follow-up

• What happens to your p99 during an AZ failover, and how do clients behave while the database standby is promoted?
• How do you stop retries from turning a slow dependency into a retry storm that takes everything down?
• How did you choose the timeout values, and what happens if a downstream timeout is longer than the upstream one?

What are the trade-offs when choosing between different database architectures for clinical data?

Medium · Technical and Domain Expertise

Approach

1. Start from access patterns and constraints, not product names. Examples: reading one patient's record by id, longitudinal queries over a patient's history, analytics across many providers, audit of who read what, retention rules, and correcting a record without losing the original.
2. Relational (PostgreSQL or Aurora): ACID transactions, foreign keys and joins fit linked entities like patients, encounters, orders and results, and ad-hoc queries are easy. The cost is that write scaling past one primary needs partitioning or sharding, and schema migrations on large tables need care (add nullable columns, backfill in batches).
3. Document or key-value store (DynamoDB or MongoDB): it handles heterogeneous payloads such as FHIR JSON resources and scales single-key reads and writes horizontally. The trade-off is that you design keys around known queries up front, and joins, ad-hoc queries and multi-item transactions are limited or costlier.
4. Analytical store: keep OLTP separate from cross-provider analytics with change data capture into a columnar warehouse (Redshift) or Parquet on S3 queried with Athena. You accept some staleness to avoid heavy scans on the transactional database.
5. Cross-cutting requirements: append-only versioning or an event log so corrections keep history, encryption at rest with KMS, point-in-time recovery, and a tenant-isolation choice (shared tables with a provider id, schema per tenant, or database per tenant) that trades isolation against operational cost.

Follow-up

• A lab result was entered with the wrong value. How does your schema store the correction while keeping what clinicians saw at the time?
• How would you add a column or change an index on a table with hundreds of millions of rows without downtime?
• Where would you enforce that one provider can never read another provider's data: in the application, in the database, or in both?

How do you ensure your code meets strict compliance and security requirements?

Medium · Technical and Domain Expertise

Approach

1. Turn the requirement into concrete controls before talking about code. Classify the data (which fields are personal or health data), then map each class to controls: least-privilege access, encryption in transit and at rest, audit logging, retention and deletion. Where US health data is involved, regulations such as HIPAA set the baseline.
2. Coding practices: use bind parameters (never string-built SQL), validate input at every boundary with a schema (pydantic in Python, zod in TypeScript), put authorization checks in one shared layer rather than in each handler, and keep secrets out of code by loading them from AWS Secrets Manager or Parameter Store.
3. Logging is a common leak. Use structured logs with field-level redaction so identifiers and record contents never reach log storage. Keep an application-level audit trail of who accessed which record, separate from debug logs and write-once.
4. Automate the guard rails in CI so they do not depend on reviewer memory: static analysis (Bandit or Semgrep for Python, ESLint security rules for TypeScript), dependency scanning (pip-audit, npm audit, Dependabot), secret scanning, and infrastructure-as-code checks. Fail the build on high-severity findings.
5. On the infrastructure side: an IAM role per service with least privilege, KMS-managed keys, TLS everywhere, private subnets for data stores, and CloudTrail for API audit. Back the code with authorization tests that check each endpoint refuses cross-tenant or unauthenticated access.

Follow-up

• An auditor asks you to prove a control actually ran last quarter. What evidence does your setup produce?
• A critical vulnerability lands in a dependency that has no patched version yet. What do you do?
• How do you make sure a newly added endpoint cannot skip the authorization check?

How would you architect a system to process real-time medical data from thousands of external providers?

Medium · System Design and Architecture

Approach

1. Clarify first: which formats providers send (HL7 v2 messages, FHIR REST calls, batch files over SFTP), message volume at peak, the end-to-end latency target, whether per-patient ordering matters, and what 'processed' means downstream. Then do a quick throughput estimate.
2. Ingestion edge: per-protocol adapters behind API Gateway or a load balancer, with each provider authenticated (mTLS or per-provider credentials). Persist the raw payload durably (for example to S3) before acknowledging it, then publish to a stream (Kinesis or Kafka on MSK). Partitioning by patient id keeps per-patient ordering. Partitioning by provider is simpler but lets one large provider create a hot partition.
3. Processing: consumers normalise each message into one canonical model. Delivery is at-least-once, so make writes idempotent with a dedup key such as provider id plus the message's own control id. Send messages that fail validation to a dead-letter queue with tooling to inspect, fix and replay them.
4. Isolation and backpressure: per-provider rate limits and quotas so one noisy sender cannot starve the rest, consumers that autoscale on stream lag (iterator age), and buffering in the stream instead of rejecting senders when downstream slows.
5. Operations: keep the raw archive so you can reprocess after a mapping bug, and keep per-provider dashboards for lag, error rate and schema-drift alerts. Onboarding a new provider should be configuration plus a mapping, not a new service.

Follow-up

• A provider resends a full day of messages after an outage on their side. What happens in your system?
• A provider changes its message format without notice. How do you detect it and avoid losing data?
• Updates for the same patient arrive out of order. How do you make sure the stored state ends up correct?

Describe your approach to building an AI-integrated workflow that requires high decision-making accuracy.

Medium · System Design and Architecture

Approach

1. Define the decision and the cost of each error before choosing a model. In a medical review, a wrong auto-approval and a wrong denial have different costs. Pick metrics that reflect this (precision and recall at the operating threshold, calibration) and build an evaluation set labelled by domain experts.
2. Treat the model as one step in an explicit workflow (AWS Step Functions or a queue-driven state machine). Auto-apply only above a calibrated confidence threshold and send low-confidence or high-risk cases to human reviewers. For each case, store the input, model version, output, confidence and final human decision for audit and for retraining.
3. For LLM components, constrain the output: a structured response validated against a schema, answers grounded in retrieved source documents with citations, deterministic rule checks as guard rails, and a bounded retry on malformed output before escalating to a person.
4. Roll out in stages: run in shadow mode and compare against human decisions, then ramp gradually. In production, monitor input drift, reviewer override rate and the agreement rate on a random audit sample, because ground truth often arrives late.
5. Failure handling: if the model times out or is unavailable, the case falls back to the manual queue and is never silently approved. Make every workflow step idempotent so a retry cannot apply the same decision twice.

Follow-up

• How would you pick the confidence threshold, and who should sign off on it?
• Ground-truth outcomes arrive weeks later. How do you detect that accuracy has dropped before then?
• Reviewers start accepting the model's suggestion almost every time. How would you notice that and respond?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.

Approach

1. Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
2. Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
3. Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
4. The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.

Follow-up

• Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
• How would you have detected this before an OOM, given the nightly restart masked the trend?

Suggested practice checklist

Built from the three reported rounds, the ten reported questions and the stack candidates describe (AWS, Python or TypeScript, distributed systems).

Day 1 — Recruiter call and project inventory

• Write and say aloud a two-minute career narrative that leads with backend and distributed-systems work and gives a reason for wanting healthcare data work.
• List five past projects with scale, your role and one measured result each, and map each to the reported questions it could answer.
• Write the questions you will ask the recruiter about round formats and the language you will code in.

Deliverable: A written narrative, a five-project inventory mapped to the reported questions, and a list of recruiter questions.

Day 2 — Fault tolerance, latency and database choice

• Outline an answer on fault-tolerant, low-latency design on AWS: failure domains, redundancy across zones, timeouts, retries with jitter and a circuit breaker, and the latency cost of each.
• Write a one-page comparison of relational, key-value, document and analytical stores for clinical data, organised by access pattern and consistency need.

Deliverable: An outline of the fault-tolerance answer, a one-page database comparison, and a working solution to the rolling failure-rate exercise.

Day 3 — Provider ingestion and zero data loss

• Draw the architecture for real-time ingestion from thousands of external providers: intake endpoint, durable queue, validation, idempotent processing, storage, dead-letter queue and replay.
• Write out the failure-state answer: acknowledgement point, outbox pattern, offset commit order, reconciliation and recovery point.

Deliverable: A labelled ingestion diagram, a written failure-state answer, and solutions to the idempotency-fingerprint and stream-merge exercises.

Day 4 — AI-integrated workflow and compliance

• Design the decision path for an AI-integrated review workflow: confidence thresholds, human review queue, audit trail, accuracy measurement and a fallback when the model is down.
• Write a checklist answer on compliance and security in code: encryption, least-privilege access, audit logging, secrets handling, input validation and sensitive fields kept out of logs.
• Practise the same answers aloud without notes and trim each to a structure you can say clearly.

Deliverable: A decision-path diagram for the AI workflow, a security checklist, and a recorded spoken answer for each of the two questions.

Day 5 — Throughput story and data-layer debugging

• Write the throughput optimization story with baseline, diagnosis, change, verification and final numbers.

Deliverable: A written throughput story with numbers, solved SQL exercises, and a written diagnostic sequence for the memory-growth case.

Day 6 — Leadership stories

• Write STAR stories for navigating technical ambiguity, raising the engineering bar through design reviews or mentorship, and influencing product strategy through technical insight.
• For each story, add the numbers, the named colleague or stakeholder, and one thing you would change.
• Rehearse each story aloud and cut it until the decision and the result take up most of the time.

Deliverable: Three finished STAR stories with numbers and a stated lesson, plus a spoken recording of each.

Day 7 — Full mock run

• Answer aloud, in one sitting, the fault-tolerance question on AWS, the provider-ingestion design and one leadership story, then compare against your written outlines.
• Rehearse the open scenarios candidates report for scaling a backend 10x and for refactoring a legacy service, and the common pitfalls of asynchronous code in your chosen language.
• List the three weakest answers and rework each once more.

Deliverable: A recorded mock run, a list of three weak answers, and a reworked version of each.

Leadership and production stories

The behavioral and leadership questions candidates report centre on technical ambiguity, raising the engineering bar through design reviews or mentorship, and influencing product strategy through technical insight. Two further reported questions, on throughput optimization and on handling failure states, are best answered with real production examples. Prepare each as a specific decision with numbers and a result, using the STAR structure.

1. Describe a time you improved the quality of your team's output and how you measured it.

Can you describe a time you optimized a backend service for high throughput?

Medium · Technical and Domain Expertise

Approach

1. Pick one service you personally tuned and open with its measured baseline: requests per second, p50 and p99 latency, CPU or database load. Without a baseline the story has no result.
2. Show the diagnosis, not just the fix: tracing or profiling that located the bottleneck (N+1 queries, a missing index, serialization cost, lock contention, a synchronous downstream call, connection-pool limits).
3. Name the change and why it fit: batching, caching with a clear invalidation rule, async or queue-based decoupling, an index or query rewrite, bounded concurrency. Say what it cost in complexity or staleness.
4. Prove the effect: a load test against the same workload before and after, a canary rollout, and the final numbers. Separate throughput gains from latency effects.
5. Close with what you would do differently and how you made sure nothing regressed under failure, such as timeouts and backpressure.

Follow-up

• How did you know that bottleneck, and not another one, was the limiting factor?
• What did the optimization cost you in consistency, complexity or operations?
• What happened to tail latency and error rate under the new load?

How do you handle failure states in a distributed system to ensure zero data loss?

Medium · System Design and Architecture

Approach

1. Define the claim first: zero loss means no acknowledged write is lost. Name the durability point (the moment you reply success) and what RPO you are designing to, and be honest about what a single design cannot cover, such as correlated regional failure under asynchronous replication.
2. Make the durable write precede the acknowledgement: persist to a replicated store or durable queue across availability zones, and only then return success. Use the transactional outbox pattern to avoid losing events between a database write and a publish.
3. Use at-least-once delivery with idempotent consumers: a stable idempotency key, deduplication on write, and offsets or checkpoints committed after processing, not before. Retries use backoff with jitter and a cap.
4. Handle poison and overflow cases: a dead-letter queue with alerts and a replay tool, bounded queues with backpressure, and per-record failure isolation so one bad record does not block the stream.
5. Detect silent loss: reconciliation jobs comparing counts or checksums between source and sink, point-in-time recovery for the datastore, and alarms on consumer lag. If you tell this as a story, anchor it in a real incident and what you changed afterwards.

Follow-up

• The consumer crashes after processing a record but before committing its offset. What happens, and why is that acceptable?
• How would you discover that records were silently dropped last week?
• What does stronger durability cost in latency and availability, and where would you relax it?

Tell me about a time you had to navigate technical ambiguity to deliver a project.

Medium · Behavioral and Leadership

Approach

1. Choose a project where the goal, the requirements or the technical path were genuinely unclear, not one where a ticket merely lacked detail. State what was unknown in one or two sentences.
2. Show how you made ambiguity smaller: questions you asked stakeholders, assumptions you wrote down and had confirmed, and the riskiest unknown you attacked first with a spike, prototype or measurement.
3. Explain how you decided with incomplete information: the options you listed, the criteria you used, what was reversible versus costly to undo, and the checkpoint where you would change course.
4. Describe delivery in increments and how you communicated uncertainty to partners, so people were not surprised. End with the result and one assumption that turned out wrong.
5. The mistake that sinks this story is waiting for someone to clarify things, or telling it with no decision and no outcome.

Follow-up

• Which assumption turned out to be wrong, and how did you find out?
• What did you decide not to build, and who disagreed?
• How did you tell stakeholders what you did not yet know?

How do you raise the engineering bar in your team through design reviews or mentorship?

Medium · Behavioral and Leadership

Approach

1. Give both halves with concrete evidence. For design reviews: a written design template covering goals, non-goals, alternatives considered, failure modes and rollout, and review comments that state the reason and mark blocking versus optional.
2. For mentorship: name one person, their starting gap, what you did (pairing, a stretch assignment, structured feedback, reading their reviews) and the observable result, such as them leading a design alone.
3. Add a team-level mechanism with an effect you can point to: a review checklist, a lint or CI rule, a rotation for reviewers, or a post-incident review habit, and what changed afterwards (fewer rollbacks, faster reviews, fewer repeated defects).
4. Keep the focus on the team's output rather than your own catches. Describe a disagreement in a review and how it was resolved with evidence rather than seniority.
5. The mistake that sinks it is a list of rituals with no outcome, or a story where you are the gatekeeper who fixed everyone's mistakes.

Follow-up

• A senior colleague pushes back on your review comment. How do you handle it?
• How do you review a design that is workable but not how you would do it?
• How do you know the mentoring or the review practice actually worked?

Describe a situation where you had to influence product strategy through technical insight.

Medium · Behavioral and Leadership

Approach

1. Pick a case where technical knowledge changed a product decision: a measured cost or latency limit, a reliability risk, a prototype showing something was feasible or not, or data about how the system was really used.
2. Translate the insight into product terms before you present it: user impact, risk, cost and delivery time, plus two or three options with trade-offs rather than a single demand.
3. Show how you built the case: the numbers, a small prototype or analysis, early conversations with the product partner to understand their constraints, and a clear ask.
4. State the outcome honestly, including partial wins or being overruled, and how you proceeded afterwards. If you have regulated or sensitive-data experience, a case where a compliance or accuracy constraint shaped scope fits well.
5. The mistake that sinks it is a story about being right and a product partner being wrong. It should show a shared decision and a result you measured.

Follow-up

• What if the product partner disagreed even after seeing your data?
• What did your recommendation cost the roadmap?
• How did you check afterwards that the changed decision was the right one?