The six position drills are the round. Everything else is confirmation.

Solution definition — the layer between an agreed process design and an engineer's estimate. Your process map tells me what should happen. It doesn't tell a developer which field is authoritative, what the acceptance criterion is, or what the screen does when the source system is a day behind. That's the gap I'd fill, and I'd rather be judged on an artefact I own end to end than on being a link in a chain. If it turns out that gap doesn't exist here because you already close it, that's genuinely worth knowing today — it would change what I'd be most useful doing.

Why it works: it names a layer rather than a function, so nothing she staffs is being claimed. The last sentence is the load-bearing one — it converts a turf claim into a question, and it is the reason the answer survives a sceptical follow-up.

You do. That's the part I'd actively not take, and I'd want to be explicit about it rather than let it drift. My preference is that you're the one having the scope conversation and I'm in the room, because the version where two people are separately negotiating scope with the same finance stakeholder is how commitments appear that nobody remembers making. Where I'd want direct access is narrower — the people doing the actual task, for half an hour, watching them work. That isn't a relationship, it's a data-gathering session, and I'd tell you before I did it.

Why it works: it concedes the asset immediately, gives a reason grounded in a failure mode rather than in deference, and then carves out the narrow access you genuinely need. Asking for less than she expected is the single strongest move available in this round.

Honestly, either works, and I'd rather agree the boundary than the box. If I'm on your side, the risk is I drift away from delivery and become another layer of documentation. If I'm on the build side, the risk is I'm quietly redoing discovery your team has already done. Both are manageable, and they're manageable in the same way — by writing down which artefacts are mine before I start. The version I'd argue for is that you keep the business problem, the process design and the relationship, and I take the spec, the data definitions, the prototype and the interface.

Watch for: the temptation to pick her side to flatter her. It reads as ingratiating and it forfeits the one negotiation you get. Name both risks, then offer the boundary. Say it once and let it sit.

Raise it once, with a specific reason, to you — not in front of the stakeholder. If you've heard it and still want to go that way, we go that way and I build it properly rather than half-heartedly. I've been on both sides of that. The version where the solution person keeps relitigating the design in stakeholder meetings poisons the relationship and doesn't even work — it just makes the business think the team is divided. What I would ask for is that we write down what we expect to be true if the design is right, so that six months later we're looking at evidence rather than re-arguing from memory.

Why it works: “once, privately, then commit” is the answer she needs before she can put you in front of her stakeholders. The final sentence turns compliance into something with a spine — you defer on the decision but not on the evidence.

[Situation — a strategy or process design that already existed, that you did not produce.] What I got was [the artefact: a target operating model, a process map, a deck]. What was missing was everything a developer would have had to ask about — [which system was authoritative for the key field, what the rule was in the edge case, what “complete” meant]. I spent [time] turning that into [a spec / a data dictionary / a clickable prototype], and the thing I'd point at is that [the estimate came back at X rather than a range] / [we found the disagreement about the definition before the build rather than in UAT]. I didn't change their design. I made it decidable.

This is the highest-value story you own. It demonstrates the position instead of asserting it, and it is the one that shows you can be additive without being territorial. If only one story is fully prepared, make it this one. End on “I didn't change their design” — she will hear it.

You'd know because of what I hand over. A layer that's genuinely additive produces something the next person can act on without a meeting — a spec with acceptance criteria, definitions agreed with the data owner, and a prototype the stakeholder has already reacted to. A layer that isn't just moves the same information into a new document and adds a week. The honest test is capacity: if the build team's rework rate doesn't fall in the first two quarters, I haven't earned the seat. I'd rather be measured on that than on throughput of requirements.

Why it works: it accepts the premise as a legitimate risk and then proposes a measurable disconfirming test. Offering the metric you'd fail on is the most senior move on this page — and it also quietly sets a metric that favours you.

I ask what decision they'll make with it, and what they do today instead. Nine times out of ten the dashboard is a proxy — someone is doing a manual reconciliation every month and they want the answer, not the chart. At [company] a spend-dashboard request turned out to be one person exporting three systems into Excel every Thursday to answer a single question a VP asked on Mondays. We didn't build a dashboard; we built the answer, on a schedule, into an email. About a fifth of the effort, and it got used — which the dashboard wouldn't have been.

Why it works: a method question answered with a method, then one concrete case with a comparative outcome. The example ends with something smaller than what was asked for, and restraint reads as experience.

I don't argue with their solution, because that's a fight about their competence rather than about the problem. I ask them to walk me through the last time they did the task, in detail, and I watch rather than interview — people describe their process as the policy says it works, not as they actually do it, and the workarounds are the requirements. Then I play their solution back with the constraint attached: “if we build exactly this, here's what it costs and here's what it doesn't cover — is that the trade you want?” Most people revise it themselves at that point, and then it's their revision, which matters for adoption later.

Follow-up to expect: “what if they won't budge?” — then you build a low-fidelity version of their idea and let contact with it do the arguing. Cheaper than a fight and it preserves the relationship she owns.

I build it their way first, at low fidelity, and let them use it. Arguing in a room is unwinnable — they know their process and I don't, yet. What I'm actually doing is finding the two or three places where the spreadsheet encodes a workaround for something we've since fixed. Then the conversation isn't “your spreadsheet is wrong”, it's “these four columns exist because the old system couldn't do X — do you still want them?” They almost always drop them themselves. Ownership of the change has to sit with them or adoption doesn't happen.

Why it works: it treats the spreadsheet as evidence rather than as an obstacle. In finance, the spreadsheet usually is the requirements document — saying so out loud lands well with anyone who has run process work.

Eliminate first, always, and it's the question people skip. Half the reports in a finance function are running because someone asked for them in 2019 and nobody has checked since — turning off a report costs nothing and the absence of complaints is the cleanest evidence you'll ever get. Then redesign, because automating a broken process just makes it produce wrong answers faster and at greater volume. Automation is last, and only where the process is stable, the volume justifies it, and the exceptions are bounded. The bit I'd watch for is a process with a thirty per cent exception rate — that's a redesign wearing an automation costume.

Why it works: ordering the options and defending the order is a judgment answer rather than a taxonomy. “Automating a broken process makes it produce wrong answers faster” is the line she will remember, and it is precisely her team's argument for existing.

First I'd find out whether anyone measures it, because “bad” without a number is usually one loud person's bad quarter. So: pull the last four to six cycles, compare forecast to actual by category and by owner rather than in aggregate, and see whether the error is bias or noise. Those need completely different fixes — consistent over-forecasting in one cost centre is a behaviour problem, and scatter across everything is a data or timing problem. Two weeks isn't enough to fix anything, but it's enough to replace “forecasting is bad” with “sixty per cent of the variance sits in three cost centres”, and that reframes what gets built.

Why it works: it refuses the premise politely, then substitutes a measurable one. Bias versus noise is the distinction that signals you have actually done this. Have a number-shaped ending even if the number is invented as an illustration — say “something like” if it is.

I try never to say no to the request — I say no to the sequence. “Yes, and here's what it displaces” is a real answer and it hands the decision back to them, which is where it belongs. What I won't do is say yes in the room and then quietly not deliver, which is the most common version of no in large organisations and by far the most damaging. If it's a hard no — usually a control or data-integrity reason — I say it once, plainly, with the specific reason, and I bring the cheaper thing that gets most of the value. [Example: at [company], [request], which I traded for [smaller thing] that delivered [outcome].]

Why it works: naming the silent-no as the real failure mode is unusual and true. She is listening for whether you will protect her team's credibility or spend it.

Mostly by making the thing I want easier than the alternative, rather than by being persuasive. Three things do the work: finishing something small early so people have evidence that work handed to me comes back, having the number that makes the case so the argument isn't about taste, and giving credit away publicly, because the currency is other people wanting to be in your next thing. The part I'd add is choosing what to spend it on — most people with no authority spend it on being right in meetings, which buys nothing.

Watch for: this question invites platitudes and most candidates supply them. The specific, slightly unglamorous mechanism — deliver something small first — is what separates a real answer.

First I check whether it's a real conflict or a definitions problem, because most of the time it's definitions — two people using the same word for different things, which in finance happens constantly with anything like headcount or spend. If it survives that, I don't mediate it. I write both positions down in one paragraph each, name what each costs, and take it to whoever owns the outcome. Mediating between two stakeholders as the requirements person is a trap: you end up owning a decision you have no authority to make, and whichever way it goes you've spent credibility you'll need later.

Why it works: refusing to mediate is the counter-intuitive move and the correct one. It also implicitly routes the escalation through her, which is exactly what she wants to hear without you having to say it.

[Situation, one sentence. Who, what they wanted, why it was a problem.] [What you did — including the part where you were partly wrong, or where you conceded something.] [How it ended, with a number or a concrete outcome.] What I'd do differently is [something specific and slightly unflattering].

Structure, not content — this one is yours. Two rules: the other person has to come out of it as reasonable, and you have to concede something real. A conflict story where you were right throughout and they eventually saw sense reads as someone who cannot work across a seam, which is the entire risk she is assessing.

Answer first, then the working, and only as much working as they ask for. The mistake is building to a conclusion — at that level the first slide is the recommendation and the number it turns on, and everything after it exists to be interrogated. I'd rather have three slides and twenty minutes of questions than fifteen slides and no time. Two specifics for finance: never show a number without saying where it came from and as of when, and know the one figure you're most likely to be challenged on well enough to defend it cold. Getting caught not knowing your own number is unrecoverable in that room.

Why it works: it is about their time and their scrutiny rather than about your presenting style. This question is really “can I put you in front of my stakeholders unsupervised?” — answer it as a risk question.

[What it was and who used it.] The problem wasn't that it looked bad — it was [the actual failure: people exported it to Excel every time, or the number didn't match the system of record, or the task took four screens]. I knew because [evidence: I watched N people do it, or usage was X, or the same question came to me weekly]. What I changed was [the structural change, not the cosmetic one]. Afterwards [the number: time per task, adoption, tickets, export rate]. The thing I got wrong first time was [something real].

The highest-risk answer in this round. She will weight the UI/UX portion more heavily than the title suggests, and a generic answer here is the most likely way the conversation goes flat. The evidence beat is what separates a designer from someone with opinions about design. See the design page for the full structure and the finance-specific principles.

I put it in front of the person who'll use it and ask them to do a real task with it while I stay quiet. Not “what do you think” — opinions are free and worthless. Watching someone fail to complete a task in ninety seconds tells you more than an hour of feedback, and it tells you it before anyone has estimated anything. The other test is whether the person who has to defend the number can find where it came from without asking me. In finance that's most of usability, and it's the thing consumer-app instincts miss.

Why it works: it gives a testable definition of good and a domain-specific second criterion. If she asks how many users, the honest answer is that five is usually enough to find the structural problems.

By saying what it is before I open it, every time: this is a disposable thing to argue with, none of it is built, and the numbers in it are fake. Then I make it look unfinished on purpose — grey boxes rather than a polished screen — because a prototype that looks shippable creates a date in someone's head whatever I say. And I never demo anything upstream that the build team hasn't seen first. That's the rule that actually does the work; the rest is hygiene.

Consistency check. This is the one answer both interviewers will hear a version of. It should be recognisably the same answer you gave in the first round — same rule, same reason. If the wording drifted, keep the round-one wording.

You probably don't want me doing the craft part, and I'd be careful about claiming it. What I do is closer to making the design decidable — turning an agreed process into screens and states specific enough that a stakeholder can react to them and a developer can build them. The value isn't visual, it's that the argument happens in a clickable thing over two days rather than in a sprint over two weeks. If there's a designer available I'd want them doing the interface and I'd be doing the flow, the states and the edge cases underneath it.

Why it works: it declines the overclaim before she can test it. Volunteering a ceiling in her domain, exactly as you would in the build lead's, is what makes both boundaries credible.

Mostly by not being in that position — if nobody asked for it, the discovery went wrong somewhere. But it happens, usually because the mandate came from above the users. Three things work: find the one person whose job it genuinely improves and make them visible, remove the old path rather than asking people to prefer the new one, and measure usage weekly from day one so the decline shows up while you can still do something about it. What doesn't work is training. Training is what teams do instead of fixing the thing.

Why it works: “training is what teams do instead of fixing the thing” is the memorable line and it is defensible. Opening by questioning the premise shows adoption is designed in rather than bolted on.

[The thing, in one sentence, and who it was for.] It was used by [low number] and then stopped. The reason wasn't the tool — it was [the real reason: it required a step nobody was accountable for, the old path still existed, the data was a day stale and they needed today's]. What I took from it is [the specific practice you now do because of this]. It's why I [measure usage weekly / kill the old path / check the refresh cadence before designing anything].

Do not skip this one. A candidate with no failure story reads as either inexperienced or evasive, and a transformation team has seen plenty of failures. The rule: the failure has to be genuinely yours, and the lesson has to be a practice you can name, not a sentiment.

I've done the version of this job with a bigger title and less contact with the actual problem, and I didn't enjoy it much. What's interesting here is that the team is early enough that the problems are still undefined — accruals, headcount, spend consolidation are all genuinely hard and genuinely unsolved. I'd rather be doing that at manager level than managing a portfolio of solved ones. I'm also clear-eyed that this is a build-adjacent role rather than a strategy chair, and that's what I want right now.

Why it works: the last sentence is the important one for this interviewer specifically. Saying plainly that you are not after a strategy chair removes the threat before she has to wonder about it.

Two things. If the boundary between the teams never gets agreed, I'd spend my time negotiating rather than delivering and I'd become a layer rather than a help — that's the one I'd actively manage from week one. The other is if the work turns out to be mostly documenting decisions other people have already made. I'm not much use as a scribe, and I'd rather say that now than discover it in month four. Both are more about how the role is set up than about capability, which is why I keep asking about the boundary.

Why it works: answering honestly about structural risk rather than performing a fake weakness is the right register, and it retroactively justifies every boundary question you have asked all hour. Good closing answer if you get the choice.

Because I've watched a role like this fail that way, and it wasn't a capability problem. Someone perfectly competent spends eighteen months negotiating what they own instead of delivering, and by the time everyone agrees, there's nothing to point at. It's also the only part of this I can't fix on my own once I'm in — everything else is effort. So I'd rather be slightly tiresome about it now than diplomatic now and stuck later.

Why it works: she may well notice the pattern, and read it as anxiety unless you name it first. This converts it into experience, and “the only part I can't fix on my own” is the asymmetry that justifies the persistence.

Yes — and there are two things I'd want if it went that way. That the build team hears the boundary from you rather than from me, because it lands completely differently coming from you. And that some part of what I'm measured on is also something they're measured on, so I'm not quietly optimising for making your team's life easier at the cost of theirs. The version of this seat that goes wrong is when the person in it has only one set of stakeholders.

Why it works: says yes without flattery, then turns it into two concrete, cheap asks that show you have thought about how that specific configuration fails. Do not hedge the yes — hedging here reads as angling for the other team.

Most likely I let the definition work happen after the commitment instead of before it — someone senior asked for a date, I gave one that assumed the data definitions would land in time, they didn't, and the spec went over with open questions in it that the engineers closed with guesses. The second most likely is that I was writing for the wrong reader: documents that survive a stakeholder review but don't answer what a developer actually needs. Both are on me, and both are visible early. The tell is how many clarifying questions arrive per ticket after handover — that's the thing I'd track from month one, because by the time anyone complains it's already been true for a quarter.

Why it works: a pre-mortem rewards specificity, and naming a leading indicator rather than a resolution is the senior move. Take the blame cleanly — any version that involves the build team not reading the document fails this question instantly.

I wouldn't propose one yet — I haven't seen a handover. What I'd do in the first month is sit at both ends of three of them and write down every question the engineers asked after the document was declared final, because that list is the actual gap and it's usually not what either side assumes. If you want my prior, it's field-level definitions and the edge cases, because that's what's missing almost everywhere. But I'd rather bring you the list than the opinion.

This is bait, and a good candidate still fails it. Answering with a confident critique of a process you have never seen is the fastest way to become a threat. Declining without a method, though, reads as evasive — so decline, give the method with a date, and offer the hypothesis as a hypothesis.

Three things, all cheap. Introductions framed as “this person owns X” rather than “this is our new hire” — that framing does more for me than anything I could say myself. Your read on which stakeholders are already tired, because I'd rather not spend my first credit on someone who's been asked for their time four times this year. And half an hour walking me through a piece of work you weren't happy with the outcome of, because that tells me more about the standard here than anything that went well.

Why it works: the asks are small, specific and reciprocal, and the third one is unusual enough to be remembered. Most candidates answer this with “context” and “time”, which asks for everything and nothing.

I'd take the win and then be very plain about what they're looking at: this proved the design, and behind it there's no connected data, no error handling, and nothing has been through a control review. Here's what real looks like in effort, and here are two smaller versions that get most of the value sooner. What I won't do is let a date get agreed in that meeting, because a date set in a room the build team isn't in isn't a date — it's a problem I've created for someone else. If they push hard, I'd rather they hear the estimate from the people who'd have to hit it.

The one answer that reassures both interviewers at once. It doesn't refuse, it converts enthusiasm into options, and it explicitly protects the build team from a commitment made upstream. Expect a follow-up on what the two smaller versions would be — have a shape ready.

Once it's escalated I stop arguing about whether it's a good idea — that decision is now above me, and continuing to relitigate it just makes me the obstacle rather than the argument. What I do is make sure the decision gets made with the right information in front of it: one paragraph on what it costs, what it displaces, and what I'd expect adoption to be, with the reasoning attached. Then whatever's decided, I build it properly. The one thing I'd ask for is that we agree up front what usage would tell us it worked, so in six months it's a fact rather than a re-argument. Being proved right later is worth nothing if I've spent the relationship getting there.

Why it works: it draws the line between advocacy and obstruction, which is exactly what she is testing. The closing line is the memorable one and it is also the thing she most needs to believe about someone she'd put in front of her stakeholders.

Accruals — and not because it's the most appealing. Headcount and spend consolidation are both definition problems where the hard part is getting people to agree, and I'd want more standing than I'll have in month one before I reopen what “headcount” means across three functions. Accruals has a chunk that's mechanical, the goods-received-not-invoiced piece, where I can produce something provable without needing anyone's permission. I'd rather earn the right to run the definitional fights by finishing something small first. If you told me the org already has that standing and the sequencing should be different, I'd take that.

Why it works: it commits, and the justification is sequencing and political capital rather than interest — which is a manager's answer rather than a practitioner's. The last sentence keeps it a conversation. Have a one-line answer ready for “why not the other two” on each.

Anywhere the output becomes a number of record without a human between it and the ledger — journals, postings, anything feeding an external filing. Not because a model can't do it, but because you can't produce audit evidence for a judgment nobody can reconstruct. I'd also skip it where the base rate is already high and exceptions are rare, because you spend more on monitoring than you save. And I'd be careful anywhere the training data is your own historical decisions — an accrual model trained on estimates nobody was ever measured on will confidently reproduce those estimates, and now the error has a machine's authority behind it.

Why it works: inversion questions are where enthusiasm gets tested, and three distinct reasons beat one good one. The last point — automating an unmeasured process bakes in its bias — is the one that sounds like experience rather than caution.

Something small and complete rather than something valuable and half-done. The first thirty is mostly listening — sit through a close, sit with people submitting accruals, read what's already been tried, because the fastest way to lose credibility in a team like this is to propose something that failed here two years ago for reasons I didn't ask about. Thirty to sixty, I'd pick the most finishable thing rather than the most valuable one and take it all the way through including adoption, because the team needs evidence that work handed to me comes back. Sixty to ninety is the definitional groundwork on something bigger. I'd be suspicious of any plan that has me presenting a strategy in week three.

The word “finish” is what makes this non-generic. “Most finishable, not most valuable” is the line to land on — it is counter-intuitive, defensible, and it is what someone who has joined a team with a credibility problem actually does.

Pick one and own it. A hedged answer fails this question outright — it is testing whether you have a spine, not whether you are correct. Two that are defensible and true to this role:

“Most dashboards shouldn't be built. A request for a dashboard is almost always a request for an answer, and the answer is cheaper, arrives on a schedule, and actually gets used. I've killed more of these than I've built and I don't think I've been wrong about it yet.”

“Training is a symptom. If a tool needs a training session, the design failed — and training is what teams do instead of fixing it, because it's visible, schedulable and doesn't require admitting anything.”

Have the counter-argument ready. She may push, and the good response is to concede the exception rather than defend the absolute: dashboards earn their place when the question genuinely changes week to week, and training is legitimate when the process is new rather than the tool being unclear.

Probably that I ask for definitions before anyone's ready to give them. I'll hold up a kickoff over what “active” means, and from the engineering side that reads as slowing things down — especially when they can see work they could be starting. The honest version is I've got the timing wrong sometimes; occasionally the definition genuinely could have waited and I made it a blocker when it wasn't one. My defence is that the alternative shows up in month three as rework, but I'd rather you heard that from me than have me pretend it doesn't happen.

Why it works: a real, specific irritation that a strategy lead would forgive and a build lead would recognise. Conceding that you sometimes get the timing wrong is what stops it being a humble-brag — without that clause, “I care too much about definitions” is exactly the fake weakness this question is designed to catch.

I under-estimate how long agreement takes. I'll scope something assuming that once the analysis is clear the decision follows, and then it sits for three weeks because two people who need to agree haven't been in a room together. I've got better at the mechanical fix — naming the decision, the decider and a date at the moment I raise it — but the instinct is still to treat a resolved analysis as a resolved question, and it isn't.

Why it works: “repeatedly” is a sharper question than “what's your weakness”, and it wants a pattern rather than an incident. A process flaw with a named mitigation and an admission that the instinct persists is the right shape — and this is a mistake senior people genuinely make, which is what makes it credible.

Two things. Whether there's genuine appetite here for the definitional work, or whether the expectation is that things get built faster and the definitions get sorted along the way — those are different jobs and I'd be better at one of them. And where the role lands, which I know isn't settled. I'm honestly less worried about the reporting line than about whether what it owns gets written down before someone starts.

Answer it truthfully — the hedge is obvious. Both items are legitimate, neither is a complaint, and the second plants the written-scope ask without demanding anything. This question is also a gift: her answer tells you which job you would actually be taking.

One thing — a sentence on what the role owns, that both of you would sign. Not a job description; a sentence. The spec, the data definitions, the prototype and the interface, with discovery and the stakeholder relationship staying where they are. I'm not asking for it to be protective. I'd just rather find out now if you and your build colleague would write that sentence differently, because that's the disagreement I'd otherwise discover in month four.

The highest-value question on this page, if it comes. It is the only moment where asking for scope in writing costs you nothing. Frame it as diagnosis rather than as a condition — “I'd rather find out now” is doing all the work, and it is genuinely true.