Research interviews have an unusual failure mode: the strongest answer and the weakest answer often contain the same words.
Two candidates both say "I'd run a diary study." One gets the offer. The difference is that the second one also said what they'd do if the diary entries came back thin, why they ruled out interviews, and which decision the study was supposed to unblock.
That's the whole thing. A research loop is not a methods quiz — everyone in the pipeline can define a diary study, and interviewers know it. What they're checking is narrower, and it's the same four worries almost everywhere:
- Do you have a toolkit, or one method you always find a reason to use?
- Have you actually run studies, or mostly read about them?
- Does anything change downstream of your work?
- Will you oversell a finding?
The next four sections map to those four worries, in the order a loop usually tests them.
The pattern underneath all twenty questions: none of them are asking whether you know the definition. They're asking whether you can defend a choice.
Choosing a method
What they're checking: whether the method follows from the question, or the question gets bent to fit your favourite method.
- How do you decide between generative and evaluative research?
- When is a survey the right tool — and when is it the wrong one?
- You have five days and no recruiting budget. What do you actually run?
- How many participants is enough, and how would you defend that number?
- When is usability testing the wrong method for the question you were handed?
Most of this section is one skill applied five ways: turning a stakeholder's question into a study that answers it. Worth having that translation ready, because in the interview you'll be doing it live — and the test inside it is whether you can name the single decision the study exists to unblock. A study pointed at two decisions usually lands neither.
| The question a stakeholder actually asked | What you'd reach for | Why not the obvious alternative |
|---|---|---|
| "Why are people dropping out of setup?" | A handful of moderated sessions on the real flow | Analytics shows you where they leave, never why |
| "Which of these two flows is better?" | Unmoderated comparative test, larger sample | Interviews get you opinions about flows, not behaviour with them |
| "What should we build next?" | Generative interviews or a diary study | Surveys make people rank features they have never used |
| "How many people hit this problem?" | Survey, or the analytics you already have | Qualitative can tell you a problem is real; it was never built to count |
| "Is this wording confusing?" | A quick unmoderated or five-second test | A full usability study is a week of overhead for a one-question answer |
Saying it out loud: question 4 is the sorting question, because the honest answer is "it depends" — and "it depends" on its own scores nothing. Say the dependency out loud instead: "For a usability round on one flow, five gets me most of the severe issues, and I'd rather run five twice than ten once, because the second round tells me whether the fix worked. For generative work I'd want closer to twelve, and I'd stop when two sessions in a row stop surprising me. And if the decision needs to know how many people this affects, qualitative won't carry that — that's a survey." Notice that no number in that answer stands alone — each one arrives with the situation it belongs to.
Running the study
What they're checking: whether you've done this with real participants and real constraints, or in a course.
- Walk me through a study you ran end to end.
- How do you recruit an audience that's hard to reach?
- What makes a screener bad, and how would you fix one?
- What's a leading question — and how do you catch yourself asking one mid-session?
- How do you handle consent, recordings and personal data?
Saying it out loud: question 9 has an easy first half — a question that suggests its own answer — and everyone gets that far. The half that scores is the recovery, because interviewers know that every moderator asks a leading question eventually. What varies is what happens next: "'How useful was that?' already assumes it was useful. When I catch it mid-session I don't apologise or explain, because that makes the participant self-conscious. I just re-ask it flat: 'Walk me through what you did after that screen.' The tell I watch for in myself is naming the feature before the participant has."
Question 10 is graded purely on specifics. "I get consent" is a non-answer; naming when you get it, how long recordings are kept, who can open them, and what you strip out before sharing a clip is the answer.
The thread through both sections so far: the weak answer and the strong answer contain the same knowledge. What separates them is that the strong one is specific enough to be checked — a number with its condition attached, the actual sentence you'd say to redirect a participant, how long recordings are kept rather than "we handle data carefully". An interviewer can't grade a method, only the detail attached to it. Which is why "it depends" is simultaneously the most common answer in research interviews and one of the weakest: it's the correct shape with the content removed.
Turning findings into decisions
What they're checking: whether teams act on your work, or you produce documents.
- Tell me about a study that changed a product decision.
- What do you do when stakeholders ignore your findings?
- What does your deliverable actually look like?
- A PM asks you to validate a decision they've already made. What do you do?
- Who do you involve in a study, and at what point?
Ignored findings as someone else's fault
“I presented the results, but leadership had already decided, so it didn't go anywhere.”
Every researcher has lived this, and it's often true. As an answer, though, it puts you outside the decision — which is exactly the position the interviewer is trying to find out whether you can get out of.
Ignored findings as a distribution problem
“The 40-page deck was the problem. I started posting three findings with clips into the team channel the day after each session, before any deck existed.”
Same obstacle, but now you're describing something you changed. That's the difference between a complaint and a method.
Saying it out loud: question 14 is the trap in this section. Refusing on principle sounds junior, and agreeing cheerfully sounds like you have no standards. The senior move is to find the real question hiding behind the request: "First I'd ask what happens if it comes back negative. If the answer is 'we ship anyway', then it's theatre and I'd say so — politely, but I'd say it. Usually though they're committed to the direction, not the details, and the details are where the risk actually sits. So I'd offer to test the riskiest part of the execution instead, because that's the finding they'd genuinely act on."
Question 11 has a quieter trap: pick a study where the decision changed in a way you can name. "It informed the roadmap" is what candidates say when nothing measurable happened.
Knowing what your data can't say
What they're checking: whether you'll overclaim — the fastest way for a team to stop trusting research.
- How do you tell a pattern from noise in a small sample?
- A participant is telling you what they think you want to hear. How do you notice, and what do you do?
- How do you combine qualitative findings with analytics or survey data?
- Tell me about a study that didn't go to plan.
- What can your research not tell us?
Saying it out loud: question 20 sounds like a trick, so most candidates hedge — and hedging is the wrong instinct, because the question is an invitation. State the limit flatly, then say what would close it: "Six sessions tell you the problem exists and what it looks like when it happens. They don't tell you how common it is. So I'd write 'four of six participants' rather than 'users find this confusing', and if the size of the problem is what the decision turns on, that's a survey or an analytics question, not this study." Almost every interviewer asking this has been burned by an overclaimed finding at some point. They remember the candidate who volunteered the limit before being pushed to it.
Question 19 has one requirement: the story has to continue past the thing that went wrong. "Recruiting fell through and the timeline slipped" is a setup, not an answer. What you cut, what you ran instead, and what you told the team you could no longer claim — that's the answer.
The part that isn't about research at all
Every section above is graded on the same channel: how you sound while explaining something technical to someone who doesn't share your vocabulary. Which is also the job — most of a researcher's influence happens in the ten minutes where a PM either follows your reasoning or quietly stops following it.
It's also where methodologically strong candidates lose loops. The thinking is fine; the answer just arrives as a chain of qualifications, and the interviewer loses the thread three clauses in. We wrote about that exact pattern in Why your data science answers sound confusing in interviews — different role, identical mechanism.
Practical target: take question 4 and question 20 — the two "how much can you claim" questions — and answer each out loud in under ninety seconds, with a number and a reason in the first sentence. If your answer opens with "it depends" and takes fifteen seconds to reach anything specific, those fifteen seconds are what the interviewer uses to decide how senior you are.
