AdventHealth Medical Group Tampa Software Engineer Interview Guide

The 60-second brief

AdventHealth Medical Group Tampa is a healthcare organisation, and candidates describe the Software Engineer role as building software for patient care and for the operational work around it. The reported work covers databases, backend processes and user interfaces, done alongside product managers, UX designers and other engineers. Reported day-to-day duties include writing maintainable code, testing it, taking part in code reviews, and fixing software problems quickly enough to limit disruption to operations. Candidates describe the requirements as proficiency in a language such as Java, Python or C#, web development frameworks, API development and integration, and familiarity with database management systems, with HIPAA knowledge and cloud platform experience listed as nice-to-haves.

This guide is for candidates interviewing for a Software Engineer role at AdventHealth Medical Group Tampa. It covers the five reported stages, the reported technical, problem-solving, coding and behavioral questions, and a seven-day plan. The questions reported for this role are general engineering questions, so the guide concentrates on core language knowledge, data structures, debugging, engineering practice and well-built stories.

Candidates report five stages: a phone screening, in-person interviews, technical assessments, behavioral questions and final evaluations, spread over roughly 4-6 weeks. Another account of the same process gives 3-4 weeks, so ask your recruiter for the schedule that applies to you.

Focus areas

• Outpatient Coding Guidelines
• Healthcare Coding Knowledge
• Coding Policy Compliance

Overview

The reported questions for this role are general software engineering questions rather than healthcare trivia. Candidates describe language choice, the principles of object-oriented programming, code quality, version control, designing a feature for an existing application, handling a production bug and weighing technical trade-offs. The coding set is classic: reverse a linked list, sort an array of integers, explain stacks versus queues, and speed up a search over a large dataset. Preparing these thoroughly covers most of what has been reported.

The requirements candidates describe point to a web and data stack: Java, Python or C#, a web framework, API development and integration, and database management systems. Pick one of those languages as your interview language and be ready to write it fluently without autocomplete. Revise the parts of that stack you can be asked about in conversation: how an API request reaches a database, how you would page through a large table, and how you would test an endpoint.

Behavioral questions make up a large share of the reported list: team conflict, deadlines and priorities, adapting to change, mentoring junior colleagues, leading a project, and troubleshooting performance in your own code. Reports also say the process involves hiring managers and team members, and the responsibilities mention cross-functional work with product managers and UX designers. Build a small bank of real stories that can each answer several prompts, and practise explaining technical decisions to a listener who does not write code.

Spend your time in this order: first the coding fundamentals you can write from memory, then the engineering-practice answers you can say aloud in your own words, then the story bank. The plan below follows that order and ends with a full mock run. Reports mention that the role lists HIPAA familiarity as a nice-to-have, so if you have handled regulated or sensitive data, prepare one honest sentence about how you protected it.

The AdventHealth Medical Group Tampa interview process

Candidates describe five stages, from a phone screening to final evaluations, over roughly 4-6 weeks. Reports do not say which question belongs to which stage, so the preparation below is organised by question type.

Phone Screening

Candidates report that the loop opens with a phone screening that checks fit for the role. No question list is reported for this stage, so treat it as a spoken summary of your background and the stack the role lists. Have a tight account of where you used Java, Python or C#, a web or API project, and a database you worked with, plus a clear reason for choosing healthcare software.

What to demonstrate

• Fit for the role, as reported for this stage
• How clearly you summarise your background and stack experience out loud

How to prepare

• Write a short account of your experience that names your main language (Java, Python or C#), one web framework and one database you have used.
• Prepare one API development or integration project you can describe end to end: what it connected, what failed, and how you fixed it.
• Decide your honest reason for a software role in healthcare, and note any exposure to regulated or sensitive data, since HIPAA familiarity appears among the nice-to-have requirements candidates describe.

In-Person Interviews

Candidates report in-person interviews with hiring managers and team members. The reported duties include code reviews and work with product managers, UX designers and other engineers, and the soft-skill requirement mentions explaining technical ideas to non-technical stakeholders. Approach this stage as a conversation about how you build and work with others: bring concrete projects, say what you personally did, and explain decisions in plain words.

What to demonstrate

• How you work with hiring managers and team members face to face
• Whether you can explain technical work to people outside engineering
• Experience with the day-to-day duties reported for the role, such as testing and code review

How to prepare

• Rehearse the challenging technical problem story aloud, with the symptom, how you narrowed it down, the fix and what you changed afterwards.
• Practise explaining one system you built to a non-engineer in a few plain sentences, with no jargon.
• Prepare two code review examples, one where you gave feedback and one where you received it and changed your approach.

Technical Assessments

Candidates report technical assessments that evaluate problem-solving skills, without saying what format they take. The reported coding and problem-solving questions are the natural material for a stage like this: reverse a linked list, sort an array of integers, stacks versus queues, search over a large dataset, handling a production bug and weighing trade-offs. Write the coding tasks by hand in your chosen language and say the complexity of each solution aloud.

What to demonstrate

• Problem-solving skills, as reported for this stage
• Working code for data-structure and sorting tasks
• Reasoning about trade-offs between technical options

How to prepare

• Write reverse-a-linked-list iteratively and recursively, and test it on an empty list, a single node and two nodes.
• Write one comparison sort and one linear-time approach where it applies, and state time, space and stability for each.
• Prepare a production-bug walkthrough: contain the impact, reproduce, find the root cause, fix, add a regression test, and follow up.
• Practise a trade-off answer using a structure of requirements, options, cost of each, and the choice you would make and why.

Behavioral Questions

Candidates report a stage of behavioral questions meant to gauge interpersonal dynamics and cultural fit. The reported prompts cover a team conflict, managing deadlines and priorities, adapting quickly to change, mentoring junior team members, taking the lead on a project and troubleshooting performance problems. Approach it with a story bank: a handful of real situations, each with your own decision, the outcome and what you learned.

What to demonstrate

• Interpersonal dynamics and cultural fit, as reported for this stage
• Your personal role in team, deadline and change situations

How to prepare

• Write a story for each reported prompt in a few lines: situation, your decision, result, lesson. Reuse one story across prompts only where it truly fits.
• Add a number to each result you can honestly support, such as a latency figure, a cycle-time change or a count of defects.
• Say each story aloud using "I" for your own actions and name the teammates involved fairly.

Final Evaluations

Candidates report that the process ends with final evaluations to decide overall fit for the team. Nothing more specific is reported, so prepare to revisit the whole loop: a consistent account of your strengths, a clear view of the gaps in your earlier answers, and questions of your own about how the team builds and ships software.

What to demonstrate

• Overall fit for the team, as reported for this stage
• Consistency of your account across the earlier stages

How to prepare

• Review the weakest answer from each earlier stage and rewrite it more concretely.
• Prepare your mentoring and project-lead stories as the strongest evidence of team contribution.
• Write questions about the team's review process, testing practice and release routine, so the conversation ends with real substance.

Where candidates lose points

Reciting the four object-oriented principles as definitions with no code to back them up

For encapsulation, inheritance, polymorphism and abstraction, prepare a small example in your own language and say when you would prefer composition over inheritance. A definition alone does not show you have used them.

Losing the next pointer while reversing a linked list, or never testing the edge cases

Keep three references (previous, current, next), write the loop, and trace it on an empty list, one node and two nodes before you say you are done. Then state O(n) time and O(1) space, and be ready to write the recursive version.

Answering the sort question with a built-in call and no explanation

Ask whether the library sort is allowed, then write one algorithm yourself and state its complexity. Be ready to say when merge sort's stability or insertion sort's performance on nearly sorted input matters, and how the standard library sort for your language behaves.

Answering the production bug question by jumping straight to a code change

Open with impact and containment (rollback, flag, or a workaround), then reproduce, find the root cause, fix, add a regression test, and review how it escaped. For a healthcare application, mention care taken with patient data in logs.

Telling conflict, leadership or mentoring stories in "we" terms, with no result

For each story, write down the decision you personally made, the outcome with a figure you can defend, and one thing you would change. If a story has none of the three, replace it.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Clarify the node shape (value and next pointer), whether to reverse in place, and what to return: the new head. Name the edge cases up front: an empty list and a single node both return the input unchanged.
2. Iterative solution with three pointers: prev = None, curr = head; while curr: nxt = curr.next; curr.next = prev; prev = curr; curr = nxt; return prev. Saving next before rewiring is the step people get wrong.
3. Complexity: O(n) time and O(1) extra space. The recursive version (reverse the rest, then set head.next.next = head and head.next = None) is also O(n) time but uses O(n) call-stack space, which can overflow on long lists, Python's default recursion limit of about 1000 included.
4. Test by tracing 1 -> 2 -> 3 to 3 -> 2 -> 1, checking that the old head's next is now None so the result has no cycle, and run the empty and single-node cases.

Follow-up

• Reverse only the nodes between positions m and n.
• Reverse the list in groups of k nodes.
• How would you reverse a doubly linked list?

How would you optimize a search algorithm for a large dataset?

Medium · Coding / Algorithms

Approach

1. Clarify the query type and data profile first: exact-key lookup, range queries, prefix or full-text search, or nearest neighbour; how large the data is, whether it fits in memory, and whether it is mostly read or frequently updated.
2. Match the structure to the query: a hash map gives O(1) average exact lookup but no ordering; a sorted array with binary search gives O(log n) lookup and ranges after an O(n log n) sort but costly inserts; a balanced tree or B-tree gives O(log n) lookup, insert and range scans on changing data.
3. For data in a database (database management is among the must-have skills candidates list), add the right index: a B-tree index on the filtered column, a composite index whose leading column matches the query's equality filter, then check the plan with EXPLAIN to confirm a scan became an index lookup.
4. For text search, use an inverted index mapping terms to record ids instead of scanning every record. Beyond the algorithm: cache hot results, paginate, partition the data, and measure with a profiler before and after each change.

Follow-up

• The dataset no longer fits in memory: what changes?
• How would you support prefix search such as autocomplete?
• Why does the column order in a composite index matter?

Explain the difference between a stack and a queue. When would you use each?

Medium · Coding / Algorithms

Approach

1. Define both by removal order: a stack is LIFO (push and pop at the same end), a queue is FIFO (enqueue at the back, dequeue at the front). Both give O(1) core operations when implemented correctly.
2. Name the right implementation in each language: in Python, a list works as a stack but list.pop(0) is O(n), so use collections.deque for a queue; in Java, prefer ArrayDeque for both over the legacy synchronized Stack class; C# has Stack<T> and Queue<T>.
3. Use a stack for anything that unwinds in reverse order: function calls, undo history, depth-first search, matching brackets, evaluating expressions. Use a queue when order of arrival must be kept: breadth-first search, job and message queues, buffering requests between a producer and a consumer.
4. Separate a priority queue, which removes by priority rather than arrival order and is usually a binary heap with O(log n) insert and remove.

Follow-up

• Implement a queue using two stacks and give the amortized cost per operation.
• Design a stack that returns its minimum in O(1).
• How would you make a bounded queue safe for multiple producer and consumer threads?

Can you write a code snippet to sort an array of integers?

Medium · Coding / Algorithms

Approach

1. Ask the constraints first: size of the array, value range, whether it is nearly sorted, and whether a built-in is allowed. In production I use the built-in: Python's sorted() is a stable Timsort-family sort, O(n log n) worst case and O(n) on already-sorted input; Java's Arrays.sort on int[] is a dual-pivot quicksort, unstable, which does not matter for primitives.
2. If asked to write one by hand, merge sort is the safe pick: split in half, sort each half recursively, merge with two pointers. O(n log n) in every case, stable, O(n) extra space.
3. Know the alternatives and their deciding properties: quicksort is O(n log n) on average and in place, but O(n^2) worst case with poor pivots, so randomise the pivot; heap sort is O(n log n) worst case and in place but unstable; insertion sort is O(n^2) but O(n) on nearly sorted input.
4. When the value range k is small, counting sort runs in O(n + k); shift by the minimum value so negative numbers work. Test with an empty array, one element, duplicates, negatives and already-sorted or reverse-sorted input.

Follow-up

• How would you sort a file of integers too large to fit in memory?
• When does stability matter, and which of these sorts are stable?
• Your quicksort is slow on an input full of duplicates: why, and how do you fix it?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.

Approach

1. Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
2. Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
3. Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
4. Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.

Follow-up

• The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
• Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?

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

1. 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.
2. 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.
3. 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.
4. 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?

What programming languages are you most comfortable with, and why?

Medium · Technical / Domain Questions

Approach

1. Name one primary and one secondary language, and tie each to something you shipped: "I write most backend code in Java; I use Python for data scripts and test tooling." Candidates describe Java, Python or C# in the requirements for this role, so lead with whichever of those you know best.
2. Give the why as trade-offs rather than taste: static typing and compile-time checks in Java or C# catch contract breaks before deploy; Python trades that for faster iteration and a large library ecosystem, with type hints plus mypy closing part of the gap.
3. Show depth with one sharp edge of your main language: Java's equals/hashCode contract for HashMap keys, Python's mutable default arguments being shared across calls, or C# blocking on .Result inside async code and deadlocking.
4. Mention the runtime model where it matters: in standard CPython builds the GIL stops threads from running Python bytecode in parallel, so CPU-bound work goes to multiprocessing while I/O-bound work is fine with threads or asyncio.

Follow-up

• If the team works mainly in a language you know less well, how would you get productive in it?
• What is one thing you would change about your primary language, and why?
• When would you pick Python over Java for a service, and when would you not?

Can you explain the principles of object-oriented programming?

Medium · Technical / Domain Questions

Approach

1. Name the four principles and attach one concrete example to each: encapsulation (an Appointment class whose status changes only through methods like cancel() that enforce valid transitions), abstraction (callers depend on a NotificationSender interface, not on SMS or email details), inheritance, and polymorphism.
2. Separate the two kinds of polymorphism: overriding is resolved at runtime by dynamic dispatch on the object's actual type; overloading is resolved at compile time from the argument types.
3. Say when inheritance goes wrong and prefer composition: deep hierarchies couple subclasses to parent internals. Use the Liskov substitution principle with the Square-extends-Rectangle example, where setting width independently breaks the parent's contract.
4. Connect the principles to SOLID briefly (single responsibility, dependency inversion) and to testability: depending on interfaces lets you inject a fake in a unit test instead of a real database or HTTP client.

Follow-up

• What is the difference between an abstract class and an interface in Java or C#, and when do you use each?
• How would you refactor a class that has grown to do five unrelated things?
• Where does object-oriented design fit poorly, and what would you use instead?

Describe a challenging technical problem you encountered and how you resolved it.

Medium · Technical / Domain Questions

Approach

1. Pick a problem with real technical depth that you personally drove (a race condition, a memory leak, a slow query, a flaky integration), and tell it in first person singular: "I traced...", not "the team fixed...".
2. Structure it as symptom, constraints, hypotheses and the evidence that ruled each one in or out (logs, profiler output, a query plan, a minimal reproduction), then the fix.
3. Quantify the result: latency before and after, error rate, hours saved, incidents avoided. Say how you confirmed the fix caused the change and not something else that shipped at the same time.
4. Close with what you changed afterwards so the problem could not recur: a regression test, an alert, a code review checklist item. If the story touched sensitive data, explain how you debugged it without exposing that data.

Follow-up

• What alternative fixes did you reject, and why?
• How did you verify the fix in production?
• What would you do differently if you hit the same problem again?

How do you ensure the quality of your code?

Medium · Technical / Domain Questions

Approach

1. Describe layers, not one practice: automated tests (many fast unit tests, fewer integration tests against a real database or API contract, a few end-to-end tests), code review, and static checks (linters, type checkers, formatters) running in CI so a failing check blocks the merge.
2. Explain how you choose test cases: boundaries, empty and null inputs, error paths and concurrency, not only the happy path. Treat coverage as a signal for untested code, not a target, since 100% line coverage can still miss wrong logic.
3. Keep changes small and reviewable: one concern per pull request, a clear description, and tests in the same change. Small diffs get read properly; huge ones get skimmed.
4. Cover quality after merge too: logging, metrics and alerts that tell you when the code misbehaves in production, plus feature flags so a risky change can be switched off without a redeploy.

Follow-up

• How would you add tests to legacy code that has none before changing it?
• What do you deliberately not test, and why?
• How do you handle a code review where you disagree with the reviewer?

What tools do you use for version control, and why are they important?

Medium · Technical / Domain Questions

Approach

1. Name Git and say why version control matters in practical terms: a full history of who changed what and why, safe parallel work on branches, review through pull requests, and the ability to reproduce or roll back any released version through tags.
2. Describe a branching workflow you have used and its trade-off: trunk-based development with short-lived branches and feature flags keeps merges small; long-lived release branches (GitFlow style) suit scheduled releases but cause bigger merge conflicts.
3. Know the commands that matter under pressure: git revert creates a new commit that undoes a pushed change and is safe on shared branches; git reset or a force push rewrites history and should stay on your own branch. git bisect binary-searches history to find the commit that introduced a regression.
4. Cover hygiene: small commits with messages that explain why, no generated files or secrets in the repository. If a credential is ever pushed, rotate it immediately, because removing it from history does not undo the exposure.

Follow-up

• When do you rebase and when do you merge?
• A bad commit is already on main and deployed: walk through how you undo it.
• How do you resolve a merge conflict in a file you did not write?

How would you approach designing a new feature for an existing application?

Medium · Problem-solving / Case Studies

Approach

1. Start with the problem, not the solution: who uses the feature, what they do today, and what acceptance criteria define done. Then read the existing code paths, data model and API contracts the feature will touch before designing anything.
2. Outline the change in layers: data model (new tables or columns), API (new endpoints or fields added in a backward-compatible way so existing clients keep working), business logic and UI. Reuse existing patterns in the codebase unless there is a reason not to.
3. Plan schema changes as expand and contract: add the new nullable column or table, deploy code that writes both, backfill, switch reads, then enforce constraints and remove the old path. That avoids downtime and keeps rollback possible.
4. Address non-functional needs explicitly: authorisation, audit logging, input validation and performance. Candidates list knowledge of HIPAA as a nice-to-have for this role, so mention limiting access to the minimum data the feature needs if it touches patient information.
5. Ship behind a feature flag to a small group first, with metrics and error alerts that tell you whether it works, and tests that cover the new path and the unchanged old one.

Follow-up

• How would you roll the feature back if it caused errors after release?
• Existing mobile or partner clients still call the old API: how do you change it without breaking them?
• How would you estimate this work and break it into deliverable pieces?

Describe how you would prioritize tasks in a project with tight deadlines.

Medium · Problem-solving / Case Studies

Approach

1. List every task, estimate each roughly, and map dependencies to find the critical path: the chain of tasks that sets the finish date. Work on the critical path first and start long-lead items (access requests, reviews from other teams) on day one.
2. Rank by impact and risk, for example with MoSCoW (must, should, could, won't): what the release cannot ship without comes first, and the riskiest unknowns get tackled early so surprises land while there is still time to react.
3. Cut scope, not quality: agree on the smallest version that meets the real need, and keep tests on the parts most likely to break or most costly if wrong.
4. Communicate trade-offs early and in writing: tell the stakeholder what will be in, what moves to the next release, and what risk remains, instead of reporting a slip on the last day. Re-check the plan daily against actual progress.

Follow-up

• Two stakeholders both say their task is the top priority: what do you do?
• Halfway through, a task takes twice your estimate. How do you respond?
• Give an example of something you cut to hit a deadline, and what it cost.

Can you provide an example of a complex problem you solved using data analysis?

Medium · Problem-solving / Case Studies

Approach

1. Pick a case where analysis changed a decision you made, and frame it as question, data, method, finding, action and measured result, in first person singular.
2. Name the concrete method: the SQL you wrote (GROUP BY with COUNT or percentiles, joins across logs and tables, window functions for trends over time), or the script or notebook you used. For latency or durations, report medians and p95 or p99 rather than averages, which outliers distort.
3. Show you checked data quality before trusting it: duplicates, nulls, time-zone mismatches, missing days, and whether the sample covered the cases that matter.
4. Guard against wrong conclusions: correlation is not causation, so explain how you ruled out confounders (a deploy, a seasonal pattern, a change in traffic mix), and how you confirmed the effect after acting on it.

Follow-up

• How did you know the data was complete and correct?
• What result would have changed your conclusion?
• How did you present the finding to someone non-technical?

If faced with a significant bug in production, what steps would you take to address it?

Medium · Problem-solving / Case Studies

Approach

1. Triage first: confirm the impact (which users, which features, how many errors, any data corruption) and set severity. Tell stakeholders an incident is open and when the next update comes.
2. Mitigate before finding the root cause: roll back the last deploy, turn off the feature flag, or fail over, whichever restores service fastest. Check recent deploys and configuration changes first, because they are the most frequent trigger.
3. Then investigate with evidence: logs, metrics and traces around the start time, error messages and stack traces, and a reproduction in a non-production environment. Use synthetic or de-identified data, never copied patient records.
4. Fix with a regression test that fails before the change and passes after, ship through the normal review path, and verify with the same metrics that showed the problem. If data was corrupted, plan and test the repair separately.
5. Write a blameless postmortem: timeline, root cause, why monitoring did or did not catch it, and owned follow-up actions such as new alerts or tests.

Follow-up

• Rollback is not possible because a database migration already ran: what now?
• You cannot reproduce the bug outside production. How do you proceed?
• How do you decide between a quick hotfix and a proper fix?

How do you evaluate the trade-offs of different technical solutions?

Medium · Problem-solving / Case Studies

Approach

1. Derive the criteria from requirements before comparing options: correctness, latency and throughput needs, cost, security and compliance, operational burden, and how well the team knows the technology. Weight them, since not all matter equally.
2. Compare two or three concrete options against those criteria, ideally in a short table. Example: a relational database gives transactions and joins for structured records; a document store gives flexible schemas but pushes consistency and joins into the application.
3. Weigh reversibility: a choice that is cheap to undo (a library behind an interface) can be made quickly; one that is expensive to undo (a primary datastore, a public API shape) deserves a prototype or benchmark first.
4. Settle unknowns with a timeboxed spike or load test rather than opinion, then record the decision, the alternatives and the reasons in a short decision record so it can be revisited when the assumptions change.

Follow-up

• Tell me about a time you chose the less elegant option. Why?
• How do you handle it when the team prefers a technology your evaluation ranks lower?
• What would make you revisit a decision you already made?

Listing latency scales with page size, not with filters

Easy · n+1 · latency · query batching

The tenant listing endpoint reads resource filtered by tenant_id and status, ordered by updated_at DESC, and returns each row plus the owner's display name from app_user and the actor of that resource's latest resource_revision. p99 is 55 ms at 10 rows per page and 1.4 s at 200. Database telemetry shows 401 statements per request, each under 1 ms, and nothing in the slow-query log. Diagnose the cause and give the fix, stating the statement count per request and the p99 you expect afterwards.

Approach

1. Read the counters before forming a theory. 401 statements for 200 rows is one driver query plus two per row, and sub-millisecond execution with an empty slow-query log rules out a bad plan. The time is round trips, which is why it is invisible in every per-query metric and scales with rows returned rather than with filter selectivity.
2. Name the two per-row statements from their normalised text: a single-row app_user lookup by user_id, and a resource_revision lookup by resource_id ordered by version DESC LIMIT 1. Confirm by dropping those two response fields and watching the statement count fall to one. That locates the calls in the serialisation layer, not the repository.
3. Check that the arithmetic accounts for the whole gap. Measure one round trip to the replica in isolation; 400 trips at roughly 3 ms of network plus 0.2 ms of execution is about 1.3 s on top of a 55 ms baseline, which matches. If the multiplication had fallen short, the N+1 would only be part of the story and you would keep looking.
4. Batch both lookups. Collect owner_user_ids and resource_ids from the driver query, then issue WHERE tenant_id = $1 AND user_id = ANY($2) for the users, and PostgreSQL's SELECT DISTINCT ON (resource_id) ... WHERE resource_id = ANY($2) ORDER BY resource_id, version DESC for the latest revision, which the UNIQUE (resource_id, version) index serves directly. On an engine without DISTINCT ON, use a lateral join or a row_number window. Three statements per request at any page size.

Follow-up

• The page size is capped at 200 today. What breaks first if it is raised to 2,000, and is it still this bug?
• How do you stop the next N+1 from reaching production, given that no individual query is slow and the endpoint's tests pass?

Suggested practice checklist

The plan starts with the language and fundamentals the reported coding questions rely on, moves to engineering practice and debugging, then builds the behavioral story bank and ends with a full mock run. Several days point at questions reported for this loop.

Day 1 — Fix your language and the loop map

• Write out the five reported stages in order and note which one you are least ready for.
• Choose Java, Python or C# as your interview language and write a one-page note answering why you are most comfortable with it, with two concrete strengths and one limitation.
• Write a short explanation of each object-oriented principle with a code example in that language.

Deliverable: A one-page loop map, a language rationale note, and four small code examples, one for each object-oriented principle.

Day 2 — Linked lists, stacks, queues and sorting by hand

• Write reverse-a-linked-list iteratively and recursively, then run it on an empty list, one node and two nodes.
• Implement a stack and a queue from scratch, and write two cases where each is the right choice.
• Write one comparison sort and note its time, space and stability, then explain which built-in sort you would use in your language and why.

Deliverable: Working code for list reversal, a stack, a queue and one sort, each with a complexity note and edge-case tests.

Day 3 — Searching large data and performance work

• Write binary search, then list what you would change for a very large dataset: an index, a hash lookup, batching or paging.
• Write the performance troubleshooting story in baseline, cause, fix and re-measure form.

Deliverable: A binary search implementation, a short note comparing offset and keyset paging, and one written performance story with before-and-after figures.

Day 4 — Engineering practice answers

• Write a spoken-length answer on how you ensure code quality, naming the tests, reviews and checks you actually use.
• Write an answer on your version control workflow, including branching, pull requests and resolving a merge conflict.
• Outline a feature design for an existing application: requirements, data model, API changes, tests and rollout.
• Prepare a trade-off answer for two real options you once weighed.

Deliverable: Four written answers (code quality, version control, feature design, trade-offs), each short enough to say aloud.

Day 5 — Debugging production issues and data-driven problems

• Write a production-bug runbook for your stack: contain, reproduce, locate, fix, test and follow up.
• Pick the strongest data-analysis problem you solved and write it as question, data, method, finding and decision.
• Revisit the challenging technical problem story and add the figures.

Deliverable: A one-page incident runbook, a written data-analysis story and a revised technical-problem story.

Day 6 — Behavioral story bank

• Write a story for team conflict, deadlines and priorities, and adapting to change, each in situation, decision, result and lesson form.
• Write a prioritisation answer for a project with tight deadlines, covering how you rank work, cut scope and tell stakeholders.
• Record yourself telling two stories and remove any "we" that hides your own decision.

Deliverable: Three written stories, one prioritisation answer and two recordings revised for personal ownership.

Day 7 — Leadership, mentoring and a full mock

• Write the mentoring answer as a method plus one real example, and the project-lead story with its result.
• Run a mock loop aloud: a phone-screen summary, one coding task, one production-bug answer and two behavioral stories.
• Write questions to ask the team about review, testing and release practice, and note your two weakest answers to repair.

Deliverable: A mentoring answer, a project-lead story, a recorded mock run and a final list of questions and repairs.

Stories to prepare for the behavioral round

Candidates report a stage of behavioral questions about interpersonal dynamics and cultural fit, and the reported prompts cover conflict, deadlines, change, mentoring, leading a project and performance troubleshooting. For this role, prepare stories that show you working with product managers, designers and other engineers, taking personal decisions and delivering results you can support with figures.

Tell me about a time you faced a conflict within a team. How did you handle it?

Medium · Behavioral / Leadership

Approach

1. Choose a real disagreement about a technical or working-practice matter, such as an API contract, a review comment or a scope cut, where you were a participant and not a bystander. A story in which you only observed a conflict gives you nothing to say about your own decisions.
2. Set the scene briefly, then state the other person's position fairly. For example: "I wanted to ship behind a flag; my teammate wanted to finish the migration first, because a half-migrated table worried her." Showing that you understood their reasoning matters more than the details of the dispute.
3. Explain how you resolved it using evidence or a conversation, not authority: a quick benchmark, a prototype, a written comparison or a call with the product manager. Then give the outcome for the project and for the working relationship.
4. Close with what you would change. A sound answer is specific, such as raising the disagreement earlier or writing the decision down, and avoids vague lines like "communicate more".
5. Avoid the two answers that sink this question: the story where the other person is the villain, and the claim that you have never had a conflict.

Follow-up

• What would you have done if the other person had still disagreed after the evidence?
• How did the relationship look a month later?
• Was there a point where you were wrong, and how did you find out?

What strategies do you use to manage deadlines and priorities?

Medium · Behavioral / Leadership

Approach

1. Give a method, then prove it with one example. A usable method: list everything due, estimate each item roughly, rank by impact and by what blocks other people, separate must-haves from items that can slip, then agree the ranking with whoever owns the deadline.
2. Show how you handle a deadline that is not realistic: raise it early, offer options such as cutting scope, delaying a feature or adding help, and let the stakeholder choose. Escalating at the last minute is the usual failure.
3. Anchor the answer in a real case with numbers you can support, for example: "I had four tickets before a release, shipped two, moved one behind a flag and deferred one with the product manager's agreement."
4. Mention how you keep priorities visible, such as a shared board or a short daily note, and how you protect time for testing and code review when time is short.
5. Avoid answers that rely on working extra hours or on generic tool lists. Those show effort but not judgement about what to do first.

Follow-up

• Two urgent requests arrive from different managers on the same day. What do you do?
• Tell me about a deadline you missed and what you changed afterwards.
• How do you keep quality from dropping when you cut scope?

Describe a situation where you had to adapt quickly to a change. What was the outcome?

Medium · Behavioral / Leadership

Approach

1. Pick a change that actually disrupted your work: a requirement reversed, a priority shifted, a key person left or a tool was replaced. A trivial change gives the answer no weight.
2. Describe your first steps in order: what you stopped, what existing work you kept, who you told, and how you reset the plan. Speed in this story is shown by sequencing, not by working faster.
3. Give the outcome with evidence, such as the revised feature shipped on the new date, or the migration finished with no data loss, and say what the change cost.
4. State what you now do differently, for example keeping work in small shippable pieces so a change discards less.
5. The mistake to avoid is telling the story as something that happened to you. Say what you decided at each point, and be honest about anything that did not go well.

Follow-up

• What did you give up to adapt, and was it the right call?
• How did you tell your team or manager about the new plan?
• Describe a change you resisted at first. What changed your mind?

How do you approach mentoring or supporting junior team members?

Medium · Behavioral / Leadership

Approach

1. Describe a method, then an example. A workable method: learn the person's current level, give a small task with the context behind it, pair on the first attempt, let them drive, and give review comments that explain why rather than only what to change.
2. Show a progression: over weeks, you move from pairing to reviewing to simply being available. Concrete signs are fewer review rounds on their pull requests, tasks they take on without help, or a first merged change.
3. Include one occasion where you held back from fixing something yourself and let them find it, and one where you stepped in because the risk was too high. Both show judgement.
4. If you have never held a formal mentor role, use a real case such as onboarding an intern, helping a new teammate with the codebase or running a short knowledge-sharing session.
5. Avoid answers that describe doing the junior's work for them or that treat mentoring as a favour and not as part of building the team.

Follow-up

• How do you handle a junior who does not ask for help?
• How do you give difficult feedback on a pull request?
• What did you learn from mentoring that changed how you work?

Share an example of a project where you took the lead. What was the result?

Medium · Behavioral / Leadership

Approach

1. You do not need a manager title. Pick a project where you set the direction, such as a feature, a migration or a service rewrite, and make the story about your decisions.
2. Cover the scope you took on, how you split the work and who did what, which risks you saw first and how you handled them. Naming the decision you made when people disagreed shows leadership better than listing tasks.
3. Say how you kept others informed: a short written plan, regular check-ins, a visible board, or demos to product managers and designers, which fits the cross-functional work reported for this role.
4. Report the result with figures you can support, such as delivery date, defects after release, or the time a manual process now takes, and then the lesson you took from running it.
5. The most common mistake is a story where "I led" hides a solo effort, or where the story ends at launch with no result.

Follow-up

• What was the hardest decision you made as lead?
• What would you do differently if you ran it again?
• How did you handle a teammate who was falling behind?

Describe a time when you had to troubleshoot performance issues in your code.

Medium · Coding / Algorithms

Approach

1. Start with measurement: the symptom, the baseline number and how you got it, for example a request latency, a runtime on a fixed input or a query time from an execution plan. Without a baseline the story cannot show that anything improved.
2. Describe how you found the cause: a profiler, timing around suspected sections, logs, or the database query plan. Name the real culprit, such as repeated queries inside a loop, a missing index, a nested loop that was quadratic in input size, or too much object creation.
3. Explain the options you weighed (cache, index, algorithm change, batching) and why you chose one, including its cost in complexity or memory.
4. Report the same measurement after the fix on the same input, then say what protects the gain: a regression test, a benchmark or an alert.
5. Avoid the story where you guessed at the cause and changed several things at once, and the story that gives no before-and-after numbers.

Follow-up

• How did you know the bottleneck was where you thought it was?
• What would you have done if the fix had only helped a little?
• How do you stop the same slowdown from coming back?