Tell me about an unpopular project you worked on

What specific steps did you take to understand why the project was unpopular?

How did you approach building support or addressing concerns?

What trade-offs or decisions did you make to move forward?

How did you balance listening to feedback with maintaining project momentum?

• What was the ultimate result of the project?
• Did you gain support over time, and if so, how?
• What measurable impact did the work have?
• What did you learn about handling resistance and building consensus?

Sample Answer (Junior / New Grad) Situation: During my internship at a fintech company, I was assigned to work on migrating legacy documentation to a new knowledge base system. The engineering team was resistant because they were comfortable with the old wiki and saw this as extra work that distracted from feature development. Many engineers openly expressed frustration in team channels about having to learn a new tool.

Task: My manager asked me to lead the content migration for my team's documentation and to help encourage adoption among the engineers. I needed to migrate at least 50 documentation pages and get at least 80% of the team actively using the new system by the end of my internship. The challenge was that I had no formal authority and the team didn't see immediate value in the change.

Action: I started by scheduling 1-on-1 coffee chats with engineers to understand their specific concerns, and I learned they worried about losing time on their sprint commitments and that the new tool seemed more complex. I created a simple 2-page quick-start guide and recorded short video tutorials showing how common tasks were actually faster in the new system. I also migrated the most frequently accessed docs first and added helpful tags and search functionality that the old wiki lacked. I regularly shared these wins in standup and celebrated early adopters who gave feedback.

Result: By the end of my internship, we had migrated 65 documentation pages and achieved 85% active usage of the new system. Three engineers who were initially the most resistant actually became advocates after seeing how much faster they could find information. My manager shared that the documentation project became a model for other teams in the company. I learned that understanding the "why" behind resistance and demonstrating quick wins is more effective than just pushing for change.

Sample Answer (Mid-Level) Situation: At my previous company, I proposed a major refactoring of our authentication service that had accumulated significant technical debt over three years. The project was unpopular because it would take two quarters, wouldn't add any user-facing features, and required other teams to update their integration code. Product managers were concerned about opportunity cost, and some engineers questioned whether the refactoring was really necessary since "the system works fine."

Task: As the tech lead for the identity team, I was responsible for improving the reliability and maintainability of our auth infrastructure. I needed to secure approval and resources for this project, then execute it while minimizing disruption to partner teams. My goal was to reduce authentication-related incidents by 70% and cut our mean time to resolution for auth bugs in half.

Action: I built a comprehensive business case documenting the $200K+ annual cost of auth-related incidents in terms of engineering time, customer support escalations, and potential security vulnerabilities. I presented data showing we had spent 600 engineering hours in the past year on hotfixes that wouldn't have been needed with cleaner architecture. I negotiated a phased approach where we'd deliver incremental improvements each month rather than a big-bang release, which gave stakeholders more confidence. I created detailed migration guides and offered pairing sessions to help partner teams update their code with minimal effort. I also set up a dedicated Slack channel for questions and sent weekly updates showing concrete progress and early wins.

Result: We completed the refactoring in 7 months, one month ahead of schedule, and reduced auth-related incidents by 75% in the following quarter. Partner team integration time decreased from an average of 3 days to 4 hours due to the improved API design. Three months after completion, the project gained recognition in our engineering all-hands as a model for handling technical debt strategically. I learned that data-driven storytelling and reducing perceived risk through incremental delivery are key to gaining support for unpopular but necessary technical work.

Sample Answer (Senior) Situation: I led an initiative to consolidate our microservices architecture from 47 services to 12 domain-oriented services at a rapidly growing healthcare tech company. This was deeply unpopular because each team had built their services with different patterns, and the consolidation meant some teams would lose ownership of their systems while others would inherit unfamiliar code. Engineering leadership was split on whether this was the right investment, and team morale was impacted by concerns about reorganization and job security.

Task: As a senior engineer and architecture lead, I was accountable for driving this consolidation to reduce operational complexity, improve system reliability, and enable faster feature development. I needed to build a coalition across seven engineering teams, secure executive buy-in for an 18-month roadmap, and manage the technical execution while addressing the organizational and cultural challenges. My success criteria included reducing operational incidents by 60%, decreasing deployment complexity, and maintaining team retention through the transition.

Action: I started by running a series of architecture workshops where teams could voice concerns and collaboratively define the target state rather than having it imposed top-down. I worked with engineering leadership to establish clear principles: no forced team reorganizations, teams could volunteer to lead consolidated domains, and we'd prioritize developer experience improvements early to build momentum. I created a detailed migration framework with well-defined phases, rollback plans, and success metrics for each milestone. I personally pair-programmed with engineers from different teams during complex migrations to build trust and knowledge sharing. I implemented a transparent decision-making process using RFCs for major architectural choices and held monthly town halls to address questions and showcase progress. When resistance remained strong from two teams, I pivoted to let them move at their own pace on a different timeline while the other teams proceeded.

Result: Over 18 months, we successfully consolidated to 14 services (slightly more than planned, based on domain analysis), which reduced our incident rate by 68% and cut average deployment time from 45 minutes to 8 minutes. Developer satisfaction scores increased by 23 points as engineers appreciated the clearer service boundaries and reduced operational burden. Importantly, we maintained 96% team retention through the transition, and two engineers who were initially the most resistant to the change became champions who presented our approach at our annual engineering conference. The flexible, people-first approach became a template for how we handle large-scale technical transformations. I learned that the success of unpopular technical initiatives depends as much on organizational change management and psychological safety as on technical excellence.

Sample Answer (Staff+) Situation: I initiated a company-wide shift from project-based teams to platform-based teams at a 500-person engineering organization, which fundamentally changed how we allocated resources and measured success. This was extremely unpopular initially because it disrupted existing team structures, changed how product managers partnered with engineering, and required redefining career paths and promotion criteria. VPs were concerned about the risk to ongoing customer commitments, mid-level managers worried about losing headcount and influence, and many engineers were anxious about being moved to unfamiliar domains.

Task: As a staff engineer and technical strategy advisor to the CTO, I was responsible for architecting this organizational transformation to address systemic issues: we had reached a scale where project-based teams created unsustainable dependencies, duplicated infrastructure work, and led to fragmented system ownership. I needed to build consensus across executive leadership, design the target operating model, develop the transition plan, and guide the organization through 12-18 months of change. Success meant improving deployment frequency by 3x, reducing cross-team dependencies by 50%, and doing so while maintaining business momentum and keeping attrition below 10%.

Action:

Result:

Common Mistakes

• Dismissing concerns as irrational -- failing to demonstrate genuine curiosity about why people opposed the project and treating resistance as something to overcome rather than understand
• Taking opposition personally -- interpreting pushback as a personal attack rather than as valuable feedback about risks, timing, or communication gaps
• Focusing only on technical merit -- emphasizing why the project was "objectively good" without addressing the legitimate organizational, timing, or resource concerns that made it unpopular
• No evidence of adaptation -- telling a story where you pushed forward with the original plan without showing how you incorporated feedback or adjusted your approach based on concerns
• Vague outcomes -- not providing specific metrics or concrete examples of how perceptions changed or what impact the unpopular project ultimately had
• Claiming universal support -- suggesting everyone eventually agreed, which often sounds unrealistic; showing that you succeeded despite some ongoing skepticism is more credible

Result: Over 18 months, we successfully consolidated to 14 services (slightly more than planned, based on domain analysis), which reduced our incident rate by 68% and cut average deployment time from 45 minutes to 8 minutes. Developer satisfaction scores increased by 23 points as engineers appreciated the clearer service boundaries and reduced operational burden. Importantly, we maintained 96% team retention through the transition, and two engineers who were initially the most resistant to the change became champions who presented our approach at our annual engineering conference. The flexible, people-first approach became a template for how we handle large-scale technical transformations. I learned that the success of unpopular technical initiatives depends as much on organizational change management and psychological safety as on technical excellence.