Behavioral

Could you describe a situation where you made a decision that didn't work out as planned? What did you learn from the experience?

UX DesignerData Science ManagerEngineering ManagerUX Researcher

Square

Meta

Asana

Apple

TikTok

Instacart

Did you come across this question in an interview?

Answers

Expert Answer

Anonymous

4Strong
Context: One of the most challenging situations I had to deal with recently was at freshpaint, a platform that helps health care providers protect their user data. The situation was deciding whether or not to expand features on a product we had just launched. The product scans our customers' websites periodically and reports on trackers and pixels that could jeopardize user PII data. We assumed that customers would also want the ability to select trackers in the reports and implement blockers we provide. This feature would require significant engineering resources and effort, and I wanted to ensure we were building the right thing.
Decision process: To approach this decision, I consulted with stakeholders, conducted customer interviews, and collected data for analysis. This involved engaging with our product team, engineering leads, and a sample of our customers to gather diverse perspectives and validate our assumptions.
Outcome: Ultimately, I decided to proceed with the feature, but I limited the scope of the feature to gather more feedback. This decision was difficult because, while early research showed potential, the evidence was not yet strong. I had to balance immediate resource allocation with other priorities. 
Learning: This experience underscored the importance of validating customer interests before committing significant resources. It also highlighted the value of flexibility in project scope and the necessity of securing stakeholder buy-in. Moving forward, I plan to allocate more time for preliminary research and validation phases to ensure we align our efforts with customer needs and organizational goals. Additionally, I will continue to emphasize the importance of iterative development and stakeholder communication in future projects.

Anonymous

4Strong
That’s a good question. So, in early 2023, I was working with one of the enterprise clients at Mantel and there was a requirement for a new feature where I was responsible for rolling out a new feature that allows role based access control in their data warehouse. The requirement also came with a relatively tight deadline. I have not previously worked on a similar solution, so I have reached out and consulted with a handful of SMEs at my firm and based on those discussions, I have designed and implemented a solution that fits the context. However, what I missed in this whole process was communicating the design with a broader engineering team at client side. What that meant was when we were getting ready to release this into production, one of the senior engineers had some concerns on a few aspects of the design, which implied at the time some delay in going to production. This was entirely my fault and in the hindsight, I should have circulated the design documentation with the team for review prior to development. To resolve this, leading up to the release of the feature, I worked closely with the client’s engineering team, addressing any and all concerns they have had, which thankfully were not significant changes and we were able to go into production as planned. But the biggest lesson I learned was the importance of open communication and gathering feedback before diving into the code.

Anonymous

4Strong
We had severals verticals at my current company such as A, B, C and others. We successfully implemented algorithms on A and B and want to implement on C. C and A share same infrastructure. So I prepared a plan to release algorithms for C vertical and quoted time of 3 months. The time lines are based on our knowledge gained from A also based on assumption that A and C are same except we have extra features in the listings to track. I held meeting with all stakeholders and shared the plan.
After that I started working with my team to release algorithms. During our analysis we detected that even though they appear similar there are at least 5 prerequisites which needs to be cleared before we can run algorithms. They existed because the changes went into production without notifying our team which is responsible for making sure everything displayed by the user will be tracked.
I reached out to stake holders immediately and explained the situation. I also escalated to concerned team leaders to solve the problem immediately. I got the ETA’s from the team leads and revised our plans. Our team worked closely with other teams to resolve the issues. We created new timeline and communicated with stakeholders.
In future, we will do an audit before coming up with plan especially when planning for unknown territory.

Anonymous

4Strong
During the design of a migration project from DynamoDB to Opensearch, I missed a detail that DynamoDB had enabled cross-region replication to avoid cross-region calls. This added significant latency in other regions. I hadnt explicitly called this out in my design doc so it never occurred to anyone either. We discovered this during the A/B testing and decided to add cross-region replication at a later point thereby causing a delay in the launch.
Result: This was a miss on my part for not verifying my assumptions. A good learning for me from this experience is to verify assumptions and call them out explicitly so even if I wasnt aware of some detail someone else might be. Another learning was to perform mult-region load testing instead of sticking to a single region as that woudl have helped discover this in the earlier stages as well.

Anonymous

3.6Strong
One of the challenging situations I had to deal with was working at Amazon on an in vehicle delivery application To support drivers with driver safety features and improve their productivity by automating tasks like loading daily package delivery itinerary, routing and navigation, at stop package details and more. The situation was to devise a solution for in field defect management solution. The engineering team can remotely monitor software issues and a limited set of predicted hardware issues. However, the delivery drivers are in the closest proximity to the hardware setup running this application so it was pragmatic to have them report any visible issues. This solution required some workarounds as the automated in-house tools were not going to be ready until end of the year 2025. To approach this solution, I consulted with the fleet program manager on how drivers report hardware issues for the other Amazon retrofit products in the van which was using a survey tool. The gap in the entire flow was to automate importing driver submitted issue to another internal tool that exports daily defects to the vendor for fixes. I proposed a solution to automate daily survey reports, parse those reports and build data to map to the existing internal tool format. Once this is plugged, we will be able to monitor both kinds of defects. Although, this was a temporary solution till we can leverage the internal tool planned for EOY 2025. I was able to secure 1 SDE resource to work on this proposal. However, we later found a gap where integrating with the survey tool APIs will require Amazon assessment and review since it involves critical customer data. This added significant scope creep. We had to pull out the resource and bridge the solution gap using manual survey review. What I learned from this was the importance of expanding my research work to the third party API assessment to avoid scope creep as resource allocation is expensive especially in a thinly operated team Structure. 

Anonymous

3.4Strong
This is a product which we release recently it would check the recent breaches that happened exploiting certain vulnarability in the recent past and also check the vulnarabilties in the infrastructure and then provide a score based on severity. the higher the severity the higher the chance of getting breached. This was a great hit but two of our customers came back with a specialised request, the wanted to quantify the severity in terms of revenue loss so it would help them prioratize fixes on the infrastructure. This not only required heavy research but also defining the scope as well that where it fits in. The reason it was important to think about this feature because it was a big contract and our company wanted close it before the end of Q2. I had a planning sessions with the stake holders and product team, we defined the scope of the feature and then communicated with the customer and got all the buy ins, there had to be some repriorization required to imediatle start working on the project, I had a chat with my team and transperantly explained why this was such a high priority for the company and how it aligns with the company goals. This gave boosted their morale and also they saw the advantages of adding this feature and the moral was high.

Anonymous

3.4Strong
There was a situation where a decision needed to be made about rolling a certain feature on a product line which would help with providing reports on vulnerabilities and trackers on our customers sites that would jeopardize user PII data.  The product feature included launching trackers on our customers website that would protect the customers web page from unwanted trackers tracking activities.  It was a great feature to have but one that required significant investment of resources upfront.
After careful consideration, we decided to not roll out the specialized feature to our customers, as rolling out this feature to the customers would require additional resources from the technical team.
We proceeded without launching the feature and after product launch, decided to go to the customer to understand  if they would like to have this feature installed.  The lesson learned here was that its better to carve out time in advance and gain all the valuable feedback needed from the customer before making plans for what features to launch.  Its better to be armed with enough information before hand, rather than having to make assumptions later on.  While the decision to delay the launch of the product feature was sound, it would have helped to know in advance.
In the end, we decided to go to the customers and ask whether or not they needed the feature and if they said yes, we would charge them with an additional upsell amount that would be billed back to their accounts.  A few of the customers agreed to have this additional feature for additional precaution while some customers decided not to pursue the additional expense.

Anonymous

3.4Strong
So i have this decision to upgrade one of the library in our codebase android. So, i see that this library causing is outdated and might have relation to the crash that happening for so long. So i did upgrade it, but when it is already on production then i just knew that because this library upgrade, firebase logs in firebase dashboard is not working as expected. Because of this, i had to rolled back the upgrade of library and turns out after production release, it is also not fixing the bugs. 

What i have learnt from this is always checking all edge cases, creating a documentation on pros/cons of why upgrading the libs, and rolling out carefully.

Anonymous

3.2Strong
I worked on a program that was similar in architecture to a current product.  I had schedule 4 builds to verify the design.  After the second build, the design looked good except for an EMC issue that was tested through some rework.  The program had some testing resource issues, so I called the engineering and compliance teams together to discuss skipping the third build.  I determined that it was low risk to skip the build and called together the key team members and stakeholders to go over the options.  The two options were to continue as is with a third build and work with other programs to address resource issue or to go straight to the 4th build and assume the low risk.  I went forward with going directly to the fourth build and we still had an EMC issue and needed to do another build.  What I learned form this is that even with low risk, I need to make sure we have a working system before going to the final build.

Anonymous

3Strong
I created a 30 day coaching plan that didn't work out. I learned as the performance improves, it best to revisit the plan and update as necessary for continuous improvement 
  • Could you describe a situation where you made a decision that didn't work out as planned? What did you learn from the experience?
  • Describe a time when you made a decision that didn't work out. What did you learn from this?
  • If you have ever made a decision that did not work out, what have you learned from it?
  • Could you tell me about a time when a decision you made didn't work out? What did you learn from it?
  • Did you ever make a decision that did not go as planned? What did you learn from this experience?
  • When have you made a decision that didn't turn out the way you expected? What did you learn from that experience?
  • Describe a time when you made a bad decision. What did you learn from this experience?
  • Describe an experience when you made a decision that did not pan out for you. What did you learn from this failure?
  • Can you tell me about a time when you made a decision that didn't work out? What did you learn as a result of this?
  • Tell me about a time when you made a decision that did not go well. What did you learn?
  • Have you ever made a decision that turned out to be the wrong one? Can you tell me about it and what you took away from it?
  • Tell me about a time you made a decision that did not pan out. What did you learn from this experience?
  • Share with me a time when you had to deal with the consequences of a decision that didn't work out as you expected. What did you learn from the experience?
  • Describe a decision that you regret making in the past. What did you learn from it, and how did you move forward?
  • Can you narrate a scenario where you made a decision that didn't turn out the way you wanted? What lessons did you take away from the situation?
  • Have you ever faced a situation where a decision you made didn't have the desired outcome? What steps did you take to recover from it, and what did you learn?
  • Tell me about a time when you made a choice that didn't work out as expected. How did you handle the outcome, and what did you learn from it?
  • Could you walk me through a decision that didn't pan out, what were the consequences, and what did you learn from the experience?
  • Have you ever made a mistake in your decision-making process? What did you learn from the experience, and how did you use this knowledge to improve?
  • Can you recall a decision you made that didn't have the expected result? How did you analyze the situation, and what did you learn from it?
Try Our AI Interviewer

Prepare for success with realistic, role-specific interview simulations.

Try AI Interview Now

Interview question asked to UX Researchers, Data Science Managers, ML Engineering Managers and other roles interviewing at Sendbird, Ally, Ironclad and others: Could you describe a situation where you made a decision that didn't work out as planned? What did you learn from the experience?.