Your role and pitfalls as an engineer note-taker in interviews

WHAT THIS TESTS: This question tests whether you view UX research as a collaborative team sport or a siloed academic exercise. The interviewer wants to know if you understand that engineers benefit from observing research first-hand and that your role is to learn how to leverage the researcher’s expertise to make better decisions, not to dominate the process.

A GOOD ANSWER COVERS: A strong answer hits four things in order. First, state that your role is to observe and experience the research first-hand so you can later leverage the researcher’s expertise to make better engineering and product decisions. Second, mention that you should only be included in situations where research findings can lead to tangible changes for users, not rigid requirements like a banking flow locked in by regulation. Third, note that before participating, there should be mutual education time: the researcher educates you on how to use research, and you educate them on engineering constraints. Fourth, acknowledge that research should feel accessible and practical, so you might reframe it as a usability review or customer discovery rather than an academic exercise.

COMMON WRONG ANSWERS: Wrong answers reveal a siloed or impatient mindset. A major red flag is saying you do not need to observe sessions first-hand and would rather just read a summary later. Another red flag is skipping the education phase and jumping straight into collaboration. Treating research as an academic or daunting exercise rather than an accessible team activity is also a miss. Finally, insisting on conducting research for features that are locked in by inflexible constraints shows poor judgment in choosing research opportunities.

LIKELY FOLLOW-UPS: The interviewer might ask how you would decide which features merit research versus direct implementation. They might ask how you would convince a skeptical engineering teammate to observe a session, or how you would partner with a researcher to make findings actionable for the sprint backlog.

ONE CONCRETE EXAMPLE: Imagine your team is building a new mobile game feature. The researcher invites you to observe three user interviews. Before attending, you meet with the researcher for education time to understand the goals and learn how the findings could change the feature design. During the sessions, you observe silently and take notes on user behaviors that relate to technical feasibility. Afterward, you discuss with the researcher which user pain points are cheap to fix and which require architectural changes, then prioritize the quick wins for the next iteration.