What you'd need to know before handing a request to engineering
Say a stakeholder asks for a new field on a report, and the interviewer asks what you'd need to know before handing that request to engineering: where the underlying data actually lives, whether the field already exists somewhere else in the system under a different name, what happens to existing reports if the schema changes.
The conversation stays on reasoning out loud, how you'd question the request, what you'd document before it goes to a developer, why a seemingly small change might touch more of the system than the stakeholder realizes. Nobody asks you to write a query or debug a script.
What gets covered
Expect questions about reading a system at a level that lets you write a requirement engineering can act on: how data moves between two systems, what a dependency between two features actually means for a change request, how you'd explain a technical constraint to a stakeholder who doesn't have the background to understand it in technical terms.
The written challenge format pairs with this, asking you to actually document a requirement, the kind of write-up a developer would receive, rather than only describing your approach verbally.
Scoring
How scoring applies here
The Technical dimension carries real weight here, and the written reasoning behind it reflects domain understanding, not code correctness, since there's no code to check. A candidate who accurately explains how a data change would ripple through a downstream report scores differently than one who gives a plausible-sounding answer that doesn't hold up under a follow-up question.
Communication matters just as much in this session, since a technically accurate answer that a developer couldn't actually act on doesn't do the job a business analyst is hired to do.
Frequently asked questions
Do business analysts write or run code during this interview type?
No. The technical interview is a spoken conversation about domain and system reasoning. When a written exercise is included, it's a written challenge documenting a requirement, not a coding or SQL execution task.
What kind of technical questions come up for this role?
Questions about how data moves between systems, what a dependency between features means for a requested change, and how you'd explain a technical constraint to a stakeholder without a technical background.
How is this different from a written requirements challenge?
The technical interview is a spoken conversation about reasoning. A written challenge has you actually document a requirement in writing, closer to the deliverable a developer would receive.
Is this interview type useful if I've never worked directly with engineers?
Yes. It's built specifically to rehearse that translation, explaining a business need in terms a technical team can act on, which is worth practicing even more if it isn't already a habit from past roles.
Related pages
Practice explaining a requirement in terms engineering can act on
Start a technical AI interview built around business analyst domain reasoning, then document a requirement through the written challenge format and see how both hold up.