Senior Full-Stack Cloud Engineer (Healthcare AI): Complete Interview Question & Answer Guide

These aren't just questions to ask. They're a framework for evaluating whether you actually want to work there — and signals to the interviewer that you've built real healthcare AI systems, not just read about them.

For every question: why you're asking it, what a strong company answer looks like, what a red flag sounds like, and what you can contribute from your own experience.

SECTION 1: Technical Architecture

Q1: "How is patient data isolated between tenants — row-level security, separate schemas, or separate databases? And how is that enforced at the API layer?"

Why you're asking this

Multi-tenancy in healthcare is not a product feature — it's a compliance requirement. Data from Hospital A must be architecturally incapable of leaking into Hospital B's queries. "Enforced at the API layer" is the key phrase — if isolation only exists in application code with no database-level enforcement, a single bug in query construction exposes all tenants.

What a strong answer looks like

"We use row-level security at the database level with a clinic_id column on every patient-bearing table. PostgreSQL RLS policies reject queries that don't include the current tenant context. The API layer sets the tenant context from the authenticated JWT on every request, and integration tests verify that a token from Tenant A cannot retrieve Tenant B's data even with a direct SQL injection attempt."

This answer tells you: they thought about defence in depth, they test the isolation, and the database is the last line of defence rather than trusting the application layer alone.

Red flags

• "We filter by clinic_id in our queries" — that's application-level only. One missing WHERE clause exposes everything.
• "We haven't needed multi-tenancy yet, it's all one clinic" — fine for an early startup, but you need to understand when they plan to add it and whether the data model will support it without a rewrite.
• Defensive or vague: "It's all handled in the middleware" — ask them to be specific. If they can't explain it clearly, it may not be implemented clearly.

What you can contribute

"In systems I've built, I've used PostgreSQL row-level security with SET app.current_clinic_id = $1 on session open, combined with a middleware guard that verifies the JWT tenant claim before any query runs. The key thing I found was that you also need to enforce isolation on blob storage — S3 bucket key prefixes and IAM policies per tenant, not just database filtering. Otherwise a patient's uploaded files are accessible cross-tenant even if the DB queries are clean."

Q2: "What's the current approach to PHI handling in the AI pipeline? Does patient data leave the cloud boundary to reach the LLM, or are you running models locally?"

Why you're asking this

This is the architectural fork that determines everything else. If they send PHI to OpenAI or Anthropic APIs, they need a Business Associate Agreement (BAA) with that provider, HIPAA-compliant API terms, and a data processing agreement under GDPR. If they run locally, they need GPU infrastructure, model management, and accept lower capability models. Many teams haven't fully resolved this tension.

What a strong answer looks like

"We have a BAA with our cloud AI provider and the data is processed in a HIPAA-compliant API tier. Before sending, we run a de-identification step that replaces names, dates of birth, addresses, and MRNs with tokens — the LLM never sees raw identifiers, only anonymised clinical text. On the output side, we reverse the token mapping before the note reaches the clinician."

Or alternatively:

"We run all inference locally inside our VPC. No patient data leaves our cloud boundary. We use quantised Llama models on GPU instances. The tradeoff is quality — we've found the models need more post-processing to reach the output quality of GPT-4, but the compliance posture is cleaner."

Either answer is strong if it's deliberate and documented.

Red flags

• "We're looking into it" — for a production healthcare AI system, PHI handling should not be on the roadmap, it should be solved.
• "We send the data to the API but we trust the provider's privacy policy" — a privacy policy is not a BAA. This is a compliance gap.
• "The doctors anonymise it before giving it to us" — shifting compliance responsibility to end users is not an architecture.

What you can contribute

"When I built a clinical documentation system, we ran local Whisper for transcription since audio is the most sensitive — raw voice recordings of consultations. The LLM structuring used a hosted API with a BAA in place, but we applied an anonymisation pass first: names became [PATIENT], dates became relative offsets, MRNs were stripped. The key decision was that we never sent raw audio to any external API. The tradeoff is that local Whisper on CPU is slower, but that was the right call for the compliance posture."

Q3: "When an AI-generated clinical output is wrong — a bad ICD-10 code, a hallucinated medication — what's the correction and audit trail flow today?"

Why you're asking this

Every clinical AI system produces wrong output. The question isn't whether it happens — it's whether the system was designed knowing it would happen. An immature system treats corrections as bugs to be fixed. A mature system treats them as expected events with a defined workflow, a correction mechanism, and a way to feed corrections back into model improvement.

What a strong answer looks like

"When a doctor corrects an AI suggestion, the correction is stored alongside the original AI output — we don't overwrite, we version. The audit log records: what AI suggested, what the doctor changed it to, who made the change, and when. We use this correction data to build an evaluation dataset. Quarterly, we run the current model against that dataset and compare accuracy. If accuracy has drifted, we retrain or adjust the prompts."

Red flags

• "The doctor just edits it and saves" — if there's no trace of what AI originally suggested, you can't measure model quality, you can't detect patterns of failure, and you can't demonstrate to regulators that errors were caught.
• "We haven't had many errors" — this is either untrue or they're not measuring. All AI systems make errors; "not many" usually means "not tracked."
• No mention of feeding corrections back to evaluation — one-time corrections that don't improve the system are a missed learning loop.

What you can contribute

"In the system I built, we stored the original LLM output as raw_llm_output on the clinical note record, and any doctor edit was a separate field with a overridden_by and overridden_at timestamp. We also had a source fidelity score — checking how much of the AI output came from the transcript vs. appeared to be generated — and we tracked that score over time. When the score trended down, it was a signal that either the prompt had drifted or the model had. The correction flow was the primary quality signal."

Q4: "What's the current observability stack? Can you trace a single patient encounter end-to-end, and see where it failed?"

Why you're asking this

In a distributed healthcare AI system, a consultation that fails might fail at: audio upload, STT transcription, LLM structuring, guardrail check, EPJ write, or notification. Without distributed tracing, debugging a failed encounter means grep-ing through multiple service logs with a timestamp. In a clinical setting, a failed encounter might mean a patient's notes don't get written — that has direct clinical consequences.

What a strong answer looks like

"We use OpenTelemetry with traces propagated across services. Every patient encounter gets a visit_id that's the trace root — you can put that ID into our Grafana/Jaeger UI and see the full span tree: STT duration, LLM call latency, guardrail check result, EPJ write status. We have alerts on STT failure rate and LLM error rate. We also log structured JSON to CloudWatch/Loki so we can query by visit_id across services."

Red flags

• "We have application logs" — logs without correlation IDs or distributed tracing are hard to use in a multi-service system.
• "We use print statements / console.log in development" — for a production healthcare system this is a serious gap.
• Long pause before answering — observability is often the first thing cut in early-stage startups and the first thing that causes pain in production.

What you can contribute

"I've used structlog for structured JSON logging with a visit_id bound to every log event in the context of a request. The key thing I found was you need to log at transition points — when you enter a state (TRANSCRIBING), when you exit it (TRANSCRIBED), and when you fail (FAILED with reason). That gives you a timeline per encounter without needing a full APM stack. For production I'd add OpenTelemetry traces for the LLM calls specifically, since those are where latency and failure concentrate."

Q5: "Is the AI layer built on fine-tuned models, RAG, prompt engineering, or a combination? Where are you unhappy with the current approach?"

Why you're asking this

This question has two parts. The first tells you the technical maturity of the AI layer. The second — "where are you unhappy" — is the more valuable question. A team that can articulate the limitations of their current approach understands it. A team that says "it works great" either hasn't pushed it hard or isn't being honest.

What a strong answer looks like

"We use RAG over patient history for context-aware Q&A — we retrieve the last 10 visit notes and inject them as context. For structuring, we use prompt engineering on a hosted foundation model with a fine-tuning experiment running in parallel to see if we can do better. Where we're unhappy: RAG retrieval is keyword-based right now, so semantic queries like 'when did this patient last have a cardiac event' miss notes that don't use those exact words. We're evaluating pgvector for semantic search."

Red flags

• "Just prompt engineering, and it works well" — for a healthcare AI platform this suggests they haven't hit the hard problems yet.
• Can't articulate limitations — either the system isn't in meaningful production use, or there's no engineering culture of honest evaluation.
• "We fine-tuned our own model" without explaining the evaluation dataset — fine-tuning without a validation dataset can make models worse in ways that are hard to detect.

What you can contribute

"I've found RAG to be the right architecture for patient-specific Q&A precisely because it prevents the model from drawing on training data statistics — you want it to say 'not in the notes' rather than 'patients like this usually take metformin.' The limitation I hit was retrieval: simple keyword search missed semantically similar content. The upgrade path is vector embeddings with pgvector, where you embed each note section and the query, then retrieve by cosine similarity. The tradeoff is embedding compute on ingestion and index maintenance."

SECTION 2: Healthcare Domain

Q6: "Which compliance frameworks are you actively certified or working toward — HIPAA, GDPR, ISO 27001, SOC 2?"

Why you're asking this

Compliance isn't a checkbox — it's an operating constraint that shapes architecture. If they're HIPAA-certified, they have documented data flows, BAAs with every vendor, and penetration testing records. If they say "we plan to get HIPAA" but have been live with patient data for a year, that's a legal exposure. Understanding where they are on this journey tells you what technical debt exists and what compliance work you'd be inheriting.

What a strong answer looks like

"We're GDPR-compliant for our EU operations with a DPA in place with all sub-processors. We're in the process of SOC 2 Type II — we have the Type I report and we're in the observation period. HIPAA applies to our US clients and we have BAAs with all data processors. ISO 27001 is on the two-year roadmap."

Clear, specific, and honest about what's complete vs. in progress.

Red flags

• "We follow HIPAA guidelines" — following guidelines is not the same as having documented compliance, BAAs, and audit records.
• "Our lawyer handles that" — engineers at a healthcare AI company need to understand what compliance means for their architecture. If the engineering team is entirely disconnected from compliance, technical decisions are being made without compliance context.
• "We haven't needed it yet because our clients haven't asked" — wait until one does. The scramble to retroactively comply is extremely expensive.

What you can add

"I've worked in environments where GDPR and healthcare data regulations shaped the architecture — specifically data minimisation principles (don't store what you don't need), right-to-erasure flows in the database, and data residency requirements that meant certain patient data couldn't leave the EU region. I'm interested in how those constraints are reflected in your current architecture and whether there are areas where the technical implementation hasn't caught up with the compliance posture."

Q7: "How are clinicians involved in AI output validation? Is there a human-in-the-loop mechanism before AI suggestions reach the clinical record?"

Why you're asking this

This is the single most important safety question. Autonomous AI writing to clinical records without clinician review is a clinical liability, a regulatory risk, and a patient safety issue. The answer tells you whether the product was designed by people who understand clinical risk or by people who saw an AI demo and shipped it.

What a strong answer looks like

"Nothing the AI generates reaches the clinical record without a clinician seeing it and explicitly approving it. The workflow is: AI generates a structured note and suggestions, these appear in a review UI, the clinician edits/approves each section, and only after their explicit approval does anything write to the EPJ. We have a clinical advisory board that reviews our AI output quality quarterly and has the authority to pause AI features if they see systematic issues."

Red flags

• "AI writes the notes and doctors can edit if they want" — this is passive opt-out rather than active approval. Research consistently shows that clinicians don't review pre-filled fields as carefully as they review suggestions.
• "We're working toward a fully autonomous pipeline to reduce clinician burden" — reducing burden is legitimate, but fully autonomous clinical documentation without human oversight is a patient safety issue, not a product improvement.
• No clinical advisors involved — an AI healthcare product with no clinicians in the feedback loop is building without the most important domain experts.

What you can contribute

"The system I built enforced human-in-the-loop at the architecture level, not just the UI level. The workflow engine had a REVIEW state that was mandatory between STRUCTURED and APPROVED — you couldn't skip it via API call. Agent actions generated a PREVIEW status first, and execute() checked for APPROVED status before running. I deliberately made approval an architectural requirement rather than a UI suggestion, because UI suggestions get bypassed. I'd want to understand how this system enforces the same principle."

Q8: "What EHR/EPJ systems are you integrated with today — direct FHIR API, vendor adapters, or middleware?"

Why you're asking this

EHR integration is notoriously difficult. Epic, Cerner, Cambio, and DIPS all have different APIs, different FHIR implementation levels, and different data models for the same clinical concepts. Integration work often consumes more engineering time than the AI itself. Understanding the current integration landscape tells you what infrastructure exists and what pain is coming.

What a strong answer looks like

"We have a production integration with Epic via their FHIR R4 API for patient demographics and note writing. We're building a Cerner integration using their Millennium APIs — that one uses a legacy HL7 v2 feed for some data and FHIR for others. We abstracted both behind a ClinicalRecordAdapter interface so the core AI pipeline doesn't know which EHR it's talking to. The adapter handles the translation. Biggest pain point: Epic's FHIR sandbox behaves differently from their production environment, which means integration tests pass but production sometimes breaks."

Red flags

• "We use an iPaaS middleware and don't need to understand the underlying protocols" — fine for simple data routing, but when you need to debug a failed write at 2am, "the middleware handles it" is not enough.
• "We're building direct integrations" without mentioning abstraction layers — without an adapter pattern, every EHR integration becomes custom code throughout the codebase.
• "We're starting with Epic" (for a Latin American company) — DIPS is the dominant EPJ in Norway, Cambio in Sweden, and regional EHRs vary significantly. If the company targets healthcare in Colombia/LATAM, ask specifically about local EPJ systems.

What you can add

"I've worked with FHIR R4 for patient and clinical resource modelling. The complexity I found wasn't the FHIR spec itself — it was that every EHR vendor implements it differently. Epic has extensions, HL7 v2 segments appear in unexpected places, and the FHIR profiles for a Condition resource look different between vendors. The right architecture is an anti-corruption layer — your domain model uses clean FHIR concepts, and adapters translate between your model and the vendor-specific implementation."

Q9: "How do you handle the 'AI refuses to make a diagnosis' problem?"

Why you're asking this

Foundation models are trained with safety guardrails that cause them to hedge in clinical contexts: "I'm not a doctor," "please consult a medical professional," "I cannot make a diagnosis." These are appropriate for consumer products and inappropriate in a clinical tool where a licensed physician is the user. If the team hasn't solved this, their AI output will be full of disclaimers that clinicians will start ignoring — which is worse than no AI.

What a strong answer looks like

"We address this through system prompt engineering combined with context framing. The system prompt establishes that the model is assisting a licensed physician in a clinical documentation context, not advising a member of the public. We explicitly instruct the model to use clinical language without disclaimers. In the post-processing layer, we strip any sentences containing self-referential AI language before the output reaches the clinician. We also evaluate outputs against a set of known hedge phrases and flag them in our quality pipeline."

Red flags

• "We just tell it not to do that in the prompt" — partial answer. Models don't always comply, so you need a catch layer.
• "We haven't hit this problem" — they haven't pushed the system hard enough or haven't looked.
• No post-processing layer — if the raw LLM output goes directly to clinicians, hedging language will appear.

What you can contribute

"This was a concrete failure mode I had to design around. The fix was two-layer: the system prompt establishes the clinical context and instructs the model to write in the third person ('the patient reports') rather than first person ('I cannot determine'), and a post-processing step removes any sentence containing markers like 'as an AI,' 'I cannot,' 'please note,' 'this is not medical advice.' These seem obvious once you've seen them in output, but they appeared frequently with smaller local models before the post-processing layer was added."

SECTION 3: Engineering Team and Process

Q10: "What does a typical deployment cycle look like — how often are you shipping, and what's the rollback story for a bad AI model update?"

Why you're asking this

AI model updates are different from code deployments. A bad code deployment is caught by tests. A bad model update might produce output that passes all existing tests but degrades clinical quality in subtle ways that only clinicians notice over days of use. The rollback story tells you whether they've thought about model versioning, canary deployments, and quality regression detection.

What a strong answer looks like

"We deploy code to production multiple times a week via CI/CD with automated tests as the gate. AI model updates go through a separate process: we evaluate the new model against our clinical evaluation dataset (ground truth notes reviewed by our clinical advisory board), and it has to score equal or better than the current model before promotion. We use model version flags so we can serve different model versions to different cohorts and compare live quality metrics before full rollout. Rollback is a config change that points back to the previous model version — no redeploy needed."

Red flags

• "We deploy when it's ready" — no cadence means no discipline. Ask what "ready" means.
• "We test with unit tests and integration tests" — necessary but not sufficient for AI model quality. Deterministic tests don't catch LLM quality regression.
• "Rolling back means reverting the code" — if the model version is baked into the code deployment rather than configurable, rollback is slow and risky.

What you can add

"The evaluation dataset question is critical for me. In a system I worked with, we built a quality evaluator that scored each output on completeness, source fidelity, and consistency. We tracked those scores over time using a sliding window comparison — first half of recent results vs. second half — to detect quality drift. A model update that passed unit tests but degraded source fidelity by 15% would be caught before clinical deployment. I'd want to understand how evaluation is gated here."

Q11: "What's the test strategy for AI outputs — evaluation datasets, LLM-as-judge, or manual QA?"

Why you're asking this

Testing AI outputs requires different techniques from testing deterministic code. Unit tests can verify JSON structure. They cannot verify clinical accuracy. This question reveals the engineering maturity of the AI quality process.

What a strong answer looks like

"Three layers: automated structural tests (does it return valid JSON with all required fields), an evaluation dataset of 200 annotated consultation transcripts with gold-standard notes reviewed by our clinical advisors (we run the model against these with every release), and LLM-as-judge for subjective quality where we use a separate model to rate factual accuracy and clinical completeness. Manual QA from our clinical team is the final gate for any major model change."

Red flags

• "We trust the model" — not a test strategy.
• "We have unit tests" — unit tests test code, not model output quality.
• No evaluation dataset — this is the most common gap in healthcare AI systems. Without ground truth data, you cannot measure whether your AI is getting better or worse.

What you can add

"I've implemented automated evaluation with a weighted score: completeness (sections filled), source fidelity (key terms from transcript appearing in the note), and structural consistency (no raw JSON fragments, no repetition). LLM-as-judge is powerful for catching nuanced issues — you can ask a second model 'does this note accurately reflect the transcript?' and get a score. The limitation is cost and latency, so I used it as a spot-check on a sample rather than every output. I'm interested in how you've balanced coverage vs. cost in your evaluation pipeline."

Q12: "What's the biggest current technical debt I'd be walking into?"

Why you're asking this

Every system has technical debt. The question isn't whether it exists — it's whether the team is honest about it. An interviewer who says "we don't really have significant debt" is either not being honest or hasn't looked. The answer tells you what your first 6 months of work will actually involve vs. what the job description says.

What a strong answer looks like

"Our most significant debt is in the integration layer — we have three EHR integrations that were each built independently, so there's a lot of duplicated logic. We're partway through abstracting that into a shared adapter pattern but it's not done. The AI evaluation pipeline is also manual right now — a data scientist reviews sample outputs weekly, but we haven't automated the evaluation run on every deployment. Those are the two things that will bite us as we scale."

This answer is honest, specific, and shows the team has already identified and is working on the problems.

Red flags

• "Nothing significant" — either not true, or the team has low engineering standards and doesn't notice it.
• Vague: "some things could be cleaner" — ask them to be specific. Technical debt you can't describe specifically is technical debt you haven't understood.
• A list so long it takes more than 2 minutes to describe — that's not debt, that's an unmaintained system.

Q13: "Where does the full-stack boundary sit — do I own infrastructure too, or is there a platform/DevOps function?"

Why you're asking this

"Full-stack" in a healthcare AI company can mean: React frontend + Python API. Or it can mean: React + Python + Terraform + Kubernetes + RDS management + S3 lifecycle policies + CloudWatch alerting. The answer determines whether you need to be proficient in cloud infrastructure or whether you can focus on application code. Neither is wrong — but you need to know which it is before you accept.

What a strong answer looks like

"We have a small DevOps function that owns the Terraform modules and cluster management. Application engineers own their service's Dockerfile and can deploy through the CI pipeline without touching infrastructure. For new infrastructure needs — a new S3 bucket, a new RDS read replica — you write a Terraform PR and DevOps reviews it. So you need to be comfortable writing Terraform but you're not on-call for the cluster."

Or:

"We're a small team so full-stack here genuinely means infrastructure too. Every engineer is expected to be on-call for their service and manage their own cloud resources. We use CDK rather than hand-written Terraform."

Both are fine if they're honest.

Red flags

• "Infrastructure is handled, don't worry about it" — and then in week 2 you're debugging an ECS task definition. Ask specifically: who manages the VPCs, the IAM roles, the database backups?

SECTION 4: Questions Referencing Your Real Experience

Q14: "What does your hallucination mitigation look like, and where do you think it's insufficient?"

Your prepared context

You've built a five-layer hallucination defence:

1. Prompt-level: "Extract only from the transcript. Never invent." — fights hallucination at the source but models don't always comply.

2. Self-tagging: Instructing the model to mark uncertainty with [VERIFY] — makes uncertainty machine-readable, surfaced as warnings in the review UI.

3. Source fidelity scoring: Checking whether key terms from the transcript appear in the generated note. Low fidelity triggers a quality warning.

4. Pattern detection: Regex checks for fabricated phone numbers, email addresses, and other data unlikely to come from an audio consultation.

5. Post-processing removal: Stripping sentences containing "as an AI," "I cannot," "please note," "this is not medical advice."

Why no single layer is enough

• Prompt instructions work most of the time but models ignore them under specific conditions (long context, ambiguous input, temperature settings).
• [VERIFY] tags only appear when the model knows it's uncertain — confident-but-wrong hallucinations aren't tagged.
• Source fidelity misses hallucinations where the fabricated content uses words that happened to appear in the transcript.
• Pattern detection only catches structured hallucinations (numbers, emails) — fabricated clinical history doesn't have a detectable pattern.
• Post-processing only catches the specific phrases in the marker list.

None is sufficient alone. All five together still don't guarantee correctness — which is why clinician review remains the final defence.

If they turn it around: "What would you add?"

"The missing layer for me is semantic hallucination detection — a second model pass that reads both the transcript and the structured note and asks: 'does this note contain any clinical claim not supported by the transcript?' That's an LLM-as-judge approach. It's expensive to run on every output, but you could run it on a sample and use the results to calibrate the cheaper automated metrics."

Q15: "Are you using a single prompt strategy across models, or have you had to split them?"

Your prepared context

Small models (1B–3B parameters) and large models (13B+) need fundamentally different prompting strategies:

For small local models:

• Short system prompts (under 200 tokens) — long prompts cause context confusion
• Simple output structure — nested instructions produce inconsistent JSON
• Explicit output examples inline — "return exactly this format: {"key": "value"}"
• Hard truncation of long inputs — a 3,000-word transcript will overwhelm a 1B model
• Different failure modes: they repeat themselves, return nested dicts instead of strings, lose section structure mid-generation

For large hosted models:

• Can handle complex multi-section system prompts
• Understand implicit formatting instructions
• Handle full consultation transcripts
• Require explicit instruction to avoid hedging ("you are assisting a licensed physician")

The concrete failures you've seen from small models:

1. Returning {"chief_complaint": {"main": "headache", "duration": "3 days"}} instead of {"chief_complaint": "Headache for 3 days"} — solved by a _flatten_value() post-processor
2. Repeating phrases 3–4 times in a section — solved by a remove_repetitions() deduplicator
3. Context confusion when transcript exceeded 500 characters — solved by hard truncation
4. Ignoring the "extract only" instruction under high-context conditions — solved by adding the instruction at both the start and end of the prompt (priming + recency bias)

If they ask: "Would you recommend local or hosted for clinical AI?"

"It depends on the compliance posture. If you can establish a BAA with a hosted provider and anonymise inputs before sending, hosted models give significantly better output quality for the same prompt effort. If you need zero data egress — which is often the case in European healthcare with GDPR — local models are the answer but you invest heavily in post-processing to compensate for their limitations. The architecture should abstract the model choice so you can swap between them without rewriting the pipeline."

Q16: "Are those kinds of concurrency concerns already solved, or still a risk area?"

Your prepared context

In the verification service, you used optimistic locking with version numbers to prevent race conditions on clinical approval:

def _assert_version(current: int, expected: int):
    if current != expected:
        raise HTTP 409 Conflict
        # "Version conflict: expected 5, got 6.
        #  Record was modified by another request. Refresh and retry."

async def approve(verification_id, reviewer, expected_version):
    v = await get(verification_id)
    assert_transition(v.status, APPROVED)
    assert_version(v.version, expected_version)
    
    v.status = APPROVED
    v.version += 1  # every write increments version

The UI sends the current version with every approval. If two reviewers click simultaneously, one gets a 409 and is told to refresh.

Why this matters in healthcare specifically

A double-approved clinical record where two reviewers both believe they approved the authoritative version creates:

• Audit trail ambiguity (which approval is canonical?)
• Potential for contradictory clinical assessments both marked approved
• Regulatory exposure if the approval trail cannot be reconstructed unambiguously

This is the same class of problem as the Nordea banking race condition — two concurrent reads followed by two concurrent writes, each believing their write is valid.

Other concurrency risks in clinical AI:

1. Concurrent note structuring — two structuring jobs run for the same visit (retry + original both succeed), producing two competing notes
2. EPJ write races — two threads both attempt to write a note to the EHR simultaneously
3. Approval + edit race — doctor edits note while it's in the middle of being sent to EPJ

If they ask: "How would you detect these in production?"

"Structured logging with a correlation ID (visit_id) on every operation, combined with an alert for duplicate write events on the same entity within a short window. For the note structuring case, a database-level unique constraint on (visit_id, model_run_id) would prevent duplicate records at the persistence layer. For EPJ writes, idempotency keys on the EHR integration request ensure duplicate calls return the same result rather than creating duplicate records."

The Closing Question: "Is there an area you'd want someone stronger in?"

Why this is the most powerful question

Most interviewers have a mental note of gaps they're uncertain about. By asking directly, you:

1. Signal confidence — insecure candidates don't ask this
2. Get actionable feedback you can address in the moment
3. Demonstrate that you evaluate yourself with the same rigor you'd apply to code

How to handle the answer

If they name a gap you have:

"That's actually something I've worked with directly — in [specific project], I [specific example]. Would it be useful to walk through that?"

If they name a gap you don't have:

"That's a fair observation. I haven't had as much depth in [X] as I have in [Y]. What I can say is [adjacent experience], and I'd approach the gap by [specific learning plan]. Is that something the role would need immediately, or is there a ramp period?"

Never pretend a gap doesn't exist. The only wrong answer is defensive.

Summary: What Each Question Signals to the Interviewer

| Question | Signal You're Sending | |---|---| | PHI in the AI pipeline | You understand the compliance-architecture connection | | Hallucination mitigation | You've built real clinical AI, not demo AI | | State machine for approval | You think about failure modes, not happy paths | | EHR integration depth | You know FHIR is not a solved problem | | Evaluation datasets | You know AI quality requires measurement | | Concurrency on approvals | You think about multi-user edge cases | | Technical debt honesty | You'll give honest assessments, not just positive framing | | Closing gap question | You're confident and self-aware |

The questions you ask in an interview communicate your engineering depth as clearly as the answers you give. A candidate who asks "what does success look like in 90 days?" and "what tech stack do you use?" is a different candidate from one who asks "where is your hallucination detection insufficient?" — even if both have identical CVs.