AtriCure Software Engineer Interview Guide

The 60-second brief

AtriCure builds surgical medical devices, and the Software Engineer role works on the software behind them. Candidate reports tie the work to treatment of atrial fibrillation and related conditions. The day-to-day described is designing and implementing features, reviewing code and following a product from requirements through validation, alongside electrical, mechanical and systems engineers and the manufacturing and quality-systems teams. Example projects include tuning device performance, improving clinician-facing interfaces and building internal engineering tools.

This guide is for software engineers interviewing at AtriCure, from the recruiter screen to the leadership conversations. It covers the five reported questions, the evaluation areas candidates describe (failure analysis and troubleshooting, process validation, cross-functional work, explaining past projects) and the testing, version control and CI/CD topics listed for the role. It also helps if you come from a non-regulated background and need to translate your experience.

No fixed round list is reported. Candidates describe a recruiter screen, technical conversations with hiring managers and peer engineers, then discussions with leadership, and an onsite that includes a tour of the facility.

Focus areas

• Failure analysis / troubleshooting
• Process validation
• Cross-functional engineering areas (product, manufacturing,

Overview

The work described for this role sits where software meets hardware and other disciplines. Candidates report designing and implementing features, doing code reviews and following a product from requirements gathering to validation, working beside electrical, mechanical and systems engineers. Projects named include tuning device performance, improving clinician-facing interfaces and building internal tools for engineers. For preparation, that means your stories should show software decisions made with other disciplines in the room, not only code written in isolation.

All five reported questions are discussion questions rather than coding puzzles: a project you took from inception to delivery, how you keep code to the quality and safety bar of a medical device, a production bug you troubleshot, your experience with software lifecycle management in a regulated industry, and how you balance technical debt against aggressive launch timelines. Reports also list example prompts on error handling in mission-critical software and on debugging a problem that is hard to reproduce. Candidates are told the topic areas are failure analysis and troubleshooting, process validation, cross-functional engineering and technical storytelling about past projects. Rehearse spoken answers that carry concrete detail: names of tools, the decision you made, the alternative you rejected and the result.

Reported requirements list core programming languages, the software development lifecycle, debugging and testing as must-haves, with medical-device or other regulated experience (aerospace, automotive), embedded systems and quality management systems as nice-to-haves. If you have not worked in a regulated setting, do not bluff. Translate what you have: code review gates, requirement-to-test traceability, release approvals, change records and incident follow-up. Candidates are also advised to say how they would find an answer when they do not know it, and to be ready to discuss every project on the resume in depth.

Where to focus your preparation

The accounts describe a sequence of conversations rather than a fixed list of rounds, so this guide treats preparation as one block covering all of them. Confirm the exact stages for your team with the recruiter.

Preparation focus

Candidates report a recruiter screen first, then technical deep-dives with hiring managers and peer engineers, then discussions with leadership, with some meeting the team they would work with and taking a facility tour onsite. No stage-by-stage question list, stage length or coding exercise is reported, and the five reported questions are discussion-style. Prepare one set of answers that works in every conversation: a project delivered end to end, your quality and safety practices, a production troubleshooting story, your lifecycle experience and your technical-debt judgement. Early conversations tend to suit crisp technical fundamentals; later ones suit decisions, influence and how you work with other functions.

What to demonstrate

• Ability to explain a past project in depth, including why you chose the architecture and how you handled setbacks
• Debugging and testing approach, including how you handle failures that are hard to reproduce
• Fit with a regulated lifecycle and with working alongside manufacturing, quality and hardware engineers
• Structured thinking out loud when a problem has no obvious starting point

How to prepare

• Write a one-page outline of your strongest end-to-end project: requirements, design choices and rejected alternatives, test strategy, release and what you would change
• Build a checklist of quality practices you really use (review, unit and integration tests, CI gates, traceability, error handling on failure paths) and attach one defect each caught
• Prepare the production-bug story with containment, evidence, root cause, verification of the fix and prevention
• Ask the recruiter which stages your loop has and who you will meet, then adjust the balance between technical depth and cross-functional stories

Where candidates lose points

Telling the project story as 'the team did X' without saying which decisions were yours

For the project from inception to delivery, name three decisions you personally made, the alternative you rejected for each and the evidence you used. Reports say the resume can be explored in depth, so practise defending every project you list, including the tools and methods you used.

Answering the quality and safety question with 'I write unit tests and do code reviews' and nothing more

Name specific mechanisms: review rules, unit and integration tests, CI gates, static analysis, requirement-to-test traceability and how failure paths are handled (explicit error returns, safe states, no swallowed exceptions, input validation). Attach one defect each mechanism caught so the answer is evidence, not a list.

A troubleshooting story that stops at the fix, with no root cause, no proof the fix worked and no prevention

Structure it as contain, gather evidence, isolate cause, fix, verify, prevent. State the signal that confirmed recovery and the guard you added. For hard-to-reproduce failures, say how you made them observable.

Treating process as overhead in the lifecycle and technical-debt answers, for example 'ship now, clean up later' with no tracking

Separate debt you can defer (naming, internal structure with test coverage) from debt you cannot (gaps in tests, error handling or data integrity). Describe how deferred debt is recorded with an owner and trigger, and how you explain the trade-off to product or manufacturing colleagues.

Claiming regulated-industry experience you do not have, or saying only that you have none

State the gap plainly, then map the closest equivalents you have worked with: release approvals, change records, test evidence, incident follow-up. Add what you would learn first on the job. Candidates are also advised to explain how they would find an answer they do not know.

Questions & practice

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

• The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
• A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

• The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
• Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Can you walk us through a complex software project you led from inception to delivery?

Medium · Technical and Domain Experience

Approach

1. Pick one project where I owned the technical decisions, and give its scope in two sentences: the problem, the system boundary (device firmware, desktop tool, test fixture, data pipeline) and my role versus the team's.
2. Walk it in lifecycle order: how requirements were captured and frozen, the architecture I chose with one alternative I rejected and why, how I broke the work into components, and how each component was verified.
3. Spend most of the time on the hardest technical problem: what failed or was unknown, how I isolated it, and the trade-off I accepted (latency vs memory, buy vs build, schedule vs test depth).
4. Show verification and release evidence: unit and integration test levels, how requirements traced to tests, how reviews worked, and what went out in the release package.
5. Close with measurable results (defects found after release, performance numbers, delivery date against plan) and one thing I would design differently now.

Follow-up

• A requirement changed halfway through. How did you assess its impact on design and tests, and who approved the change?
• Which architectural decision would you reverse with hindsight, and what would it cost to change now?
• How did you coordinate with hardware, manufacturing or quality engineers when your software depended on their schedule?

How do you ensure your code meets the rigorous quality and safety standards required for medical devices?

Medium · Technical and Domain Experience

Approach

1. Start from risk: hazard analysis per ISO 14971 identifies how software can contribute to harm, and the IEC 62304 safety class (A: no injury possible, B: non-serious injury possible, C: death or serious injury possible) sets how much rigour each software item needs.
2. Keep traceability end to end: each requirement maps to design elements, code and at least one test, and each risk control implemented in software has its own verification test. A gap in the trace matrix is a defect.
3. Layer the verification: unit tests with a branch-coverage target on safety-related units, integration tests against real or simulated hardware, system tests against the requirements, plus static analysis (MISRA C or a strict clang-tidy profile, warnings treated as errors) and checklist-based peer review.
4. Code defensively where a fault matters: validate every input range, check return codes, use a watchdog and a defined safe state, avoid dynamic allocation after start-up in embedded code, and log enough to reconstruct a field failure.
5. Control the build: everything under version control, reproducible CI builds, evaluated and pinned third-party components (SOUP in IEC 62304 terms), and change control so every released binary maps to a reviewed commit.

Follow-up

• Which IEC 62304 activities change when a software item moves from Class B to Class C?
• How do you qualify a third-party library or RTOS whose source you cannot inspect?
• What should the software do if a sensor reading goes out of range in the middle of a procedure?

What experience do you have with software lifecycle management in a regulated industry?

Medium · Technical and Domain Experience

Approach

1. Map my experience onto the IEC 62304 processes rather than listing tools: development planning, requirements analysis, architecture, detailed design, unit implementation and verification, integration, system testing and release, then maintenance, configuration management and problem resolution.
2. Describe change control concretely: every change starts from a change request or problem report, gets an impact analysis (which requirements, risk controls and tests it touches), a defined regression scope, review sign-off and a traceable commit.
3. Explain verification versus validation with an example from my work: verification shows the outputs meet the design inputs (tests against requirements); validation shows the product meets user needs in its intended use.
4. If my background is aerospace or automotive, map it honestly (DO-178C or ISO 26262 to IEC 62304, a hazard analysis to ISO 14971) and name what I would still need to learn; if it is unregulated, show the equivalent discipline I already practise.
5. Cover running iterative development in a regulated setting: short sprints with traceability and reviews kept current every sprint (AAMI TIR45 describes this approach), rather than a documentation catch-up before release.

Follow-up

• A bug is found after release. Walk through what happens from the problem report to the fixed version shipping.
• How do you keep the trace matrix current when requirements change every sprint?
• What goes into a design review, and what evidence has to exist before it can pass?

How do you balance technical debt with the need to meet aggressive product launch timelines?

Medium · Technical and Domain Experience

Approach

1. Classify the debt before trading it: anything touching a risk control, safety-related code or verification evidence is not negotiable for the date; internal quality debt (duplication, slow builds, awkward interfaces) can be scheduled.
2. Negotiate scope, not quality: cut or defer a feature, keep the test and review evidence for what ships, because shipping untested code in a regulated product creates rework that lands after release.
3. Price the deferral: in a regulated product, a post-release fix goes back through change control, impact analysis and re-verification, so I estimate that regression cost and compare it with fixing now.
4. Make deferred debt visible and owned: a ticket with the cost it adds to each future change, an owner and a target release, reviewed at release planning so it does not disappear.
5. Back it with one real example with numbers: what I deferred, what I refused to defer, the date met or missed, and what the deferred item cost later.

Follow-up

• Tell me about a debt item you deferred that cost more than you expected. What would you decide differently?
• How do you convince a product manager to fund a refactor that has no visible feature?
• When is a rewrite justified instead of incremental refactoring, and how would you de-risk it?

Every query on one table stalls for forty seconds mid-deploy

Medium · lock contention · ddl · migrations

During a release on PostgreSQL, every query touching resource times out for about 40 seconds and then recovers with no intervention. The release ran one migration, ALTER TABLE resource ADD COLUMN archived_reason TEXT, and the migration log shows it completing in 6 ms. Unrelated tables showed no change in error rate. Explain how a 6 ms statement caused a 40-second stall, give the ordered checks you would run on a live system to confirm it, and give the migration procedure that prevents a repeat.

Approach

1. Separate the statement's duration from the lock's duration. ADD COLUMN with no default is a catalogue-only change and genuinely runs in milliseconds, but it requires ACCESS EXCLUSIVE, and it cannot acquire that until every transaction already touching the table has finished.
2. Account for the queueing, which is the part that surprises people. A lock request that is waiting blocks later requests for conflicting modes behind it rather than letting them overtake, so one long-open transaction holds the DDL and the DDL holds all the traffic. The stall length is set by the longest open transaction, not by the size of the change.
3. Confirm on a live system in this order: pg_stat_activity for that table ordered by xact_start, looking for the oldest transaction and specifically for state = idle in transaction; then pg_locks where granted = false to find the waiter; then join them on pid to name blocker and blocked. pg_blocking_pids() does that join for you and is the fastest single call.
4. Prevent rather than merely time it better. Set lock_timeout to a second or two on the migration session so the DDL abandons the queue after a bounded wait and is retried, instead of holding it for as long as the oldest transaction lives. Be exact about what that buys: queries arriving during the wait still queue behind the pending ACCESS EXCLUSIVE request, so each attempt costs them up to one lock_timeout of added latency. The outage goes from 40 seconds to about one second per attempt, not to zero. Also run migrations away from deploy-time peaks, and put a statement timeout and an idle-in-transaction timeout on the analytics role that opens the long transactions.

Follow-up

• The same release also wants NOT NULL on that column. What is the sequence that gets there without a long lock?
• Your lock_timeout retry fails ten times in a row because the analytics transaction is always open. What do you change?

Suggested practice checklist

Each day targets one of the reported questions or topic areas: project storytelling, quality and safety practices, troubleshooting, regulated lifecycle, technical debt, cross-functional influence, then a full spoken run. Practice-library questions on debugging, concurrency and code review are added where they sharpen the same skills.

Day 1 — Inventory your projects and shape the delivery story

• List every project on your resume with your role, the stack, the outcome and one decision you would defend in depth.
• Pick one project you carried from inception to delivery and outline it as requirements, design choices with rejected alternatives, test strategy, release and what you would change.
• Tell the story aloud for the question about a complex project from inception to delivery and tighten any part where you say 'we' without naming your own call.

Deliverable: A project inventory and a one-page outline of the end-to-end story, plus a recorded spoken run of it.

Day 2 — Build the quality and safety answer

• Write the list of quality practices you actually use: review rules, unit and integration tests, CI gates, static analysis and traceability from requirement to test.
• For each practice, attach one defect it caught or one failure it prevented.
• Write your policy for error handling in mission-critical code: safe state on failure, no swallowed exceptions, input validation, timeouts and logged faults.
• Answer the question on meeting medical-device quality and safety standards aloud using those examples.

Deliverable: A practice-and-evidence checklist and a spoken answer to the quality and safety question.

Day 3 — Troubleshooting stories and hard-to-reproduce bugs

• Write the production-bug story with context, containment, evidence, root cause, fix, verification and prevention.
• Write a repeatable method for an intermittent failure: capture inputs, add targeted logging, compare environments, bisect releases.
• Work the practice debugging question about queries stalling mid-deploy and the practice SQL question on detecting a concurrent edit, and note the diagnosis order you used.

Deliverable: A written troubleshooting story, a diagnosis checklist for intermittent bugs and notes on both practice questions.

Day 4 — Describe your lifecycle experience for a regulated setting

• Map your last team's lifecycle onto requirements, design, implementation, verification, validation, release and maintenance, naming the artifact each stage produced.
• List how changes were approved and traced, such as review records, release sign-off and incident follow-up.
• If you have no regulated experience, write an honest answer that states the gap, names the nearest equivalents and says what you would learn first, then practise it aloud.

Deliverable: A lifecycle map with artifacts and a spoken answer on regulated-industry lifecycle management.

Day 5 — Technical debt against launch timelines

• Write one case where you deferred debt to hit a date and one where you paid it down, with the reasoning and the outcome for each.
• Write your decision rule: debt that touches test coverage, error handling or data integrity does not ship deferred; the rest is logged with an owner and a trigger.
• Practise explaining the trade-off to a non-software colleague, then work the practice question on turning a code review disagreement into a decision.

Deliverable: Two debt cases, a written decision rule and notes on the code review practice question.

Day 6 — Cross-functional work and technical influence

• Write a story where you worked with hardware, quality, manufacturing or product colleagues and a software decision changed because of it.
• Write a story where you mentored someone or led a technical initiative without formal authority.
• Work the practice question on unblocking an engineer without taking the keyboard, and practise explaining one technical decision to a non-software audience.

Deliverable: Two cross-functional or influence stories and a plain-language explanation of one technical decision.

Day 7 — Full spoken run and questions to ask

• Answer all five reported questions back to back aloud, recorded, and cut any answer that lacks a concrete example.
• Re-read your resume and confirm you can speak in depth to every project on it.
• Write the questions you would ask about the development process, the team's current challenges and how software works with manufacturing and quality.

Deliverable: A recorded run of the five answers and a short list of questions for interviewers.

Stories to prepare for AtriCure

The reported conversations lean on stories: a project you delivered, a production failure you handled, a lifecycle you worked within, a trade-off between debt and dates, and how you work with other functions. Candidates also report that leadership and influence matter even in individual contributor roles, so have a mentoring or technical-initiative example ready. Tell each story in first person with the decision, the evidence and the outcome.

1. Tell me about a project you carried from inception to delivery and the decision you would defend most.
2. Describe a time you worked with hardware, manufacturing or quality colleagues and changed a software decision because of it.
3. Tell me about a time you mentored a colleague or led a technical initiative without formal authority.
4. Describe a time you shipped with known technical debt: what you deferred, what you refused to defer and why.

Describe a time you had to troubleshoot a critical bug in a production environment.

Medium · Technical and Domain Experience

Approach

1. Choose an incident you owned: you made the containment and root-cause calls, not one you watched. Give the context in two sentences (system, symptom, who or what was affected) and spend the remaining time on reasoning. For a medical-device employer, a story where a wrong fix would have been costly, such as data integrity or a device-facing behaviour, fits the setting.
2. Walk the sequence in order. Contain first (rollback, feature flag, disabling the failing path). Then collect evidence: logs, metrics, traces, a captured failing input, a bisect over recent releases. Then list hypotheses and say which observation eliminated each one. Name the root cause separately from the visible symptom.
3. If the bug was intermittent, say how you made it reproducible or observable: added targeted logging, compared the failing and healthy environments, replayed recorded inputs, or narrowed the window by bisecting versions. Concurrency, timing, configuration drift and bad input are the usual families, so name the one you found.
4. Close the loop on the fix. Describe the regression test that failed before the change and passed after, the peer review of the fix, how you released it (staged or monitored) and the metric or signal that showed the problem had gone. Then say what you changed so it cannot recur: an alert, a validation, a test, a checklist or a post-incident write-up shared with the teams affected.
5. The mistake that sinks this answer is a story that ends at 'I restarted it' or 'I found the line', with no root cause, no verification and no prevention, or one told entirely as 'the team did'. Keep it first person and include one thing you would do differently.

Follow-up

• How did you confirm the fix addressed the root cause rather than the symptom?
• What would you have done if you could not reproduce the failure at all?
• Who did you tell while it was unresolved, and what did you say about risk and next steps?

Turn a code review disagreement into a decision

Easy · code review · optimistic concurrency · communication

A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.

Approach

1. Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
2. Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
3. Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
4. Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.

Follow-up

• Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
• The author says clients cannot handle a 409. How do you check whether that is true?

Unblock an engineer without taking the keyboard

Easy · mentoring · leases · at-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach

1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.

Follow-up

• How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
• Their handler calls an external endpoint before recording that it did. What do you tell them to change first?