Walk me through a big problem or issue in your organization that you helped to solve.
Asked at:
Cohesity
Meta
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to understand the scale of problems you naturally gravitate toward, how much ownership you take when things are unclear, and whether you can drive a problem toward a real resolution rather than just contribute a piece. They are also checking whether your example matches the scope expected for your level and whether you can explain a messy situation with clear judgment, prioritization, and follow-through.
“Tell me about a major problem facing your team or organization that you personally helped resolve.”
“What's a significant challenge your group was dealing with, and what role did you play in fixing it?”
“Describe a high-impact issue in your company that you took ownership of. How did it unfold?”
“Can you walk me through a messy or important problem at work that you helped get under control?”
Key Insights
- You do not get much credit for merely noticing a problem. Show how you diagnosed it, chose where to focus, and stayed with it until the situation materially improved.
- A 'big problem' is not just about drama or outage severity. It can also be a chronic organizational drag like slow delivery, unclear ownership, or recurring quality issues, as long as you explain why it mattered.
- You should make your role legible. In multi-person efforts, explicitly separate what the organization did from what you personally drove, influenced, or decided.
What interviewers probe atlevel
Top Priority
Show that you did some real thinking to understand the issue before jumping to a fix, even if others helped shape the approach.
Good examples
🟢I compared successful and failing cases, narrowed the issue to one input path, and used that to guide the fix.
🟢I started with a few possible causes, checked each one with data and reproduction steps, and ruled out the wrong directions before making changes.
Bad examples
🔴The system was failing, so I changed the obvious piece that looked wrong and we deployed it.
🔴We didn't know why it was happening, so I tried a couple of fixes until one seemed to work.
Strong answers show a simple but credible reasoning process; weak answers are mostly guess-and-check.
Even with guidance, show that you did more than execute assigned steps—you helped move the problem forward end to end.
Good examples
🟢After noticing the pattern, I gathered examples, proposed a likely cause to my mentor, and owned the code and validation work for the fix.
🟢I coordinated with QA to reproduce the issue, updated the failing path, and monitored the results after release so we knew the problem was actually resolved.
Bad examples
🔴My lead told me to investigate logs, then told me what code to change, and I implemented that fix.
🔴I surfaced the issue quickly to the team and then waited until the senior engineer came back with the solution.
Strong answers make the candidate an active driver within their level of support; weak answers portray them as mainly a messenger or implementer.
Pick a problem that was genuinely significant within your local scope and show why it mattered to users, the team, or delivery.
Good examples
🟢A recurring production issue was creating support tickets every week, and I took ownership of investigating the pattern and helping land a durable fix with guidance.
🟢Our release was at risk because a key workflow kept failing in edge cases, and I focused on stabilizing that path because it was blocking customer use.
Bad examples
🔴The biggest issue was that our local setup instructions were confusing, so I rewrote part of the README and that solved it.
🔴We had a bug in a low-traffic internal page, and I fixed it quickly because nobody else had time.
Strong answers show a problem with visible consequences in the candidate's immediate scope; weak answers mistake any completed task for a 'big problem.'
Valuable
Even in a small-scope story, show that you understood why others responded the way they did instead of treating them as blockers.
Good examples
🟢I learned that the tester was worried about a regression in a related flow, so I added coverage there and that got us to a better fix.
🟢My teammate was hesitant because they'd seen a similar change break something before, so I walked through the edge cases with them and adjusted the plan.
Bad examples
🔴QA kept sending the issue back, but they were being overly strict, so I just proved the code was fine.
🔴Another engineer disagreed with my fix, but they hadn't looked closely enough, so I went with my approach after talking to my lead.
Strong answers show curiosity about others' concerns; weak answers reduce disagreement to others being difficult.
Example answers atlevel
Great answers
One big issue on my team was a recurring checkout error that only happened for certain discount combinations, and it was creating support tickets every few days. I was still fairly new, but I noticed the pattern, gathered examples from logs, and worked with a more senior engineer to narrow it to one validation path that handled promotions inconsistently. I took ownership of reproducing it reliably, made the code change, and added a test for the edge case because that scenario hadn't been covered before. After we released it, I kept checking the error dashboard for the next couple of weeks and the failures dropped off. What made it feel meaningful to me was that it wasn't just fixing one bug; it removed a recurring customer issue and gave the team better coverage in a risky area.
Our analytics team relied on a nightly data report that regularly took three hours to finish and often failed, so people would show up in the morning and spend time restarting jobs instead of doing their work. I volunteered to take a look, traced the delay to a single database query that was scanning an entire table, and worked with a senior engineer and the DBA to add a targeted index and simplify the query logic. I also added a small cache for intermediate results and wrote a short runbook plus a Slack alert so the on-call person would be notified before it became a problem. After those changes the job runs in about 10–15 minutes and rarely needs intervention, which has noticeably reduced morning fire drills. It felt great because I helped restore predictable mornings for the team and learned practical skills for diagnosing performance and coordinating cross-team fixes.
Poor answers
A big issue in my organization was that onboarding for our service was kind of confusing. I rewrote part of the setup guide and shared it with the team, and after that new engineers had fewer questions for me. It was a good example of solving a broad problem because documentation affects everyone. I like examples like that because they show initiative and I didn't need much help to get it done.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid March, 2026
Cohesity
Staff
Early March, 2026
Meta
Senior
Late October, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.