Interview guides · CVS Health

CVS Health Software Engineer Interview Guide

CVS Health software engineer prep on databases: indexes, query plans, and the anomalies an isolation level still permits.

The 60-second brief

As a Software Engineer at CVS Health, you play a vital role in shaping and enhancing technological solutions that improve healthcare delivery and patient outcomes. Your work impacts millions of users, from customers seeking health services to healthcare professionals requiring efficient tools for patient management. In a rapidly evolving industry, the ability to design and implement innovative software solutions is paramount to maintaining CVS Health’s competitive edge and commitment to customer-centric care.

Browser-facing seats are not covered by algorithm practice. Scope in state ownership, what the page does on a slow or failed request, and how you would diagnose something that renders correctly but feels slow.

Focus areas

Design person merges that remain reversible afterwards
Hold accumulator limits under concurrent claim adjudication
Version clinical results instead of updating rows in place

Overview

This role is critical not only for product development but also for the strategic influence it holds within the organization. You will be involved in various projects that leverage technology to streamline operations, enhance user experiences, and ultimately contribute to the broader mission of making healthcare more accessible. Expect to collaborate with cross-functional teams, tackling complex challenges that require both technical acumen and a deep understanding of user needs.

The CVS Health interview process

CVS Health candidates report 3 rounds · ≈ 3-5 weeks. The stages below are what candidates describe, not a published process.

Phone Screening

Half of this call is the part candidates treat as small talk: start date, notice period, work authorisation and its timing, location and time zone, on-call, and the number. Those are what kill offers late, after several engineers have each spent a day. Surfacing a hard constraint now costs you nothing and occasionally buys you something, since a loop compressed to fit a competing deadline can usually only be arranged if it is asked for early. The common failure is deflecting the compensation question twice, then discovering at offer stage that the band never reached your number.

What to demonstrate

Whether your hard constraints are compatible with the role before a loop gets booked: earliest start, notice period, what authorisation you hold and when it needs action, days on site, willingness to carry a pager
Whether you give a compensation range with something behind it, such as current total compensation or a competing timeline, rather than leaving the band untested
Whether your stated timeline is real, since a competing deadline raised now is something scheduling can sometimes work around and the same deadline raised at offer stage usually is not

How to prepare

Write each constraint down in one line before the call and state them as facts rather than negotiating them live under a question you were not expecting
Set your range from two or three current data points for that level and location, and name the structure you are quoting in, so the number is comparable to the one they are holding
If another process is running, say where it stands and by when, and ask directly whether this loop can be scheduled inside that window

Technical Interviews

The same problem is scored by two different mechanisms depending on the format, and preparing for one does not cover the other. With a person watching, partial progress is visible and a hint is a correction you can absorb; silence is the expensive failure, because nobody can read a half-written function. With an automated grader there is no partial credit for what you were about to do, nobody to ask, and the worked examples in the prompt are the entire specification. Read them as a contract, down to whether an empty result should be an empty list or no output at all.

What to demonstrate

In a live session, whether your commentary tracks what your hands are doing, and whether a hint redirects you or gets defended against
In an automated one, whether you cover the cases the examples do not show, since the hidden cases are where the score moves
Whether you manage the clock on purpose: abandoning an approach that is not converging while there is still time to write something simpler that finishes

How to prepare

Have someone hand you a problem and feed you one deliberately wrong hint. Practise testing it against a concrete case instead of accepting or rejecting it on authority.
Do one timed run a week in a plain browser editor with autocomplete, linting and your own snippets switched off, which is closer to what these environments give you
For the automated format, write the harness before the solution: a main that feeds the worked examples plus an empty and a single-element case and prints expected against actual, so a wrong submission is caught by you first

Behavioral Assessments

Your first answer is not really what is scored. It buys the follow-up questions, and those decide the round. An interviewer with fifteen minutes takes one thread and pushes on it four or five times, so a story you can only tell at a single level of detail collapses under the third why. That is an argument for fewer stories known deeply rather than one prepared per prompt. Four or five pieces of work you can still explain down to the code you changed and the argument you had about it will cover nearly anything asked in this round.

What to demonstrate

Whether a story holds as the questioning moves from what you did to why that instead of the alternative, and then to what you would change knowing what you know now
Whether you can re-cut a project to answer the question actually asked rather than delivering a rehearsed block that answers an adjacent one
Whether your level of detail is chosen rather than habitual: going down to the schema when the question is about the data model, staying out of it when the question is about the person who disagreed with you

How to prepare

Pick four projects and write the chain out four levels deep for each: what you did, why that, why not the alternative, and what would have to be true for the alternative to have won. Where you cannot reach the fourth level, you have a placeholder rather than a story
Have someone ask why three times in a row on a single thread with nothing else added, and mark the point where you start repeating a sentence you already said. That point is where the interviewer stops learning anything
Build a one-page index instead of an answer bank: the common prompts in this round (disagreement, a failure that was yours, thin requirements, a deadline you missed, work you inherited) mapped to which of your four projects you would use for each, so the choosing is done now rather than while an interviewer waits

Where candidates lose points

Upserting on the order or result identifier, so a correction overwrites the original row.

It makes the question 'what did the clinician see at 14:02' unanswerable, which is exactly what an incident review or a legal hold asks. It also leaves downstream consumers that already acted on the preliminary value with no correction event to react to, because the state transition was collapsed into a single mutated row and never emitted.

Storing monetary amounts as floating-point numbers.

Binary floating point cannot represent values like 0.10 exactly, so summing allowed and paid amounts across millions of claim lines accumulates representation and rounding error. Reconciliation against a remittance file is exact to the cent, so the drift surfaces as a balance that is off by a few cents with no identifiable cause, and engineers lose days looking for a logic bug in code that is correct apart from its numeric type. Integer minor units or an exact decimal type removes the class entirely.

Writing code before the input contract is pinned down

Before the first line, state the types, the size bounds, whether duplicates, negatives or an empty input are possible, whether the input is sorted, whether you may mutate it, and what the function returns when nothing matches. Every one of those answers changes the code, and discovering one at minute twenty costs a rewrite you no longer have time for.

Never running a concrete value through the code

Trace one small input and one edge input by hand, index by index, out loud. Re-reading your own code catches design mistakes; walking a real value through it catches the off-by-one, the uninitialised accumulator and the loop that never advances.

Questions & practice

Write a function to reverse a linked list.

Medium · data structures and algorithms

Approach

Restate the input: its shape, its size, and what is guaranteed about it.
Name the brute-force solution and its complexity before improving on it.
Choose the data structure from the access pattern, not from familiarity.

Follow-up

How does this change if the input no longer fits in memory?
Which test case would catch an off-by-one here?

Extract an idempotency key from a raw HL7v2 message

Easy · parsing · idempotency · delimiters

An HL7v2 message arrives as a byte buffer up to 256 KB, segments terminated by carriage return (0x0D), first segment MSH. MSH-1 is the field separator character itself and MSH-2 holds the encoding characters, so splitting the MSH segment on the separator puts MSH-n at index n-1 for n of 2 or more. Return the idempotency key built from MSH-4 sending facility, MSH-3 sending application, MSH-10 message control ID and MSH-7 event timestamp, with escape sequences decoded in each value. Single pass, O(n). Do not hardcode the separator characters.

Approach

Read the delimiters out of the message instead of assuming them: the byte immediately after MSH is the field separator, and the next field's bytes give component, repetition, escape and subcomponent separators in that order. Everything downstream uses those values, because a partner is entitled to send different ones and the common defaults are a convention, not a guarantee.
Verify the first three bytes are MSH before anything else and reject otherwise, since a socket read can begin mid-message. Then bound the segment at the first terminator and split that slice only, applying the n-1 offset that the MSH segment alone requires.
Decode escapes in one left-to-right pass per extracted value: on the escape character, read to the next escape character and map the codes for field, component, subcomponent, repetition and escape back to their literal characters. Treat an unterminated escape as a malformed message rather than dropping the tail silently.
Normalise MSH-7 to UTC before it enters the key. The timestamp may carry an offset or omit one, and two spellings of the same instant must hash identically or the ledger stops deduplicating the moment a partner changes its formatter.
Compose the key as the full tuple, not the control ID alone. The control ID is unique only per sending application and some senders roll the counter over, so facility plus application plus control ID plus instant is the smallest key that survives a rollover.
Cost is O(n) time and O(k) space for the extracted values. Hashing the whole body is also O(n) but cannot distinguish a genuine resend from a corrected retransmission that reuses the control ID, which is a different event.

Worked solution (15 min)

Take the separator characters from bytes 3 through 7 of the buffer and store them.
Slice to the first segment terminator and split on the field separator into tokens.
Read tokens at indices 2, 3, 6 and 9 for MSH-3, MSH-4, MSH-7 and MSH-10.
Unescape each extracted value with the escape character you read in step one, then convert MSH-7 to UTC.
Return the tuple, and the hash of it if the ledger stores a fixed-width key.

Expected result: For a message whose MSH reads MSH, then the encoding characters, then LABAPP, SITE-A, EHR, SITE-B, 20260315142233-0400, an empty field, ORU^R01, MSG00042, P, 2.5.1, the key is (SITE-A, LABAPP, MSG00042, 2026-03-15T18:22:33Z). The local time 14:22:33 at offset -0400 is 18:22:33 UTC.

Verify it yourself

Reading MSH-9 with the same rule lands on ORU^R01. If it lands on the empty field or on P, your index is off by one in one direction or the other.
Re-encode the same message with a different field separator character and the parser returns the identical key.
A value containing the escaped field separator decodes to that literal character and does not cause the field to re-split.
Parsing the message twice yields byte-identical keys, and the same control ID from a different facility yields a different key.

Follow-up

One partner sends MSH-7 with no timezone offset and another sends it with an offset. What do you store, and what do you compare on?
A sender rolls its control ID counter over and restarts from zero. Which component of your key absorbs that, and which message pairs would still collide?
Segments arrive separated by line feed instead of carriage return, or with a trailing empty field. Which should the parser accept and which should it negatively acknowledge?

Reconstruct what the chart displayed at five million past instants

Hard · external sort · as-of join · io bound

observation_result holds 200 million versions: observation_id, enterprise_person_id, filler_order_id, loinc_code, value_numeric, result_status, collected_ts, issued_ts, version, supersedes_observation_id. An incident review hands you 5 million queries of (enterprise_person_id, filler_order_id, loinc_code, as_of_instant). For each, return the version that was visible at that instant, meaning the one with the greatest issued_ts at or before it. Neither side fits in memory. The per-query scan is correct. Explain precisely why it is too slow, then give a plan with its complexity.

Approach

Name the clock before naming an algorithm. Visibility is issued_ts, the release time. collected_ts is when the specimen was drawn and can precede release by hours, so ordering on it reports a correction as visible long before anyone could have seen it. No amount of index work rescues the wrong column.
Be exact about why the naive plan fails, because the interviewer is testing whether you can tell arithmetic cost from I/O cost. Per query the chain scan is O(V_k) and the arithmetic is trivial, but 5 million independent lookups into a 200-million-row structure that does not fit in RAM is 5 million random reads. The job is bounded by seeks per query, not by comparisons, and buying a faster comparison changes nothing.
Convert random access into sequential access. Hash-partition both sides on the chain key (enterprise_person_id, filler_order_id, loinc_code) into P shards sized to fit memory, sort each shard's versions by (chain key, issued_ts) and its queries by (chain key, as_of_instant), and sweep the pair in lockstep. Total O((V + Q) log(V + Q)) with external sort, replacing Q seeks with two sequential passes.
Inside a chain the sweep is linear, not logarithmic, because queries are visited in ascending as_of order and the version pointer only moves forward: O(V_k + Q_k) per chain. Binary search per query is the better shape only when Q is small relative to V and the versions are already indexed and resident.
Return the empty answer as a distinct outcome. A query whose as_of precedes the first issued_ts means nothing was displayed, which is not the same as the earliest value, and is frequently the exact fact the review is chasing.
Return a version later marked entered_in_error if it was live at the instant asked about. Reconstructing the past means reporting what was on the screen, including what was wrong, and quietly substituting today's truth defeats the purpose of the exercise.

Follow-up

Read replicas lagged 40 seconds at the time. Does your answer describe what the clinician actually saw, and how would you bound the difference?
Serve the same question online for a single chart at a p99 under 50ms. What changes?
One partner changed its filler_order_id format mid-year, so the chain key is not stable. How does that appear in your output, and how do you detect it rather than returning empty answers?

Bitemporal coverage table with retroactive termination queries

Easy · bitemporal · schema design · retroactive correction

You maintain coverage_span: coverage_id, enterprise_person_id, payer_id, plan_id, effective_date, termination_date (nullable, meaning open-ended, not unknown), status, valid_from timestamptz, valid_to timestamptz DEFAULT 'infinity'. An enrolment file received on 2026-03-05 terminates a member effective 2026-03-01, after a claim for service date 2026-03-03 was already adjudicated against the answer then in force. State your termination_date convention, write the two SELECTs — (a) is the person covered on 2026-03-03 as known now, (b) what the system believed on 2026-03-04 — and say precisely what the loader writes when the file lands.

Approach

Separate the two time axes explicitly before writing anything: effective_date/termination_date are business time (when benefit applied), valid_from/valid_to are system time (when this row was the system's belief). Every query names both, or it is ambiguous.
Pin the inclusivity convention, because the predicate depends on it. Enrolment files conventionally carry termination_date as the last covered day, so the business-time predicate is effective_date <= :svc AND (termination_date IS NULL OR termination_date >= :svc). If your feed uses an exclusive end, it becomes > :svc, and a half-open daterange column removes the ambiguity permanently.
Write the as-known-now query by pinning system time to the open version (valid_to = 'infinity') and letting business time float to the service date.
Write the as-of-belief query by pinning system time to an instant: valid_from <= :asof AND valid_to > :asof. Half-open on both ends is what makes 'exactly one row per key per instant' provable.
Describe the write as one guarded statement rather than two independent ones: a data-modifying CTE whose UPDATE stamps the open row's valid_to to now() (the only UPDATE the design permits — it stamps system time, it never edits business facts) and returns that row's keys, with the INSERT of the new version selecting FROM that CTE. Feeding the INSERT from the UPDATE's RETURNING is what makes a replayed file a no-op; an unconditional INSERT leaves the partial unique index to raise 23505 instead, which is a backstop rather than idempotency. The pre-correction row stays readable either way, which is what makes the already-adjudicated claim defensible.

Follow-up

The claim adjudicated on 2026-03-03 is now retroactively uncovered. What does reprocessing have to read — the belief at adjudication time or the current truth — and what does the remittance reversal reference?
Add the constraint that stops two active coverage versions from overlapping in business time for the same person and plan, without blocking the superseded history rows.
A later file reinstates coverage with the same effective_date. How many rows exist for that period afterwards, and which one does query (a) return?

Fix a paid-amount report that double counts claim versions

Medium · join fan-out · versioned claims · aggregation correctness

claim_line: claim_line_id, claim_id, claim_version smallint, line_number, frequency_code in ('original','replacement','void'), enterprise_person_id, coverage_id, billing_provider_npi, service_from_date, procedure_code, units, billed_amount_cents bigint, allowed_amount_cents, paid_amount_cents, adjudication_status, UNIQUE (claim_id, claim_version, line_number). A monthly report sums paid_amount_cents and joins coverage_span on enterprise_person_id with date overlap to attribute a plan. It overstates payment by roughly 9%, and reconciliation against remittance fails. Name both causes, then write the corrected query returning paid cents and plan per billing_provider_npi for March 2026 service dates.

Approach

Cause one: the SUM spans every claim version. A replacement supersedes a prior claim and a void cancels one, so a replaced claim contributes twice and a voided claim contributes once when it should contribute nothing. Resolve the surviving version per claim_id before aggregating, never by deleting superseded rows.
Cause two: the coverage join is one-to-many. coverage_span carries a system-time version per coverage period, so a person with three beliefs about one period multiplies every claim line by three. The join is for a label, not for filtering, so it must not be allowed to change cardinality.
Collapse the version chain with DISTINCT ON (claim_id) ... ORDER BY claim_id, claim_version DESC, then join the lines back on (claim_id, claim_version), and exclude the surviving version when its frequency_code is 'void'.
Make the coverage lookup cardinality-safe with a LEFT JOIN LATERAL ... LIMIT 1 pinned to valid_to = 'infinity' and ordered by valid_from DESC. LATERAL with LIMIT 1 cannot fan out by construction; a plain join can, and no amount of later DISTINCT repairs a SUM that already doubled.
Keep the money in integer minor units the whole way. SUM(bigint) returns numeric in PostgreSQL, so there is no overflow and no binary floating-point error; cast to a display type only at the edge.

Worked solution (35 min)

Prove cause one with a diagnostic: SELECT claim_id, count(DISTINCT claim_version) FROM claim_line GROUP BY 1 HAVING count(DISTINCT claim_version) > 1 — confirm the affected claims exist and their paid totals.
Prove cause two by running the original report with count(*) alongside the SUM and comparing it to the count of qualifying claim_line rows; any excess is fan-out.
Write the surviving-version CTE with DISTINCT ON (claim_id).
Join the lines to it on both claim_id and claim_version, exclude 'void', filter adjudication_status = 'paid' and the half-open March service-date range.
Attach the plan label through LEFT JOIN LATERAL with LIMIT 1, then re-run the count(*) check and confirm it now equals the qualifying line count exactly.
Diff the new total against remittance and confirm the 9% gap closes to zero cents, not to 'close enough'.

Expected result: WITH surviving AS ( SELECT DISTINCT ON (claim_id) claim_id, claim_version, frequency_code FROM claim_line ORDER BY claim_id, claim_version DESC ) SELECT cl.billing_provider_npi, cov.plan_id, SUM(cl.paid_amount_cents) AS paid_cents FROM claim_line cl JOIN surviving s ON s.claim_id = cl.claim_id AND s.claim_version = cl.claim_version LEFT JOIN LATERAL ( SELECT cs.plan_id FROM coverage_span cs WHERE cs.enterprise_person_id = cl.enterprise_person_id AND cs.valid_to = 'infinity' AND cs.effective_date <= cl.service_from_date AND (cs.termination_date IS NULL OR cs.termination_date >= cl.service_from_date) ORDER BY cs.coverage_order, cs.valid_from DESC LIMIT 1 ) cov ON true WHERE s.frequency_code <> 'void' AND cl.adjudication_status = 'paid' AND cl.service_from_date >= DATE '2026-03-01' AND cl.service_from_date < DATE '2026-04-01' GROUP BY 1, 2;

Verify it yourself

Replacing the aggregate with count(*) yields exactly the number of claim_line rows that pass the same predicates without the coverage join — equality proves the LATERAL did not fan out.
Removing the LATERAL entirely changes no monetary total, only the plan column; if the total moves, the join is still multiplying.
Every claim_id appears with exactly one claim_version in the surviving CTE: count(*) equals count(DISTINCT claim_id).
The corrected total reconciles to the remittance file to the cent, and the residual for each voided claim is exactly its previously included paid amount.

Follow-up

A replacement arrives before its original. Your surviving-version logic picks max(claim_version) — what does the report show in the window before the original lands, and does the number self-correct?
Add a claim_line_adjustment table with several reason codes per line. What does that do to this query, and where do you aggregate to keep it safe?
Reconciliation is still off by 400 cents. Which of the two causes could still produce that, and what is your next query?

How would you ensure high availability in a distributed system?

Medium · system design and architecture

Approach

State the consistency you need, and where you are willing to be stale.
Fix the scope first: who calls this, how often, and what they do when it fails.
Choose a partition key and say what query it makes expensive.

Follow-up

What breaks first when traffic grows ten times?
How does this behave when that dependency is down for an hour?

Design a system to manage patient records for a healthcare provider.

Medium · system design and architecture

Approach

Fix the scope first: who calls this, how often, and what they do when it fails.
Choose a partition key and say what query it makes expensive.
Name the read and write paths separately; they rarely have the same bottleneck.

Follow-up

What breaks first when traffic grows ten times?
How does this behave when that dependency is down for an hour?

Explain the difference between an abstract class and an interface.

Medium

Approach

Work from the requirement backwards to the design.
Clarify what is being asked and what a complete answer contains.
State your assumptions explicitly before working the problem.

Follow-up

How would you know your answer was wrong?
What assumption would you test first?

Describe a challenging bug you encountered and how you resolved it.

Medium

Approach

Say what you would check first and why it is the highest-information step.
Clarify what is being asked and what a complete answer contains.
Work from the requirement backwards to the design.

Follow-up

What assumption would you test first?
How would you know your answer was wrong?

Idempotent admission feed ingestion under replay and reordering

Easy · idempotency · at-least-once · event-ordering · queues

The gateway consumes HL7v2 admit, discharge, transfer and update messages over MLLP: a few million a day with fourfold nightly bursts, across twelve parallel workers. Delivery is at-least-once — a lost acknowledgement makes the sender resend, and an interface restart replays a window. Message types are routed through separate queues and retried independently, so a discharge can arrive before the admission it closes. Define the idempotency key and the assumption it rests on, the mechanism that makes deduplication atomic under concurrency, and how the encounter row reaches the same final state under any arrival order.

Approach

Reject the message control identifier on its own: it is unique only per sending application, and senders roll the counter over. Use the tuple of sending facility, sending application, control identifier and the message timestamp, or a SHA-256 of the raw message body when the header cannot be trusted to be stable. Write the assumption down — no control identifier reuse within the timestamp's resolution — and count near-duplicate bodies with distinct keys so you learn in production when it stops holding.
Make deduplication a write-side decision: insert the key into a ledger under a UNIQUE constraint in the same transaction that applies the effect. A select-then-insert in application code is not sufficient, because two workers holding the same replayed message both pass the existence check before either inserts; the unique violation is the only thing that serialises them. Deduplicating on read costs you the effect already having been applied.
Order per encounter rather than per queue. Carry the sender's event timestamp and apply with UPDATE ... WHERE source_event_ts < :incoming plus a row_version bump, so an older message loses deterministically regardless of which worker wins the race.
Make out-of-order arrival constructive instead of a rejection: a discharge for an unknown encounter inserts the encounter in status discharged with the discharge fields set, and the later admission fills only what is missing. Rejecting the orphan turns a recoverable ordering problem into permanent loss that surfaces months later as a census report that is short.
Prove the property rather than assert it: replay a fixture stream containing a duplicate, an early discharge and a late correction under several random permutations and assert the final encounter rows are identical. If the final state depends on the permutation, the merge rule is wrong and the fixture is fine.

Worked solution (25 min)

Write the idempotency key as a concrete tuple, then list each field's uniqueness scope and which sender behaviour would break it.
Write the ledger insert and the effect apply as one transaction, and state what the handler returns on unique violation.
Write the conditional UPDATE that enforces per-encounter ordering, and show what happens when a late update loses.
Define the merge rule for a discharge preceding its admission, naming which fields each message may set and which it must not overwrite.
Permute a ten-message fixture five ways and compare the final rows field by field.

Expected result: A composite idempotency key with its assumption stated and monitored, deduplication enforced by a UNIQUE constraint inside the effect transaction rather than by an application-level existence check, per-encounter ordering driven by the sender's event timestamp, and an upsert-and-fill merge rule that makes the final state independent of arrival order.

Verify it yourself

Replaying the same message ten times produces one encounter row and one ledger entry.
Five random permutations of the same fixture stream yield identical final rows.
Two workers processing the identical replayed message simultaneously produce exactly one effect, with the loser observing a unique violation.
A discharge arriving before its admission leaves the encounter discharged rather than rejected or re-opened.

Follow-up

A sender re-emits an entire day after a restart with the same control identifiers but fresh message timestamps. What does your key do, and what would you change?
Two update messages for one encounter carry identical sender event timestamps. How do you break the tie deterministically across twelve workers?

One facility stops updating while aggregate ingestion lag looks fine

Medium · poison message · head-of-line blocking · dead-letter queue

Encounters from one sending facility stopped updating at 02:10. Aggregate HL7 ingestion throughput looks normal and the consumer group's total lag is up only 4%. One consumer instance is pinned at 100% CPU. The error log shows the same message control ID repeating about 200 times a second with a parse error on a timestamp field. The stream is partitioned by (sending facility, encounter) to preserve per-encounter ordering. Give the ordered diagnosis, the fix, and what you must not do to the message.

Approach

Look at lag per partition, never the aggregate. With 64 partitions, one fully stuck partition raises total lag by about 1.6% while that facility's encounters stop entirely, so the aggregate metric is structurally blind to head-of-line blocking. The alert that would have caught this is per-partition lag or a committed offset that has not advanced.
Confirm the loop by grouping errors by offset or control ID. The same identifier repeating at the retry rate, with the partition's committed offset frozen, is a poison message. A growing set of distinct identifiers instead means a systematic parse regression, which points at a dialect change on the partner's side and has a different fix.
Classify before acting: parse-time or apply-time failure. A parse failure has written nothing and can be parked safely. An apply failure may have committed part of its work, so you must confirm the write path is idempotent against a unique constraint on the idempotency key before you replay or skip anything.
Fix the mechanism rather than the one message: bounded retries with exponential backoff and a maximum attempt count, then park the raw bytes, partition key and offset to a dead-letter store and advance the offset. Alert on dead-letter depth, because lag will not catch the next one either.
Handle the ordering consequence explicitly. Silently skipping a message in a per-encounter ordered stream permanently drops a clinical event — a transfer, a discharge, a result release. Mark the encounter key as blocked and reconcile it, rather than letting later messages apply over a gap nobody recorded.
Then repair the parser. Partial-precision HL7v2 timestamps are legal: 2026, 202609, 20260922 and 20260922143000-0700 are all valid, so the parser must carry a precision rather than assume fourteen digits plus an offset, and must reject with a typed error the dead-letter path can classify.

Follow-up

What maximum attempt count do you choose, and what does it imply about a transient failure like a downstream store being briefly unavailable, which looks identical to a poison message for the first few attempts?
After the parser is fixed, how does an operator replay parked messages for that encounter without re-applying the messages that already succeeded behind it?

Suggested practice checklist

For someone who has spent the last few years shipping features and reading other people's code, and who has not solved a timed problem from a blank file in a long time. Five days rebuild the primitives and the patterns that sit on them, working from invariants rather than remembered solutions, and the last two attach that back to the rest of the loop.

Day 1 — Rebuild the primitives by implementing them

Implement a dynamic array with doubling growth and an operation counter, then change the growth rule to add a fixed sixteen slots instead, and time both for n of ten thousand, a hundred thousand and a million. The fixed-increment version resizes n/16 times at O(n) each, so its total work is quadratic; doubling is what makes append amortised constant.
Implement a hash map with separate chaining and a load-factor resize, then insert ten thousand keys engineered to land in one bucket and record what happens to lookup time, so that average-case O(1) becomes a claim with a stated precondition rather than a reflex.
For dynamic-array append and hash-map insert, write down which cost is amortised rather than worst-case, which single operation pays the whole bill, and what a system with a hard per-operation deadline would have to do instead.

Deliverable: Two working implementations plus a timing table showing the input at which each structure's advertised complexity stops holding.

Day 2 — Arrays under an invariant: two pointers, sliding window, binary search

Solve longest-subarray-with-sum-at-most-K using a sliding window, then run it on an input containing negative numbers and watch it return the wrong answer: extending the window only moves the sum monotonically when every element is non-negative, and that precondition is the whole reason the technique works.
Write the binary search that finds the first index satisfying a predicate rather than an exact value, put the loop invariant above the loop in a comment, and verify termination on the two inputs that break careless versions: the empty range, and a range where every element satisfies the predicate.
Compute the midpoint as lo + (hi - lo) / 2 and write one line on why the obvious (lo + hi) / 2 is a genuine defect in a fixed-width integer type and a non-issue in a language with arbitrary-precision integers.

Deliverable: Three solved problems, each with its invariant written above the loop, plus one recorded input on which the sliding window is provably wrong.

Day 3 — Sorting, heaps, and the greedy argument that has to be proved

Solve one top-k problem three ways, by full sort, by a size-k heap, and by quickselect, then write the values of n and k at which each becomes the right choice, along with quickselect's quadratic worst case and why a randomised pivot makes that unlikely rather than impossible.
Implement bottom-up heapify and count sift-down steps to confirm it does linear work rather than n log n, because most nodes sit near the bottom of the tree and therefore move only a short distance.
Take interval scheduling by earliest finishing time and write the exchange argument out in full: given any optimal schedule, swapping in the earliest-finishing interval keeps it feasible and no smaller. Then construct the weighted variant where that same greedy fails and name what has to replace it.

Deliverable: A three-way top-k comparison with measured crossover points, one written exchange argument, and one counterexample to a greedy rule that looks almost identical.

Day 4 — Recursion, memoisation, and the step to a table

Take one problem with overlapping subproblems, such as edit distance or coin change, instrument the plain recursion with a call counter to show the blow-up, then add memoisation and re-count.
Convert the memoised version to a bottom-up table and state the two properties you relied on: each subproblem's result depends only on its arguments, and the dependencies form a DAG you can enumerate in order.
Rewrite one deep recursion with an explicit stack, then find the input length at which the original hits the interpreter's frame limit, which defaults to about a thousand frames in CPython, so you know when the rewrite is required rather than decorative.

Deliverable: One problem in three forms, naive, memoised and tabulated, with call counts for each and the input length at which recursion depth becomes the binding constraint.

Day 5 — Graphs, where most of the work is choosing the traversal

Implement BFS and DFS over one adjacency list, then answer for each which finds a shortest path in an unweighted graph and which you would use to detect a cycle in a directed graph, including why the in-progress versus finished distinction matters for the second.
Implement topological sort by in-degree, feed it a graph containing a cycle, and confirm the failure signature is that fewer than V nodes come out rather than an exception, then note that the order it produces is one of several valid ones.
Run a shortest-path search on a graph with a single negative edge weight and show the wrong answer, then write the precondition Dijkstra actually needs, non-negative weights, because it finalises a node's distance the first time that node is popped, and name the algorithm you would switch to and its own limit.

Deliverable: A small graph library with BFS, DFS and topological sort, plus two inputs that produce documented wrong answers under the wrong algorithm choice.

Day 6 — One day for everything that is not an algorithm

Sketch one system only to the depth a coding-heavy loop tends to reach: the endpoints, what the service stores, and the single query pattern that decides the schema. Stop at twenty-five minutes.
Prepare the project answer for an interviewer who codes, which means rehearsing the two levels they push to: the specific thing you built, and why you chose that approach over the alternative they will name. Open with a number and be ready to say what it excludes.
Prepare the answer to what you would do differently, choosing a real technical mistake with a specific fix rather than a complaint about process or staffing.

Deliverable: One design sketch at endpoint-and-schema depth, plus a project answer rehearsed to two levels of follow-up.

Day 7 — Solve out loud, under time

Do three timed problems at twenty-five minutes each in a plain editor with no autocomplete and no execution until the end, then tally separately the failures that were syntax and the ones that were approach, because those two numbers call for different fixes.
Narrate one solution from the first sentence, stating the approach and its complexity before writing any code, and rehearse the sentence you will use when you realise mid-solution that the approach is wrong.
Re-solve from blank the two problems you were slowest on this week and compare the times against the day they first appeared.

Deliverable: A recording of one fully narrated solution and a tally that separates syntax failures from approach failures.

Review and mentoring: what you let through

Counting review comments or mentees proves nothing. The useful version is a specific change you approved with a reservation you stated, or one you blocked and the delay that cost. Say which standard you were holding and why it was worth the friction. A mentoring story needs the thing the other person can now do without you.

Give an example of how you handled a disagreement with a team member.

Medium · behavioural and engineering judgement

Approach

Name the disagreement and how you resolved it with evidence.
Give the blast radius: what could have broken, and what you measured.
Pick a story where you made the decision, not one where you watched it.

Follow-up

How did you know your change caused the improvement?
What did you decide not to do, and why?

How do you handle version control in your projects?

Medium · behavioural and engineering judgement

Approach

Name the disagreement and how you resolved it with evidence.
State the situation in two sentences and spend the rest on the reasoning.
Give the blast radius: what could have broken, and what you measured.

Follow-up

What would you do differently if you ran that again?
What did you decide not to do, and why?

Describe a time when you had to lead a project. What challenges did you face?

Medium · behavioural and engineering judgement

Approach

Give the blast radius: what could have broken, and what you measured.
State the situation in two sentences and spend the rest on the reasoning.
Pick a story where you made the decision, not one where you watched it.

Follow-up

How did you know your change caused the improvement?
What would you do differently if you ran that again?