Interview guides · AdventHealth Sports Med & Rehab Orlando

AdventHealth Sports Med & Rehab Orlando Software Engineer Interview Guide

AdventHealth Sports Med & Rehab Orlando Software Engineer interview guide: reported rounds, coding and design questions, behavioral prep, 7-day plan.

The 60-second brief

Candidates describe this Software Engineer role as building and maintaining software for healthcare delivery at AdventHealth Sports Med & Rehab Orlando: applications that hold patient data and treatment plans, tools for rehabilitation workflows, and larger data systems that feed clinical decision-making. The work is reported as shared with healthcare professionals, IT specialists, product managers and UX/UI designers, so the engineer turns clinical needs into working, secure software.

This guide is for engineers preparing for the Software Engineer loop at AdventHealth Sports Med & Rehab Orlando. It covers the three reported rounds, every reported question (healthcare experience, maintainable code, languages, production incidents, user feedback, patient-system design, privacy and security, rehabilitation tracking, load and performance cases, sorting patient records, searching a healthcare database and four behavioral prompts) and a plan that ties them together. It assumes the 3-5 years of experience that the reported requirements mention.

Candidates report three rounds over roughly 3-5 weeks: an Initial Screening, Technical Interviews that may include coding challenges or system design discussions, and Behavioral Interviews about team dynamics and personal experience.

Focus areas

Software Engineering (General)
Stakeholder Communication
Team Collaboration

Overview

The reported role centres on software that touches patient data, treatment plans and rehabilitation processes, built alongside clinicians, IT staff, product managers and UX/UI designers. Duties candidates list include building applications, troubleshooting, code review, documentation and adding security measures around sensitive health information. For preparation, that means your examples should show software used by non-engineers, and your design answers should start from who uses the system and what happens when it fails.

The requirements candidates describe name Java or C# as must-have languages (Python also appears), web-based applications, an understanding of healthcare data standards, and 3-5 years of experience, preferably in healthcare or another regulated industry. Cloud services such as AWS or Azure and Agile practice are listed as nice-to-have. Pick one language you can code in fluently, and prepare one regulated-industry example if your background is not clinical.

The reported questions are mostly domain-flavoured rather than puzzle-style. Coding prompts are about sorting patient records by urgency and searching a healthcare database. Design prompts cover a patient management system, privacy and security, and a rehabilitation tracking application that scales. Case studies ask about a sudden jump in user load and about improving an existing system. Prepare each with a short opening that states users, data and failure modes before naming any component.

Behavioral preparation carries real weight because the final stage is reported as behavioral interviews on team dynamics and personal experience, and communicating technical ideas to non-technical colleagues is listed as a skill. Two example scenarios are reported: designing a user-friendly interface for elderly patients, and introducing a new technology into a legacy system. Have a story ready for each, plus stories for a difficult teammate, a tight deadline and a project you influenced.

The AdventHealth Sports Med & Rehab Orlando interview process

Candidates describe three stages in order: Initial Screening, Technical Interviews and Behavioral Interviews, over roughly 3-5 weeks. This is what candidates report, not a published process.

Initial Screening

Candidates describe the first stage as a screening of basic qualifications and fit for the role. Little else is reported, so treat it as the place where your background is checked against the listed requirements: Java or C#, web applications, healthcare data standards, and 3-5 years of experience, preferably in healthcare or a regulated field. Prepare a short account of your career that points at those requirements, and a clear answer on which languages you have shipped in.

What to demonstrate

Basic qualifications against the role's stated requirements
Fit for a healthcare software role, including any regulated-industry experience
Clarity when summarising your background and languages

How to prepare

Write a short career summary that names your main language, the web applications you built and one example involving sensitive data.
Prepare an honest answer on healthcare experience; if you have none, choose a regulated project with audit, privacy or compliance requirements.
List the Java, C#, Python, AWS, Azure and Agile items from the reported requirements and note one project of yours for each you can claim.
Ask the recruiter which formats the technical stage uses, since candidates report coding challenges and design discussions as possibilities.

Technical Interviews

Candidates report technical interviews that may include coding challenges or system design discussions. The reported question set suggests the shape: coding around sorting patient records by urgency and searching a healthcare database, design around a patient management system, data security and privacy, and a scalable rehabilitation tracking application, plus case studies on a load spike and on improving an existing system. Practise coding in your chosen language and rehearse design answers that begin with users, data and failure behaviour.

What to demonstrate

Working code if a coding challenge is used
Reasoning about architecture, data and privacy in a design discussion
Approach to diagnosing load and performance problems
Ability to describe past language use and production experience

How to prepare

Implement the urgency sort and a healthcare record search in your language, with tests for ties and missing values.
Outline a patient management system on paper: users, core records, access roles, audit trail and what you would build first.
Prepare a measure-first answer for a load spike and for slow existing systems: metrics, profiling, the first change, and how you verify it.
Write up one production incident from your own work with symptom, diagnosis, fix and prevention.

Behavioral Interviews

The final stage is reported as behavioral interviews about team dynamics and personal experiences. Reported prompts include working with a difficult team member, handling tight deadlines and influencing a project, and the evaluation areas candidates describe include explaining technical ideas to non-technical stakeholders and resolving conflict. Bring concrete stories in which you made decisions, and keep clinical or customer details anonymised.

What to demonstrate

Team dynamics and collaboration across clinical, IT and product roles
Personal experience shown through specific stories
Communication of technical concepts to non-technical people
Conflict resolution and reaching consensus

How to prepare

Write four stories with situation, your action, result and lesson: a difficult teammate, a tight deadline, an influenced project and healthcare experience.
Prepare the two reported scenarios: a user-friendly interface for elderly patients, and a new technology introduced into a legacy system.
Practise explaining one technical decision in plain language, as you would to a clinician or product manager.
Replace every we in your stories with I plus the specific thing you did.

Where candidates lose points

Answering the healthcare experience and language questions with a list of technologies and no specific work

Anchor each language or domain claim in one project: what you built, the constraint that mattered (sensitive data, uptime, audit) and what you decided. If you lack healthcare history, say so and use your closest regulated example.

Sorting patient records by urgency with a bare comparison on one field

Define the ordering first: urgency rank, then a tie-break such as arrival time, a rule for missing or unknown urgency, and a stable sort. Say what you do for a stream of arrivals (a heap) and test ties and empty input.

Saying encrypt everything when asked about security and privacy

Cover who can see what (roles, least privilege), audit logging of access, encryption in transit and at rest, keeping identifiers out of logs and test data, and retention. Tie each control to a threat.

Jumping to scaling components in the patient management or rehabilitation tracking design before knowing the users

Start with the users (clinicians, therapists, front desk, patients), the core records, the write and read paths and what happens when the system is down. Prioritise features out loud and say what you would defer.

Behavioral stories that say we throughout, blame a teammate, or end without a result

Write each story with I, your decision, a measurable or observable result and a lesson. For the difficult-colleague story, include what you changed in your own behaviour.

Questions & practice

Write a function to sort patient records based on urgency.

Medium · Coding / Algorithms

Approach

Clarify the record shape and ordering: the urgency field (a numeric level or triage category and which end is most urgent), the tie-breaker (earlier arrival first), whether the sort must be stable, how missing or invalid urgency is handled, and the input size.
One-off sort with a composite key in O(n log n): in Python, sorted(records, key=lambda r: (-r.urgency, r.arrival)); in Java, Comparator.comparingInt(Record::urgency).reversed().thenComparing(Record::arrival). Python's sort and Java's object List.sort are stable; C#'s List.Sort is not, while LINQ OrderBy/ThenBy is stable.
If urgency has a small fixed number of levels k, bucket the records by level in input order and concatenate: O(n + k) time and stable.
If patients arrive continuously and you repeatedly need the most urgent one, use a priority queue: O(log n) per push and pop. Python's heapq is a min-heap, so push (-urgency, arrival, seq, record), where the sequence counter keeps ties ordered and stops records being compared.
Test the edge cases: an empty list, every record at the same urgency, missing urgency (reject it or place it last, by stated rule), duplicate patient ids and very large inputs.

Follow-up

A patient's urgency changes while they are in the queue. How do you update it?
How would you stop low-urgency patients from waiting indefinitely?
How would you get a stable result from an unstable sort?

How would you implement a search feature for a healthcare database?

Medium · Coding / Algorithms

Approach

Clarify what is searched and by whom: patients by medical record number, name or date of birth, or free text in notes; exact, prefix or fuzzy matching; how many records; and which users may see which results.
Exact identifiers get a B-tree index (MRN, date of birth). For name prefixes, index lower(last_name); in PostgreSQL a B-tree serves LIKE 'smi%' only under the C collation or with text_pattern_ops, so state that.
For misspellings and substrings, use a pg_trgm GIN index (similarity and ILIKE '%x%'), phonetic matching such as Double Metaphone from fuzzystrmatch, and tsvector full-text search for notes. At larger scale, a search engine such as OpenSearch fed by change data capture, accepting a short indexing lag.
If asked to code it in memory: a trie gives prefix lookup in O(L) to reach the node plus the cost of collecting the matches; an inverted index (token to set of ids) handles multi-term queries by intersecting the smallest posting lists first.
Make the API safe: bind parameters rather than concatenated SQL, keyset pagination, a minimum query length, row-level authorisation on results, an audit log of searches, and PHI kept out of URLs (send it in a POST body).

Follow-up

How would you rank results when several patients share a name?
How do you keep a separate search index in sync with the database?
How would a search for 'Jon' also find 'John' without returning thousands of rows?

Collapse a redelivered event batch into per-aggregate high-water marks

Easy · hashing · at-least-once · aggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach

One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.

Follow-up

The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
How do you verify the backfill actually finished, given rows are still being inserted while it runs?

How do you ensure your code is maintainable and scalable?

Medium · Technical / Domain Questions

Approach

Split the answer in two, because the levers differ: maintainability is how cheaply and safely the next engineer can change the code; scalability is how the system behaves as users, requests and data grow. Give one concrete practice for each from your own work.
Maintainability: small modules with one reason to change, dependencies injected behind interfaces so business rules (a scheduling or treatment-plan rule) are unit-testable without a database, tests run in CI on every pull request, code review, and the why recorded in commit messages or architecture decision records.
Scalability: keep the service tier stateless so instances can be added behind a load balancer, move slow work (reports, notifications) onto a queue, index for the real query patterns, and cache read-heavy reference data with an explicit invalidation rule.
Name the trade-off: abstraction layers and caches both add indirection and new failure modes, so I add them when a measurement justifies it (a profile, a slow-query log, a change that had to touch ten files), not speculatively.
Close with evidence, such as p95 latency before and after a change or how much less a later feature touched, so the answer is not a list of principles.

Follow-up

Tell me about a codebase you made easier to change. What did you measure?
When would you decide not to add a cache?
How do you change a shared module without breaking the other teams that call it?

What programming languages are you proficient in, and how have you used them in past projects?

Medium · Technical / Domain Questions

Approach

Rank your languages honestly by depth: the one you write production code in without looking things up, the ones you are working-level in, and the rest. Candidates report Java, C# and Python among the languages listed for this role, so lead with whichever of those you have shipped in.
Tie each main language to a project: what you built, the framework and runtime (Spring Boot on the JVM, ASP.NET Core on .NET, Django or FastAPI in Python), and one decision you made because of the language.
Show depth beyond syntax: garbage collection and its effect on latency, the concurrency tools (Java executors and CompletableFuture, C# async/await with Task, CPython's GIL and when asyncio or multiprocessing fits), and the build and test tooling (Maven or Gradle with JUnit, NuGet with xUnit, pip with pytest).
Cover web work explicitly, since candidates describe web-based application experience as a requirement: REST endpoints, an ORM (Hibernate, Entity Framework, SQLAlchemy) and the SQL it generates.
Have a short comparison ready: why a statically typed language suits a long-lived service holding patient data (compile-time checks, safe refactoring), and where Python is the better fit (scripts, data work, quick tooling).

Follow-up

Describe a bug that was specific to that language and how you found it.
How would you get productive in C# if you have mostly written Java, or the reverse?
What would you watch for when an ORM generates the queries for you?

Can you explain a time you resolved a critical issue in production?

Medium · Technical / Domain Questions

Approach

Tell it in debugging order: the symptom and its impact (which users, which records, which workflow stopped), how it was detected (an alert or a user report), then the sequence of hypotheses you tested and what ruled each one out.
Mitigate before root-causing: roll back the last deploy, turn off a feature flag, scale out or fail over, and say why that was the fastest safe way to stop the impact.
Show the diagnosis as evidence: logs correlated by request id, the metric that shows when the error rate changed, the deploy or config change that lined up with it, and how you reproduced it outside production.
State the fix and how you verified it, then the prevention: a regression test, an earlier alert, a runbook entry and a blameless postmortem with named owners.
For a healthcare system, say how data integrity was checked afterwards: whether any records were written incorrectly or exposed, and how you found and repaired them.

Follow-up

If a schema migration made rollback impossible, what would you have done instead?
How did you keep non-technical stakeholders informed while the issue was open?
Which alert would have caught this earlier, and why did it not exist?

What is your approach to integrating user feedback into software design?

Medium · Technical / Domain Questions

Approach

Collect feedback from more than one channel, because each is biased differently: sessions with the people who use the tool (for clinical software, clinicians, therapists and front-desk staff), support tickets, and product analytics such as task completion and drop-off points.
Turn requests into problems: ask what the user was trying to do and what got in the way, then write it as a user story with acceptance criteria before discussing a solution.
Prioritise with an explicit rule, such as frequency times severity weighed against effort, with anything affecting patient safety or data correctness ahead of convenience; record what was deferred and why.
Validate cheaply before building fully: a clickable prototype, or a feature flag to a small group, then measure the same signal that motivated the change.
Close the loop by telling users what changed and what did not, and give one concrete example from your own work with its before-and-after result.

Follow-up

What do you do when two user groups ask for conflicting changes?
Tell me about feedback you decided not to act on, and how you explained that.
How did you know the change actually helped?

Design a patient management system. What features would you prioritize?

Medium · System Design / Architecture

Approach

Scope first: the users (front desk, clinicians or therapists, billing staff, possibly patients through a portal) and the core flows. For a first version I prioritise registration and demographics, scheduling, visit notes and treatment plans, and defer analytics and portal extras, saying why.
Data model in a relational database, because the entities are related and need transactions: Patient, Provider, Appointment (patient_id, provider_id, start, end, status), Encounter, TreatmentPlan, Note. Prevent double booking with a constraint, for example a PostgreSQL exclusion constraint on provider and time range, not only an application check.
Architecture: web client to an authenticated API, services or modules for patients, scheduling and clinical records, a queue for reminders and notifications, and an indexed patient search. If records must flow to or from an EHR, use a standard interface such as HL7 FHIR rather than ad hoc exports.
Security and records handling: role-based access, an audit log of every read and write of a chart, encryption in transit and at rest, and versioned notes, since clinical records are amended rather than overwritten.
Reliability: the workload is read-heavy, so cache schedules and add read replicas; take backups with point-in-time recovery; and make sure scheduling still works when the notification service is down.

Follow-up

How do you stop two staff members booking the same slot at the same moment?
How would you detect and merge duplicate patient records?
What changes if several clinics share one deployment?

How would you handle data security and privacy in a healthcare application?

Medium · System Design / Architecture

Approach

Start from the data and the rules: identify which fields are protected health information and name the governing regulation (in the US, the HIPAA Privacy and Security Rules), which shapes the access-control, audit and breach-handling requirements.
Access: single sign-on with MFA, role- or attribute-based access with least privilege (a therapist sees their own patients), and an emergency break-glass path that is logged and reviewed afterwards.
Encryption: TLS for everything in transit, encryption at rest with keys held in a managed KMS and rotated, secrets in a vault rather than in code or config files, and field-level encryption or tokenisation for the most sensitive identifiers.
Application security: bind parameters instead of string-built SQL, output encoding, OWASP Top 10 checks, dependency scanning, short-lived tokens and session timeouts, and no PHI in logs, URLs or error messages.
Operations: an append-only audit trail of who accessed which record, alerts on unusual access patterns, de-identified data in non-production environments, encrypted backups, and a written incident-response plan.

Follow-up

How would you let an analyst work with patient data without exposing identities?
A developer needs production data to debug an issue. What do you allow?
How would you detect an employee viewing records they have no reason to see?

Explain the architecture of a scalable rehabilitation tracking application.

Medium · System Design / Architecture

Approach

Scope the flows: therapists assign exercise programmes and review progress; patients log sessions (exercise, sets, reps, pain score) from a phone, possibly with wearable data. That means many small writes from patients and aggregate reads for therapist dashboards.
Components: mobile and web clients, a load-balanced stateless API, a relational database for programmes and assignments, an append-only session-event table partitioned by time, and object storage behind a CDN for exercise videos.
Make the mobile client work offline: queue logs locally and sync with a client-generated UUID as an idempotency key, so a retried upload cannot create duplicate sessions.
Do the heavy work asynchronously: a queue for reminders, and a job that computes per-patient adherence and progress summaries so dashboards read precomputed rows instead of scanning raw events.
Scale and protect it: add instances to the stateless tier, read replicas and caching for dashboards, and the same PHI controls as any clinical system (authentication, encryption, audit logging), plus monitoring on sync failures.

Follow-up

How would you ingest wearable data arriving at a high rate?
How do you resolve conflicts when the same programme is edited on two devices?
Which progress metric would you show a therapist, and how is it computed?

How would you approach a sudden increase in user load on a healthcare application?

Medium · Problem-solving / Case Studies

Approach

Triage before acting: confirm the load is real users and not a retry storm, a bot or an attack, by breaking request rate down by endpoint and client and checking error rate, p95/p99 latency and saturation (CPU, memory, database connections).
Mitigate immediately: scale out the stateless tier, add read replicas or caching for hot reads, rate-limit, and shed or defer non-essential work (reports, bulk exports) so clinical workflows keep working; add circuit breakers on slow dependencies.
Find the real bottleneck, which is often the database: connection-pool exhaustion or a few slow queries. Use the slow-query log and EXPLAIN ANALYZE, and put a connection pooler such as PgBouncer in front if connections are the limit.
Stop clients amplifying the problem: retries with exponential backoff and jitter, timeouts shorter than the caller's, and idempotent writes so retries are safe.
Afterwards: load-test above the observed peak, autoscale on a signal that rises before users feel it (queue depth, CPU), level write spikes with a queue, and plan capacity for known scheduled peaks.

Follow-up

Autoscaling added servers but latency got worse. Why might that happen?
Which requests would you shed first, and how would you implement it?
How would you load-test this without affecting real patients?

What steps would you take to improve the performance of an existing system?

Medium · Problem-solving / Case Studies

Approach

Define the target first: which operation, which percentile (p95 or p99, not the average), and what number counts as done; take a baseline from production metrics or an APM tool.
Measure where the time goes with tracing and profiling rather than guessing; Amdahl's law caps the gain from optimising a step at that step's share of total time.
Work through the usual causes from cheapest to fix: missing or unused indexes (check with EXPLAIN ANALYZE), N+1 queries from the ORM, unbounded result sets without pagination, repeated work that can be cached or batched, synchronous work that can move to a queue, then algorithmic fixes.
Change one thing at a time, measure again under a comparable load, and confirm correctness did not regress, since caching and batching can serve stale or wrong data.
Keep it fixed: a performance test in CI for the hot path, dashboards and an alert on the latency percentile you improved.

Follow-up

How do you find and fix an N+1 query?
When does adding an index make the system slower?
The median is fine but p99 is bad. Where do you look?

Edge instances grow 400 MB per hour until the nightly restart

Hard · memory leak · heap analysis · metric cardinality

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

Approach

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

Follow-up

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

Suggested practice checklist

Seven days built around the three reported rounds, the reported coding, design, case-study and behavioral questions, and the languages and cloud tools listed in the requirements. Practice-library exercises are added only where they match a skill the loop calls for.

Day 1 — Map the loop and your evidence

Write the reported sequence (Initial Screening, Technical Interviews, Behavioral Interviews) and mark the stage you are least ready for.
Build a grid of the reported requirements (Java or C#, web applications, healthcare data standards, AWS or Azure, Agile) and note one project of yours as evidence for each.
Write a short career summary that leads with your strongest match.

Deliverable: A one-page loop map, a requirements-evidence grid and a career summary.

Day 2 — Coding: urgency sort and record search

Implement the patient-record urgency sort in your main language, with urgency rank then arrival time, a rule for missing urgency and a stable ordering.
Implement a search over patient records: exact lookup by identifier, prefix search by name, and state what index you would use for each in a database.
Write tests for ties, empty input and duplicate records, and state the complexity of each approach.
Optional extra from the practice library: the redelivered-events exercise, to practise grouping records by key.

Deliverable: Working, tested code for the sort and the search with a complexity note for each.

Day 3 — Design: patient management and privacy

Outline a patient management system: users, core records, which features come first and which wait.
Write the access model: roles, least privilege, audit trail, encryption, what is excluded from logs and test data.
Say aloud how the design behaves when a dependency is unavailable during a clinic day.

Deliverable: A one-page design with a prioritised feature list and a security and privacy section.

Day 4 — Scale, load and performance

Outline a scalable rehabilitation tracking application: records, session data, reads versus writes and a growth path.
Write a measure-first checklist for a sudden jump in user load and for slowness in an existing system: metrics, profiling, first fix, verification.
Optional extra from the practice library: the memory-growth debugging exercise and the join fan-out exercise, as practice for diagnosis and query tuning.

Deliverable: A rehabilitation tracking design and a one-page load and performance playbook.

Day 5 — Engineering experience answers

Prepare a spoken answer on your languages with one project each, and a set of maintainability habits you can name from real work (tests, review, interfaces, documentation).
Write up one production incident: symptom, diagnosis order, fix and prevention.
Describe how you take user feedback into design, using the elderly-patient interface scenario as the example.

Deliverable: Three spoken answers and an incident write-up, each recorded once and reviewed.

Day 6 — Behavioral stories

Write four stories (healthcare experience, difficult colleague, tight deadline, project influence) with situation, your action, result and lesson.
Prepare the legacy-system technology story and a plain-language explanation of one technical decision.
Say each story aloud and cut anything that does not show your own decision.

Deliverable: Four written stories plus the legacy-system story, each trimmed to the decision and result.

Day 7 — Full rehearsal

Run the screening pitch, then a coding question aloud, then a design question aloud.
Answer two behavioral prompts with I-only wording.
Review weak spots and list questions to ask at the end.

Deliverable: One recorded full run-through with a list of fixes and questions to ask.

Behavioral stories for a healthcare engineering team

Candidates describe the final stage as behavioral interviews about team dynamics and personal experiences. The skills they list include conflict resolution, reaching consensus and explaining technical ideas to non-technical colleagues, so choose stories with clinicians, designers, product managers or other non-engineers in them.

How would you approach designing a user-friendly interface for elderly patients?
Describe a time when you had to implement a new technology in a legacy system.

Describe your experience with healthcare software development.

Medium · Technical / Domain Questions

Approach

Choose one real system and say what it did, who used it (clinicians, front-desk staff, patients) and which part you built or decided. If you have no healthcare job, use the nearest regulated work, such as payments, insurance or anything with audit and privacy duties, and say so plainly.
Name the constraints that made it different from ordinary software: sensitive personal data, role-based access, audit trails, integration with other systems through a data standard such as HL7 or FHIR if you actually used one, and low tolerance for downtime in a clinical workflow.
Give one decision with a trade-off, for example masking identifiers in logs and test data, or choosing a safe default when a downstream system was unavailable, and state the measurable or observable result.
Close with what the work taught you about working with non-engineers: how you learned the clinical workflow, and what you changed after watching someone use the software.

Follow-up

How did you keep sensitive data out of logs, test environments and screenshots?
How did you learn what clinicians or other non-technical users needed, and what did you change because of it?
Which healthcare data standard or integration did you work with, and what went wrong with it?

Describe a situation where you had to collaborate with a difficult team member.

Medium · Behavioral / Leadership

Approach

Use a real conflict with a colleague whose working style or priorities clashed with yours, and describe behaviour and impact, not personality: missed handoffs, repeated review disputes, changing requirements without notice.
Show that you tried directly first: a private conversation to understand their constraint, then a shared written agreement on the points in dispute, such as review turnaround or interface contracts.
Show what you changed on your side as well; a story where only the other person was at fault reads as blame and hides your own contribution.
State the outcome with evidence, such as fewer reopened reviews or a delivered milestone, and what you would do earlier next time. Escalate to a manager only if you describe it as a late step after direct attempts.

Follow-up

What would you have done if they had not changed at all?
How did you give them feedback, and how did they respond?
What did the situation reveal about your own habits?

How do you handle tight deadlines and project pressures?

Medium · Behavioral / Leadership

Approach

Pick one concrete deadline and state the date pressure, the stakes (for example a release that clinical staff depended on) and what you owned. Skip general statements about working well under pressure.
Show triage: list what must work, what can be reduced, and what can wait. For healthcare software, protect correctness, privacy and data integrity, and cut polish or secondary features.
Show communication: you told stakeholders early what would and would not ship, offered options (reduced scope, later date, extra help), and let them choose with the cost spelled out.
Report the result honestly, including what was deferred, the follow-up work you scheduled, and what you changed in planning afterward. A story that ends in unplanned overtime with no process change is the weak version.

Follow-up

How did you decide what to cut, and who agreed to it?
What happened to the deferred work afterward?
What would you have done differently in planning to avoid the crunch?

Give an example of how you influenced a project in a previous role.

Medium · Behavioral / Leadership

Approach

Choose a project where you had no formal authority over the outcome and changed its direction: a design, a testing practice, a rollout plan, an interface decision. Be exact about which decision moved because of you.
Describe how you built the case: the problem with evidence (incident count, user complaints, review findings), two or three options with costs, and a recommendation.
Show who you brought along, such as a product manager, a UX/UI designer or clinical users, and how you handled the person who disagreed, ideally with a small trial or pilot rather than argument.
Give the result and separate your contribution from the team's. The usual mistake is claiming a team outcome as personal, or defining influence as overruling others.

Follow-up

Who opposed it, and what changed their mind?
How did you measure whether the change helped?
What would you have done if your recommendation had been rejected?