Original practice question. The scoring rubric is our teaching guide. How we research and score answers
TL;DR: Pick one user (say, an operations analyst at a mid-sized company), find the jobs where AI helps (writing formulas, cleaning messy data, explaining a sheet someone else built), and design every AI output as an editable, checkable change, never a silent edit. Because spreadsheets are trusted for numbers, the core risk is a wrong figure nobody notices, so evaluate with deterministic recomputation wherever possible.
How to approach it
Narrow the user first: a finance analyst, a small shop owner and a student have different jobs. List those jobs, then decide which ones need a model and which need better ordinary features. The answer stands or falls on two things: knowing where AI does not belong, and designing for the case where it is wrong.
A strong answer
User and jobs. An operations analyst who builds weekly reports from exported data. Their jobs and pains:
| Job | Pain today | Does it need a model? |
|---|---|---|
| Write formulas (lookups, conditional sums, date logic) | Syntax, trial and error | Yes: natural language to formula |
| Clean imported data (inconsistent dates, merged names, typos) | Tedious, error-prone | Yes: messy input |
| Understand a sheet built by someone else | Hours of tracing references | Yes: explanation |
| Spot anomalies in a weekly number | Missed until a manager asks | Partly: statistics first, model to explain |
| Format and chart | Annoying but fast | Mostly no: better templates |
Design principles. Three decisions shape everything.
- AI changes appear as a diff, not an edit. A suggested formula appears beside the cell with a preview of the results it would produce on the first ten rows; the user accepts or edits. Data cleaning shows before and after columns, with changed cells highlighted. Nothing changes without the user seeing it.
- Provenance on every AI-touched cell. A small marker shows that a value or formula came from AI, with the prompt that produced it. When the sheet is shared, a reviewer can see which parts to check.
- "Explain this" everywhere. Select a cell or range and get a plain-language explanation of what it computes and where its inputs come from. This builds understanding instead of dependence, and it is the lowest-risk, highest-trust feature in the set.
The main risk. A model writes a plausible formula that is subtly wrong: off-by-one ranges, a lookup that silently matches the wrong row, a date treated as text. The number looks reasonable and flows into a report. Mitigations: show sample results before accepting, flag formulas that return errors or blanks on some rows, and when the user asks a question in words ("total sales for the north region in Q3"), compute the answer in two ways (the generated formula and an independent query) and warn if they disagree.
There is a recent real-world lesson here. Microsoft shipped a =COPILOT worksheet function in 2025 that let users call a model from a cell, and its own announcement listed the limits: the function "returns dates as text rather than Excel's date serial format", and arithmetic like summing a range is "not suitable for LLMs". The same post now says the function stopped being available on 14 September 2026 (company-reported). Whatever the reasons, the design point stands: a model inside a cell produces values nobody can recompute. The safer pattern is a model that writes an ordinary formula the grid evaluates, which is where this answer puts it.
Evaluation. Most of it can be deterministic. Build a set of spreadsheets with natural-language requests and known correct answers; run the generated formula and compare the output, not the formula text. Research benchmarks do the same: SpreadsheetBench (2024) is built from 912 real user questions and judges each solution by its results on several spreadsheet files, so a formula that only works on the example sheet fails. Use model-based judgment only for explanations, checked against analyst labels.
Metrics. Accepted-suggestion rate, edits after acceptance, undo rate, time from opening a messy export to a finished report, and, as the guardrail, error reports on AI-generated formulas.
I would launch with formula help and "explain this", because both are easy to verify, then add data cleaning, and leave autonomous actions (rebuilding a whole report) until the accepted-suggestion data shows where the model is reliably right.
What interviewers probe next
"Why not a chat panel where users ask for anything?" Chat is fine as an entry point, but answers must land as checkable changes in the grid. A chat reply that says "the total is 48,200" with no formula behind it is unverifiable.
"Why not let the model compute values directly in a cell?" Because nobody can recompute or audit them, and dates and sums are exactly where models slip. Generate a formula; let the spreadsheet engine compute.
"How would you handle a 200,000-row sheet?" The model works on structure and samples, and generates formulas or queries that run on the full data. It never reads every row.
How it's scored
| Signal | Weak | Hire | Strong Hire |
|---|---|---|---|
| Scoping | "AI for everyone" | Picks a user | Picks a user, lists jobs and decides per job whether a model is needed |
| Uncertainty | AI edits cells directly | Suggestions with accept | Diffs with preview, provenance markers, independent checks on numeric answers |
| Evaluation | User ratings | Accuracy on test prompts | Executes formulas against known answers; judgment only for explanations |
Common mistakes
Designing a chat interface whose answers cannot be traced to formulas.
Letting AI write directly into cells without a preview.
Evaluating by comparing formula text instead of the results it produces.
See the AI fit test and designing for uncertainty.