The call — everything except the technical answers

Answers — say these out loud is what to say when they ask a technical question. This file is everything around it: the self-intro, the project story, the behavioural questions the ad’s responsibilities turn into, your questions for them, and the close.

The English mechanics — buying time, disagreeing politely, bridging when you do not know, closing an answer cleanly — are written up in full in the 14 August call script and apply unchanged. The six phrases that matter most are repeated at the end of this file.

The likely shape

A senior tech check with a tech lead usually runs about an hour. If they say otherwise, adjust; the order rarely changes.

0-5     hello, they describe the project
5-7     your self-intro
7-15    your last project, then drilling into it
15-45   technical questions        -> 02_answers.md
45-55   process and behavioural    -> this file
55-60   your questions, next steps

While they describe the project, write down three things: what the backend is today (framework, database, how many services), what is changing (the scaling, the integrations they mention), and what hurts (anything they mention twice). Use all three later — in your examples and in your questions.

If they have not said which framework they use by the time they finish, ask. The ad does not name one, and every later answer gets sharper once you know.

Your self-intro — 90 seconds

The one part of the call you can fully rehearse. Say it aloud until it is your most fluent minute — it sets their expectation of your English for everything after.

“Thanks. So — I’m a Python backend engineer with over five years of commercial experience, mostly building API services and integrations, a lot of it on AWS.

Most recently I worked on an automation platform for underwriting — a serverless Python system. Submissions come in, structured data is extracted with AI, validated through a multi-stage rules engine, and turned into pricing. I built Python services across Lambda functions orchestrated by Step Functions, REST integrations with Salesforce and OAuth2 services like Microsoft Graph and Slack, and two internal Streamlit applications on ECS with Cognito SSO.

Before that I worked on an investment planning platform — a regulated financial product. FastAPI services on PostgreSQL, the data models including audit and consent records, third-party integrations, and we worked test-first with pytest. I also built the AI assistant there with LangGraph, with guardrails for regulated advice.

What I care about is the production side — tests that catch real bugs, safe deploys, being able to debug from the logs — and I like reviewing code and helping newer engineers.

Healthcare feels like a natural next step. It’s the same discipline as regulated finance — audit trails, consent, careful handling of personal data — just with higher stakes. Happy to go deeper on any part of that.“

Why it is built this way. It follows the resume they are holding — most recent project first, in the resume’s own words — so nothing you say contradicts the page in front of them. It says regulated and audit and consent, the words that make finance experience read as healthcare-adjacent. It plants “reviewing code and helping newer engineers”, which the ad lists and the resume barely shows. And it hands the conversation back cleanly instead of trailing off.

On the years: the resume says 5+, and so does the ad. Say “over five years” — the words they are reading — and move straight on to scope.

The project story — 5 to 7 minutes

“Tell me about your last project” is the most predictable question in the call, and the last project on the resume is the Automation Platform — tell that one first. Bring in the Invest Planning Platform when the questions turn to databases, APIs or regulated data. Tell one thread of each, not a tour of the stack: the interviewer is looking for a decision you owned and can defend.

The shape, said aloud. Signal it first — “Let me give you the context, then what I owned, then the decision I’d defend, and the result.”

1. Context, in one sentence. “A serverless platform that automates underwriting — submissions come in, structured data comes out, a rules engine validates it, and it gets priced.”
2. What you owned. [your services, integrations and apps — your boundary, not the team’s. The resume says “contributed to” the platform, so be precise about which parts were yours]
3. The architecture, in words. [submission → Step Functions → Lambda steps → AI extraction → rules engine → pricing; state in DynamoDB; API Gateway in front; the Streamlit apps on ECS behind Cognito]
4. The decision you would defend. [two options, why you chose one, what it cost] — the part they are actually scoring.
5. The result. [a number if you have one; if not, what changed — and say honestly that it was not measured]
6. What you would change. A real limitation, not a humblebrag.

Then stop. Silence after the result usually means they are writing.

Prepare these drill-downs — each is a place they can push:

• How did a submission move through Step Functions, and what happened when a step failed halfway — retries, idempotency, where the state lived?
• How did the Salesforce and OAuth2 clients handle tokens, rate limits and errors?
• How did you know AI-extracted data was right before the rules engine trusted it?
• On Invest Planning: how did you handle audit and consent records? Prepare this one hardest — it turns finance experience into healthcare experience: “[what was recorded and when, how it was stored — append-only? — and who could read it]”.
• How did working test-first change the way you built it?

The STAR worksheet for Invest Planning is in Describing your strongest project.

The behavioural questions this ad produces

Each responsibility line comes back as a question. Have one story per question, with a number in it where you can. The code-review and architecture-decision answers are in Answers — say these out loud; this is the story half.

“Tell me about a feature you owned from design to production”

The ad says “ownership from design to production”, so tell the whole lifecycle, not just the code:

“[The feature] — I [clarified what it needed, and with whom], designed [the shape, and the alternative I rejected], built it test-first, shipped it [behind a flag / with a safe migration], and watched [the metric, or Sentry] after release. [What happened in the first week.]”

The last sentence is the one that proves ownership. Most candidates stop at “and then we deployed it”.

“Tell me about a technical decision you drove”

Context → two or three options → why you chose → what you gave up → how you got agreement → whether you would choose it again. If the decision was the team’s, say what your part was; inflating it collapses on the first follow-up.

Candidates from the two projects, if one of them was yours: how the Step Functions workflow handled failures and retries, how the Salesforce and OAuth2 clients were structured, or how the audit and consent records were modelled.

“Tell me about a disagreement in code review”

“[What you flagged] — I raised it as a question rather than a demand, and marked it blocking because [the risk]. [They disagreed because…] We settled it with [a test, a benchmark, a quick call]. Afterwards [the lint rule, the checklist item, or the shared understanding that came out of it].”

Showing you can be wrong too is a strong ending: “…and in that case they were right, because…”.

“Tell me about a production incident”

Detection → mitigation → diagnosis → fix → what changed. Say how you found out — an alert, Sentry, or a user. “A user told us” is honest, and it leads naturally to the improvement you made.

“[What broke, and the impact.] We noticed through [the source]. First I [mitigated — rollback, flag, scale], and once users were fine I traced it to [the cause]. The fix was [the fix], and afterwards we added [an alert, a test, a runbook step] so it would page us before a user noticed.”

“How do you mentor less experienced engineers?”

The ad names mentoring explicitly. Give the approach, then the story.

“I try to make people independent, not dependent on me. In practice that is three things. Code review as teaching — I explain why, link the pattern or the doc, and leave matters of taste to them. Pairing on the first task in an unfamiliar area, then stepping back: first I drive, then they drive and I watch, then they build it and I review. And real ownership early — a small feature end to end, with me as the safety net.

[Your example: who, what they were stuck on, what you did, and a result you could see — ‘within two months they were reviewing others’ code in that area’.]“

The result has to be something observable. “They grew a lot” is not a result.

“How do you work in a distributed team?”

“Most communication is written and asynchronous, so I write for someone who will read it in eight hours without a chance to ask me. Pull request descriptions that explain why, not just what. Questions that can be answered without a follow-up. Decisions written down where the next person will look.

I keep the overlap hours for things that need a conversation — design discussions and unblocking people — rather than status. And I make progress visible: a short written update on what is done, what is next and what is blocked, so nobody has to chase me. [Your team: the time zones, and one habit that made it work.]“

“Why this role? Why healthcare?”

“Two reasons. The work — backend services, APIs and integrations at real scale are what I do best, and an international product with millions of patients has exactly those problems. And the domain — I’ve worked in regulated finance, where audit, consent and careful handling of personal data were part of the job. Healthcare is the same discipline with higher stakes, and that matters to me. And it being long-term matters too: I want to own things long enough to see my decisions play out.”

Adjust it to what is true for you. A rehearsed motive that is not yours sounds rehearsed.

Questions to ask them

Ask two or three. They are scored like technical answers — a good question shows how you think.

• “Which framework and database is the core on — and are the newer services different from the older ones?”
• “How is patient data split across countries — is there data residency per region, and how does that shape the architecture?”
• “Where does the AI sit — in-house models or third-party APIs — and how do backend engineers work with it?”
• “What does production support look like for the team — on-call, incident reviews?”
• “How are architectural decisions made — written proposals, ADRs, an architect, or the team together?”
• “What would success look like for this role after three months?”

The close

“Thanks — this was useful. From what you’ve described, [the integration work / the scaling / the thing they said hurts] is where I think I could contribute fastest. What are the next steps on your side?”

Asking for next steps is normal and expected. Not asking reads as a lack of interest.

The six phrases

The full bank is in the 14 August call script. If you keep only six:

• “There are two parts to that — let me take them in order.”
• “The trade-off there was…”
• “To give you a concrete example…”
• “I haven’t used X specifically, but I’ve done the same thing with Y.”
• “Let me think about that out loud for a second.”
• “So that’s how I’d approach it.”