Evaluating Customer Experience and Overcoming a Major Unforeseen Obstacle

This behavioral segment of a phone screen for a senior software engineer asked two questions. Answer each with one real story from your own work, structured as situation, task, action and result. The interviewer pushed on the core of each question: a story that only touched it at the surface was challenged, and in one case the candidate was asked to switch to different stories. ### Clarifying Questions - For the customer-experience question, do internal customers, such as other teams that depend on my service, count, or should the story be about external end users? - For the obstacle question, is the interest in a technical obstacle, an organizational one, or either? - Should each story fit in a few minutes, leaving room for follow-up probes? ### Part 1 — Evaluating customer experience How do you evaluate customer experience? Walk through a time you had to judge whether something you built or operated was actually working well for its customers, and what you did with that judgment. In the reported interview, a story built around collecting feedback directly from customers did not satisfy the interviewer, who treated the evaluation itself as the point of the question. ```hint Feedback is an input Gathering opinions is only the first step. Be ready to say what you measured, what you compared it against, and how you decided whether the experience was good or bad. ``` ```hint Close the loop Pick a story where the evaluation changed what the team did, and where you can show how you checked that the change helped. ``` #### What This Part Should Cover - A definition of a good experience for this specific customer, expressed as observable signals - How the signals were collected, validated and reconciled when they disagreed - A decision or change that the evaluation drove, and the measured outcome - How the evaluation kept running after the change ### Part 2 — A significant obstacle you did not anticipate Tell me about a time you ran into a major obstacle that you had not foreseen. What was it, and what did you do? In the reported interview, the interviewer judged the first story's obstacle not significant enough and had the candidate retell the answer with several bigger obstacles, so the size of the obstacle is part of what is being assessed. ```hint Make the stakes visible Choose an obstacle that put a commitment at real risk, such as a launch, a deadline, customers or data, and be ready to say what would have happened if you had not acted. ``` ```hint Why it was missed Expect to be asked why you did not see it coming, and what you changed afterwards so that it, or problems like it, would be caught earlier. ``` #### What This Part Should Cover - Stakes and scope that make the obstacle clearly significant for a senior engineer - Why it was not anticipated, and how it was detected - The candidate's own decisions, the options weighed, and who else was brought in - The result, and the lasting change that came out of it ### What a Strong Answer Covers - Stories whose scope fits a senior role: cross-team impact, ambiguity, and consequences that outlast the project - Clear ownership: what the candidate personally decided and did, separate from what the team did - Quantified results, including what did not go well - Backup stories ready, so the candidate can switch to a stronger one when the interviewer pushes back - Specific, calm answers to probing questions instead of repeating the same summary ### Follow-up Questions - Which signal in your customer-experience story turned out to be misleading, and how did you find out? - What did you tell stakeholders while the obstacle was still unresolved, and when? - If the same obstacle appeared on your next project, what would happen differently? - When a customer-experience improvement and its engineering cost pulled in opposite directions, how did you decide?