What research do you give an engineer starting a new feature?
This tests distilling research into actionable engineering guidance. A strong answer gives the engineer a validated problem statement and user context, delivered in the ticket or a five-minute sync. A red flag is handing over a full research deck or raw notes.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
What is the most effective way to deliver research findings to an engineer who is beginning work on a new feature?
- a.Send raw interview transcripts and detailed notes for the engineer to review independently
- b.Add a concise problem statement with user constraints to their ticket and offer sprint-time supportCorrect
- c.Prescribe the specific technical solution to ensure the research insights are implemented correctly
- d.Schedule a formal presentation to walk through the full research deck and methodology details
Why? this is the answer
The correct approach respects the engineer's time by embedding a validated problem statement directly into their workflow and staying available for questions, rather than overwhelming them with documentation. Option D is tempting because thoroughness feels rigorous, but a full deck or presentation shifts the burden of filtering signal from noise onto the engineer, which is a common red flag.
Just read this? Test yourself on what you have been reading.
Read the original → koji.so
- #ux research
- #stakeholder communication
- #problem statement
- #research ops
- #product delivery
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ux research — each one lists the topics its interview covers.
See open roles