Interview prep

In one line

Nobody hires you for knowing what FHIR stands for. They hire you because they believe you'll make good decisions on the days the data is wrong — and the interview is a crude instrument for finding that out.

What they're actually testing

Behind almost every question in a health-informatics interview sits one of three real ones:

1. Do you understand that this data describes people? Not rows. People, with consequences.
2. What do you do when you don't know? Because you frequently won't.
3. Can you explain something technical to someone who isn't? Half this job is talking to clinicians and administrators.

Candidates over-prepare for recall and under-prepare for these. Recall is the part an interviewer trusts least anyway — they know you could look it up, and so could they.

The questions that actually get asked

"Walk me through what happens when a lab result arrives." They want the whole chain — the ORU message, the mapping, what the EHR does, who sees it, what happens if it's critical. This question is a map of how much of the system you actually hold in your head.

"You've mapped this field and the values don't fit. What do you do?" The right answer is never "force it." It's: understand what the source means, check whether the loss is acceptable, document the equivalence honestly, and tell someone. They're testing whether you'll quietly launder bad data to hit a deadline.

"This number looks wrong. How would you check?" They want to see you reach for the denominator, the time window, the definition — not the chart library.

"Why is interoperability still hard?" A bad answer blames vendors. A good one knows that valid FHIR is not interoperability, that meaning is what gets lost, and that incentives — not formats — are the durable obstacle.

"Tell me about something you got wrong." Not a trick. They're checking whether you notice being wrong, which is a prerequisite for being trusted with anything that matters.

The answer that beats a confident wrong one

Say this, out loud, when it's true:

"I don't know. Here's how I'd find out."

In most fields that's a small hit. In health informatics it's a hiring signal, because the alternative is a person who confabulates a plausible answer about medication data. Your interviewer has met that person. They may still be cleaning up after them.

Then actually answer the second half — name the spec you'd read, the person you'd ask, the query you'd run to check. That's the sentence that gets you hired: not knowing everything, but demonstrably knowing how to close a gap.

Preparing usefully

• Know your own portfolio cold. Every decision in it is a question you've invited. If you can't defend a choice, take it out.
• Have three stories ready: something you built, something you broke, something you disagreed with someone about. Most behavioural questions are one of these three wearing a costume.
• Learn the basics properly, not broadly. HL7 v2 message structure, FHIR resources and references, the difference between a classification and a terminology. Depth in a few things reads as competence; a thin layer over everything reads as a memorised list.
• Have a question for them. "What's your worst integration?" tells you more about the job than anything on the job description — and signals you've done this before.

For candidates in India

Two things worth naming, since they shape a lot of these interviews:

Your clinical or RCM background is an advantage, not a detour. If you've coded claims or nursed patients, you already know why billing data lies and what a real workflow looks like — the exact things engineers learn slowly and painfully. Lead with it. Don't apologise for not having a CS degree.

Know the ABDM story. For any India-facing role, being able to speak clearly about consent artefacts, HIP/HIU, and the M1–M3 milestones puts you ahead of most candidates immediately — because most of them have read the press release and stopped.