The structural read
The upstream team owns strategy, design, process mapping and stakeholder management. The build team owns delivery of the AI and automation solutions. Your scope — requirements, strategy, design, some UI/UX — overlaps the first and depends on the second.
That produces two symmetric worries, and almost every question is a probe into one of them.
| What they quietly fear | What they want to hear | |
|---|---|---|
| Strategy lead | You'll bypass their process work and stakeholder governance, demo something to an exec, and create expectations they have to clean up. Or more simply: you'll duplicate someone already on their team. | Their artefacts are your input, you prototype to de-risk their design rather than to replace it, and stakeholder conflict routes through them. |
| Build lead | You'll hand over fuzzy requirements, demo a prototype that becomes an unspoken production commitment, and promise things their engineers then have to walk back. | You write specs they can estimate against, you know a prototype is disposable, and you check feasibility before anything is promised upstream. |
The single highest-value preparation
One crisp answer to "where does your role start and stop", said the same way to both of them. If they compare notes afterwards and heard two different boundaries, that is the fail — and it's the one failure mode you can eliminate entirely with rehearsal. It's below.
The Strategy lead
Owns strategy, design, process mapping, stakeholder management. Upstream of every build.
What they're actually screening for
Whether you extend what their team does, or repeat it. Their team already produces process maps and manages the stakeholder relationship, so the useful version of you starts where their artefacts stop — at the point a developer would still have to guess. If you can't articulate that line, you're a risk to their turf and they have no reason to advocate for you.
Their likely questions
- A controller says they want a dashboard — what do you do?
- Automate, redesign or eliminate — how do you decide?
- A stakeholder insists on replicating their spreadsheet
- How do you drive adoption of something people didn't want?
- How do you say no to a stakeholder?
- How do you influence without authority?
- How do you present to a CFO-level audience?
- Our team already does strategy and process mapping — what do you add?
- What if you disagree with our process design?
- Who owns the stakeholder relationship day to day?
How you win them
Defer on the relationship, claim the artefact. Say plainly that they own the business problem and the stakeholder, and that what you own is the thing that turns an agreed design into something buildable — the spec, the data definitions, the prototype, the interface. Then ask a question that shows you've thought about their pain rather than yours: where does the hand-off break down today?
Expect the UI/UX portion to carry more weight with this interviewer than the title suggests. Have one redesign you can walk through in detail — what was wrong, how you knew, what you changed, what improved. The finance-interface principles on the domain page are the ones to reach for, because most candidates answer with consumer-app instincts that are wrong in this context.
The Build lead
Owns delivery of AI and automation solutions for Finance. Downstream of every requirement.
What they're actually screening for
Whether you'll be an accelerant or a bottleneck. They've almost certainly had requirements arrive half-formed before, and they're calculating how much of their team's capacity you'd save or consume. The two things that most reassure them are a specific answer about what a requirement contains, and an honest statement of your technical ceiling.
Their likely questions
- How technical are you, honestly?
- What does a good requirements document contain?
- How do you keep a prototype from becoming production?
- My engineers can generate an app from a description — what do you add?
- What if a requirement is infeasible or ten times the cost?
- How do you scope an MVP?
- How do you handle requirements changing mid-build?
- You don't manage my engineers — how do you get work done?
- How do you measure whether a build succeeded?
- How do you handle hallucination in a finance context?
- How would you approach the accruals redesign?
How you win them
Be specific and be honest about the ceiling. Overclaiming technical depth is the fastest way to lose a build team's trust, and it always surfaces by month two — whereas a clearly-drawn line ("I can read and write SQL and prototype something clickable; I can't design a pipeline that survives a backfill") is immediately workable. Then give them the thing they most want: a concrete definition of ready, and a commitment that nothing gets promised upstream before they've seen it.
The posted req sits in the Data Science function with a Python, SQL, BigQuery and Looker bar. Even if the role has been re-scoped away from that, expect enough technical questioning to calibrate you — not to fail you. Answer at your actual level and say what you'd need from them.
Placement is unconfirmed — prepare for all three
You don't yet know whether the role reports into the strategy side, the build side, or sits between them. Don't build your pitch on a guess. What's worth knowing is that the scope overlap with the strategy team exists regardless of the reporting line — only the mechanism for resolving it changes.
| If you land… | The real question being tested | Your emphasis |
|---|---|---|
| In the strategy team | Do you extend what we do, or duplicate a colleague? | Solution definition, prototyping, spec quality — the part their team stops at |
| In the build team | Can you stop our engineers building the wrong thing? | Requirements discipline, acceptance criteria, resisting scope creep |
| Between the two | Accelerant or relay station? | Owning an artefact end to end, plus a hand-off protocol in both directions |
All three want the same underlying evidence: that you turn ambiguity into something a builder can act on, and that you own a deliverable rather than routing other people's. Lead with that and it lands in every configuration.
How to find out rather than guess
Ask the recruiter beforehand. "Which team does this role report into, and has that been finalised?" It's a normal question and costs nothing. If the answer is that it's still being worked out, that's useful in itself — it means you may have some influence over it.
In the room, ask it neutrally. "How is the team structured around this role — where does it sit relative to the strategy side and the build side?" That's curiosity. The presumptive version — "since I'll be sitting between the teams…" — reads as not having done your homework if you're wrong.
Read the signal from what they ask. If the strategy lead spends the hour on process mapping and stakeholder handling, you're likely in or near that org. If the build lead's questions lean on delivery mechanics and estimation, you're closer to theirs. If both keep circling hand-offs and boundaries, it genuinely isn't settled — and then the strongest move is to name it: "it sounds like the seam between the two teams is where the friction is. Whichever side I report to, here's how I'd run that hand-off…"
The boundary answer
Rehearse until it comes out the same way twice, in under forty-five seconds.
"Honestly, that's one of the things I want to understand better today, and I'd rather agree it than assume it. My working view is that the strategy side owns the business problem, the process design and the relationship. I own turning that into something buildable — the requirements, the data definitions, the prototype, the interface — so what reaches the build team is estimable and testable. I'm not redoing discovery. The place I'd want to be explicit is who talks to the stakeholder about scope, because that's where roles like this usually go wrong. My preference is that it's them, and I'm in the room."
Three things make it work. It opens by admitting you don't know, which removes any hint of presumption. It gives away the relationship — the thing the strategy lead most needs to keep — and claims an artefact instead. And it names the specific failure mode, which is the part that makes it sound like experience rather than a proposal.
Questions to ask them
Have five ready; ask two or three. The best ones reveal whether the role is real, not just whether it's interesting.
For the Strategy lead
- "Where has the hand-off from your team to the build team broken down before, and what would you want this role to have fixed six months in?" — the single best question on this page. It gets them describing the actual job, and their answer tells you what to emphasise for the rest of the conversation.
- "What would make you feel like this role was a net add rather than another hand-off?"
- "How much of your team's time goes on the same three stakeholder conversations repeatedly?"
For the Build lead
- "What proportion of your team's capacity currently goes on rework because requirements shifted?" — quantifies the pain you'd be solving and shows you think in terms of their capacity, not your remit.
- "What's in a requirements doc today that you wish were there and isn't?"
- "What does 'production' mean here — who owns it at 2am, and is there an SRE model, or does the builder own it?"
For either, and the one to keep in reserve
- "If this role didn't exist, who does the work today — and what do they stop doing when I start?" — this tells you whether the seat is real or aspirational, and asking it reads as exactly the judgment they're hiring for.
- "How do you decide what gets built? Is there a formal intake, and who breaks a tie between two VPs?"
- "What's been tried here already that didn't work?" — protects you from proposing something that failed two years ago.
Domain questions that prove fluency
Only use one, and only if the conversation has gone deep on that project. Each is on the domain page with its reasoning.
- Accruals: "What share of accrual value comes from manual submissions rather than PO data — and does anyone measure accrual accuracy against the true-up?"
- Headcount: "When there's a reorg, does the dashboard restate history under the new structure, or preserve what was true at the time?"
- Spend: "Is forecast error measured by category and by owner, or only in aggregate?"
What to listen for
You're assessing them too, and this particular role shape has known ways of going wrong. Three things worth noticing:
Nobody can say what the role owns. If both interviewers describe it as "helping" or "connecting" without naming a deliverable, the seat may not be real yet. That's survivable if you shape it yourself, but you should know that's the job you're taking.
The two of them describe the boundary differently. Note it, don't point it out in the room. It tells you the first three months will be negotiation, and it's a fair thing to raise with the hiring manager at offer stage.
Adoption never comes up. If a transformation team talks entirely about what it builds and never about what gets used, the measurement culture isn't there — and you'd be joining a team that will struggle to prove its value regardless of how good the work is.
One thing to check before the day
The req and the re-scope may not match
The posted role sits in the Data Science function with an explicit Python, SQL, distributed-data and BI-tool bar. If it's been re-scoped toward requirements, strategy and design, it's worth asking the recruiter whether the job description and level or band were re-scoped with it:
"Given we've shifted the scope toward requirements, strategy and design — has the req and levelling been updated to match, or is it still mapped to the Data Science ladder?"
This matters beyond compensation. On a data-science ladder your performance criteria and promotion path may be written against technical output you're no longer producing. Better to surface it now than in the first review cycle.