Interviewing for a cross-functional AI role: product, BA, UX

An interview for a product, business analysis or design role on an AI topic is rarely won on technical knowledge, and yet that is where preparation usually concentrates. The candidate revises the vocabulary, learns the difference between fine-tuning and RAG, then struggles on a framing question they would have handled on any other project.

Knowing the vocabulary is not the mistake; it is useful. The mistake is believing the assessment is about it. On these roles, the interview is trying to find out whether you can decide in a context where the system is probabilistic, where quality is measured rather than observed, and where failure has to be designed for from the start.

What the interview actually assesses

Four capabilities come back, whatever the company. They are almost never announced as such, but every serious question tests at least one of them.

1. 1

   Framing a problem

   1

   Being able to state the need before the solution, and to recognise a case where AI is not the right tool. An answer that jumps straight to an architecture disqualifies more often than it reassures.

2. 2

   Reasoning under uncertainty

   2

   Accepting that a system can be wrong, and designing accordingly: which error is tolerable, which is not, who verifies, and when.

3. 3

   Defining what "good" means

   3

   Translating a business expectation into an observable criterion. It is the most discriminating capability, and the one most often missing.

4. 4

   Working with engineers

   4

   Asking useful questions, understanding a constraint without contesting it blindly, and arbitrating without pretending to decide for the technical team.

None of these four requires writing code. All of them require having thought about a system that does not always return the right answer.

The technical level expected, and its limit

You are expected to understand the main families of approaches, what they imply in data, cost and time, and what they do not solve. You are not expected to choose an architecture or discuss implementation.

The recurring questions, and what they look for

• "How would you decide whether this use case deserves AI?" — testing your ability to say no, and to name a simpler alternative.
• "How would you know it works?" — expecting an observable criterion, a population of cases and a threshold, not a feeling.
• "What do you do about the system's errors?" — testing whether you design a journey that assumes error rather than one that ignores it.
• "How do you prioritise between quality and deadline?" — looking for an owned trade-off, with the accepted consequence named.
• "How do you work with engineers?" — mostly listening to how you talk about a past disagreement.
• "What surprised you on an AI project?" — checking that you actually lived through one, at any scale.

What the interview looks for in a product or PO profile

On an AI product, the product interview is not about implementation: it is about how you choose a use case, how you define what "good" means, and how you decide when quality is never guaranteed. The most discriminating question remains the one about giving up: being able to say that a case does not deserve AI, or that a business rule would be enough, reassures more than an ambitious roadmap.

• The choice of use case: which user or business problem already exists, and why this one rather than another.
• The expected value, phrased as something other than "saving time": what concretely changes for the person doing the work today.
• The definition of quality: what a good answer is, who judges it, and above which threshold the feature becomes useful.
• Metrics fitted to the case, rather than an overall accuracy borrowed from another context.
• Prioritisation and the trade-off between quality, cost and latency, with the compromise owned and explained.
• Dependencies on data and engineering teams: what you need to ask them, and when.
• The decision to launch, to restrict the scope or to stop, and the signals that trigger it.
• The ability to conclude that AI is not the right solution, while naming the alternative.

Nobody expects a product profile to choose an architecture. They expect framing, prioritisation and arbitration in a probabilistic context, then the ability to explain that compromise to an engineering team.

What the interview looks for in a BA, business analysis or consulting profile

The BA interview is won on decomposition. Restating "the business wants a chatbot" is not analysis: it repeats a solution that has already been chosen. What is observed is your ability to go back up from the stated need to the real process, then down again to acceptance criteria someone can check.

• The existing process: what happens today, step by step, before any idea of a solution.
• The actors: who does what, who approves, who bears the error when it happens.
• The data required, its real availability, its freshness and its known quality.
• The exceptions: the rare cases that often carry most of the workload and most of the disputes.
• Permissions: who is allowed to see what, and what that implies when an assistant surfaces information.
• Dependencies and risks, including the non-technical ones: regulation, outsourcing, calendar.
• Acceptance criteria, written so they can be verified, including for cases where the system must decline to answer.
• Integration into how work actually happens, and adoption: at what point in the day the tool is used, and by whom.

The expected chain is always the same: problem → process → actors → data → rules → exceptions → expected outcome → acceptance criteria. It does not cover the AI Engineer's responsibilities, and it is not meant to.

What the interview looks for in a UX, research or design profile

Designing an AI experience is not adding a conversation to the interface. The system can fail plausibly, produce an answer that is wrong but convincing, and vary from one run to the next. The interview looks at how you design for that instability rather than assuming it away.

• The user's mental model: what they believe the system can do, and the gap with what it actually does.
• Appropriate trust: neither suspicion that makes people abandon the tool, nor blind confidence in a wrong answer.
• Representing uncertainty, when it supports a decision rather than decorating the screen.
• Handling plausible errors: what the user sees when the answer is fluent and incorrect.
• Fallbacks: what happens when the system does not know, and why that is a design moment in its own right.
• Correction and recovery: being able to flag, fix, undo or hand back to a human.
• The level of control left to the user, and the points where an explicit confirmation is required.
• Useful transparency: what genuinely helps judge an answer, rather than a decorative explanation.
• User research with a non-deterministic system: observing real sessions, comparing variants, measuring trust and usage rather than declared satisfaction.

Human-in-the-loop is not a patch added at the end. It is a design decision that determines where the user takes back control, at what attention cost, and what the system does with that correction.

A cross-functional case, to place the three perspectives

The scenario below is fictional and pedagogical; it describes no real company and no real project. An organisation wants to add an AI assistant to an internal process: employees could look up information scattered across several document repositories and get help preparing certain recurring business tasks. Not all documents are up to date, not everyone has access to the same resources, and some of the questions asked will concern rarely documented edge cases.

1. 1

   Product / PO

   value

   Which problem genuinely deserves solving, for which population and on which initial scope. How to decide the result is useful enough to be extended, and which trade-offs to accept between coverage, cost and response time.

2. 2

   BA / consulting

   process

   Which process changes, who does what today, which data and rules are involved, which permissions must be respected, which exceptions must stay with a person, and how the assistant fits into how the work actually happens.

3. 3

   UX / research / design

   usage

   How the user understands what the assistant can and cannot do, what happens when it is wrong, when to ask for confirmation, when to allow human recovery, and how to observe trust and real usage rather than initial enthusiasm.

Engineering and data teams remain partners in the scenario: they are the ones who will make retrieval, access rights and content freshness workable. What is expected from a product, BA or UX profile is not to do that work, but to discuss its constraints without claiming ownership of them.

Connecting the case to interview questions

A single scenario answers most of the expected questions, provided you unfold a line of reasoning instead of reciting an answer: assumptions, the questions you would ask, the trade-offs considered, then a decision you own.

• "When would you not choose AI?" — when the reference documents are few and stable: a search engine and a repository clean-up cost less and fail more legibly.
• "How would you know it is good enough?" — by building a set of real questions from the process, defining what an acceptable answer is with the people doing the work, and fixing the threshold before launch.
• "What if users trust incorrect answers?" — treat it as a design and measurement problem: make the source visible, degrade the presentation when the answer is weak, and observe corrections rather than opinions.
• "How would you define evaluable criteria with engineering?" — by bringing the cases and the business definition of the expected outcome, leaving the measurement method to the team, and agreeing together on what blocks a release.
• "What should be watched after launch?" — real usage by population, unanswered questions, human corrections, gaps between displayed confidence and accuracy, and what the process actually changed.

Grounding your answers in a case you lived

The strongest answer is not the most general: it is the one grounded in a real situation, described with its constraint and its decision. An internal framing workshop, an abandoned pilot, a manual evaluation over fifty cases are all enough, provided they are told honestly.

1. 1

   The context

   situate

   What problem, for whom, under which real constraint — deadline, data, regulation, adoption.

2. 2

   Your exact role

   clarify

   What you decided yourself, and what others decided. Precision here is a reliability signal.

3. 3

   The difficulty

   own

   What did not work first time, and what it cost.

4. 4

   The decision

   choose

   What you arbitrated, on what basis, and what you accepted to lose.

5. 5

   What you would change

   close

   A reflection, not a token piece of self-criticism.

Three common traps

The first is talking about the model rather than the problem: technical detail then replaces product reasoning. The second is promising an impossible measurement, such as an accuracy rate on a subject where nobody can define the right answer. The third is presenting collective work as personal: the follow-up question almost always comes, and the gap shows immediately.

Saying "that part was owned by the data team, my contribution was framing and evaluation" does not reduce the value of an answer. It is what makes it checkable.

Questions worth asking at the end

• How do you measure the quality of what is already in production today?
• Who decides when perceived quality and measurement diverge?
• What share of the work is exploration and what share is industrialisation?
• How do product, BA and UX roles share decisions with the engineering and data teams?
• Which use case was recently abandoned, and why?

The last one is the most informative. A company that can name an abandoned use case has a decision process; a company with none has probably not yet met the constraint of production.

• Interview
• AI product
• Framing