Interview guides · Garner health
Garner health Software Engineer Interview Guide
Prepare for Garner Health SWE interviews with runnable Fibonacci, booking race tests, identity and permission checks, versioned data and a seven-day plan.
Interviewing at Garner health
- Practice bank: 4+ questions
- Rounds: 1
- Typical prep: 1–2 weeks
- Interview reports: 1
Interview rounds
| Round | Questions |
|---|---|
| Technical Screen | 4 |
How hard is the Garner health Software Engineer interview?
| Difficulty | Share | Questions |
|---|---|---|
| Easy | 0% | 0 |
| Medium | 100% | 4 |
| Hard | 0% | 0 |
What Garner health actually tests for
| Topic | Share | Questions |
|---|---|---|
| System Design | 50% | 2 |
| Behavioral & Leadership | 25% | 1 |
| Coding & Algorithms | 25% | 1 |
Prepare for a Garner Health software engineer interview by connecting ordinary coding skills to identity, permissions, booking state and recoverable data changes. A correct algorithm is one part of the answer. You also need to explain which record belongs to which person, which operation is permitted, and what a retry can safely repeat.
The worked exercises below add problem-specific tests and healthcare-data boundaries. All people, records, permissions and booking examples are fictional; they describe an engineering mock, not Garner's production architecture or a clinical policy.
Match the Preparation to the Role
Garner's current public site describes provider recommendations, member assistance and reimbursement-related services. Its careers page emphasizes ownership and communication. Those facts make data reliability and clear user workflows useful preparation themes. They do not prove that every software engineer works on appointment booking or clinical records.
Ask your recruiting contact which team owns the opening, whether the exercise is live or asynchronous, which language is permitted and what the design discussion covers. The public pages reviewed do not establish a universal three-round process or a three-to-five-week timeline. Treat any individual candidate account as one experience rather than a schedule for your own application.
For a take-home, keep the stated time box. Write a short explanation of the contract, the tests you prioritized, the known limits and what you would do next. For a live task, narrate the failing case before changing code. The same habits make an unfamiliar codebase easier to review.
Answer the Named Coding Prompt: Fibonacci
“Write Fibonacci using recursion and iteration” needs runnable implementations and a comparison of repeated work. It does not need a discussion of unrelated database scale. Define F(0)=0, F(1)=1 and F(n)=F(n-1)+F(n-2) for a nonnegative integer n. Reject booleans, negative values and non-integers for this exercise.
def check_n(n):
if isinstance(n, bool) or not isinstance(n, int) or n < 0:
raise ValueError("n must be a nonnegative integer")
def fib_recursive(n):
check_n(n)
def visit(k):
if k < 2:
return k
return visit(k - 1) + visit(k - 2)
return visit(n)
def fib_iterative(n):
check_n(n)
a, b = 0, 1
for _ in range(n):
a, b = b, a + b
return a
The recursive implementation mirrors the definition but recomputes the same subproblems. Its call count follows C(n)=1+C(n-1)+C(n-2) with C(0)=C(1)=1, giving 2F(n+1)-1 calls. For n=10, both functions return 55; the recursive version makes 177 helper calls, while iteration performs ten additions. For n=20, the recursive call count is 21,891. Count calls rather than claiming an arbitrary runtime speedup on someone else's machine.
After i iterations, a=F(i) and b=F(i+1). The simultaneous assignment preserves that invariant, so after n iterations the function returns F(n). Under a unit-cost arithmetic model, iteration takes O(n) time and a constant number of variables; naive recursion takes exponential time and O(n) stack depth. Python integers grow with the result, so constant variables do not mean constant bits of memory, and large-integer additions are not constant-cost operations.
Memoization is another valid recursive answer: store each computed result and reduce repeated subproblems to O(n) work in that same model. It still uses O(n) cached values and recursion depth. Do not run a large naive-recursion input merely to demonstrate slowness; small deterministic call counts already show the mechanism.
Test n=0, n=1, a small sequence, and invalid inputs. Both functions should agree for a bounded range. If the prompt asks for the first n values rather than the nth value, change the output contract explicitly instead of returning a single number and hoping the examples match.
Answer the Reliability Prompt With a Booking Failure
For “How do you test code and ensure reliability?”, start with an invariant and a bug a test would catch. Consider a fictional appointment slot with one place. The invariant is that at most one active booking owns that slot. A naive handler reads “available,” creates a booking and updates availability. Two requests can both read the initial state and both succeed.
Use a transaction that atomically claims the slot and creates its booking. For an illustrative PostgreSQL design, a conditional update is the claim:
UPDATE appointment_slot
SET remaining = remaining - 1
WHERE slot_id = :slot_id AND remaining > 0
RETURNING slot_id;
If no row is returned, report that the slot is unavailable and do not insert a booking. If a row is returned, insert the booking in the same transaction; roll back both operations if the insert fails. Protect the capacity with a nonnegative check constraint. Keep external notifications outside the critical transaction, using a durable outbox if the requirement is eventual delivery.
Give each booking request a scoped idempotency key and store its request fingerprint and result transactionally. Repeating the same key and request returns the original booking; the same key with different slot or person must conflict. A database uniqueness rule alone is not the entire retry protocol: the losing duplicate attempt must roll back a provisional capacity decrement before reading and returning the existing result.
The discriminating test starts two workers behind a barrier, then releases them against the same one-place slot. Require one success, one clean refusal, one booking and remaining capacity zero. A sequential test with two calls could pass even with a race. Also interrupt the response after commit and retry the identical request: the booking ID and capacity must remain unchanged.
This SQL sketch has been reviewed against PostgreSQL's documented locking behavior; it is not a claim that a live PostgreSQL concurrency test was run for this article. A deterministic policy model can exercise the expected decisions locally, while a production implementation needs database-backed race, rollback and retry tests at its actual isolation level.
| Test | Initial or injected state | Required outcome |
|---|---|---|
| Competing requests | One place, two different people | One active booking |
| Identical retry | First request committed; response lost | Same booking ID; no second decrement |
| Changed retry | Same key, different slot | Conflict; original booking unchanged |
| Booking insert fails | Slot claim happened in transaction | Rollback restores capacity |
| Notification unavailable | Booking already committed | Retry outbox delivery; preserve booking |
Identity and Permission Tests Must Change One Thing
A data test should identify the reason a read is refused. Give fictional people P1 and P2 the same display name but distinct internal IDs. A request authorized for P1 must not read P2's record. Name matching is not an identity key. At integration boundaries, retain the source system and identifier namespace as well as the identifier value; two systems can issue the same local number to different people.
For this original authorization mock, a permission is keyed by person, requester organization, purpose and resource scope. Omitting purpose or scope from a cache key can turn permission for one operation into permission for another. Begin with a permit for P1/O1/care/summary, then change only the purpose to analytics and require denial. Change only the person to P2 and require denial again. Each test isolates a different boundary.
Use an explicit policy for overlapping rules. In this mock, an exact organization rule outranks a wildcard organization rule; denial wins at equal specificity; no applicable rule means deny. Those are chosen exercise rules, not universal healthcare authorization requirements. Document a different policy if your actual system requires one.
Expiry is evaluated at read time, even when a cache entry remains within its age limit. Revocation also needs an end-to-end freshness rule. A 30-second local TTL does not bound exposure if the cache repeatedly reloads a stale materialized permission table. Track the projection's verified source watermark or require an authoritative version check before renewing a permit. When freshness cannot be established, this mock denies the read.
Test a stopped invalidation bus and a delayed projection separately. They are different failures. Keep the original permission directive and its versions as the source record, so a decision can be reconstructed and the projection rebuilt. An audit record should include the decision version and requested context without casually copying sensitive record contents into logs.
Reconstruct Versioned Data Without Inventing What a User Saw
The existing clinical-data practice idea is useful when the question is made precise. A fictional observation has three versions: preliminary value 5.2 issued at 09:12, final value 5.4 issued at 11:40 and corrected value 7.1 issued at 14:02. The numbers have no clinical interpretation in this exercise.
Define the query as “Which version had been released by this instant?” Select the greatest issuance timestamp at or before the requested instant, with a stable version tie-break if timestamps can be equal. A query at 08:00 returns no released result; 10:00 returns preliminary; 12:00 returns final; exactly 14:02 returns corrected. Using specimen collection time would answer a different question.
If a later correction invalidates a prior value, preserve the history needed to reconstruct the earlier released state. Separate current truth from historical release. Neither proves what a clinician actually saw: replica lag, application caching and whether the user opened the view can differ. Reconstructing actual display requires relevant access and rendering evidence. Do not silently substitute release history for that evidence.
For a small chain already sorted by release time, binary search finds the boundary. For a large offline batch, sort queries and versions by chain and time, then sweep each chain with a forward-only pointer. Test the inclusive boundary, an empty answer before the first version, shuffled query order and a chain transition. State the sorting and storage costs rather than calling a multi-pass external job “two reads” without its preparation work.
Design Recovery Around the User's State
In a composite summary, label each section's freshness and availability. Do not assume that a partially missing summary is suitable for a clinical decision. Which sections are mandatory and how degraded results can be used are requirements to establish with the responsible domain owners. The engineering answer should expose missing information clearly rather than present an incomplete response as complete.
For booking recovery, distinguish a missing response from a failed commit. Query by the idempotency key before repeating an uncertain write. For data-import recovery, retain source versions and stable event IDs so replay does not create duplicate observations. For permission recovery, rebuild the projection from directives while refusing requests whose required freshness cannot be established.
Prepare a project story with the same structure: user problem, invariant, failure, discriminating test, repair and evidence. If you only ran a simulated interleaving, say so. If you tested a database race, name the isolation level and the outcomes. A clear limit makes the result easier to trust.
A Week Connected to the Healthcare Exercises
| Day | Deliverable | Acceptance check |
|---|---|---|
| 1 | Fibonacci implementations and call counts | Match small outputs; reject invalid n |
| 2 | Identity fixture with equal display names | P1 authorization cannot expose P2 |
| 3 | Purpose/scope permission matrix | Changing either dimension can change the decision |
| 4 | Booking race and retry design | One winner; identical retry returns original result |
| 5 | Versioned-result boundary fixture | Exact release time returns the new version |
| 6 | Recovery trace with response loss and stale projection | No duplicate booking; stale permission not renewed |
| 7 | Mixed mock and project review | Explain one failure test and the measured repair |
Spend the review time on mistakes in the contracts, not just on new topics. A test that passes because it checks the wrong person or clock is weak evidence. Ask a reviewer to change one condition and predict the new result before running it.
Sources and Further Reading
- Garner Health: current product context
- Garner Health careers: mission and working expectations
- PostgreSQL: explicit and row-level locking
- HL7 FHIR: Patient and identifiers
- HL7 FHIR: Consent resource
- HL7 FHIR: HTTP versioning and history
Editorial review: October 8, 2026. Fixtures and policy rules are original engineering practice. They do not establish clinical suitability, regulatory compliance or Garner's internal interview criteria.