Alphatec Spine Software Engineer Interview Questions & Guide 2026

The 60-second brief

As a Software Engineer at Alphatec Spine, you will play a pivotal role in developing sophisticated, life-impacting medical technologies within the orthopedic and spine care sectors. Your work directly contributes to advanced platforms like Alpha Informatix and Valence, driving the creation of client-facing applications, distributed backend services, and robust data gateways. You will partner closely with multidisciplinary teams to build software that integrates seamlessly with physical medical hardware and clinical workflows.

If the seat owns a service boundary, scope your preparation toward failure behaviour rather than topology. Retrying over an at-least-once channel produces duplicates by construction, so a retry policy is only as safe as the idempotency key underneath it.

Focus areas

• Hold accumulator limits under concurrent claim adjudication
• Authorise every identified read against current consent
• Model bitemporal coverage and retroactive eligibility changes

Overview

This position demands both technical versatility and a rigorous commitment to quality, as the software you build operates in high-stakes, regulated medical environments. You will navigate the entire software development life cycle, from conceptual design and C#/.NET development to integration with message-based architectures like RabbitMQ and embedded systems. The scale and complexity of this work require you to balance architectural elegance with strict adherence to medical device standards such as and.

Success in this role requires more than just writing clean code; it requires a genuine passion for improving surgical outcomes and a collaborative mindset. You will work alongside globally distributed engineering, clinical, and quality teams to solve complex technical challenges that bridge the digital and physical worlds. Expect an intellectually stimulating environment where your technical contributions directly influence the next generation of spine surgery solutions.

The Alphatec Spine interview process

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

Initial Screening Call

The title covers product work, platform work, infrastructure, mobile and frontend, and those are different jobs with different loops behind them. A screening call is the cheapest place to find out which one the seat is, and asking reads as experienced rather than fussy. The questions that separate them: what the team is on call for, what the last three projects were, and whether any round happens inside an existing repository instead of a blank file. Then say which of that you have done and which you have not. Claiming the whole posting is the fastest way to be found out one round later.

What to demonstrate

• Whether you can locate your experience inside one flavour of the role honestly instead of claiming the entire requirements list
• Whether you name what you have not done, which an experienced screener reads as a level signal and can plan the loop around
• Whether what you want next matches what the seat is: someone who wants greenfield work landing on a team that mostly operates an existing system is a hire that leaves within the year

How to prepare

• Mark every line of the posting as done, adjacent or new, and write one sentence for each adjacent line naming the closest thing you actually built
• Split your last two years into rough percentages across feature work, operating and debugging live systems, and design or review, so a question about scope gets numbers rather than adjectives
• Bring three questions that discriminate between seats: what the team is paged for, how much of the work is changing existing code versus standing up something new, and what shipped in the last quarter

Interview with Hiring Manager

This round is a resourcing decision in the shape of a conversation: how large a piece of work can be handed to you with a one-line brief and no check-in for two weeks. The manager is listening for the seams in your story, the places where you settled something yourself and the places you went back for a ruling. Most candidates describe the system and skip the decisions, which reads as having been present rather than responsible. Say who wanted the work, which option you rejected and why, and where you would have stopped and escalated.

What to demonstrate

• Whether you can point at a design decision that was yours rather than the team's, and name the alternative you turned down and the constraint that killed it
• What you treat as yours to settle against what you take to someone else, and how long you sit on a blocker before raising it
• Whether the scope you claim survives a follow-up into the unglamorous part of it: the data migration, the backfill, the rollout to users who were already on the old path
• Whether you asked what problem the request was solving before building what was literally asked for, and what changed in the design once you had the answer

How to prepare

• Write out the brief for your last two projects exactly as it reached you, usually one sentence in a ticket, then list every question you had to answer yourself before code could be written. That list is most of what this round is asking for.
• For one decision in each project, write down the rejected option, what you were trading against, and the piece of evidence that would have flipped you. A tradeoff you cannot argue in reverse was not really a decision.
• Have an escalation ready: a blocker you took to your manager, what you had already tried, and the specific thing you were asking them to decide. If every example is something you handled alone, that reads as someone who does not ask.

Panel Interview

Where the day includes a partner from product, design or data, that conversation is weighted like the technical ones and prepared for least. They are deciding one thing: whether having you in the room makes their decisions cheaper. That means options with costs attached, not implementation detail and not "it depends". An estimate someone can plan against — a range, the assumption that would push it to the high end, and what you would drop to hit the low one — is worth more than a confident single number, which everyone present already knows is wrong.

What to demonstrate

• Whether an estimate comes as a range with the assumption most likely to break it, and states what a specific scope cut would actually buy
• Whether a technical constraint is handed over as a choice with consequences on their side, rather than as a verdict they have no standing to argue with
• Whether you establish what decision is on the table before proposing anything
• Whether risk is raised while it can still change the plan, with the trigger that would confirm it, instead of reported afterwards as a slip

How to prepare

• Take a project that shipped late and write the two-sentence warning you could have given three weeks earlier, naming what you would have needed decided at that point
• Rehearse one estimate out loud until it arrives in three parts: the range, the single assumption that would blow it, and the smallest thing you would cut to protect the date
• Rewrite an objection you have actually made — the "we can't do that" version — as two options with their costs, so the choice ends up with the person who owns it

Where candidates lose points

Caching an eligibility answer with a long time-to-live and without an as-of date.

Coverage terminates retroactively as a matter of routine: an enrolment file received on the fifth of the month can terminate coverage effective the first. A day-long cache means services are delivered against a 'covered' answer that was already false when it was served, and the denial arrives weeks later. The answer needs to be keyed on person, plan and service date, carry the date it was computed as of, and expire fast enough that the exposure window is a decision rather than an accident.

Writing the access audit record inside the read transaction, or firing it off after the response with no durability.

Inside the transaction, an audit-store outage blocks clinical reads and turns a logging dependency into a care outage. Fire-and-forget afterwards means the audit trail is incomplete during precisely the incidents it exists to reconstruct, and the gaps are invisible until someone asks for the log. The usual resolution is committing the access decision and its audit row together to a local outbox and shipping asynchronously, which keeps the read path available while preserving durability.

Hardcoding to the sample inputs

Solve the stated problem rather than the two examples; special-casing a literal to make a sample pass is obvious immediately and reads as either a misunderstanding or an attempt to fake progress. If you genuinely cannot generalise yet, say which part is a stub and what would replace it.

Choosing a schema before the access patterns are known

Write the queries first, with their filters, sort orders, cardinalities and which ones sit on the latency-critical path, then design tables and indexes to serve them. An index nothing queries still costs write throughput and storage, and a hot query with no supporting index becomes a full scan that only hurts once the table is big.

Questions & practice

Flatten overlapping coverage spans into a primary-payer timeline

Medium · sweep line · intervals · bitemporal

For one enterprise_person_id you hold up to 10,000 coverage_span rows: coverage_id, payer_id, plan_id, effective_date, termination_date (null means open-ended), coverage_order (1 is primary), status, valid_from and valid_to (system time). Given a system instant T and a date range D0 to D1, return disjoint business-date intervals covering that range, each labelled with the active coverage_id of lowest coverage_order, and with uncovered stretches returned explicitly. termination_date is the last covered day. Only status active counts. Target O(N log N) time, O(N) space.

Approach

1. Apply the system-time slice before any interval logic: keep rows where valid_from is at or before T and valid_to is after T. That single predicate is what makes the answer 'what we believed at T' rather than 'what we believe now', and a retroactive termination loaded after T leaks straight into the output if you skip it.
2. Convert each surviving row to a half-open day interval from effective_date up to termination_date plus one day, using positive infinity for a null termination. Half-open removes every off-by-one at the join between a termination and the next plan's effective date, which is where same-day switches get turned into false gaps.
3. Sweep: emit 2N boundary events, sort by date in O(N log N), and hold the active set in a min-heap keyed by (coverage_order, coverage_id) with lazy deletion, popping the top while it has already expired at the current boundary. Each coverage is pushed once and popped once, so the sweep is O(N log N) total and O(N) space.
4. Emit an output interval whenever the heap top changes between consecutive boundaries, and emit an explicit uncovered interval when the heap empties. A gap reported as a gap is a different answer from a gap omitted, and downstream the difference is a denial versus a silent assumption of coverage.
5. Fix the tie-break and state it: lowest coverage_order, then lowest coverage_id. Two rows at order 1 is a data error, and without a deterministic rule the coordination-of-benefits answer changes between two runs over identical data.
6. Clip to D0 and D1 last, so a coverage that starts before D0 still contributes its correct order inside the window.

Follow-up

• Run the same query at two system instants and diff the timelines. What did the correction change, and what does each extra instant cost you?
• A termination arrives with an effective date earlier than the service date of a claim that already adjudicated and paid. What does the timeline now say, and what has to happen to that claim?
• Two enrolment files disagree on coverage_order for a dependent. What does your tie-break do, and what should the system do instead of tie-breaking?

Sum surviving claim versions in one pass over unordered lines

Easy · hash map · versioning · streaming aggregation

You are streamed up to 50 million claim_line records in arbitrary order: claim_id, claim_version, line_number, frequency_code (original, replacement, void), enterprise_person_id, allowed_amount_cents. Every version of a claim shares its claim_id, and a replacement arrives as a higher claim_version. Return total allowed_amount_cents per enterprise_person_id, counting each claim once at its highest version and contributing zero when that version is a void. Amounts are non-negative int64 minor units. Target O(N) time and O(C) space for C distinct claims, single pass, no sort.

Approach

1. Say the two grains out loud before writing anything: the version lives at claim grain, the money lives at line grain. Every wrong answer here comes from applying a claim-level rule with a line-level filter.
2. Keep one hash map from claim_id to a small record (best_version, sum_cents, person_id, is_void). Per line: if claim_version is greater than best_version, reset sum_cents to this line's amount and overwrite the person and void flag; if equal, add to it; if lower, discard the line. That reset is what makes the pass order-independent, so a replacement arriving before its original still wins.
3. Resolve the void at the end, not at ingest. A void only nullifies the claim if it is the surviving version, and zeroing on sight would let an earlier replacement that arrives later resurrect the money.
4. Fold the C claim records into a person-keyed map in a second phase, O(C). Do not accumulate into the person total during the stream: you cannot subtract a superseded version you have already forgotten.
5. Cost is O(N) time, O(C) space. The sort-based alternative, group by (claim_id, claim_version) and keep the max, is O(N log N) and needs the set resident; prefer it only when C approaches N and the map will not fit.
6. Keep cents in int64 throughout. Fifty million lines at a realistic per-line ceiling stay four orders of magnitude below 2^63, so the integer type costs nothing and removes the float drift class entirely.

Worked solution (20 min)

1. Define the per-claim record and the three-way comparison on claim_version: greater resets, equal accumulates, lower discards.
2. Run the stream once, touching only the claim map.
3. Walk the claim map, skipping entries whose surviving version is a void, and add each remaining sum into a person map.
4. Return the person map sorted descending by total.

Expected result: Claim A: version 1 has lines of 12000 and 8000 cents, version 2 (replacement) has lines of 9000, 8000 and 500. Claim B: version 1 has a single line of 5000, version 2 is a void carrying one zero-amount line. Both claims belong to one person. Your answer is 17500 cents, from claim A's version 2 only. The naive sum over all seven lines is 42500.

Verify it yourself

• The number of claims contributing equals the number of distinct claim_ids whose highest version is not a void.
• For a multi-line claim, the addends in its sum equal that surviving version's line count, not one.
• Shuffling the input and re-running produces an identical result, which is the property the reset-on-higher-version rule buys you.
• The all-rows sum is greater than or equal to your total, equal only when no claim has a version above 1 and none is a void.

Follow-up

• You shard the stream across eight workers. Sharding by hash of claim_id works; what exactly breaks if you shard by enterprise_person_id instead?
• A replacement arrives for a claim_id whose original never appears in the batch. What does your map produce, and is that the financially correct answer or a reconciliation break?
• The same claim_id is reused by two different submitting organisations. How does the key have to change, and when would you have noticed?

Flag a requester reading too many distinct charts per window

Medium · sliding window · two pointers · distinct count

You consume access-audit records (event_ts, requester_id, enterprise_person_id, purpose_of_use, break_glass) at tens of thousands per second, non-decreasing in event_ts. For each requester, emit an alert the first time any sliding 600-second window contains reads of more than D distinct enterprise_person_ids. Break-glass reads count toward the window and are also reported separately. Return (requester_id, window_start_ts, distinct_count). Target O(1) amortised per event and memory proportional to the events resident in the window, not to the day.

Approach

1. Per requester, hold a deque of (event_ts, person_id) and a hash map from person_id to its occurrence count inside the window, plus a running distinct counter. Push on the right; while the front is older than event_ts minus 600 seconds, pop it, decrement its count and erase the key when the count reaches zero, decrementing the distinct counter. Each event is pushed once and popped once, so the amortised cost is O(1) and the memory is O(W) for window occupancy W.
2. Test the threshold immediately after each push and nowhere else. Between two consecutive events the window can only lose members as its left edge advances, so the maximum distinct count over all window positions is attained at a position whose right edge is an event. Checking at pushes is therefore exhaustive rather than a sampling approximation.
3. Latch the alert per requester and re-arm only when the distinct count falls back below D, otherwise one busy stretch emits thousands of near-identical rows and the real signal is buried by its own volume.
4. Bound memory both per requester and globally. A requester whose window legitimately holds tens of thousands of reads must not hold the process hostage, so cap the deque and degrade above the cap to an approximate distinct counter such as HyperLogLog, stating the error you accept in exchange.
5. Count break-glass toward the window but carry it in its own output field. Break-glass has to succeed during an emergency, which is exactly why it must be the most visible path in the audit, and excluding it from the count would make the abuse route the quiet one.
6. State the precondition: this is correct only while input is non-decreasing in event_ts. Out-of-order arrival needs a bounded-lateness buffer and a watermark, and dropping late events without a counter is the failure that hides itself.

Follow-up

• One region's events arrive up to 90 seconds late. What buffer do you add, and what does that do to alert latency?
• One person uses two requester accounts. What has to change in the key, and what new false positive does that introduce?
• How do you restore window state after a process restart without replaying the whole day?

Denormalise consent into a decision table with a stated staleness bound

Hard · denormalisation · cache invalidation · access control

Access governance answers 'may this requester read this person's data for this purpose' on every identified read — tens of thousands per second at a 5ms p99 — from consent_directive: consent_id, enterprise_person_id, version, scope, purpose_of_use text[], grantee_org_id (NULL meaning all organisations), permit boolean, effective_ts, expires_ts, revoked_ts, status. Evaluating the normalised version history per read misses the budget. Design the denormalised decision store and its key, state the revocation staleness bound in seconds and the mechanism that actually enforces it, and say which normalised rows remain the system of record and why.

Approach

1. Derive the shape from the read, not from the source table. The read is a point lookup on (person, grantee organisation, purpose), so fan the purpose_of_use array out into one row per purpose and make those three columns the primary key. A GIN index on the array would serve containment queries nobody issues.
2. Handle the wildcard concretely. grantee_org_id NULL means 'all organisations', and NULL never equals anything, so a nullable column in the key breaks both the primary key and the equality lookup. Store a sentinel org id of 0 for the wildcard and resolve specific-before-wildcard in the lookup, or the wildcard row is silently unreachable.
3. Make refusal a row, not an absence. An explicit permit = false must outrank a permit for the same key, so carry a precedence rank (specific grantee beats wildcard, refusal beats permit at equal specificity) and resolve with ORDER BY rank LIMIT 1. Default deny when nothing matches, so a rebuild failure fails closed.
4. Separate the two staleness mechanisms and be precise about which one is the bound. The in-process decision cache has a TTL; a revocation also publishes an invalidation. The publish shortens the typical case to milliseconds, but it can be lost, so the guaranteed bound is the TTL alone — quote that number, for example 30 seconds, and justify it against the cache hit rate you need to hold 5ms p99.
5. Evaluate expires_ts at read time against the request clock rather than baking the decision. A cached permit whose expires_ts has passed is wrong regardless of invalidation, because no event fires when a timestamp simply goes by.
6. Keep consent_directive as the system of record: audit must reconstruct the directive in force at any past instant, the decision table holds only current state, and a corrupted decision table must be rebuildable by replaying the directives. Bound the write amplification by keeping grantees at organisation granularity and purposes a closed code set, so one directive expands to a known small number of rows rather than an unbounded cross product.

Worked solution (40 min)

1. Write the decision table DDL with the three-column primary key, the sentinel wildcard, the precedence rank and a monotonic decision_version.
2. Write the lookup query: equality on the key with the wildcard row unioned in, ORDER BY rank, LIMIT 1, and an expires_ts predicate evaluated against the request timestamp.
3. Write the projection that turns one consent_directive version into its decision rows, and compute the expansion factor for a directive covering four purposes and one organisation.
4. State the TTL, then justify it: at N reads per second and M people, compute the cache hit rate the TTL yields and check it against the 5ms p99 budget.
5. Write the failure narrative for a lost invalidation and confirm the TTL, not the bus, is what caps exposure.
6. Write the rebuild procedure from consent_directive and the assertion that proves the rebuild is complete before it is swapped in.

Expected result: consent_decision (enterprise_person_id bigint, grantee_org_id int NOT NULL DEFAULT 0, purpose_of_use text, scope text, permit boolean NOT NULL, precedence smallint NOT NULL, expires_ts timestamptz NULL, decision_version bigint NOT NULL, computed_at timestamptz NOT NULL, PRIMARY KEY (enterprise_person_id, grantee_org_id, purpose_of_use)), where grantee_org_id = 0 is the wildcard. Lookup: SELECT permit FROM consent_decision WHERE enterprise_person_id = :p AND purpose_of_use = :pou AND grantee_org_id IN (:org, 0) AND (expires_ts IS NULL OR expires_ts > :now) ORDER BY precedence LIMIT 1; no row means deny. The guaranteed revocation bound is the local cache TTL — 30 seconds — because the invalidation publish is best-effort and a lost message must not extend exposure. consent_directive stays the system of record: it is what audit replays to reconstruct the directive in force at a past instant, and what the decision table is rebuilt from.

Verify it yourself

• A person with an explicit refusal for one organisation and a wildcard permit resolves to deny for that organisation and permit for every other — verified by two lookups against one fixture.
• Truncating consent_decision yields deny for every request rather than permit, confirming the store fails closed.
• With the invalidation bus stopped, a revoked directive stops being served no later than TTL seconds after the revocation commits — measured, not assumed.
• A decision row whose expires_ts has passed is never returned even when the cache entry is still within its TTL.

Follow-up

• Break-glass must always succeed and must be unmistakably marked. Where does it sit relative to this lookup, and what stops it from becoming the quiet default path?
• The invalidation bus is down for thirty minutes. Walk through what a revoked person's data exposure looks like minute by minute, and what the backlog does when the bus returns.
• Where does the access audit record get written so that an audit-store outage degrades neither the log's completeness nor the read's availability?

Diagnose why an eligibility lookup ignores its index

Medium · indexing · query planning · partial indexes

A 40-million-row coverage_span serves eligibility lookups with: SELECT coverage_id, plan_id, coverage_order FROM coverage_span WHERE enterprise_person_id = $1 AND valid_to = 'infinity' AND effective_date <= $2 AND (termination_date IS NULL OR termination_date >= $2). An index exists on (effective_date). EXPLAIN (ANALYZE, BUFFERS) shows a sequential scan reading 1.8 million buffers at 2.4 seconds. Explain why that index cannot help, propose the index plus any schema change that makes the predicate index-friendly, and state what you expect the new plan and buffer count to be.

Approach

1. Read the predicate for selectivity before touching the index. effective_date <= $2 matches most of a 40-million-row history, so a leading range scan on that column returns a large fraction of the table and the planner correctly prefers a sequential scan over millions of random heap fetches. The index is not being ignored; it is being rejected on cost.
2. Put the equality column first. enterprise_person_id = $1 selects a handful of rows out of 40 million, so it must lead the composite index; a b-tree can only use columns after the first range predicate as filters, not as search bounds.
3. Turn the open-ended termination into something indexable. The OR ... IS NULL branch forces either a BitmapOr or a post-index filter. Add coverage_end date GENERATED ALWAYS AS (COALESCE(termination_date, DATE '9999-12-31')) STORED and rewrite the predicate to coverage_end >= $2; both COALESCE over a column and a date literal are immutable, so the generated column is legal.
4. Make the index partial on WHERE valid_to = 'infinity'. Most rows in a bitemporal table are superseded beliefs, so the partial index is a fraction of the full one, stays in cache, and encodes the predicate for free rather than re-checking it per row.
5. Consider the range alternative honestly: a daterange(effective_date, termination_date + 1, '[)') column with a GiST index and the && operator handles overlap queries and supports an EXCLUDE constraint against overlapping active coverage, but GiST lookups are slower than b-tree for this point-in-time pattern. Pick b-tree for the read path and keep GiST only if you also need the overlap constraint.
6. Verify rather than assert: re-run EXPLAIN (ANALYZE, BUFFERS) and read Rows Removed by Filter and the shared hit/read split, not just the total time.

Follow-up

• After the change the plan is still a sequential scan for one particular member. What single query tells you whether that is stale statistics, a genuinely huge row count for that person, or parameter-dependent plan caching?
• Your generated column needs backfilling on a live table. Does adding a STORED generated column rewrite it, and what does that mean for your maintenance window?
• How would you serve the same lookup when the answer must be as of a past system-time instant rather than the current belief, given your index is partial on valid_to = 'infinity'?

How would you approach integrating a software application with an embedded hardware component?

Medium · system design and architecture

Approach

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

Follow-up

• What would you drop to keep the system up under load?
• What breaks first when traffic grows ten times?

They asked technical questions about the design I had created. What materials I would use, how I would test it, etc.

Medium · system design and architecture

Approach

1. Name the failure you are designing for, then the recovery path.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Fix the scope first: who calls this, how often, and what they do when it fails.

Follow-up

• What would you drop to keep the system up under load?
• What breaks first when traffic grows ten times?

Design a distributed system architecture and explain how inter-service communication is handled.

Medium · system design and architecture

Approach

1. Choose a partition key and say what query it makes expensive.
2. Name the read and write paths separately; they rarely have the same bottleneck.
3. Name the failure you are designing for, then the recovery path.

Follow-up

• How does this behave when that dependency is down for an hour?
• What would you drop to keep the system up under load?

Programming concepts, OOP, general technical knowledge, and prior experience

Medium

Approach

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

Follow-up

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

Specific interests that pertain to bio tech and the position in general?

Medium

Approach

1. Work from the requirement backwards to the design.
2. Say what you would check first and why it is the highest-information step.
3. State your assumptions explicitly before working the problem.

Follow-up

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

Enrolment loading, bitemporal writes and retroactive fan-out

Hard · bitemporal · backpressure · invalidation · retroactive-correction

A weekly X12 enrolment file carries between tens of thousands and two million member rows and routinely terminates coverage retroactively — received on the fifth, effective the first. It writes coverage_span, whose effective_date and termination_date are business time and whose valid_from and valid_to are system time, alongside status and source_file_id. Two files covering overlapping populations can be in flight at once. Design the loader's backpressure, the bitemporal write, and the invalidation fan-out to the eligibility cache and to claims already adjudicated against the now-terminated coverage.

Approach

1. Never update a coverage_span row. A retroactive termination closes the current row by setting valid_to to now and inserts a new row with the same effective_date, the new termination_date, and valid_from set to now. Both questions then stay answerable: current truth for a past service date filters valid_to = 'infinity' and ranges on business time, while what the system believed on a past date filters valid_from <= that instant < valid_to.
2. Index for the two axes separately rather than hoping one structure serves both. A btree on (enterprise_person_id, effective_date DESC) partial on valid_to = 'infinity' serves the hot current-truth path; the as-of-system-time path is rare and analytical and can afford a wider scan. A single range index covering both usually makes the common query worse to make the rare one tidier.
3. Bound the loader instead of running it flat out: chunk into batches of a few thousand rows with a committed checkpoint offset per file, and pace on a downstream signal — replication lag or invalidation queue depth — rather than a fixed sleep. Two million rows written as fast as the database accepts them is how a weekly file becomes a replica-lag incident at 03:00, and the checkpoint is what makes a mid-file crash resumable instead of a full re-run.
4. Serialise per person rather than per file. Two overlapping files must not interleave versions for one member, so key the work queue on enterprise_person_id and let files proceed concurrently across different members; order within a person's partition by the file's assertion time, and keep source_file_id so a bad file is attributable and reversible as a set.
5. Fan the consequences out as work, not as a cache flush. Publish the changed enterprise_person_ids so the eligibility cache drops exactly those keys, and enqueue the claim identifiers whose service dates now fall outside coverage. Those claims need reversal and re-adjudication, which touches accumulators, so this is a throttled backlog with its own ordering rather than a synchronous cascade at load time.
6. Measure the blast radius before it lands: a dry-run pass counting rows whose termination precedes the file's receipt date, and the claims each would affect, turns 'we loaded the file' into a reviewed number. A file retroactively terminating forty thousand members is either a real event or a sender bug, and you want to know which before the reversals run.

Worked solution (45 min)

1. Write the close-and-insert pair for a retroactive termination, then write the two queries — current truth for a past service date, and belief as of a past instant — and run both against the result.
2. Write the chunked loader loop with its checkpoint and the downstream signal it paces on, and state the batch size and what it is derived from.
3. Define the per-person work queue key and show what happens when two overlapping files touch the same member.
4. Write the fan-out payload and the two consumers, and state the throttle on the claims reprocessing backlog.
5. Write the dry-run query that counts retroactively terminated members and the claims they affect.

Expected result: Retroactive changes written as close-and-insert across system time with no in-place update, separate indexes for the current-truth and as-of paths, a chunked and checkpointed loader paced on a downstream signal, per-person serialisation that lets overlapping files proceed concurrently, and a published-identifier fan-out feeding cache invalidation and a throttled claims reprocessing backlog.

Verify it yourself

• After loading the correction, a query as of the day before it arrived still returns the original coverage.
• Killing the loader mid-file and restarting resumes from the checkpoint without duplicating or skipping rows.
• Two files touching one member produce a single linear version chain with no interleaving.
• The eligibility cache stops returning covered for the affected service dates within one invalidation cycle, and the affected claims appear in the reprocessing queue.

Follow-up

• The sender resends last week's file unchanged. What does the loader write, and how do you prove nothing changed?
• One file terminates a coverage that a later file reinstates with the same effective date. What does the current-truth query return while both are mid-load?

Duplicate patients created quietly by a matcher timeout fallback

Hard · partial outage · fallback policy · identity resolution

Over two days the manual duplicate-review queue grew eight-fold, and a clinician reports that a patient's prior results are missing from the chart. No error-rate alert fired: registration calls the identity resolution service with a 250ms timeout and, on timeout, creates a new enterprise person and returns 200. person_identity_link records match_score, link_status, decided_by and decided_at per link version. The identity service is operated by another team. Give the ordered investigation, what you can prove alone, and what you must ask them for.

Approach

1. Work backwards from the damage rather than forwards from a dashboard. Take one duplicate pair, read both person_identity_link rows, and examine decided_by and match_score: a matcher version string, a user id, or the fallback's marker tells you which code path asserted the identity, and a NULL match_score means a deterministic link rather than a probabilistic one. If the duplicates were created by the fallback path, one query has given you the mechanism.
2. Correlate decided_at for fallback-created links against your own client-side timeout counter, minute by minute. A creation rate that tracks the timeout rate with no lag is causal; one that does not sends you back to the first step rather than letting you build on a coincidence.
3. Determine the failure shape. Is the timeout rate uniform across identity-service instances or concentrated on a few? Uniform means capacity or a global regression; concentrated means a partial outage — one degraded shard or replica — and the remedies differ. You can often infer this alone if responses carry an instance identifier; if they do not, that is the first thing to request.
4. Name the real defect. The latency is the trigger; the incident is a fallback that converts unknown into new person. A 200 carrying a fabricated identity is worse than a 503, because it silently splits a chart, and the missing prior results are the direct consequence of that split rather than a separate problem.
5. Stop the bleeding without blocking registration: on timeout, register under a provisional identity with link_status = potential_duplicate and route it to review. Clinical safety requires that registration proceeds; nothing requires that the system assert a new person on the strength of a timeout.
6. Repair, then state the ask precisely. Because links are versioned and merges are reversible, remediation means re-running the matcher offline over the window's registrations and generating merge candidates — never rewriting downstream foreign keys. From the other team, request per-instance p99 and timeout counts for the window plus their deploy and index-maintenance log, and say which of your conclusions depends on that answer.

Follow-up

• The missing results are attached to the losing identity. Describe the read path that surfaces them before the merge is approved, and what a clinician sees while the pair is still pending.
• Your timeout is 250ms against a 200ms budget. What is the right value, and what happens to duplicate creation and to registration latency if you double 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.

What the behavioural round is actually measuring

Every story you tell gets read for blast radius and judgement: what could have broken, who else it touched, what you knew at the moment you decided. Nobody can audit your code in an hour, so they audit your reasoning instead. Pick work where the call was genuinely yours and the consequences were real enough to remember.

Why are you interested in working in orthopedics?

Medium · behavioural and engineering judgement

Approach

1. Pick a story where you made the decision, not one where you watched it.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Name the disagreement and how you resolved it with evidence.

Follow-up

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

Interviewers want to understand your professional background, how you handle challenges, and why you are drawn specifically to medical technology.

Medium · behavioural and engineering judgement

Approach

1. Close with what you would do differently, concretely.
2. State the situation in two sentences and spend the rest on the reasoning.
3. Name the disagreement and how you resolved it with evidence.

Follow-up

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

What do you like to do, hence bringing you to Carlsbad?

Medium · behavioural and engineering judgement

Approach

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

Follow-up

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