Six things to actually learn
Six areas, in the order worth spending time on. The first is worth more than the other five combined, and it is the only one nobody else can do for you. Every self-test card on this page is collapsed on purpose — say your answer out loud, then reveal.
You already have more prepared material than you can deliver in an hour. What changes the outcome now is knowing six things well enough to be interrupted mid-sentence and keep going.
| Area | Why it matters here | Time |
|---|---|---|
| 1 · Your own numbers | Every prepared answer has a bracket in it. Brackets are where this falls apart. | 60–90 min |
| 2 · Accruals | Hardest of the three named projects and the most likely case question. | 40 min |
| 3 · As-was vs as-is | One idea and its three follow-ups. The highest-signal thing you can say about the headcount problem. | 25 min |
| 4 · AI under controls | The axis where this role differs from the same role anywhere else. | 30 min |
| 5 · Her vocabulary | Her team's craft words. Using them signals adjacency; explaining them signals reading. | 15 min |
| 6 · eBay right now | The only genuinely missing piece. One fact used well beats five recited. | 20 min |
How to use this page
Read a section once. Then close it and answer its self-test cards out loud before revealing. Rate honestly, filter to amber and red, and work only those on the second pass. Reading an explanation feels like studying and mostly is not — the retrieval is the part that builds the memory.
This is worth more than everything else on the page. Every model answer you have prepared contains a slot where a real figure goes, and a senior register with invented specifics collapses on the first follow-up — because the follow-up is always about the number.
You need roughly six. Go and find them rather than recalling them: old decks, old dashboards, old email threads, the ticket queue, whatever you still have access to. Approximations said confidently are fine — “roughly a third”, “somewhere around forty minutes down to under ten”. A precise invented figure is not, because precision invites interrogation.
What makes a number usable in an interview is not size but provenance. You have to be able to say, immediately and without hedging, where it came from and over what period. A modest number you can source beats an impressive one you cannot.
Fill these in and they will carry four or five answers each. Saved in this browser only.
Aim for — a before-and-after on time · an adoption figure · a cycle time · an error or rework rate · a cost or effort saved · one unflattering number you would volunteer
There is no model answer here — the test is whether you hesitated. If you did, that number is not yet usable and either needs sourcing or needs replacing.
The trap: being asked “over what period?” and answering “I think about six months”. The hesitation, not the figure, is what gets remembered.
Of the three named projects this is the one to over-learn. It is the hardest, it belongs to Controllership rather than FP&A, and the close calendar makes it the pain everyone in the function feels.
Accrual accounting says an expense belongs to the period in which the value was consumed, not the period the invoice arrived. So at month-end, if a consultancy worked through March but bills in mid-April, Finance books an estimated expense in March. The following month that accrual is reversed, the real invoice lands, and the difference between estimate and actual is the true-up.
That third category means Finance spends the first days of every close chasing several hundred non-finance people for estimates, in spreadsheets, against a calendar that cannot slip. Submissions arrive late, which compresses everything downstream. The estimates are often poor, which shows up as large true-ups the following month and eventually as an audit question. And nobody is measured on estimate quality, so nobody improves — which is the structural observation worth making out loud, because it explains why throwing a tool at the problem has not worked.
| Metric | What it tells you |
|---|---|
| Close cycle, in working days | The headline Controllership is judged on. Everything else is in service of this. |
| Manual journal entry count | A direct proxy for effort and for control risk. |
| Accrual accuracy | |accrual − actual| ÷ actual. The quality measure nobody currently has. |
| True-up volatility | Big swings mean the estimate process is not working, whatever people say about it. |
| % of accrual value auto-generated | The number a transformation project would actually move. |
| Submission timeliness | Where the cycle time is really being lost. |
An accrual books an expense in the period the value was consumed rather than the period the invoice arrives — so work done in March that bills in April is estimated and booked in March. The following month it reverses, the real invoice lands, and the difference between the estimate and the actual is the true-up.
Why it matters: this is the vocabulary check. Fumbling it costs credibility disproportionately, because it is the one piece of accounting the role genuinely requires.
Purchase orders with a goods receipt and no invoice, then contracts and run-rates, then manual estimates from cost-centre owners. I'd automate the first with rules, not a model — it's deterministic and it's usually the biggest single chunk. The manual submissions are where the pain is, but they're the last thing I'd point a model at, because the fix there is mostly process: fewer people asked, better defaults, and someone finally measuring estimate quality.
Why it works: ranking the sources, then declining to reach for AI on the painful one, is the answer that separates you from a candidate who has read the same primer.
Because nobody is measured on estimate quality. The cost-centre owner submitting the number isn't in Finance, isn't judged on the true-up, and has a day job — so a rushed guess is rational behaviour for them. Until someone can show a person their own accuracy over the last six months, no tool changes anything. That's why I'd want accrual accuracy measured before I'd want anything built.
Why it works: it locates the problem in incentives rather than in tooling, which is exactly the register a strategy and process team works in. It also sets up “measure first, build second” without you having to preach it.
I'd start by splitting the accrual population by source and sizing each one, because the answer is completely different depending on whether eighty per cent of the value is systematic or eighty per cent is emailed in. Then measure accrual accuracy against the true-up, which I'd expect nobody does today — that gives a baseline and it tells you which cost centres are actually the problem. The first build would be auto-generation from the goods-received-not-invoiced position, because it's rules-based and provable. The manual submissions I'd treat as a process problem before a tooling one: ask fewer people, give them their own history as a default, and publish accuracy back to them.
Watch the length. This is the answer most likely to run to three minutes. Four beats, ninety seconds, then stop and let her ask.
The highest-signal thing you can say about the headcount project, and it works as both an answer and a question back. It is worth learning past the definition, because the follow-ups are where it pays.
Start with the reason the problem exists at all. “Headcount” is not one number. It lives in at least four systems built for different purposes: the HR system knows who is employed now, the applicant tracking system knows who you are trying to hire, the planning tool knows who was budgeted, payroll and the general ledger know what was actually paid — and contingent workers and contractors are usually nowhere at all.
In Q1, Director X's org has 40 people. In Q2 a reorg moves 15 of them under a newly created Director Y. Now look back at Q1:
| Looking back at Q1 | Director X shows | Director Y shows |
|---|---|---|
| As-was — preserve what was true then | 40 | Does not exist |
| As-is — restate under today's structure | 25 | 15 |
Same people, same quarter, two different published numbers. Both correct. Neither is a bug.
As-was is right whenever the number has to tie back to something already committed — budget versus actual against the budget as approved, anything audited, anything already presented to the board, anything filed externally. If the historical number can move, the tie-out breaks and the audit trail goes with it.
As-is is right whenever you want a like-for-like trend for the org as it exists today. A director who inherited a restructured team learns nothing from as-was numbers, because the thing they now manage did not exist a year ago. Their entirely reasonable question — “is my org growing?” — is only answerable if history is restated.
So the mature answer is that you usually need both. The real failure is not picking the wrong one; it is picking one silently and not labelling which view a screen is showing.
As-is is the accidental default, and that is the trap worth naming. If you join headcount facts to the current version of the org dimension — the cheapest thing to build, and what happens when nobody decides — you have chosen as-is without knowing you chose. Getting as-was requires effective-dated hierarchy: every org node and every person-to-node assignment carries a valid-from and a valid-to, and you report “as of” a date.
In data-modelling terms it is the difference between overwriting the dimension and versioning it, and it is a decision that is expensive to reverse once a year of history has been loaded under the wrong one. That is why it belongs in the definitions document rather than in a design review.
The third axis, if you want the deep version
Reorgs are entered retroactively. HR backdates a transfer to 1 April but keys it in on the 20th — so “headcount as of 5 April” answered on 10 April is a different number from the same question asked on 30 April, and both are correct. That is valid time versus transaction time, and it is why “as of when” has two meanings in finance. You are unlikely to need this in the room, but it is what separates knowing the concept from having been burned by it.
Restatement works cleanly when a team moves. It has no defensible answer when a node splits or merges. If one team of 30 becomes two teams of 15, there is no principled way to allocate last year's headcount or spend backwards, because the split was not a fact then — any restated number is an allocation somebody invented.
This is the case worth naming out loud, because it proves you have hit the edge rather than read the summary. The workable answer is that splits fall back to as-was, and the screen says so.
A number someone presented to their VP last quarter changes. They did nothing, they cannot explain it, and they did not cause it. They quietly go back to their spreadsheet — and they never tell you. That is the mechanism: dashboards do not die of bugs, they die of one unexplained movement.
One page, agreed before anyone designs a screen: which view is the default, which reports use which, whether restatement is available as a toggle or fixed, and the rule for what happens when a node splits. It is a boring document and it is the whole project.
The sentence to own
“The first deliverable isn't a chart, it's a definition — one agreed meaning per field, one named source of truth per attribute, and a decision on as-is versus as-was reporting. Every headcount dashboard I've seen fail, failed because that document didn't exist and everyone assumed their own definition was the obvious one.”
The question back
“When there's a reorg, does the dashboard need to restate history under the new structure, or preserve what was true at the time?” Almost nobody outside the problem asks this, and it is the decision that determines the entire data model. Keep it for the headcount conversation specifically.
As-is restates history under today's org structure, so a team that was reorganised last quarter shows a consistent trend under its current shape. As-was preserves what was true at the time, so last year's numbers never move. Both are legitimate and they answer different questions — as-is is right for “how has this team trended”, as-was is right for anything that has to tie back to what was reported at the time. The reason it matters is trust: if a number someone presented to a VP last quarter changes because of a reorg they had nothing to do with, they stop using the dashboard, and no amount of fixing it afterwards brings them back.
Why it works: it explains both, refuses to declare one universally correct, and lands on the human consequence rather than the data model. Almost nobody outside the problem asks this, which is exactly why it signals experience.
Because it isn't a reporting problem, it's a definitions problem wearing a reporting costume. The number lives in four systems built for different purposes — the HR system, the recruiting pipeline, the planning tool and payroll — and contractors usually live in none of them. On top of that you've got effective dating, two hierarchies that don't agree, and in-flight people who can be counted twice or not at all. Every organisation of size has attempted this and most have failed twice, and it's almost never because the charting was wrong.
Follow-up to expect: “so what would you do first?” — the answer is the definitions document, named owner per field, and the as-is versus as-was decision, before anyone designs a screen.
When a team splits or merges. Moving a team is fine — you can map every person backwards. But if one team of thirty becomes two teams of fifteen, there's no principled way to allocate last year's headcount or spend across them, because the split wasn't a fact then. Whatever number you produce is an allocation someone invented, and it'll be challenged the first time it's shown. So splits fall back to preserving what was true at the time, and the screen says which one you're looking at.
Why it works: it demonstrates the edge case rather than the definition, and “whatever number you produce is an allocation someone invented” is the phrasing that makes it sound like something you have argued about rather than read.
Because reorgs and transfers get entered retroactively. HR backdates a move to the first of the month but keys it in three weeks later, so “as of 5 April” genuinely has a different answer on the 10th than on the 30th, and both were right when they were run. It's the difference between when something was true and when the system found out. Practically it means anything anyone might have to defend needs a run timestamp on it, not just an as-of date — otherwise you spend the close arguing about which version of the truth someone printed.
The deep one. You may never need it, but if she has lived through a headcount project this is the answer that tells her you have too. Do not volunteer it unprompted — it lands as showing off if the conversation has not earned it.
Preserve what was true at the time as the default, and offer restatement as an explicit toggle rather than the other way round. The reason is asymmetric damage: if the default preserves history, someone who wants a like-for-like trend is mildly inconvenienced and asks for it. If the default restates, numbers that people have already presented change underneath them, and you lose them permanently without ever finding out. I'd rather the failure mode be a complaint than a quiet defection.
Why it works: it commits to an answer, which most candidates avoid on a “both are valid” question, and it justifies the commitment with asymmetric risk rather than preference. Having a view and a reason for it is the whole test here.
This is the axis where an AI-and-automation role in Finance differs from the same role anywhere else, and it is where you can be distinctive without claiming technical depth you do not have.
If it touches financial reporting, controls apply. In practice that means three things: the process must produce documented evidence that it worked, someone independent must review what the automation produced, and the ability to change it must be restricted. An automation that cannot produce its own audit evidence is not cheaper — it is a control finding waiting to happen.
Segregation of duties survives automation. Whoever can change the model cannot also be the person who approves its output. This catches people out, because a small team automating its own work can collapse a control that existed for a reason without noticing.
Model changes are changes. If a forecast model is retrained and the numbers move, someone has to be able to say why. Version the model, keep the training window, and be able to answer “why is this month different” with something other than a shrug.
Straight-through processing rate is the honest headline metric — the share of items that complete with no human touch. It trends, it is hard to game, and it exposes the failure mode where an automation quietly generates exceptions that somebody handles manually off to the side.
Mostly by not putting a generative model where a wrong answer is expensive. It's good at drafting and classification — narrative commentary, routing, summarising a contract — and anything that becomes a number stays deterministic. Above a materiality threshold the model proposes and a human disposes, and the audit trail shows what was proposed, what was posted, and who approved the difference. And I'd want accuracy measured against a labelled set of past cases before anyone relies on it, because “it seemed fine in testing” isn't evidence.
The weak answer describes prompt engineering. This question is coming in some form, and it is one of the few places where a crisp answer meaningfully differentiates you.
Segregation of duties, usually without anyone noticing. The person who built the rule ends up being the person who reviews its output, which is a control that existed for a reason and has now quietly gone. The other one is evidence — a manual process leaves a trail of emails and sign-offs almost by accident, and an automated one leaves nothing unless someone designed it to. So I'd rather build the audit trail into the first version than retrofit it after an auditor asks.
Why it works: it is a specific, unglamorous failure that only shows up in practice. Naming it is more convincing than any general statement about governance.
Straight-through processing rate — the share of items that complete with no human touch — tracked weekly from day one. It's the honest one, because the common failure isn't that the automation stops, it's that it quietly starts producing exceptions someone handles manually off to the side, and headline volume looks fine while the effort saved is zero. Alongside that, cycle time and the error rate on what it produced. I'd want all three agreed before it goes live, because a metric chosen afterwards is always chosen to flatter.
The line that lands: “a metric chosen afterwards is always chosen to flatter.” It also sets up your own accountability, which reads well to someone deciding whether to advocate for the seat.
These are her team's craft words. The goal is to use two or three naturally while describing your own work — not to define them. Explaining a term signals you read about the discipline; using it in passing signals you have worked alongside it.
| Term | What it means | Used naturally |
|---|---|---|
| Current state / future state | How the process works today versus how it should work after the change. | “We mapped current state first, because the policy version and the real version had drifted.” |
| Swimlane | A process map laid out by who does each step, so hand-offs are visible. | “Once it was in swimlanes it was obvious the delay was in a hand-off, not in the work.” |
| Wait time vs touch time | Time the work sits idle versus time someone is actually doing it. Wait time is usually most of the cycle. | “Touch time was about forty minutes; the cycle was six days. All of it was waiting.” |
| Target operating model | The agreed future shape — who does what, with which systems, under which governance. | “That sat above me — I was turning the operating model into something buildable.” |
| Capability map | What the function must be able to do, independent of who does it or how. | Use sparingly; it is easy to sound like a consultant. |
| RACI | Who is responsible, accountable, consulted, informed for each step. | “The RACI was the argument, not the tool.” |
| Definition of ready / done | The agreed bar for work entering a build, and for calling it finished. | “Nothing went to the engineers without a definition of ready they'd signed off.” |
| Pain-point heatmap | Volume × effort × error rate, so where to intervene is arguable rather than political. | “We scored it so the prioritisation conversation had something in it besides seniority.” |
| Straight-through processing | Share of items completing with no human touch. | “Straight-through rate was the metric we agreed up front.” |
| Materiality threshold | The value above which a human must review. | “Above the materiality threshold the model proposes and a human disposes.” |
No model answer — the test is whether it sounded natural or bolted on. If a term needed a clause of explanation, drop it. Three used comfortably beats six used stiffly.
The failure mode: a candidate who has just learned the vocabulary uses all of it. Someone who has lived in it uses two or three and does not remark on them.
The genuinely missing piece, and the one that makes “why here” concrete. One fact used well beats five recited — do not lead with financials, and do not perform having read the earnings release.
| Measure | Q2 2026 | A year earlier |
|---|---|---|
| Revenue | $3.1bn, up 15% | — |
| Gross merchandise volume | $22.4bn, up 15% | — |
| GAAP operating margin | 21.6% | 17.6% |
| Non-GAAP operating margin | 28.5% | 28.3% |
| Advertising revenue | $596m, 2.7% of GMV | — |
The headline GAAP margin jumped about four points, but the non-GAAP margin moved by two-tenths of a point. So most of the improvement came from lower GAAP-only charges rather than from core operating leverage — on an underlying basis margins were essentially flat despite fifteen per cent revenue growth, which means reinvestment kept pace with the topline.
That is the commercial reason a finance transformation team exists. Growth is being reinvested, so efficiency in the back office is one of the levers left for defending margin. You do not need to say any of this out loud. You need it so that when someone asks why this work matters here, your answer is about the company rather than about your career.
The one fact worth actually using
eBay closed the $1.4bn Depop acquisition on 30 July 2026. An acquisition makes all three named FIT projects harder at once — a new entity entering the close, a new population entering the headcount view with its own systems and its own definitions, and new commitments entering consolidated spend. That is a genuinely good question to ask her, and it is about her problem rather than your candidacy.
From the outside, the thing that stands out is that underlying margins have been roughly flat while revenue has grown at double digits — the growth is being reinvested, which is a choice, and it means back-office efficiency is one of the levers left. That's usually when a transformation team stops being a nice idea and starts being funded. And with an acquisition just closed, the three projects you've named all get harder at the same time, which is the kind of moment where definitional work either happens now or gets paid for later.
Use at most one of these facts. Two reads as preparation; three reads as performance. And if you are not confident in a figure, describe the direction rather than quoting it.
“With Depop closing at the end of July — does the integration land on the same three projects, or does it push them? I'd assume a new entity in the close and a new population in the headcount view, both with their own definitions.”
Why it works: it is current, specific, and it demonstrates the definitions instinct in the question itself rather than in a claim about yourself. Keep it in reserve for when the conversation is going well.
Check before you quote
These figures come from the Q2 2026 release linked below. Open it once and confirm the two or three you intend to use — being corrected on a public number by someone who works there is a bad trade for a detail you did not need.
If everything else falls out of your head, these five carry most of the value on this page. Say each one out loud now.