What research do you give an engineer starting a new feature?

WHAT THIS TESTS: Your ability to filter signal from noise and serve engineering teams exactly what they need to build with user intent, not your ability to conduct research. Interviewers want to see that you respect an engineer's time constraints and understand that research value is measured by decisions made, not pages produced.

A GOOD ANSWER COVERS: Four things in order. First, the artifact is a validated problem statement paired with one or two critical user constraints or acceptance criteria drawn from research, not a full report. Second, the delivery mechanism is embedded in the engineer's existing workflow, such as a concise comment in Jira, a brief Loom video under two minutes, or a five-minute desk-side sync, rather than a scheduled presentation. Third, the content answers three questions explicitly: what user problem this solves, what success looks like from the user's perspective, and what tradeoffs or edge cases emerged in research. Fourth, you offer to be available for clarifications during the sprint rather than handing off a static document.

COMMON WRONG ANSWERS: Three red flags appear often. One, sending a lengthy research deck or a link to a full study and expecting the engineer to self-serve. Two, providing solution prescriptions instead of user context, which undermines engineering autonomy. Three, overloading the engineer with methodology details, sample sizes, or raw quotes that do not change implementation decisions.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle a situation where the engineer disagrees with the research findings, or how you would adapt if the sprint is starting before research is fully complete. They may also ask how you prioritize which findings to share when multiple user segments conflict.

ONE CONCRETE EXAMPLE: Imagine research for a checkout flow showed that users abandon carts when forced to create an account. The critical piece is not the full interview transcript but a one-sentence problem statement and a constraint: allow guest checkout because forced account creation drops conversion by roughly thirty percent, and users interpret it as distrust. You drop this into the ticket description and spend three minutes in sprint planning explaining the user quote that drove the finding, then remain in Slack for quick questions.