American Medical Association Software Engineer Interview Guide

The 60-second brief

The American Medical Association (AMA) is the organisation behind this role. Candidates describe the Software Engineer position as building and maintaining software that supports its public-health mission, for users such as physicians, patients and policy makers. The project areas mentioned are electronic health records, telemedicine platforms and patient engagement tools. Day to day, the responsibilities candidates describe cover writing maintainable code, taking part in code reviews, following a feature from requirements through deployment, extending existing applications, building new features and connecting to third-party services, alongside product managers, designers and other engineers.

This guide is for software engineers preparing for the American Medical Association loop. It covers the five reported rounds, the reported technical, system design, problem-solving, coding and behavioral questions with worked preparation advice, the languages and frameworks the role lists, and a seven-day plan. It does not cover pay, and it makes no claim about what any interviewer will ask in a given round.

Candidates report five rounds over roughly 4-6 weeks: an HR Conversation, a Technical Phone Screen, an In-Person Interview with a whiteboarding exercise, Director Meetings, and a Panel Interview with the VP and hiring manager.

Focus areas

• Whiteboarding / In-Person Problem Solving
• Technical Phone Screen
• Problem Solving

Overview

The role description candidates see lists Java, Python or JavaScript, a web framework such as React or Angular, SQL and NoSQL databases, and Agile or Scrum working practices. Nice-to-have items are healthcare or health IT experience, cloud services such as AWS or Azure, UI and UX principles, and Git. That is a broad full-stack profile, so prepare to talk about both frontend and backend work, database choices and the software development life cycle, and choose one language you can write cleanly on a whiteboard.

The reported questions fall into five groups. Technical fundamentals: the difference between REST and SOAP, the principles of object-oriented programming, a challenging technical problem you solved, code quality and maintainability, and development methodologies. Design: a high-level architecture for a healthcare application that tracks patient data, security of sensitive health information, and API design for third-party integrations. Problem solving: diagnosing a bug a user reports in a critical application, and prioritising under a tight deadline. Coding: reversing a linked list, implementing a search algorithm with its time complexity, and a problem using stacks or queues. Behavioral: collaborating on a team goal, handling team conflict, and adapting to a significant project change. Candidates describe these as representative patterns that vary by team, so train the underlying skills rather than memorising answers.

Because the design questions centre on patient data and health information, the security reasoning matters as much as the box diagram. Be ready to say what data is sensitive, who may read or change it, how access is recorded, how data is protected in transit and at rest, and what you would expose to an outside integrator. If you have no health IT background, reasoning carefully about sensitive records is the way to show you can work in this setting; for a US context, know the basics of what HIPAA's privacy and security rules require.

The later rounds are reported as director meetings and a panel with the VP and hiring manager, both described as covering technical expertise and leadership. Plan for stories where you owned a decision, a project walk-through you can explain from requirements to deployment, and examples of giving or receiving feedback and mentoring. The same stories can serve the behavioral questions and the 'challenging technical problem' question, so prepare a small set deeply instead of many shallowly.

The American Medical Association interview process

Candidates describe five stages, from an HR conversation through to a panel. The order below is the one they report, and what each stage covers is limited to what they describe.

HR Conversation

Candidates report an opening conversation with an HR representative about the role and your background. Treat it as the point where your experience is matched to the languages and frameworks the role lists. Have a concise walk through your career ready, tied to the stack in the requirements, and a plain reason for wanting to build software in a healthcare organisation.

What to demonstrate

• How clearly you describe your background and the kind of work you want
• How your experience lines up with the languages, frameworks and databases the role lists
• Your interest in the role and the organisation's healthcare setting

How to prepare

• Write a short career walk-through that names one project each for backend work, frontend work and database work, using Java, Python, JavaScript, React, Angular, SQL or NoSQL only where you have really used them.
• Prepare a sentence on why healthcare software interests you that refers to a concrete project area such as electronic health records, telemedicine or patient engagement tools.
• Write down your questions about the remaining rounds and ask for the full loop in writing, since the later stages involve directors and a panel.

Technical Phone Screen

Candidates report a technical phone interview with members of the tech team. A phone format has no whiteboard, so each answer must work spoken aloud: state the concept, contrast it with the alternative, then give one concrete example from your own work. The reported technical questions include REST versus SOAP, the principles of object-oriented programming, code quality, and development methodologies, which are the kind of material a phone conversation covers well.

What to demonstrate

• Working knowledge of the languages, web frameworks and databases listed for the role
• How well you explain technical ideas without diagrams
• The depth behind your stated skills, shown through examples from past projects

How to prepare

• Practise a spoken answer to the difference between REST and SOAP that covers contract, message format, transport, error handling and when you would choose each.
• Prepare the four object-oriented principles (encapsulation, abstraction, inheritance, polymorphism), each with a small example in your main language.
• Prepare an account of how you keep code maintainable: reviews, automated tests, naming, small functions, refactoring and static analysis, using a real repository as the example.
• If you are asked to explain code verbally, practise narrating pointer or index changes step by step, and stating the time and space complexity at the end.

In-Person Interview

Candidates report an in-person interview that includes a whiteboarding exercise where you solve a technical problem collaboratively. Whiteboard problems here can be coding or design, so practise both. The collaborative framing means you should think out loud, ask clarifying questions and treat the interviewer as a partner in the solution, rather than writing in silence.

What to demonstrate

• Working code or a coherent design produced without an editor or compiler
• How you break a problem down and communicate while solving it
• Whether you can take a hint or a changed requirement and adapt your solution

How to prepare

• Hand-write solutions to the reported coding questions: reverse a linked list iteratively and recursively, implement binary search with its complexity, and solve a stack or queue problem such as matching brackets or a queue built from two stacks.
• Practise a patient-data architecture on a blank board: clients, API layer, services, database, audit log and identity, drawn in a consistent order while you explain each choice.
• Rehearse an opening routine for every problem: restate it, ask about inputs and limits, give an example, outline the approach, then write.
• Practise a bug-diagnosis walk-through you can narrate: reproduce, narrow down, form a hypothesis, test it, fix, add a regression test.

Director Meetings

Candidates report meetings with directors that cover technical expertise and leadership capabilities. Expect conversation about your past work and decisions rather than only exercises, so prepare to go deep on one or two projects: the requirements, the architecture, the trade-offs you made, and what happened after deployment.

What to demonstrate

• Depth of technical expertise in the projects you describe
• Leadership shown through projects you led, feedback you handled and people you mentored
• How you reason about security of sensitive information and about APIs that other organisations consume

How to prepare

• Prepare a project walk-through that goes from requirements to deployment, naming your decisions, the alternatives you rejected and what you would change now.
• Prepare answers on securing sensitive health information: least-privilege access, encryption in transit and at rest, audit trails, secrets handling and data minimisation.
• Prepare an API design answer for third-party integrations covering authentication, versioning, rate limits, idempotent writes, clear error responses and documentation.
• Choose two leadership examples, such as leading a feature or mentoring a colleague, and write the situation, your action and the result for each.

Panel Interview

Candidates report a panel interview with the VP and hiring manager, focused on technical and leadership skills. Several people ask in one sitting, so organise answers into a short headline followed by supporting detail, so that each listener can follow whichever level they care about. Reuse the stories and project walk-through you built for the earlier stages.

What to demonstrate

• Technical judgement and leadership as discussed with a mixed audience of senior and hiring-manager listeners
• Consistency between what you said in earlier rounds and what you say now
• How you collaborate with, and influence, other people on a team

How to prepare

• Practise your project walk-through twice: once as a two-minute headline version for a non-specialist and once as a detailed version for an engineer.
• Rehearse the collaboration, conflict and project-change stories until each states your own role and a verifiable result.
• Prepare the trade-off reasoning behind your design answers, such as SOAP versus REST for a given partner or relational versus document storage for patient data.
• Write closing questions about team structure, how work is planned and how engineers work with product managers and designers.

Where candidates lose points

Answering REST versus SOAP with two memorised definitions and no contrast

Compare them on specific axes: SOAP uses an XML envelope with a WSDL contract, standardised faults and WS-Security, while REST uses resources, HTTP verbs, usually JSON, stateless calls and cacheable reads. Then say which you would pick for a partner integration and why.

Losing the next pointer or missing empty and single-node lists when reversing a linked list on a whiteboard

Write the iterative version with previous, current and next pointers, dry-run it on an empty list, one node and three nodes before declaring it done, and state O(n) time and O(1) space. Then offer the recursive version and its stack cost.

Drawing a patient-data architecture as boxes and arrows with no treatment of who may see what

Add identity and role-based access, encryption in transit and at rest, an audit log of reads and changes, data minimisation and a backup and retention plan to the first sketch, before scaling concerns.

Telling collaboration, conflict and change stories in the first person plural so your own role disappears

Open each story with your specific responsibility, use 'I' for your actions and decisions, and end with a result and what you would change. The reported collaboration question asks for your role explicitly.

Jumping to a fix when asked how you would diagnose a bug a user reports in a critical application

Narrate the sequence: gather the report and impact, reproduce it, check recent deployments and logs, narrow the cause by bisecting, apply the smallest safe fix, add a regression test, and tell the user what happened.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Clarify the input: a singly linked list given by its head node, possibly empty; the function returns the new head.
2. Iterative solution with three pointers: prev = None, curr = head; while curr: nxt = curr.next; curr.next = prev; prev = curr; curr = nxt; return prev. It runs in O(n) time and O(1) extra space.
3. Explain the invariant: at every step prev heads the already-reversed part and curr heads the untouched rest; saving next before rewiring is what prevents losing the remainder of the list.
4. Mention the recursive version (reverse the rest, then set head.next.next = head and head.next = None): 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).
5. Test the edge cases aloud: empty list, a single node, two nodes, and confirm the old head now points to None so the result has no cycle.

Follow-up

• Reverse only the nodes between positions m and n in one pass.
• Reverse the list in groups of k nodes, leaving a final group shorter than k as it is.
• How does the code change for a doubly linked list?

How would you implement a search algorithm? What would be its time complexity?

Medium · Coding / Algorithms

Approach

1. Ask what is being searched: an unsorted array calls for linear search at O(n) time; a sorted array allows binary search at O(log n); repeated lookups by key justify building a hash map once for O(1) average, O(n) worst-case lookups.
2. Write binary search iteratively: lo = 0, hi = n - 1; while lo <= hi: mid = lo + (hi - lo) // 2; return mid on a match, move lo = mid + 1 if the value is smaller, else hi = mid - 1; return -1. O(log n) time, O(1) space.
3. Point out the classic bugs: computing (lo + hi) / 2 can overflow a 32-bit int in Java, an off-by-one loop condition skips the last element, and failing to move lo or hi past mid loops forever.
4. Handle edge cases: empty array, target smaller or larger than every element, and duplicates; if the first occurrence is needed, write the lower-bound variant that keeps searching left after a match.
5. Place it among other searches: a balanced binary search tree gives O(log n) search with ordered traversal (O(n) if it degenerates), and BFS or DFS search a graph in O(V + E).

Follow-up

• Find the first and last positions of a target in a sorted array that contains duplicates.
• Search a sorted array that has been rotated at an unknown pivot.
• When would a hash map be the wrong choice compared with a sorted structure?

Solve a problem that involves data structures like stacks or queues.

Medium · Coding / Algorithms

Approach

1. Pick the structure from the access order: a stack (last in, first out) for matching and undo problems such as checking balanced brackets, evaluating expressions or iterative DFS; a queue (first in, first out) for BFS, level-order traversal and task scheduling.
2. Work one canonical problem fully, for example balanced brackets: push each opening bracket, on a closing bracket pop and check it matches, fail on an empty stack, and succeed only if the stack is empty at the end; O(n) time, O(n) space.
3. Know the monotonic stack pattern for next-greater-element problems: each index is pushed and popped at most once, so the whole pass is O(n) amortized.
4. Know the design variants: a queue built from two stacks has amortized O(1) enqueue and dequeue, and a min stack keeps a second stack of current minimums so getMin is O(1).
5. Use the right library type: in Python, collections.deque for queues because list.pop(0) is O(n); in Java, ArrayDeque rather than the legacy Stack class.

Follow-up

• Implement a queue using two stacks and explain why dequeue is amortized O(1).
• Return the maximum of every sliding window of size k in O(n) using a deque.
• How would you make your stack or queue safe for concurrent producers and consumers?

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?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

1. Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
2. Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
3. For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
4. State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

• A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
• How do you honour an erasure request while resource_revision.actor_user_id still references this table?

Explain the difference between REST and SOAP.

Medium · Technical / Domain Questions

Approach

1. Open with the category difference: SOAP is a protocol with a fixed XML message format (Envelope, optional Header, Body, and a Fault element for errors), while REST is an architectural style built on resources named by URIs and the uniform HTTP interface.
2. Contrast the contracts: SOAP services are usually described by a WSDL file and clients are often generated from it; REST APIs have no mandatory contract, so teams typically publish an OpenAPI description and use JSON, though any representation works.
3. Cover transport and caching: SOAP is transport-neutral (HTTP, SMTP, JMS) and over HTTP almost always uses POST, so ordinary HTTP caches do not help; REST reuses HTTP semantics, where GET is safe and cacheable and PUT and DELETE are idempotent but POST is not.
4. Cover security and reliability: SOAP has WS-Security for message-level signing and encryption and WS-ReliableMessaging; REST normally relies on TLS plus OAuth 2.0 tokens, which protects the channel rather than the individual message.
5. Close with a choice rule: REST for web and mobile clients and public integrations where simplicity and caching matter; SOAP when a partner or legacy enterprise system already mandates a WSDL contract or message-level security.

Follow-up

• Why is PUT idempotent but POST is not, and how would you make a POST safe to retry?
• If you had to call a legacy SOAP service from a REST API, where would you put the translation and how would you map SOAP Faults to HTTP status codes?
• Is GraphQL or gRPC closer to REST or to SOAP, and why?

What are the key principles of object-oriented programming?

Medium · Technical / Domain Questions

Approach

1. Name the four principles and give one line each: encapsulation (state is private and changed only through methods that keep invariants), abstraction (callers depend on what an object does, not how), inheritance (a subtype reuses and extends a supertype), polymorphism (one call resolves to different behaviour depending on the runtime type).
2. Ground each in one small example, such as a Patient class whose date of birth can only be set through a validating method, and a Notifier interface with EmailNotifier and SmsNotifier implementations called through the same send method.
3. Separate the two kinds of polymorphism in Java: overriding is resolved at runtime by dynamic dispatch, overloading is resolved at compile time from the argument types.
4. Show judgement, not just definitions: prefer composition over deep inheritance trees, and respect the Liskov substitution principle (a subtype must work anywhere its supertype does; the Square-extends-Rectangle example breaks it).
5. If time allows, connect to SOLID, especially dependency inversion: depending on interfaces is what makes classes testable with mocks.

Follow-up

• When would you choose an abstract class over an interface in Java, given that interfaces can have default methods since Java 8?
• Give an example where inheritance caused you a maintenance problem and how composition would have avoided it.
• How does Python achieve encapsulation without private keywords?

Describe a challenging technical problem you solved in a previous project.

Medium · Technical / Domain Questions

Approach

1. Choose a problem with a measurable symptom (a slow query, a memory leak, a race condition, a failing integration) and one you personally drove, then state the context and the constraint that made it hard in two or three sentences.
2. Spend most of the answer on the diagnosis: the hypotheses you formed, the evidence you gathered for each (profiler output, query plan, logs, a reproduction), and why you ruled each one in or out.
3. Explain the fix and the trade-off you accepted, for example adding an index that slowed writes slightly, or a cache that introduced staleness, and how you checked it was safe.
4. Give the result in numbers (latency before and after, error rate, hours saved) and how you verified it in production.
5. Keep it in first person singular; credit teammates by name for their parts, but make clear which decisions were yours. A story with no technical detail, or one where the problem solved itself, sinks the answer.

Follow-up

• Which alternative solution did you reject, and why?
• How did you confirm the fix addressed the root cause rather than the symptom?
• What would you build or monitor now so the same problem is caught earlier?

How do you ensure code quality and maintainability?

Medium · Technical / Domain Questions

Approach

1. Organise the answer by stage: before code is written (clear requirements and small, well-scoped tickets), while writing (readable names, small functions, consistent style enforced by a formatter and linter), and after (review, tests, CI).
2. Describe testing concretely: many fast unit tests, fewer integration tests against a real database or service, a handful of end-to-end tests; treat coverage as a signal for untested paths, not a target to hit.
3. Describe review practice: small pull requests, a checklist covering correctness, error handling, security and readability, and automated checks (static analysis, dependency scanning) so humans review design rather than formatting.
4. Cover maintainability over time: refactor when touching code, record design decisions, track technical debt as real backlog items, and keep dependencies current.
5. Give one example from your own work, such as a recurring bug class you removed by adding a lint rule or a test, to show the practice changed an outcome.

Follow-up

• How would you add tests to a legacy module that has none and is risky to change?
• A reviewer and you disagree on a design choice in a pull request; how do you settle it?
• Which metric would tell you code quality is getting worse on a team?

What software development methodologies are you familiar with?

Medium · Technical / Domain Questions

Approach

1. Describe Scrum precisely: fixed-length sprints, a product backlog owned by the Product Owner, a Scrum Master, and the events (sprint planning, daily scrum, sprint review, retrospective) with a potentially releasable increment each sprint.
2. Contrast Kanban: continuous flow with no sprints, explicit work-in-progress limits per column, and flow metrics such as cycle time and lead time; it suits support and maintenance work with unpredictable arrivals.
3. Place Waterfall honestly: sequential phases with sign-off between them, workable when requirements are fixed and change is expensive, weak when feedback arrives late.
4. Mention engineering practices that make any of these work: continuous integration, test-driven development, pair programming from Extreme Programming, and a clear definition of done.
5. Tie it to your experience: which method your teams used, one thing you changed in a retrospective, and the result; candidates report that the requirements listed for this role include Agile and Scrum.

Follow-up

• A story will not fit in one sprint; what do you do with it?
• When would you recommend Kanban over Scrum for a team?
• How do you keep estimates useful without treating story points as a performance measure?

Design a high-level architecture for a healthcare application that tracks patient data.

Medium · System Design / Architecture

Approach

1. Fix scope first: who uses it (clinicians, patients, administrators), the core operations (register a patient, record encounters, vitals, medications and notes, view a patient's history), and the non-functional needs: strict access control, an audit trail, high availability for reads, and no data loss.
2. Outline the data model: Patient, Provider, Encounter, Observation (vitals and lab values with units and timestamps), Medication and Allergy; store it in a relational database such as PostgreSQL for transactions and referential integrity, with an index on patient_id plus time for chart reads.
3. Outline the components: web and mobile clients, an API gateway handling authentication and rate limits, application services behind it, the primary database with a replica for reads, object storage for scans and documents, and an append-only audit log of every read and write.
4. Handle concurrent edits with optimistic locking (a version column checked on update) so two clinicians cannot silently overwrite each other, and keep history by writing amendments rather than updating clinical records in place.
5. Separate analytics from the clinical path: publish change events to a queue and load a de-identified copy into a warehouse, so reporting queries never slow down chart reads.

Follow-up

• How would you expose this data to other healthcare systems, for example through an HL7 FHIR API?
• What happens to the application if the primary database fails, and what recovery point and recovery time would you target?
• How would you let a patient see only their own records while a care team sees all of their patients?

How would you ensure the security of sensitive health information in your applications?

Medium · System Design / Architecture

Approach

1. Start by classifying the data: which fields are protected health information, where they are stored, which services touch them, and who needs access; the goal is to apply the minimum-necessary rule and keep PHI out of systems that do not need it.
2. Access control: strong authentication with MFA for staff, role-based or attribute-based authorization enforced on the server for every request, least-privilege service accounts, and a reviewed break-glass path for emergencies that is logged and audited.
3. Encryption: TLS for all traffic in transit, encryption at rest (for example AES-256) with keys held in a managed KMS or HSM and rotated, and field-level encryption or tokenisation for the most sensitive identifiers.
4. Application security: bind parameters for every query, input validation and output encoding, dependency and secret scanning in CI, secrets in a vault rather than config files, and logs scrubbed so PHI never lands in log lines or error messages.
5. Detection and response: an immutable audit log of who viewed or changed each record, alerts on unusual access patterns, tested backups, and an incident response plan; for US health data, map these controls to the HIPAA Security Rule's administrative, physical and technical safeguards.

Follow-up

• How do you stop PHI from leaking into application logs, analytics events or error-tracking tools?
• How would you give a data science team useful data without exposing patient identities?
• An engineer needs production data to debug an issue; what process do you allow?

What considerations would you take into account when designing APIs for third-party integrations?

Medium · System Design / Architecture

Approach

1. Authentication and authorization: OAuth 2.0 client credentials for server-to-server partners, scoped tokens so each partner gets only the resources it needs, per-client keys that can be revoked individually, and TLS everywhere.
2. Contract and versioning: publish an OpenAPI description, version the API (a /v1 path or a version header), make only additive changes within a version, and give a deprecation window for breaking ones, which can be signalled with the Sunset header.
3. Reliability for callers: idempotency keys on POST so retries after a timeout do not create duplicates, cursor-based pagination for large collections, and rate limits that return 429 with a Retry-After header.
4. Errors: one consistent error body (the problem-details format in RFC 9457 is a standard choice) with machine-readable codes, correct status codes (400 vs 401 vs 403 vs 404 vs 409), and request IDs that partners can quote to support.
5. Events and operations: webhooks signed with an HMAC so partners can verify the sender, retried with exponential backoff, plus a sandbox environment, per-partner usage metrics and audit logs of what each partner accessed.

Follow-up

• How do you make webhook delivery reliable when a partner's endpoint is down?
• You need to rename a field that partners already use; how do you roll it out?
• How would you detect and handle a partner whose integration is misbehaving and flooding the API?

A user reports a bug in a critical application. How would you diagnose and resolve the issue?

Medium · Problem-Solving / Case Studies

Approach

1. Gather facts before touching code: exact steps, the user's account, time, device or browser, app version, the error shown, and whether it affects one user, a segment or everyone; that scope sets the urgency.
2. Correlate with evidence: search logs and traces by request ID or user ID around the reported time, check error-rate and latency dashboards, and list recent deployments, config changes and dependency incidents.
3. Mitigate first if impact is wide: roll back a correlated deploy, disable the feature flag, or apply a workaround, and tell the user and support what is happening; the root cause can follow once users are unblocked.
4. Reproduce in a non-production environment with matching data and version, narrow the cause (git bisect between a good and a bad release, or adding targeted logging), then write a failing test that captures the bug.
5. Fix, get it reviewed, deploy, confirm with the original user and the metrics, repair any bad data the bug wrote, and write a short blameless postmortem with the monitoring or test that would have caught it earlier.

Follow-up

• You cannot reproduce the bug locally; what do you try next?
• The bug corrupted some records before you fixed it; how do you find and repair them?
• How do you decide between a quick hotfix and a proper fix that takes longer?

You have a tight deadline for a project. How do you prioritize tasks to ensure timely delivery?

Medium · Problem-Solving / Case Studies

Approach

1. Clarify what is fixed: the deadline's reason, what must ship for the deadline to count as met, and which parts are negotiable; write the must-haves down and get the stakeholder to agree to them.
2. Break the work into tasks, map dependencies, and find the critical path; start the riskiest and most blocking items first so surprises surface early.
3. Rank the rest with a simple scheme such as MoSCoW (must, should, could, won't) or value against effort, and cut scope before cutting quality; tests on the critical path stay.
4. Protect execution: limit work in progress, remove blockers daily, parallelise independent tasks across the team, and decline new requests unless something of equal size comes out.
5. Communicate early and with options: if the date is at risk, bring the trade-off (drop a feature, add help, or move the date) rather than a surprise, and use a real example of a deadline you met or renegotiated.

Follow-up

• The stakeholder insists every item is a must-have; what do you do?
• Halfway through you realise the deadline cannot be met; who do you tell and what do you bring them?
• What shortcut would you refuse to take even under deadline pressure, and why?

Read latency spikes on a sixty-second sawtooth

Medium · cache stampede · single-flight · ttl

The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.

Approach

1. Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
2. Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
3. Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
4. De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.

Follow-up

• The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
• How does your answer change if the recompute takes 4 seconds instead of 250 ms?

Suggested practice checklist

The plan follows the reported loop: technical fundamentals for the phone screen, whiteboard coding and patient-data design for the in-person interview, then project and leadership stories for the director meetings and panel. Each day ends with something you can produce and review.

Day 1 — Map the loop and your stack

• Write the five reported rounds in order and, beside each, the evidence you will bring: a project, a technical explanation or a story.
• List the languages and tools in the role requirements (Java, Python, JavaScript, React, Angular, SQL, NoSQL, Agile, Scrum), mark the ones you can discuss from real work, and pick one language for whiteboard coding.

Deliverable: A one-page loop map, plus a stack checklist with one chosen coding language and the weakest area circled.

Day 2 — Technical fundamentals aloud

• Write and rehearse a spoken answer for REST versus SOAP covering contract, message format, error handling and when to choose each.
• Write one example per object-oriented principle in your main language, and rehearse them aloud without notes.
• Practise the SDLC and methodologies question by describing how Agile or Scrum worked on one real team.

Deliverable: A one-page cheat sheet comparing REST and SOAP, a set of four principle examples, and a recorded spoken answer for each of the three questions.

Day 3 — Whiteboard coding

• Hand-write iterative and recursive linked-list reversal, dry-running each on empty, one-node and multi-node inputs.
• Write binary search and a linear search, state their time complexity, and note the sorted-input requirement.
• Solve two stack or queue problems by hand, such as bracket matching and a queue built from two stacks, narrating while you write.

Deliverable: Handwritten solutions with complexity notes for reversal, search and two stack or queue problems, each dry-run on edge cases.

Day 4 — Patient-data design and security

• Sketch a patient-data application from clients to database, including identity, access roles, an audit log and a separate read path for reporting.
• Write a security checklist for sensitive health information: encryption in transit and at rest, least privilege, audit trails, secrets storage and data retention.
• Outline an API for a third-party integration: authentication, versioning, rate limits, idempotent writes and error responses.

Deliverable: One annotated architecture diagram, a one-page security checklist and an API contract outline with error cases.

Day 5 — Databases, debugging and delivery

• Write your approach to prioritising work under a deadline: scope cut, risk first, communication, and what you would defer.

Deliverable: Worked SQL solutions, a written diagnosis sequence for the debugging exercise and a one-paragraph prioritisation method.

Day 6 — Stories for directors and the panel

• Outline a story for the challenging technical problem and a project walk-through from requirements to deployment, including the trade-offs you made.
• Write one story each for collaboration, team conflict and adapting to change, structured as situation, your action, result and what you would change.
• Write your answer on code quality and maintainability, with the review, testing and refactoring practices you actually use.

Deliverable: Five written story outlines and a code-quality answer, each naming your own role and a checkable result.

Day 7 — Full mock loop

• Run a mock in loop order: a short background intro, a spoken technical round, a whiteboard design and a coding problem, then a panel-style Q&A.
• Review the recording or notes and mark every place you said 'we' without naming your own role, skipped a complexity statement, or omitted security from the design.
• Write your questions for the interviewers and fix the three weakest answers.

Deliverable: A scored mock-session review, the fixed answers and a final list of interviewer questions.

Collaboration, conflict and change stories

Candidates report that the director meetings and the panel with the VP and hiring manager cover technical expertise and leadership alongside the technical content, and the reported behavioral questions ask about collaboration, conflict and change. For a software engineer, strong answers name your own role, the decision you made, and a result you can check, using projects where you worked with product managers, designers and other engineers.

1. Describe a challenging technical problem you solved in a previous project.
2. You have a tight deadline for a project. How do you prioritize tasks to ensure timely delivery?
3. Tell me about a project you led, even informally, and how you handled feedback or mentored a teammate.

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

Medium · Behavioral / Leadership

Approach

1. Choose a goal with a clear deliverable and several contributors, such as a release delivered by developers, a tester, a designer and a product manager. Describe the goal and the people involved in two sentences, then move on.
2. Spend most of the answer on your own role. Say what you owned, which decisions were yours, and what you did that nobody had assigned, such as writing the interface agreement between two components, unblocking a colleague or reviewing a risky change.
3. Show how the work stayed coordinated: a shared API contract, small pull requests, regular check-ins, a written decision log, or the Agile ceremonies your team used. Concrete mechanisms are more convincing than saying communication was good.
4. Close with a result you can check, such as the feature shipping, a defect rate or a shorter cycle, and one thing you would run differently. The mistake that sinks this answer is saying 'we' throughout, which leaves your own contribution unclear when the question asks what your role was.

Follow-up

• What did you do when a teammate's piece was late or blocked?
• How did you handle a colleague in design or product whose priorities differed from yours?
• Which part of the outcome would have been worse without you?

How do you handle conflicts within a team setting?

Medium · Behavioral / Leadership

Approach

1. Pick a real disagreement about substance, such as an architecture choice, scope, or feedback on a code review, not a personality clash. Avoid a story where the other person was simply wrong and you were simply right.
2. State both positions fairly in a sentence each, then say what you did first: you talked with the person directly, asked what constraint they were optimising for, and checked that you understood their reasoning before arguing yours.
3. Show how it was resolved with evidence: a small prototype, a measurement, a written comparison of trade-offs, or an agreed decision-maker such as the tech lead. If you escalated, say why direct discussion had run its course.
4. Finish with the outcome for both the project and the relationship, including that you committed to the decision even if it went against you. Stories where you went around someone, or claims that you never have conflicts, are the usual failures.

Follow-up

• What if the other person still disagreed after seeing the evidence?
• When would you bring a manager in, and what would you ask of them?
• How would your approach change if the conflict were with a product manager about scope?

Provide an example of a time when you had to adapt to a significant change in a project.

Medium · Behavioral / Leadership

Approach

1. Choose a change with real consequences, such as requirements altered mid-sprint, a third-party service replaced, a shift in priorities, a teammate leaving, or a technology migration. A minor reshuffle gives you nothing to show.
2. Describe your first steps: how you learned of the change, how you assessed what was already built and what could be kept, and how you estimated the effect on the plan. Say what you re-sliced, cut or put behind a feature flag.
3. Show that you communicated early with stakeholders, giving options and trade-offs, not only the bad news. State what you pushed back on, if anything, and why.
4. End with the result and a lasting change in how you work, such as smaller increments or earlier check-ins with stakeholders. Do not present adapting as simply working longer hours, which shows no judgement.

Follow-up

• How did you decide which work to drop or defer?
• Did you push back on the change, and what did you base that on?
• How did you handle the effort already spent that the change made redundant?