Tell me about a time where you proactively proposed a change.

What steps did you take to build your proposal?

How did you gain support from stakeholders and decision-makers?

What obstacles did you overcome during implementation?

• What measurable improvements resulted from your initiative?
• How did this change benefit the team, product, or company?
• What recognition or follow-up came from your work?
• What did you learn about driving proactive change?

Sample Answer (Junior / New Grad) Situation: During my internship on a mobile app team, I noticed our onboarding flow had a 40% drop-off rate at the account creation step. The team was focused on new features, and no one had prioritized investigating why so many users were abandoning the signup process. I spent time reviewing user session recordings and noticed that users seemed confused by the password requirements.

Task: Although I was assigned to work on a settings page redesign, I felt this drop-off issue was costing the company potential users every day. I decided to investigate the root cause and prepare a proposal for how we could improve the experience. My goal was to present data-driven recommendations that would be compelling enough for the team to prioritize.

Action: I spent two days analyzing user behavior data and discovered that our password requirements weren't clearly visible until after users made an error. I created a quick prototype showing the requirements upfront and ran it by our UX designer for feedback. Then I put together a brief deck with the problem statement, data showing the drop-off, my proposed solution, and an estimate that it would take only two days to implement. I scheduled a 15-minute meeting with my manager and the product lead to present my findings.

Result: The team agreed to let me implement the change during my final week. After launch, we saw the drop-off rate decrease from 40% to 22% within two weeks, which translated to approximately 500 additional sign-ups per week. My manager mentioned this initiative in my intern review, and it helped me receive a return offer. I learned that even junior team members can drive meaningful change when they back up their ideas with data and present clear solutions.

Sample Answer (Mid-Level) Situation: As a software engineer at a fintech company, I noticed our customer support team was spending significant time manually reconciling payment discrepancies that arose from a legacy integration with our banking partner. During conversations with support colleagues over lunch, I learned they were handling 50-60 of these cases weekly, each taking 20-30 minutes to resolve. Our engineering team had no formal ticket to address this because it was considered a "support process issue" rather than a product problem.

Task: I realized this was a clear opportunity to reduce operational burden and improve customer experience, but it wasn't on any roadmap. I needed to quantify the impact, design a solution, and convince both engineering and support leadership that this was worth prioritizing. The challenge was that our team was already at capacity with committed feature work for the quarter.

Action: I partnered with a support team lead to audit two weeks of reconciliation tickets and calculated we were losing approximately 45 hours of support time weekly, costing roughly $60,000 annually in operational overhead. I then spent evenings over a week building a proof-of-concept automation tool that could detect and auto-reconcile 80% of these discrepancies. I presented this in our monthly eng-all-hands, demonstrating the working prototype and the cost savings. I proposed we allocate one sprint to productionize the solution, and I volunteered to lead the work. My manager and the VP of Support both championed the proposal, and we got approval to prioritize it.

Result: After implementing the automated reconciliation system, we reduced manual support cases by 78%, freeing up approximately 35 hours of support capacity per week. Customer satisfaction scores for payment issues improved by 15 points because discrepancies were resolved instantly rather than requiring support tickets. The tool processed over 2,000 reconciliations in its first quarter, and the support team sent the engineering team a thank-you note. I learned that the most impactful improvements often exist at the intersections between teams, where no single group has clear ownership.

Sample Answer (Senior) Situation: As a senior engineer on the infrastructure team at a SaaS company, I observed that our development velocity had been declining over the past year. Build times had grown from 8 minutes to 35 minutes, and developers were increasingly frustrated. While people complained about it in Slack, there was no formal initiative to address it because infrastructure work often gets deprioritized for customer-facing features. Our engineering org had grown from 40 to 120 engineers during this period, and the tooling hadn't scaled accordingly.

Task: I recognized this was a significant productivity drain that would only worsen as we continued hiring. I needed to quantify the business impact, build a cross-functional coalition, and design a comprehensive improvement plan that would get executive buy-in. The challenge was that this would require dedicated resources for at least a quarter, competing with product roadmap commitments. I also needed to be careful not to position this as blaming the infrastructure team, but rather as a natural consequence of growth that required investment.

Action: I started by instrumenting our build system to collect detailed metrics over three weeks, then surveyed 30 engineers about their experience. I calculated that slow builds were costing the company approximately 250 hours of engineering time weekly—equivalent to six full-time engineers. I created a comprehensive proposal outlining a three-phase improvement plan: immediate wins (parallelizing tests, upgrading CI hardware), medium-term optimizations (dependency caching, incremental builds), and long-term architectural improvements (modular microservices). I socialized the document with engineering leaders across teams, incorporated their feedback, and presented it to the VP of Engineering with specific resource asks. I volunteered to tech-lead the initiative while continuing 50% of my regular work, and I recruited two engineers from other teams who were passionate about developer experience to join part-time.

Result: We secured approval and dedicated resources for the initiative. Over three months, we reduced average build times from 35 minutes to 9 minutes, with P95 times dropping from 58 minutes to 14 minutes. Based on our metrics, we recovered approximately 200 engineering hours per week, delivering an ROI equivalent to $1.5M annually in productivity gains. Developer satisfaction with tooling increased from 4.2 to 7.8 out of 10 in our quarterly survey. The initiative became a model for how to propose and execute infrastructure improvements, and I later presented our approach at an internal engineering summit. I learned that senior engineers drive the most value by identifying and solving problems that have broad organizational impact, even when they're not explicitly assigned to do so.

Common Mistakes

• Focusing only on the idea without showing execution -- Interviewers want to see how you drove the change through to completion, not just that you had a good idea
• Not demonstrating stakeholder management -- Proactive initiatives require buy-in; explain how you influenced others without formal authority
• Lacking measurable impact -- Quantify the benefit of your initiative with specific metrics or outcomes, not just general improvements
• Making it sound easy -- Acknowledge the challenges and obstacles you faced; overcoming resistance demonstrates leadership
• Taking sole credit -- Even for proactive initiatives, acknowledge collaborators and how you built coalition
• Choosing trivial examples -- Select initiatives that had meaningful scope and impact; fixing a typo in documentation doesn't demonstrate strategic thinking

Result: We secured approval and dedicated resources for the initiative. Over three months, we reduced average build times from 35 minutes to 9 minutes, with P95 times dropping from 58 minutes to 14 minutes. Based on our metrics, we recovered approximately 200 engineering hours per week, delivering an ROI equivalent to $1.5M annually in productivity gains. Developer satisfaction with tooling increased from 4.2 to 7.8 out of 10 in our quarterly survey. The initiative became a model for how to propose and execute infrastructure improvements, and I later presented our approach at an internal engineering summit. I learned that senior engineers drive the most value by identifying and solving problems that have broad organizational impact, even when they're not explicitly assigned to do so.

Result: The initiative was approved with explicit executive sponsorship. Over the following two quarters, we established the database platform guild, created standardized connection pooling libraries, implemented automated query performance monitoring, and developed runbooks for common scenarios. We reduced database-related SEV-2 incidents from 23 in the first six months to 4 in the subsequent six months—an 83% reduction. Mean time to resolution for database issues dropped from 4.2 hours to 45 minutes because teams could leverage shared knowledge and tooling. The guild model was so successful that we replicated it for security and observability practices. I learned that staff+ engineers create leverage by identifying systemic problems that no single team can solve and building the organizational structures needed to address them sustainably.