AI Engineer

What matters most

• Independent plug-in architecture

  The engineer owns the runtime and registry, including manifests, scopes, event subscriptions, and per-hospital installation and kill switches. The core HMIS must continue working with every AI feature off.

• Three clinical launch plug-ins

  Deliver discharge-summary drafts for doctor review and signature, structured notes from consultation conversations, and suggested ICD and procedure codes from notes.

• Measured quality and human acceptance

  Build a golden dataset, run regressions on every prompt change, and track acceptance rate and edit distance per hospital. Clinical advisors sign off before enablement; AI output cannot enter clinical or financial records without human acceptance.

• Defensible LLM gateway

  Build model routing, prompt versioning, identifier redaction before data leaves the boundary, and a full audit trail. The role also requires accounting for what patient data is sent, where it is processed, and what is retained.

• Production operation and cost control

  Operate Python AI services, control token use and costs per plug-in and hospital, and report costs monthly. The posting favors simpler prompts and smaller models when sufficient.

Likely challenges to think through

• Isolation without clinical-system dependency

  Likely challenge (inference): shared plug-in infrastructure must support hospital-specific settings without making core workflows depend on AI availability. Prepare to explain failure handling, scope boundaries, and tests for disabled or interrupted plug-ins.

• Useful drafts without automatic record changes

  Likely challenge (inference): the three plug-ins may produce plausible but inaccurate clinical text or codes, while clinicians need suggestions they can efficiently review. Prepare an approach to structured outputs, human acceptance, and measuring edits and acceptance separately for each use case.

• Quality versus data exposure and cost

  Likely challenge (inference): richer context and larger models may improve output but increase patient-data exposure and per-hospital spend. Prepare to discuss redaction and retention decisions, regression comparisons, and when a simpler prompt or smaller model is sufficient.

Topics to prepare

• Plug-in boundaries in a multi-tenant HMIS

  Suggested exercise: diagram how manifests, scopes, event subscriptions, per-hospital installation and kill switches keep the core system working when AI is off. Relevance: the posting makes an independently switchable plug-in layer central to the role.

• Human acceptance in clinical workflows

  Suggested exercise: trace a discharge draft from generation through doctor edit and signature, marking where acceptance is required. Relevance: the posting says AI outputs are suggestions and cannot enter clinical or financial records without human acceptance; clinical advisors sign off before a hospital enables a plug-in.

• Quality measurement and release decisions

  Suggested exercise: explain how a golden dataset, prompt-change regressions, and per-hospital acceptance rate and edit distance would reveal an improvement or regression. Relevance: the posting explicitly prioritizes measured quality and asks for an account of a real-user LLM feature, its quality measurement, and subsequent changes.

• Patient-data boundaries and auditability

  Suggested exercise: map one model request, identifying what patient data is sent, where it is processed, what is retained, where identifiers are redacted, and what is audited. Relevance: these are explicit gateway and patient-data responsibilities.

• LLM patterns and model-selection trade-offs

  Suggested exercise: compare a simple prompt with a more complex approach for one launch plug-in; explain when structured output, RAG, function calling or streaming helps, and how quality and cost affect model choice. Relevance: all are named application patterns, and the posting favors simpler prompts and smaller models when sufficient.

Skills to revise

• Build a Python plug-in runtime

  Suggested exercise: implement a small Python registry that reads a manifest, checks scopes and hospital installation state, handles an event subscription, and stops execution when a hospital kill switch is set. Relevance: the posting calls for this runtime and production Python services.

• Implement a controlled LLM gateway

  Suggested exercise: prototype one request path using Amazon Bedrock, the Anthropic API or the OpenAI API; record model and prompt versions, enforce a token or cost limit, redact identifiers before sending, and audit the request. Relevance: the gateway functions and production experience with one of these providers are explicit.

• Produce reviewable clinical outputs

  Suggested exercise: define and validate a structured draft for one launch plug-in—discharge summary, consultation notes, or suggested ICD and procedure codes—and keep it separate from accepted records. Relevance: these are the three specified plug-ins, and their outputs must remain suggestions.

• Run prompt regressions and report outcomes

  Suggested exercise: create a small golden dataset, run two prompt versions against it, flag changed outputs, and calculate example acceptance-rate and edit-distance results by hospital. Relevance: the posting calls for regressions on every prompt change and per-hospital dashboards.

• Account for usage by plug-in and hospital

  Suggested exercise: aggregate example audited requests into a monthly report of tokens and cost for each plug-in–hospital pair. Relevance: monthly cost control and reporting at that level are explicit responsibilities.

• Document a shipped LLM feature

  Prepare a truthful walkthrough of a feature used by real users: your Python production-service work, Bedrock/Anthropic/OpenAI API use, how you measured quality, and what you changed afterward. These are stated requirements; do not invent experience.

• Sketch the plug-in boundary

  As a design exercise, draw a runtime and registry with manifests, scopes, event subscriptions, and per-hospital installation and kill switches. Show how the core HMIS keeps working when all AI plug-ins are off.

• Trace an audited gateway request

  Prepare a sample request flow showing identifier redaction before data leaves the boundary, model routing, prompt versions, token and cost controls, and a complete audit record. Be ready to discuss what is sent, where it is processed, and what is retained.

• Walk through the three launch plug-ins

  Outline inputs, suggested outputs, and human acceptance for discharge-summary drafts, structured scribe notes, and ICD/procedure-code suggestions. Include doctor review and signature for summaries; treat Indian-accented and code-switched speech experience as preferred, not required.

• Design a quality release exercise

  Propose a golden dataset, regression runs for every prompt change, and per-hospital acceptance-rate and edit-distance views. Explain how clinical-advisor sign-off precedes enabling a plug-in and how suggestions stay out of clinical or financial records until accepted.

• Prepare technical trade-off examples

  Bring concise examples of schema-constrained output, RAG, function calling, streaming, and evaluation. For each proposed use, explain when a simpler prompt or smaller model would suffice; these are interview examples, not claimed implementation choices.

• Model tenant-level operations and costs

  Sketch how a Python AI service could report monthly cost per plug-in and hospital and operate alongside the stated Bedrock Mumbai, TypeScript/NestJS, PostgreSQL, and AWS stack. Mark architecture choices beyond the posting as proposals.

• Write questions for the employer

  Ask how hospitals define acceptance, what clinical advisors need for sign-off, what patient-data processing and retention boundaries apply, and how the core team expects plug-ins to integrate while remaining independently switchable.