Interview guides · CareDx

CareDx Software Engineer Interview Guide

CareDx Software Engineer interview guide: the phone screen and onsite rounds, reported coding, design and behavioral questions, and a 7-day prep plan.

The 60-second brief

Candidates' reports describe CareDx as a healthcare technology company whose software supports organ transplant management and related services. Software Engineers build and maintain those applications alongside cross-functional teams, and the reports name data analytics, system integration and user experience as areas those teams cover. The day-to-day work described includes designing and writing code, code reviews, architecture discussions, debugging existing software, and following a change from requirements through deployment and maintenance.

This guide is for engineers preparing for a Software Engineer interview at CareDx. Candidates describe the typical background as 2-5 years of software engineering experience, with healthcare technology experience counted as a plus. It covers the two reported rounds, the sixteen reported questions across technical, system design, behavioral, problem-solving and coding topics, and a plan built around the skills the role lists: Java, Python or C#, SQL or NoSQL, cloud, Git and Agile or Scrum.

Candidates report two rounds over roughly 2-4 weeks: a phone screening on background and fit, then onsite interviews with several stakeholders, including technical leads and HR representatives. The reported questions mix technical, design, coding and behavioral topics.

Focus areas

Ability to Listen and Engage
Interview Communication Skills
Professionalism in Interviewing

Overview

As candidates describe the role, a CareDx Software Engineer works on applications for transplant management and related services, with colleagues from data analytics, system integration and user experience. The listed duties cover the whole software lifecycle: gathering requirements, writing and reviewing code, joining architecture discussions, debugging existing software and deploying and maintaining it. That is why the reported questions are broad and practical rather than puzzle-heavy: the software development lifecycle, how you debug, what RESTful services are and how you built them, and what you have done with cloud services and deployments.

The sixteen reported questions fall into five groups. Technical and domain questions are conceptual and ask for your own experience (lifecycle, a hard problem you solved, cloud deployments, debugging, REST). Design questions cover real-time data processing in a healthcare application, database management for a large-scale application, and data security and compliance. Problem-solving questions ask how you handle ambiguous requirements and a complex coding challenge. Coding questions are reversing a linked list, optimizing a search algorithm for a large dataset, and depth-first versus breadth-first search. Behavioral questions cover teamwork, conflict and influencing a project. Many answers are only convincing when anchored in a real project, so the preparation is mostly choosing projects and rehearsing them aloud.

The role lists Java, Python or C#, web frameworks and cloud technologies, SQL or NoSQL databases, Agile or Scrum, and Git as requirements, with data analytics tools and knowledge of healthcare regulatory compliance as nice-to-haves. Pick one of the three languages for the coding questions, and be ready to name the database, cloud services and branching workflow from your own projects. Because the design questions are set in healthcare and one asks directly about security and compliance, treat access control, encryption, audit logging and data retention as parts of every design answer rather than a closing remark.

Use the guide in this order: map the two rounds, drill the three coding questions until the code is clean, build spoken answers for debugging, REST and the lifecycle, outline the three design questions with security included, then turn your projects into four or five stories that cover the teamwork, conflict, influence, ambiguity and cloud prompts. The last day is a full mock of the phone screening followed by a mixed onsite.

The CareDx interview process

These are the stages candidates describe, not a published process. Reports do not tie question types to a specific round, so prepare every type for the onsite.

Phone Screening

Candidates describe this stage as an initial call about your background and how you fit the role. Reports also list listening and engagement, and setting expectations with the recruiter, among the topics tested. Use it to give a specific account of your experience with the stack the role lists (Java, Python or C#, SQL or NoSQL, cloud, Git, Agile or Scrum) and to find out what the onsite will contain.

What to demonstrate

Your background and fit for the role, as the call is described
Listening to the question asked and answering it directly
Clear expectation-setting with the recruiter about the next stages

How to prepare

Write a short career walkthrough that names the language, database and cloud work on each project, and finishes with why healthcare software interests you if that is true.
Rehearse the cloud services and deployments answer as a short story with a named provider, a release you owned and one result.
Prepare questions about the onsite: who you will meet, which question types to expect and what the timeline looks like.
Have your location, notice period and compensation expectations ready so the call stays on your experience.

Onsite Interviews

Candidates report several interviews with different stakeholders, including technical leads and HR representatives, and a mix of technical assessments and behavioral questions. Across the loop, the reported questions include coding (reversing a linked list, depth-first versus breadth-first search, optimizing search over a large dataset), design (real-time healthcare data processing, database management at scale, data security and compliance), debugging, REST and teamwork stories. With several interviewers in one stage, prepare for breadth rather than one specialty, and have each answer ready in a form you can say aloud.

What to demonstrate

Technical knowledge in conversation with technical leads, as the stage format reports
Problem-solving shown through working code and a talked-through design
Collaboration and communication in conversations with HR and other stakeholders

How to prepare

Write the linked-list reversal, depth-first and breadth-first search, and a search-optimization answer in your chosen language, and run each on edge cases.
Outline a real-time healthcare data pipeline and a large-scale database plan, each with a security and compliance section.
Prepare spoken answers on how you debug, what RESTful services are and how you built them, and how the lifecycle ran on a real project.
Build a story bank for teamwork, conflict, influence, ambiguous requirements and cloud deployments, each with your own actions and a measurable result.

Where candidates lose points

Answering the software development lifecycle question with a textbook list of phases

Tie each phase to something you did on a real project: how requirements were gathered, how work was split in Agile or Scrum sprints, which tests and code reviews gated a merge in Git, how the release went out and who maintained it afterwards. Be ready to say which phase your team shortened and what that cost.

Writing the linked-list reversal without testing the empty, one-node and two-node cases

Keep three pointers (previous, current, next), save the next node before you overwrite the link, and return the previous pointer as the new head. Run the empty list, a single node and a pair, then state the cost: linear time, constant extra space iteratively, linear stack depth if recursive.

Defining depth-first and breadth-first search without tying them to a use, or optimizing a search without asking about the data

Tie depth-first search to a stack or recursion and breadth-first search to a queue, then to uses such as cycle detection versus shortest path in an unweighted graph. For search over a large dataset, ask first whether it is sorted, how often it changes and whether it fits in memory, then choose binary search, a hash index or a database index.

Treating the healthcare design questions as a generic scaling exercise and mentioning security only at the end

Put a security section inside the real-time processing design and the database design: encryption in transit and at rest, role-based access, audit logs of reads, fewer sensitive fields stored, and retention and deletion rules. Name the regulation that governs patient data where you work (HIPAA in the US) without claiming detail you do not know.

Telling teamwork, conflict and influence stories that all come from one project and never say what you personally did

Build a bank of three or four stories from different projects and map each to the teamwork, conflict, influence, ambiguity and cloud deployment prompts. For each, write the situation in two sentences, your own actions in first person and a measurable result.

Questions & practice

How would you approach a project with ambiguous requirements?

Medium · Problem-Solving / Case Studies

Approach

Start by finding the decision the project serves: who the users are (clinicians, lab staff, internal teams), what problem they have today, and what result would count as success. Write these down as assumptions and open questions, not as settled facts.
Turn ambiguity into checkable statements: acceptance criteria for the first slice, explicit non-goals, and a list of unknowns ranked by how much they would change the design.
Reduce risk with a thin vertical slice or a prototype shown to users early, and a timeboxed spike for any technical unknown. Feedback on something concrete resolves more questions than a long requirements meeting.
Design for the parts most likely to change: put uncertain rules behind an interface or configuration, keep the data model easy to extend, and record key decisions with their reasoning so later changes are cheap to make.
Give a real example in the first person: what was unclear, which assumption you checked first, what changed as a result, and what you shipped.

Follow-up

Two stakeholders give you conflicting requirements. How do you resolve it?
How do you decide when to stop clarifying and start building?
Tell me about an assumption that turned out to be wrong. What did it cost, and how did you recover?

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

Iterative version: prev = null, curr = head; on each step save next = curr.next, set curr.next = prev, then move prev = curr and curr = next. When curr is null, prev is the new head. O(n) time, O(1) extra space.
Recursive version: reverse the rest of the list, then set head.next.next = head and head.next = null, and return the new head. Also O(n) time, but O(n) call-stack space, so a very long list can overflow the stack (Python's default recursion limit is 1000).
Trace the edge cases out loud: an empty list returns null, a single node returns itself, and two nodes check that the old head ends with next = null so no cycle is left.
Common mistakes: losing the rest of the list by overwriting curr.next before saving it, and returning curr (null) instead of prev.
For a doubly linked list, swap each node's prev and next pointers and return the last node visited.

Follow-up

Reverse the nodes in groups of k, leaving any leftover tail as it is.
Reverse only the part of the list between positions m and n in one pass.
Check whether a linked list is a palindrome in O(1) extra space.

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

Medium · Coding / Algorithms

Approach

Clarify the kind of search before choosing a structure: exact key lookup, range queries, prefix matching, full-text, or nearest-neighbour. Also ask whether the data is static or constantly updated, and whether it fits in memory.
Match the structure to the query: linear scan is O(n); a hash index gives O(1) average exact lookups but no ranges; sorting once in O(n log n) allows O(log n) binary search and range queries; a balanced tree or B-tree keeps O(log n) under inserts, and the B-tree's high fan-out keeps disk reads low.
For text, use a trie for prefixes and an inverted index (as in Lucene or Elasticsearch) for full-text search. For similarity search on vectors, use approximate nearest-neighbour indexes such as HNSW, which give up some exactness for speed.
At scale, partition the data and search shards in parallel, cache hot queries, and use a Bloom filter to skip partitions that cannot hold the key: it can return false positives but never false negatives.
Measure before and after: profile where the time goes, then benchmark p50/p99 latency and memory on realistic data, since a constant-factor fix such as better cache locality or fewer I/O round trips can matter more than a change in big-O.

Follow-up

The dataset no longer fits in memory. What changes in your design?
The data changes constantly. How do you keep the index current without slowing writes too much?
How would you size a Bloom filter for a target false-positive rate?

Explain the difference between depth-first search and breadth-first search.

Medium · Coding / Algorithms

Approach

BFS explores level by level with a FIFO queue; DFS follows one path as deep as it can with a stack or recursion, then backtracks. With an adjacency list both run in O(V + E) time; with an adjacency matrix both are O(V^2).
BFS finds the shortest path by edge count in an unweighted graph, because it reaches each node first at its minimum depth. Mark nodes visited when you enqueue them, not when you dequeue, so no node is queued twice.
DFS suits cycle detection (three-colour marking in directed graphs), topological sort, connected components, and backtracking problems such as permutations or maze paths. Tree preorder, inorder and postorder traversals are DFS; level-order traversal is BFS.
Memory differs: BFS holds the whole frontier, which grows with breadth (about b^d nodes for branching factor b at depth d); DFS holds the current path, which grows with depth. Recursive DFS can overflow the call stack on deep graphs, so use an explicit stack there.
Neither handles weighted shortest paths: use Dijkstra for non-negative weights. Iterative deepening DFS combines DFS's small memory footprint with BFS's shortest-depth guarantee.

Follow-up

Write BFS to find the shortest path between two cells in a grid with walls.
How would you detect a cycle in a directed graph, and why does undirected cycle detection differ?
When does BFS stop giving shortest paths, and what would you use instead?

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?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
A dashboard runs this for 40 owners in one page load. What changes about the design?

Can you explain the software development lifecycle?

Medium · Technical / Domain Questions

Approach

Name the phases in order and what each produces: requirements (user stories with acceptance criteria), design (architecture and data model reviewed before coding), implementation (feature branches and code review in Git), testing (unit, integration, user acceptance), deployment (release with a rollback path) and maintenance (monitoring, bug fixes, change requests).
Contrast the models: waterfall runs each phase once, in sequence, which suits fixed requirements; iterative models such as Scrum repeat the whole cycle in short sprints with a backlog, sprint review and retrospective, so feedback arrives early. Agile, Scrum and Git appear in the requirements candidates describe for this role, so connect your answer to them.
Show where automation enforces the lifecycle: a CI pipeline that runs tests on every pull request and blocks the merge on failure, and CD that promotes the same build artifact through staging to production.
For healthcare software, add traceability: each requirement links to its design, code change and test evidence so an audit can follow it end to end. For regulated medical-device software, standards such as IEC 62304 formalise this.
Close with one project of your own and the phase where you caught a problem, e.g. a defect found in integration testing that a sharper acceptance criterion would have caught earlier.

Follow-up

How does Scrum absorb a requirement that changes in the middle of a sprint?
Which checks would you make mandatory before a merge, and which can run after deployment?
How would the lifecycle change if every requirement had to be traceable to a test for an audit?

Describe a challenging technical problem you've encountered and how you solved it.

Medium · Technical / Domain Questions

Approach

Pick a problem with real technical depth and a clear personal role: a race condition, a slow query, a memory leak, a failing integration. Open with the system, the symptom and why it mattered (users affected, error rate, latency), in two or three sentences.
Spend most of the answer on diagnosis: what evidence you gathered (logs, metrics, profiler output, query plans), the hypotheses you ruled out and how, and the point where the root cause became clear.
Name at least two fixes you considered and the trade-off that decided between them, e.g. adding an index versus denormalising, or a lock versus an idempotent retry.
Give a measured result (p95 latency from X to Y, error rate to zero for N weeks) and how you prevented a repeat: a regression test, an alert, a runbook entry.
Say "I" for your own decisions and be precise about what others did; a vague team story with no numbers does not show your technical judgement.

Follow-up

Which alternative did you reject, and what would have made it the better choice?
How did you confirm in production that the fix addressed the root cause and not just the symptom?
What would you do differently if you met the same problem again?

Explain the concept of RESTful services and how you have implemented them.

Medium · Technical / Domain Questions

Approach

Define REST as an architectural style over HTTP: resources identified by URIs (nouns such as /patients/{id}/results), a uniform interface through the HTTP methods, stateless requests that carry their own authentication, cacheable responses, and representations, usually JSON.
Get method semantics right: GET is safe and idempotent; PUT replaces a resource and DELETE removes it, and both are idempotent; POST creates and is not idempotent; PATCH applies a partial update and is not guaranteed idempotent.
Use status codes precisely: 200, 201 with a Location header, 204, 400 for invalid input, 401 unauthenticated versus 403 forbidden, 404, 409 conflict, 422 validation failure, 5xx for server faults. Add pagination, filtering, consistent error bodies and a versioning scheme (/v1 in the path or a header).
Describe one API you built in a framework from the role's listed languages (Spring Boot for Java, Flask or FastAPI for Python, ASP.NET Core for C#): the resources, auth (OAuth2 bearer tokens over TLS), input validation, and how you tested it.
Cover concurrency and retries: ETags with If-Match return 412 on a stale update, and an idempotency key on POST lets a client retry safely without creating duplicates.

Follow-up

What is the difference between PUT and PATCH, and when would you use each?
How would you add a breaking change to an API without breaking existing clients?
When would you choose gRPC or GraphQL over REST?

Design a system for real-time data processing in a healthcare application.

Medium · System Design / Architecture

Approach

Clarify scope first: data sources (lab instruments, devices, clinical systems sending HL7 or FHIR messages), event volume, end-to-end latency target, and consumers (clinician alerts, dashboards, downstream analytics). The latency target decides between stream processing and micro-batches.
Ingest through an authenticated API or gateway into a durable log such as Kafka or Kinesis, partitioned by patient ID so each patient's events stay in order. The log decouples producers from consumers and allows replay after a bug.
Process with a stream engine (Flink, Kafka Streams or Spark Structured Streaming): validate the schema, enrich with reference data, compute windowed aggregates and threshold rules. Use event time with watermarks so late or out-of-order readings are handled, and send malformed messages to a dead-letter queue.
State the delivery semantics: at-least-once with idempotent consumers keyed by event ID, so duplicates never produce a double alert or a double write. Store recent data in a query store for dashboards and raw events in object storage for audit and reprocessing.
Treat the data as protected health information: TLS in transit, encryption at rest, least-privilege access, and audit logs of every read. Add monitoring of consumer lag and backpressure, since a growing lag means alerts arrive late.

Follow-up

How do you handle readings that arrive minutes late or out of order?
If the alerting service is down for ten minutes, how do you avoid both lost and duplicate alerts?
A rule had a bug for a day. How would you reprocess that day's data?

How would you handle database management for a large-scale application?

Medium · System Design / Architecture

Approach

Start from the access patterns: read/write ratio, the hottest queries, data growth, and consistency needs. Transactions and joins point to a relational database; very high write volume on simple keys or flexible documents can justify NoSQL. The role's listed requirements mention both SQL and NoSQL systems.
Tune before scaling out: composite indexes that match the WHERE and ORDER BY columns (a B-tree index serves its leftmost prefix), EXPLAIN to check the plan, a fix for N+1 query patterns, and connection pooling so the database is not flooded with connections.
Scale reads with replicas and a cache (cache-aside with a TTL and invalidation on write). Name the cost: replication lag, so a user who just wrote may read stale data unless that read goes to the primary.
Scale writes and size with partitioning (for example by time range, which makes dropping old data cheap) and then sharding. The shard key decides everything: a good one spreads load evenly, and queries that do not include it fan out to every shard.
Cover operations: backward-compatible schema migrations (add a column, backfill, switch reads, then drop the old one), automated backups with point-in-time recovery and regularly tested restores, and slow-query monitoring.

Follow-up

How would you choose a shard key, and what do you do when one shard becomes hot?
How would you add a column or index to a very large table without downtime?
How do you guarantee read-your-writes when reads go to replicas?

Discuss how you would ensure data security and compliance in your software solutions.

Medium · System Design / Architecture

Approach

Classify the data first: patient health information, identifiers, operational data. Then name the rules that apply; in US healthcare that is typically HIPAA, whose Security Rule covers access control, audit controls, integrity, authentication and transmission security. Map each control to that list.
Protect the data: TLS for everything in transit, encryption at rest with keys held in a key management service and rotated, secrets in a vault rather than in code or config, and backups encrypted the same way.
Control access: single sign-on with MFA, role-based least-privilege authorization checked on the server for every request, and no shared accounts. Log who read or changed which record, append-only and retained, so any access can be reconstructed.
Build security into the development process: threat modelling at design time, parameterized queries against SQL injection, output encoding, dependency and static scanning in CI, and code review for security-sensitive changes.
Minimise exposure: collect only what is needed, de-identify or pseudonymise data for analytics and test environments, define retention and deletion, and keep an incident response plan for a breach.

Follow-up

How would you give an analytics team useful data without exposing patient identities?
An auditor asks who viewed one patient's record last month. How does your system answer?
A database credential leaks. What are your first steps?

Walk us through your thought process when tackling a complex coding challenge.

Medium · Problem-Solving / Case Studies

Approach

Restate the problem and confirm the input, the output and the constraints. Input size sets the target: around 10^5 elements rules out O(n^2) and points to O(n log n) or O(n).
Work one or two small examples by hand and list edge cases before coding: empty input, a single element, duplicates, negative numbers, very large values.
State the brute-force solution and its complexity, find the repeated work, and pick the pattern that removes it: a hash map for lookups (two-sum goes from O(n^2) to O(n)), two pointers or sorting, a sliding window, a heap for top-k, BFS/DFS for graphs, dynamic programming for overlapping subproblems.
Code in small named helpers while explaining each step, then test by tracing an example and the edge cases through the code, and state the final time and space complexity.
If you get stuck, say which part is unclear, solve a simpler version (smaller input, sorted input) and build from it rather than going silent.

Follow-up

What do you do when you cannot see an optimisation after the brute-force version?
How do you check your code is correct without running it?
When would you choose a slower but simpler solution?

How do you approach debugging an application?

Medium · Technical / Domain Questions

Approach

Reproduce first: pin down the exact input, environment, version and configuration that trigger the bug, and write the reproduction as a failing test if possible. Without a reliable repro every fix is a guess.
Collect evidence before theorising: the stack trace, application logs around the timestamp, metrics, and what changed recently (deploys, config, dependency upgrades, data). A correlation ID across services lets you follow one request end to end.
Narrow the search by halving it: git bisect finds the breaking commit in about log2(n) steps, toggling a feature flag or shrinking the input isolates the trigger, and a debugger with breakpoints or targeted logging confirms the state at each step.
Watch for bugs that change under observation: race conditions, timeouts, caching and environment differences. Compare production and local config, and test under concurrency.
Fix the root cause, keep the failing test as a regression test, check nothing else depends on the old behaviour, and record what happened so the class of bug is caught earlier next time.

Follow-up

The bug appears only in production and never locally. What do you check first?
How would you debug a test that fails only about one run in twenty?
How would you track down a memory leak or an endpoint that slowly gets slower?

Suggested practice checklist

The seven days follow the reported question types: loop mapping, coding fundamentals, debugging and REST, healthcare-flavored system design, databases and cloud, behavioral stories, then a full mock of both rounds.

Day 1 — Map the loop and choose your language

Write out the two reported rounds, the phone screening and the onsite interviews, and list the sixteen reported questions under technical, design, problem-solving, coding and behavioral.
Mark the five questions you could not answer well aloud today, and pick Java, Python or C# as the single language you will code in.
List the databases, cloud services and Git or Agile practices from your last two projects so they are ready for the phone screening.

Deliverable: A one-page loop map with the weakest questions marked, your chosen language, and a list of projects with their stack.

Day 2 — Coding core: linked list, graph traversal, search

Write the linked-list reversal iteratively and recursively, and test the empty, one-node and two-node cases.
Implement depth-first search (recursive and with an explicit stack) and breadth-first search on an adjacency list, then use breadth-first search for a shortest path on a grid.
Write a spoken answer on optimizing search over a large dataset that starts with questions about sortedness, update rate and memory, then compares linear scan, binary search, a hash index and a database index.

Deliverable: Three working solutions with tests in your chosen language, plus a written outline of the search-optimization answer.

Day 3 — Debugging, REST and the lifecycle

Write your debugging sequence (reproduce, narrow with bisection, check logs and instrumentation, form one hypothesis at a time, fix, add a regression test) and attach a real bug you fixed.
List what makes a service RESTful (resources, HTTP verbs, status codes, statelessness, idempotency, pagination, versioning) and write up one REST API you built.
Tell the software development lifecycle through one real project, phase by phase, including testing, deployment and maintenance.

Deliverable: Three spoken answers rehearsed from notes, plus a one-page REST reference tied to an API you built.

Day 4 — Healthcare system design with security built in

Sketch a real-time data processing design: ingestion through an API or queue, validation, a stream or worker stage, storage, and alerting. State the delivery guarantee, how you handle duplicates and what happens when a downstream system is down.
Outline a database plan for a large-scale application: relational versus document storage, indexing, replication, backups, schema migrations and archiving.
Write the security and compliance layer that you will add to both designs: encryption, access control, audit logging, minimal sensitive data and retention.

Deliverable: Two labelled diagrams (processing pipeline and database plan) and a spoken security and compliance answer for each.

Day 5 — Databases and cloud deployments

Write your cloud deployment story: provider, services used, the path from commit to production, rollout method, rollback signal and one measured result.
Prepare a short comparison of when you would choose SQL or NoSQL, using a real project as the example.

Deliverable: Two completed SQL exercises with explanations, a written cloud deployment story and a SQL versus NoSQL answer.

Day 6 — Behavioral stories and problem-solving process

Write out three stories from different projects, one each for the team goal and your role, a conflict, and a positive influence on a project, with your actions in first person and a measurable result.
Prepare the story of a challenging technical problem you solved, with the diagnosis steps and the fix.
Write how you approach ambiguous requirements (questions to ask, assumptions to write down, a first small deliverable to confirm) and how you work through a complex coding challenge from restating the problem to testing it.

Deliverable: Three written story outlines, a technical-problem story and two spoken process answers.

Day 7 — Full mock of both rounds

Run the phone screening: a career walkthrough, the cloud deployment story and your questions for the recruiter. Record it.
Run a mixed onsite: reverse a linked list in your chosen language, answer the real-time healthcare data processing design aloud, and tell your conflict story.
Review the recordings and list the three weakest answers, then redo each one.

Deliverable: A recorded mock of both rounds and a list of three fixes with the redone answers.

Teamwork, conflict, influence and cloud stories

Candidates report teamwork, conflict and influence questions, and the reported list also asks about your own experience with cloud services and deployments and a challenging technical problem. Reports name leadership, including communication and collaboration, and culture fit among the evaluation areas, and the onsite includes HR representatives. Prepare each prompt as a real story with your own actions and a result, because the experience-based technical prompts are best answered the same way.

Describe a challenging technical problem you've encountered and how you solved it.
How would you approach a project with ambiguous requirements?

What is your experience with cloud services and deployments?

Medium · Technical / Domain Questions

Approach

Open with a one-line inventory of what you have actually run in the cloud (compute, storage, a managed database, a queue, a scheduler), then pick one deployment you owned and tell it as a story. Name the provider and services you really used; a short true list is stronger than a long one you cannot defend.
Walk the path from commit to production: build and tests in CI, a versioned artifact such as a container image or package, a staging environment, then the rollout method (rolling, blue-green or canary) and the signal that told you to proceed or roll back.
Cover the parts that fail quietly: configuration and secrets kept out of source control, parity between environments, database migrations that stay compatible with the previous release, and the dashboards or alerts you watched after the release.
State what you personally decided, for example: I split the schema migration into its own step so the old version could keep serving traffic. End with a result you measured, such as fewer failed releases or faster rollback. If your cloud experience is limited, describe the closest deployment work honestly and what you have studied since.

Follow-up

How did you roll back that release, and have you had to do it in production?
How did you manage secrets and per-environment configuration?
What would you change in that pipeline if you rebuilt it today?

Describe a situation where you had to work within a team to achieve a goal. What was your role?

Medium · Behavioral / Leadership

Approach

Choose a project where goal, team shape and your role fit in two sentences, for example: a team of four had to ship an integration between two systems and I owned the data mapping and its tests. The question asks for your role, so the role has to be concrete.
Separate your contribution from the group's. Describe your interfaces with teammates (who you depended on, who depended on you), how the work was divided, and one decision of yours that changed the outcome.
Show how the team stayed coordinated: tickets and sprint planning if you used Agile or Scrum, review habits on pull requests in Git, and how a blocker was raised and cleared.
Close with a measurable result and one thing you would run differently. The mistake that sinks this answer is describing the team's success in collective pronouns so that your own contribution disappears.

Follow-up

What was the hardest handoff between you and a teammate?
What did you do when a teammate's part was late?
How did you know the team's goal had actually been met?

How do you handle conflict within a team setting?

Medium · Behavioral / Leadership

Approach

Pick a disagreement about substance, such as an API contract, a schema change, a release date or a review comment, rather than a personality clash, and state what was at stake.
Show that you understood the other position first: say it in their terms and name the constraint behind it. Then show how you moved from opinions to evidence: a small prototype, a benchmark, a production log, the written requirement, or a decision from the person who owns that area.
Describe how it ended. Agreement, a compromise, or being overruled and committing to the decision are all acceptable endings if you show the reasoning and what the working relationship was like afterward.
Avoid a story where the other person was simply wrong, and avoid claiming you never have conflict. Keep your description of the other person neutral and specific.

Follow-up

What if the other person still disagreed after you showed the benchmark?
At what point would you escalate, and to whom?
Tell me about a disagreement with someone more senior than you.

Can you give an example of how you have influenced a project positively?

Medium · Behavioral / Leadership

Approach

Choose a change you started without being assigned it: a test or review practice, a monitoring gap you closed, a requirement you challenged, a design you simplified. The story must show your initiative and a change in the project's results, not only effort.
Give the before and after with numbers you can defend, such as defect counts, deploy frequency, incidents, support requests or review turnaround. If you have no number, describe the observable difference and how you checked it.
Explain how you gained agreement without authority: who you spoke to first, what you showed them (a demo, a pull request, a small pilot) and how you handled objections. If the project involved other functions, include a non-engineering stakeholder you had to persuade.
End with whether the change lasted after you stopped pushing it, and say which part of the result was yours rather than the whole team's.

Follow-up

How did you separate the effect of your change from other things that changed?
Who disagreed with you, and how did you handle it?
What would you have done if the team had rejected the idea?