Interview guides · 3Y Health
3Y Health Software Engineer Interview Guide
3Y Health Software Engineer interview prep: the reported rounds, coding and system design questions with worked approaches, and a 7-day plan.
The 60-second brief
3Y Health is a healthcare technology employer. Candidates cite a role description that mentions healthcare products such as EHR systems and patient-facing tools. The responsibilities it lists include defining requirements with product managers and designers, code reviews, architecture discussions, testing and debugging, and documentation, with collaboration alongside healthcare professionals and adjacent data science, QA and operations teams. HIPAA awareness appears among the topics candidates are told to be ready for. For interview purposes, treat patient data, access control and auditability as part of the problem in your technical answers.
This guide is for engineers interviewing for a Software Engineer position at 3Y Health, roughly at the 3-5 years of experience the reported requirements describe. It covers the five reported stages, the reported questions across backend fundamentals (REST and GraphQL, dependency injection, SQL tuning, OOP, code quality), system design (URL shortener, caching, microservices, distributed consistency, real-time messaging), debugging and problem-solving, coding (linked lists, strings, binary search, merging) and behavioral prompts. The listed languages are Python, Java and JavaScript, with AWS or Azure and healthcare compliance experience as extras.
Candidates report five stages over about 4-6 weeks: Preliminary Screening, Coding Challenges, System Design Discussion, Behavioral Interview, and an Onsite Interview of multiple rounds that may include technical and behavioral assessments.
Focus areas
- Backend Software Engineering
- Frontend Software Engineering
- Full-Stack Software Engineering
Overview
The reported questions span five groups, and none of them is exotic: technical and domain questions on API styles, dependency injection, slow SQL, code quality and OOP; system design on a URL shortener, distributed consistency, a real-time messaging app, microservices and caching; problem-solving prompts on production troubleshooting, dataset analysis, ambiguous problems, debugging and technical debt; five classic coding problems; and five behavioral prompts. Because the reported coding set is standard, aim for clean, tested code with edge cases handled rather than hunting for a rare trick.
The requirements candidates describe are broad rather than deep in one framework: Python, Java or JavaScript, web development frameworks and tools, software engineering principles and design patterns, with AWS or Azure, healthcare technology or regulatory compliance, and data structures and algorithms listed as extras. The topic areas reported for this role cover backend, frontend and full-stack work plus fundamentals and technical leadership, so also be able to describe a patient-facing screen in your JavaScript framework: state, data fetching against a REST or GraphQL API, accessibility, and keeping PHI out of client storage and logs. Pick one language for the coding stage and be able to discuss the web stack around it: how a request reaches your code, how it is tested, and how it reaches the database.
Healthcare context is worth weaving into design and backend answers. HIPAA appears among the topics candidates are told to be ready for, and one reported example asks how you keep code compliant with healthcare regulations. In a caching answer, say which patient data never goes into a shared cache; in a messaging or microservices answer, mention encryption, access control and audit logs of who read which record. These additions take a sentence each and show you have thought about the data involved.
Candidates cite a role description that mentions working with product managers, designers, healthcare professionals and adjacent teams, and they report a dedicated behavioral stage plus possible behavioral assessments in the onsite. Prepare a small bank of real stories with your own decisions and measurable outcomes, and reuse them across the reported behavioral and problem-solving prompts such as technical debt versus deadlines.
The 3Y Health interview process
Candidates report five stages over roughly 4-6 weeks, and say the process can vary by team. Each stage below gives what candidates report and how to prepare for it.
Preliminary Screening
Candidates list Preliminary Screening as the opening stage, an early look at whether your background suits the role. No question content is reported for it. Treat it as the place to show that your background matches the reported requirements (one of Python, Java or JavaScript, web frameworks, a few years of shipped work) and that your interest in healthcare software is real. Use it also to collect the facts the reports leave open: the format of the coding challenges, which language you may use, and how the onsite is split.
What to demonstrate
- Your qualifications against the reported requirements: Python, Java or JavaScript, web frameworks, design patterns
- Fit for the role, which is how candidates describe the purpose of this stage
How to prepare
- Write a short pitch of one project: the system, your part in it, the stack, and one number that shows the result, so your summary is crisp.
- Prepare an honest answer to why healthcare software, tied to the products candidates cite (EHR systems, patient-facing tools).
- List questions for the recruiter: coding challenge format and language, onsite composition, team, and whether the work touches HIPAA-regulated data.
Coding Challenges
Candidates list Coding Challenges as the second stage, where technical skill is shown through code. Whether they are live or take-home is not reported, so ask. The reports do not tie questions to stages, but the reported coding questions are classic problems: reversing a linked list, the first non-repeating character in a string, the longest substring without repeating characters, binary search, and merging two sorted arrays. Practise them in the language you will use, write the code fully, run it on edge cases, and state the time and space complexity before you are asked.
What to demonstrate
- Technical skills, as candidates describe the purpose of this stage
- The coding and algorithm questions reported for this role, which the reports do not tie to a specific stage
How to prepare
- Solve the five reported coding problems from a blank file, then rewrite each without notes until the code is correct first time.
- For each, write the edge-case tests yourself: empty list or string, one element, all duplicates, target absent, and state complexity and your choice of data structure aloud.
- Practise the pattern behind each: pointer rewiring, hash-map counting, sliding window, binary-search invariants, two-pointer merge.
System Design Discussion
Candidates name System Design Discussion as the third stage. The reports do not tie questions to stages, but the reported design questions are a URL shortening service, data consistency in a distributed system, a real-time messaging application, a microservices architecture, and caching in a web application. Use one repeatable structure: requirements and scale assumptions, API, data model, read and write paths, then scaling, failure modes and trade-offs. Add the healthcare angle where it applies: what data is sensitive and how it is protected and audited.
What to demonstrate
- Architectural thinking and problem-solving, the attribution candidates give this stage
- The system design questions reported for this role, which the reports do not tie to a specific stage
How to prepare
- Outline the URL shortener end to end, including key generation, the 301 versus 302 choice and click analytics off the redirect path.
- Write one page on consistency tools: transactions, saga, transactional outbox, idempotent consumers, read-your-writes, and practise naming the trade-offs (consistency versus availability, cache freshness versus load).
- Sketch the messaging app: WebSocket gateways, session registry, per-conversation ordering, offline sync.
Behavioral Interview
Candidates name Behavioral Interview as the fourth stage, and the reports connect it to how you would work with the team and company. The reported behavioral prompts cover a significant technical challenge, prioritising across deadlines, a difficult team member, motivation and feedback. Answer each with a specific story in STAR form, keep the situation short, and spend most of the answer on what you decided and why. Candidates cite a role description that mentions product managers, designers and healthcare professionals, so have at least one story with a non-engineering partner.
What to demonstrate
- Fit within the team and company culture, as candidates describe this stage
- Collaboration and communication, which the reports list among their evaluation areas
How to prepare
- Write six stories covering a hard technical problem, competing deadlines, a conflict, feedback received, a cross-functional project and a trade-off with technical debt.
- For each, note the decision you personally made and a measurable result, so your own ownership is clear.
- Rehearse the reported prompts aloud, checking each story is told in the first person singular.
Onsite Interview
Candidates describe the Onsite Interview as multiple rounds that may include technical and behavioral assessments. Its exact content is not reported, so prepare for all the reported question types in sequence: coding, design, backend fundamentals, debugging scenarios and behavioral stories. The main risk is uneven readiness, so run at least one full mock day before it.
What to demonstrate
- Multiple rounds that may include technical and behavioral assessments
- The exact mix of sessions is not reported, so confirm it with the recruiter
How to prepare
- Run a mock onsite: one coding problem, one design question, one debugging scenario and two behavioral prompts back to back.
- Prepare crisp explanations of REST versus GraphQL, dependency injection, OOP principles and slow-query tuning, and keep your depth even across coding, design and fundamentals.
- Ask the recruiter how the onsite sessions are split so you can weight the last days of practice.
Where candidates lose points
Off-by-one and pointer bugs on the reported coding problems: left moving backwards in the longest-substring window, an infinite loop in binary search, a lost node in the linked-list reversal.
Write the invariant before coding (what the window or the lo/hi range means), then trace your code by hand on an empty input, a one-element input and a duplicate-heavy input before calling it done.
Answering the slow SQL question with "add an index" and nothing else.
Lead with reading the execution plan, then name the specific causes: non-sargable predicates, wrong composite column order, row multiplication from a one-to-many join, large OFFSET, stale statistics. Mention the write cost of every index you add.
Drawing boxes for the URL shortener or messaging design before stating requirements and the read/write balance.
Open every design answer with scope and rough scale, then the API and data model. Make at least one explicit trade-off per design: 301 versus 302, counter versus hash keys, fan-out on write versus on read.
Treating patient data like any other data in design and backend answers, for example caching records in a shared CDN or logging full payloads.
HIPAA appears among the topics candidates are told to be ready for. In caching, messaging, microservices and debugging answers, add one sentence on access control, encryption, audit logging or what must not be cached or logged.
Behavioral stories told in the plural with no personal decision and no result.
For each story in your bank, write the one sentence that starts with "I decided" and the number that shows the outcome. If you cannot write both, pick a different story.
Questions & practice
Write a function to reverse a linked list.
Medium · Coding / Algorithms
Approach
- Iterative: prev = null, curr = head; loop: save next = curr.next, set curr.next = prev, advance prev = curr and curr = next; return prev. O(n) time, O(1) space.
- Recursive: reverse the rest, then head.next.next = head and head.next = null. O(n) stack space; in Python the default recursion limit of 1000 makes it fail on long lists.
- Test empty list, single node and two nodes, and print the list after reversing to check no node is lost.
- Know the variants: reverse between positions m and n, reverse in groups of k, reverse a doubly linked list by swapping prev and next.
Follow-up
- Reverse only the sublist between positions m and n.
- Reverse the list in groups of k.
- Check whether the list is a palindrome with O(1) extra space.
How would you find the first non-repeating character in a string?
Medium · Coding / Algorithms
Approach
- Two passes: count every character in a hash map (or a fixed array for ASCII), then scan the string again and return the first character with count 1. O(n) time, O(k) space for alphabet size k.
- Mention the brute force first: for each character, scan the rest, O(n^2).
- Edge cases: empty string, all characters repeating (return -1 or None), case sensitivity, and Unicode (Java chars are UTF-16 units, so surrogate pairs need code points).
- Streaming variant: keep counts plus an insertion-ordered structure (LinkedHashMap, OrderedDict, or a queue) and drop the front while its count exceeds 1.
Follow-up
- Characters arrive as a stream; report the answer after each one.
- Make the match case-insensitive.
- How would you handle a string too large for memory?
Solve for the longest substring without repeating characters.
Medium · Coding / Algorithms
Approach
- Sliding window with a map from character to its last index. For each right index, if the character was last seen at or after left, move left to that index + 1; update the map; best = max(best, right - left + 1).
- O(n) time, O(min(n, alphabet)) space; mention the O(n^2) set-based brute force first.
- The common bug: moving left backwards when the repeat lies before the window. Only move left forward (left = max(left, last + 1)).
- Edge cases: empty string, all identical characters, all unique, spaces and symbols. If asked for the substring, track the start index of the best window.
Follow-up
- Longest substring with at most k distinct characters.
- Return the substring itself, not its length.
- How does the solution change for a large Unicode alphabet?
Implement a binary search algorithm.
Medium · Coding / Algorithms
Approach
- Precondition: sorted input. lo = 0, hi = n - 1; while lo <= hi: compute mid with integer division, so in Python write mid = (lo + hi) // 2 because / returns a float; return mid on a match, else move lo or hi past mid; return -1. O(log n) time, O(1) space.
- Overflow matters only in fixed-width languages: in Java or C++, (lo + hi) / 2 can overflow int, so use lo + (hi - lo) / 2 or (lo + hi) >>> 1 in Java. Python integers do not overflow.
- State the loop invariant. For duplicates, write the half-open lower-bound version that returns the first index whose value is >= target, and avoid infinite loops when lo = mid.
- Edge cases: empty array, one element, target below or above every value, repeated targets.
Follow-up
- Find the first and last positions of a target.
- Search a rotated sorted array.
- Compute an integer square root with binary search.
Write a function to merge two sorted arrays.
Medium · Coding / Algorithms
Approach
- Two pointers into a new output array: take the smaller head each step, then append whatever remains. O(n + m) time and space.
- In-place variant where the first array has spare capacity at the end: fill from the back with three pointers so nothing is overwritten. O(1) extra space.
- Take from the first array on ties to keep the merge stable; duplicates are preserved.
- Edge cases: either array empty, all of one array smaller than the other, negative numbers.
- Extensions: merge k sorted arrays with a min-heap in O(N log k); for data larger than memory, an external merge of sorted chunks.
Follow-up
- Merge k sorted arrays.
- Find the intersection of two sorted arrays.
- How would you merge two sorted files that do not fit in memory?
Describe how you would optimize a slow SQL query.
Medium · Technical / Domain Questions
Approach
- Measure before changing anything: capture the exact query and parameters, then run EXPLAIN (ANALYZE, BUFFERS) in Postgres, or EXPLAIN ANALYZE in MySQL 8.0.18 and later (older MySQL has plain EXPLAIN). EXPLAIN ANALYZE really executes the statement, so for INSERT, UPDATE or DELETE run it inside a transaction you roll back, or on a replica. Find the node with the most time and the biggest gap between estimated and actual rows.
- Index fixes: a sequential scan on a selective filter needs an index; for composite indexes put equality columns before range columns; a covering index avoids table lookups. Remember each index slows writes.
- Rewrite predicates that block index use: a function wrapped around the column, a wildcard at the start of a LIKE pattern, an implicit type cast, OR across different columns.
- Fix query shape: aggregate before a one-to-many join so rows do not multiply, replace correlated subqueries with joins or EXISTS, select only needed columns, and use keyset pagination instead of a large OFFSET.
- Check the environment: stale statistics (run ANALYZE), lock waits, table bloat, and ORM N+1 patterns where the slowness is many small queries. Verify the fix on production-sized data.
Follow-up
- An index exists but the planner ignores it. What are the possible reasons?
- A dashboard aggregates a large table every page load. How would you speed it up?
- What does adding this index cost on the write path?
Find version gaps and relay lag with window functions
Medium · window functions · event tables · frame semantics
outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.
Approach
- Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
- Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
- Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
- Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.
Follow-up
- Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
- Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?
Can you explain the difference between REST and GraphQL?
Medium · Technical / Domain Questions
Approach
- REST models resources at URLs and uses HTTP verbs and status codes; the server fixes each response shape. GET requests cache naturally with Cache-Control and ETag.
- GraphQL exposes one endpoint over a typed schema and lets the client select exactly the fields it needs, removing over-fetching and the multiple round trips a screen built from several REST resources needs.
- Trade-offs: GraphQL makes HTTP caching harder (persisted queries or a client-side normalised cache help), invites N+1 resolver queries (batch with a DataLoader), needs depth and cost limits, and reports errors in an errors array, often with status 200.
- Versioning differs: REST usually versions by URL or header; GraphQL evolves one schema and marks fields deprecated.
- Pick by use case: GraphQL for a patient app screen aggregating appointments, messages and profile; REST for simple CRUD, public integrations, webhooks and file uploads. With health data, note GraphQL needs authorisation per field, not only per endpoint.
Follow-up
- How would you stop a deeply nested GraphQL query from overloading the database?
- How do you enforce field-level authorisation in a GraphQL API?
- How would you cache GraphQL responses?
What is the purpose of dependency injection in software development?
Medium · Technical / Domain Questions
Approach
- Define it: an object receives its collaborators (repository, HTTP client, clock) from outside, through the constructor, a setter or a parameter, instead of constructing them itself. It is one form of inversion of control.
- Purpose: testability (pass a fake repository or notifier in a unit test), loose coupling to interfaces rather than concrete classes, and per-environment configuration without code changes.
- Give a concrete example: an AppointmentService taking a Repository and a Notifier in its constructor; production wires the real database and SMS client, tests wire in-memory fakes.
- Name the tooling in your language: Spring in Java, NestJS or plain constructor wiring in JavaScript, FastAPI Depends or manual wiring in Python, and scopes (singleton versus per-request, such as a database session).
- Costs: indirection, wiring errors that surface at startup or runtime, and over-abstraction. Contrast with the service locator pattern, which hides dependencies inside the class.
Follow-up
- What is the difference between dependency injection and a service locator?
- How would you scope a database session per request?
- Can you do dependency injection without a framework? Show it.
How do you ensure code quality in your projects?
Medium · Technical / Domain Questions
Approach
- Answer in layers: automated formatting and linting (Prettier and ESLint, black or ruff, Checkstyle), static typing (TypeScript, mypy), and a test pyramid of many unit tests, fewer integration tests and a few end-to-end tests, all gated in CI on every pull request.
- Code review: small pull requests, review for correctness, design and readability, leave style to tools, and require tests with behaviour changes.
- Feedback from production: error tracking, monitoring and postmortems whose action items include a regression test.
- Make it domain-specific: in a healthcare codebase, add checks that patient data is not logged and that access-controlled endpoints have authorisation tests.
- Close with a real example and a number: a bug class you eliminated, or flaky tests you fixed and the change in CI pass rate.
Follow-up
- A teammate wants to skip tests to make a deadline. What do you do?
- What test coverage target do you find useful, and why?
- How do you deal with flaky tests?
What are the key principles of object-oriented programming?
Medium · Technical / Domain Questions
Approach
- Name and define the four: encapsulation (state hidden behind methods that protect invariants), abstraction (expose what an object does, not how), inheritance (reuse through an is-a relationship), polymorphism (one interface, behaviour chosen at runtime through dynamic dispatch).
- Use one running example, such as a Notifier interface with Email and SMS implementations that the caller uses without knowing which it holds.
- Go past the definitions: prefer composition over inheritance, explain the fragile base class problem, and give the Liskov substitution violation of Square extending Rectangle.
- Connect to SOLID and a few design patterns (strategy, factory, observer), since the reported requirements list design patterns.
- Note language differences: Java interfaces versus abstract classes, Python duck typing and abstract base classes, JavaScript prototypes behind class syntax.
Follow-up
- When would you choose composition over inheritance?
- Give an example that violates Liskov substitution and how to fix it.
- Interface versus abstract class in Java: when do you use each?
Design a URL shortening service. What considerations would you take into account?
Medium · System Design / Architecture
Approach
- Requirements first: create a short link, redirect, optional custom alias and expiry, click analytics. State that reads (redirects) far outnumber writes and make rough capacity assumptions aloud.
- Key generation: base62 encoding of a counter (7 characters gives about 3.5 trillion codes), with counter ranges handed out to each app server; or a truncated hash of the URL with collision checks; or random codes with a uniqueness check. Counters are compact but enumerable.
- Storage: a key-value mapping of short code to long URL with owner, created_at and expiry, looked up by primary key and partitioned by code.
- Read path: cache hot codes in Redis in front of the store. Choose 301 (browsers cache it, less load, lost analytics) or 302 (every click reaches you). Send click events to a queue so analytics never slow the redirect.
- Abuse and lifecycle: rate-limit creation, screen malicious URLs, expire and clean up old links, reserve custom aliases in the same keyspace.
Follow-up
- How do you stop custom aliases colliding with generated codes?
- How would you count clicks per link at high volume?
- What happens to redirects if the cache cluster fails?
How would you handle data consistency in a distributed system?
Medium · System Design / Architecture
Approach
- Start per data type: decide which operations need strong consistency (an order or a medication change) and which tolerate eventual consistency (feeds, counters). Frame it with CAP and PACELC.
- Within one service, use ACID transactions. Across services, avoid two-phase commit (blocking, coordinator failure) and use a saga with compensating actions, orchestrated or choreographed.
- Publish events reliably with a transactional outbox (write the event in the same transaction, relay it afterwards) and make consumers idempotent with dedupe keys, because delivery is at-least-once.
- For replicas: read-your-writes by routing a user's reads to the leader after a write or tracking replica lag; quorum reads and writes with R + W > N; conflict resolution by version vectors or CRDTs rather than blind last-write-wins.
- For concurrent updates: optimistic locking with a version column, or distributed locks with fencing tokens.
Follow-up
- How does the outbox pattern prevent lost or phantom events?
- What happens when a saga's compensation step itself fails?
- How do you guarantee a user sees their own update immediately?
Describe the architecture of a real-time messaging application.
Medium · System Design / Architecture
Approach
- Scope: one-to-one and group chat, delivery and read receipts, presence, offline delivery, history, multiple devices, ordering within a conversation.
- Connections: clients hold WebSocket connections to gateway servers; a session registry (user to gateway, in Redis) lets the backend find recipients; fall back to long polling.
- Message flow: the chat service assigns a per-conversation sequence number, persists the message, then fans out over pub/sub to recipients' gateways. Offline users get a push notification and sync everything after their last acknowledged sequence on reconnect.
- Storage: partition messages by conversation_id and order by sequence, matching the main read of the latest N messages. Clients send a generated message ID so retries are idempotent.
- For a patient engagement setting, add encryption in transit and at rest, retention rules and audit logging of who accessed which conversation.
Follow-up
- How do you handle one user on two devices?
- How would you implement presence without flooding the system?
- How does fan-out change for very large groups?
What would you include in a microservices architecture?
Medium · System Design / Architecture
Approach
- Open with when to split: a small team often does better with a modular monolith. Then decompose by business capability, with each service owning its data.
- Core components: API gateway (authentication, rate limiting, routing), service discovery, synchronous REST or gRPC plus asynchronous messaging, containers with an orchestrator, and an independent CI/CD pipeline per service.
- Resilience: timeouts on every call, retries with exponential backoff and jitter, circuit breakers, bulkheads, idempotency keys and health checks.
- Observability: centralised logs, metrics and distributed tracing with a correlation ID across services. Security: mutual TLS between services, least-privilege credentials, and audit trails for access to patient data.
- Cross-service data: sagas and events instead of a shared database, plus contract tests and API versioning so services deploy independently.
Follow-up
- How would you split an existing monolith without a rewrite?
- A request is slow across five services. How do you find where?
- How do you prevent one slow downstream service from causing a cascading failure?
Explain how you would implement caching in a web application.
Medium · System Design / Architecture
Approach
- Name the layers: browser caching (Cache-Control, ETag), CDN for static assets, an application cache such as Redis or Memcached, and precomputed results such as materialised views. Cache by read-to-write ratio and recomputation cost.
- Patterns: cache-aside (on a miss, load from the database and set with a TTL), write-through, write-behind. Invalidate by deleting the key after the database commit, with a TTL as a backstop.
- Failure modes: stampede when a hot key expires (request coalescing, a lock, early refresh), repeated misses on absent keys (cache negatives or a Bloom filter), stale-data races between writers, hot keys.
- Eviction and sizing: LRU or LFU, memory limits, and hit rate plus latency as the metrics to watch.
- Sensitive data: never put patient records in a shared CDN cache; use Cache-Control private or no-store, per-user keys, and encryption where the cache holds protected data.
Follow-up
- Two writers update the same record. How do you keep the cache consistent?
- A very popular key expires under heavy load. What happens and how do you prevent it?
- What data would you refuse to cache, and why?
Given a dataset, how would you approach analyzing it for patterns?
Medium · Problem-Solving / Case Studies
Approach
- Clarify the question the analysis must answer, the grain of the data (one row per what) and where it comes from.
- Check quality: missing values, duplicates, outliers, units, time zones; then summary statistics and distributions, using SQL or pandas.
- Explore: segment with group-bys, look at trends and seasonality over time, compute correlations and plot histograms, scatter plots and time series.
- Validate before reporting: sample size, confounders, Simpson's paradox, and a hold-out check. Report findings with caveats, and limit access to de-identified data when it concerns patients.
Follow-up
- You find a strong correlation between two metrics. How do you test whether one drives the other?
- The dataset does not fit in memory. What do you do?
- A key column is 30% missing. How do you handle it?
How would you approach a problem with no clear solution?
Medium · Problem-Solving / Case Studies
Approach
- Restate the problem and define what a good outcome looks like; list what is known and unknown.
- Gather information cheaply: look at data, talk to users and stakeholders (product, healthcare professionals, support), check prior art, and time-box a spike or prototype.
- Generate two or three options, compare trade-offs, prefer reversible steps, and define in advance what signal would show the choice was wrong.
- Illustrate with a real example where you followed this and what happened.
Follow-up
- How do you decide when to stop investigating and commit?
- Tell me about a time your first approach failed.
- How did you get others to agree on the direction?
How do you balance trade-offs in project timelines with technical debt?
Medium · Problem-Solving / Case Studies
Approach
- Classify the debt: deliberate or accidental, and what interest it charges (slower changes, incidents, compliance risk).
- Decide by comparing cost of delay with that interest; when you take a shortcut, track it as a ticket with a payback plan. Refuse shortcuts on security and compliance paths such as access to patient data.
- Mechanisms: a standing share of each iteration for debt, refactoring code you are already changing, and explaining debt to product managers in their terms (delivery speed, defect rate).
- Give a real example of debt you took on knowingly and how and when it was repaid.
Follow-up
- How do you convince a product manager to fund a refactor?
- Tell me about debt you chose to take on.
- How do you keep track of technical debt?
What steps would you take to troubleshoot a production issue?
Medium · Problem-Solving / Case Studies
Approach
- Triage: establish scope and severity (which users, which endpoints, since when), open an incident channel and assign roles if it is large.
- Mitigate before finding the root cause: roll back the latest deploy, turn off a feature flag, scale out or fail over.
- Investigate with evidence: error rate, latency and saturation dashboards, logs joined by correlation ID, traces. Correlate the start time with deploys, config changes, traffic shifts and dependency outages, then narrow by bisection.
- In a healthcare system, also check data integrity (records written wrongly during the incident) and any exposure of patient data.
- Close the loop: root-cause fix with a regression test, a blameless postmortem with owned action items, and an alert that would have caught it sooner.
Follow-up
- The deploy included a database migration, so rollback is unsafe. What now?
- How do you tell whether your service or a dependency is at fault?
- What goes into the postmortem?
Describe your thought process in debugging a complex issue.
Medium · Problem-Solving / Case Studies
Approach
- Reproduce reliably and shrink to a minimal case; for intermittent bugs, record the conditions (load, input, timing) and add targeted logging.
- Form hypotheses and test the cheapest to falsify first; bisect over commits (git bisect), inputs or system layers.
- Use the right tools: debugger, structured logs, traces, profilers; question assumptions about config, versions and environment differences.
- Know the hard classes: race conditions, memory leaks, stale caches, time-zone and encoding bugs. Fix the root cause, add a regression test and write down what you found.
Follow-up
- How do you debug a problem that only appears in production?
- How does git bisect work?
- Walk through debugging a race condition.
Suggested practice checklist
Each day covers one group of this guide's reported questions, moving from coding to backend fundamentals, design, debugging and behavioral stories, and ends with a mock run of the multi-session onsite.
Day 1 — Pointer and array problems
- Write the iterative and recursive linked-list reversal from a blank file and test empty, one-node and two-node lists.
- Implement binary search plus a lower-bound version for duplicates; check it on an empty array and a missing target.
- Merge two sorted arrays into a new array, then in place from the back.
Deliverable: Three tested solutions (reversal, binary search with lower bound, two merge versions), each with its complexity written above it.
Day 2 — String problems with hash maps and sliding windows
- Solve the first non-repeating character with two passes, then the streaming variant with an ordered structure.
- Solve the longest substring without repeating characters with a last-index map; add a test where the repeat sits before the window.
- Re-solve all five coding problems in your interview language without notes, timing yourself.
Deliverable: Two string solutions with edge-case tests, and a list of mistakes from the re-solve to fix on day 7.
Day 3 — Backend fundamentals, SQL and a frontend sketch
- Write a comparison table of REST and GraphQL covering caching, N+1, versioning, errors and field-level authorisation.
- Write a small class that takes its repository through the constructor and test it with a fake; use it to explain dependency injection and the four OOP principles.
- Take a slow query on a local Postgres table, read its EXPLAIN ANALYZE output (inside a rolled-back transaction if it modifies data), fix it with an index or rewrite, and record before and after; then do the window-function practice problem.
- Sketch a patient-facing screen in your JavaScript framework: state and data fetching against a REST or GraphQL API, accessibility basics, and keeping PHI out of browser storage and logs.
Deliverable: The comparison table, a tested DI example, a before/after query plan, a one-paragraph code-quality answer and a short frontend sketch.
Day 4 — Design: URL shortener and caching
- Outline the URL shortener: requirements, key generation, storage, cache, 301 versus 302, analytics queue, abuse controls.
- Outline caching for a web application: layers, cache-aside with invalidation, stampede protection, and which patient data is never cached.
- Explain both designs aloud from memory using the same structure.
Deliverable: Two one-page design outlines, each ending with a list of three trade-offs.
Day 5 — Design: distributed systems
- Write a one-page reference on consistency: transactions, saga, outbox, idempotent consumers, read-your-writes, quorums.
- Sketch the real-time messaging app: gateways, session registry, sequencing, offline sync, storage layout, security.
- List the components of a microservices architecture and the resilience patterns, then explain how to debug a slow cross-service request.
Deliverable: A consistency reference page, a messaging diagram and a microservices checklist.
Day 6 — Debugging and problem-solving scenarios
- Write your production-incident sequence (triage, mitigate, investigate, postmortem) and attach a real incident from your work to it.
- Outline your debugging method with one example of a hard bug, including how you bisected it.
- Prepare answers on analysing a dataset, approaching a problem with no clear solution, and trading deadlines against technical debt, each with a real example.
Deliverable: Five short written answers, each tied to a real example from your experience.
Day 7 — Behavioral stories and a mock onsite
- Write six STAR stories and map them to the reported behavioral prompts; check each has an "I decided" sentence and a number. Include one story about Agile methods on a past project.
- Run a mock onsite with a friend: one coding problem, one design question, one debugging scenario and two behavioral prompts back to back.
- Revisit the mistakes list from day 2 and re-solve any problem you missed.
Deliverable: A story bank mapped to each behavioral prompt, notes from the mock onsite, and a clean re-solve of every missed problem.
Behavioural preparation
Candidates report a dedicated Behavioral Interview tied to team and culture fit, and say the onsite may include behavioral assessments too. Candidates cite a role description that mentions product managers, designers, healthcare professionals and adjacent teams, so prepare stories that show your own decisions, how you worked with non-engineers, and measurable results.
- Describe your experience with Agile methodologies in past projects.
Tell me about a time you faced a significant technical challenge. How did you overcome it?
Medium · Behavioral / Leadership
Approach
- Pick a challenge with real technical depth that you drove yourself: a performance problem, a migration, a hard production bug. Give the situation and the stakes briefly.
- Spend most of the answer on actions: how you diagnosed it, the options you considered and why you rejected them, and how you reduced risk (feature flag, staged rollout, backfill check).
- End with a measured result (latency, error rate, hours saved) and what you changed afterwards.
- What sinks it: a team story with no clear personal contribution, or a challenge caused by your own poor planning with no reflection on it.
Follow-up
- Which alternatives did you reject, and why?
- What would you do differently now?
- How did you keep non-engineering stakeholders informed?
How do you prioritize tasks when you have multiple deadlines?
Medium · Behavioral / Leadership
Approach
- State your method: separate hard deadlines from soft ones, then rank by impact, cost of delay and whether the task blocks others.
- Show communication: you flagged early what would slip, negotiated scope (shipping a smaller first version) and confirmed priorities with your manager or product manager instead of deciding silently.
- Anchor it in a real collision of deadlines: what you shipped, what you deferred, and the outcome.
- What sinks it: saying you simply work longer hours, or answering in general terms without one example.
Follow-up
- Tell me about a deadline you missed.
- How do you handle an urgent request from another team that conflicts with your commitments?
- How do you estimate a large task?
Describe a situation where you had to collaborate with a difficult team member.
Medium · Behavioral / Leadership
Approach
- Choose a professional friction (blocking code reviews, missed commitments, disagreement over design) and describe the behaviour neutrally, not the person's character.
- Actions: a private conversation to understand their view, a shared goal, and concrete working agreements such as writing a design doc before coding or review turnaround expectations. Escalate only after trying directly.
- Result: how the project and the working relationship ended up, and what you changed in your own behaviour.
- What sinks it: blaming, going to the manager first, or a story where you simply prove the other person wrong.
Follow-up
- What would you have done if the direct conversation had failed?
- What part of the friction came from you?
- How did it affect the rest of the team?
What motivates you to perform at your best?
Medium · Behavioral / Leadership
Approach
- Name one or two specific motivators and back each with something you did: for example, fixing a workflow after watching users struggle, or seeking out the hardest performance problem on the team.
- Connect to this role only where true: the healthcare products candidates cite (EHR systems, patient-facing tools) and work alongside healthcare professionals.
- Mention what drains your motivation and how you manage it; it shows self-awareness.
- What sinks it: generic enthusiasm with no example, or a list of five motivators with nothing behind them.
Follow-up
- Tell me about a project that did not motivate you and how you handled it.
- Why healthcare software?
- What kind of work would you prefer not to do?
How do you handle feedback on your work?
Medium · Behavioral / Leadership
Approach
- Tell a story with a specific piece of feedback (a review comment on over-engineering, a note that your updates were unclear), your first reaction, what you changed, and evidence that the change held.
- Show that you ask for feedback: reviewers, retrospectives, a manager check-in.
- Cover disagreement: ask for examples, test the feedback, push back with data if needed, and commit once a decision is made.
- What sinks it: feedback that is a disguised strength, or a defensive tone when telling the story.
Follow-up
- Tell me about feedback you disagreed with.
- How do you give hard feedback to a peer?
- What is the most recent feedback you received?