← Back to companies
[ OK ] Loaded —
[ INFO ]
$ cd
$ ls -lt
01
02
03
04
05
$ ls -lt
01
02
03
04
05
user@intervues:~/$
How did you approach the conversation and prepare for it?
What techniques did you use to understand their concerns?
How did you present your perspective or alternative view?
What data, examples, or reasoning did you use to make your case?
Sample Answer (Junior / New Grad) Situation: During my internship at a fintech startup, I was working on improving our user onboarding flow. My mentor, a senior designer, was strongly against adding a tutorial walkthrough, believing users would skip it and it would delay our launch by two weeks. She had seen similar features fail at previous companies and was vocal about her concerns in our planning meetings.
Task: As the intern assigned to the onboarding redesign, I needed to either convince her that the tutorial was valuable or find an alternative solution. Since she was the design lead and had final approval on UI changes, I couldn't move forward without her buy-in. I knew I needed to address her specific concerns rather than just push my idea.
Action: I scheduled a one-on-one coffee chat to understand her past experiences with failed tutorials. After listening, I realized her concerns were valid—poorly designed tutorials are often ignored. I then conducted a quick competitive analysis showing how successful apps implemented optional, contextual tutorials rather than forced walkthroughs. I also ran a prototype test with five users and recorded their feedback, which showed strong positive response to a lightweight, skippable version.
Result: After reviewing the user testing data and seeing how I'd incorporated her feedback about keeping it optional, she agreed to move forward with a modified tutorial design. The feature launched on time, and our completion rate for the onboarding flow increased by 34% in the first month. More importantly, she later told me she appreciated that I'd listened first and used data to address her specific concerns, and she became a strong advocate for my work during the rest of my internship.
Sample Answer (Mid-Level) Situation: As a product manager at a B2B SaaS company, I was leading a project to rebuild our API documentation. Our lead backend engineer was strongly opposed to using an interactive documentation platform, arguing it was "over-engineered" and that simple markdown files would suffice. He had significant influence with the engineering team and his resistance was blocking progress on a project that customer success had been requesting for months.
Task: I needed to get him on board because his team would be responsible for maintaining the documentation, and without his support, the project would either fail or create ongoing tension. My goal was to address his underlying concerns about complexity and maintenance burden while still delivering the improved developer experience our customers needed.
Action: I started by setting up a working session where I asked him to walk me through his concerns in detail—turns out he'd had bad experiences with documentation platforms that became outdated and created technical debt. I acknowledged these were legitimate risks and proposed we run a four-week pilot with just two API endpoints. I also showed him how the platform's auto-generation features would actually reduce maintenance work compared to manual markdown updates. During the pilot, I made sure to gather his feedback weekly and adjusted our approach based on his suggestions about simplifying the setup process.
Result: By the end of the pilot, he became one of the project's strongest advocates. He presented the results to the engineering team himself, highlighting how the interactive examples reduced support tickets by 28%. The full rollout was approved, and he volunteered to lead the technical implementation. Our API documentation NPS score improved from 42 to 78 within three months. The experience taught me that resistance often signals valid concerns that, when addressed collaboratively, can lead to better solutions than my original proposal.
Sample Answer (Senior) Situation: As Engineering Manager for a payments platform, I proposed consolidating our three separate fraud detection services into a unified ML-based system. The director of our risk operations team was firmly against this change, concerned that a single system would be a single point of failure and that our fraud analysts would lose the specialized tools they relied on. Given that risk operations was a critical stakeholder and this director had 15 years of domain expertise, his opposition could derail the entire initiative, which was projected to save $2M annually in infrastructure costs.
Task: My responsibility was to either gain his support or redesign the proposal to address his concerns without compromising the core business value. I needed to transform this from a technical architecture decision into a collaborative problem-solving exercise. The challenge was that his concerns were rooted in real operational risks, not just resistance to change, so I couldn't simply push forward with data about cost savings.
Action: I scheduled a series of deep-dive sessions where I asked him to show me exactly how his team used the existing tools and what failure scenarios kept him up at night. I discovered his real concern wasn't the consolidation itself but losing visibility during the transition and having no rollback plan. I revised the proposal to include a six-month parallel-run period where both systems would operate simultaneously, with clear success metrics and rollback triggers. I also worked with my team to design a new dashboard that gave his fraud analysts even more visibility than they had before. Most importantly, I made him a core member of the architecture review process and incorporated his team's requirements into our design from the ground up.
Result: He shifted from opponent to co-sponsor of the project. During the leadership review, he presented the risk mitigation plan himself and advocated for the budget allocation. The parallel-run approach he'd pushed for actually helped us identify three edge cases we would have missed, preventing potential fraud losses estimated at $400K. The unified system launched successfully, achieved the projected cost savings, and reduced fraud detection latency by 60%. His team's satisfaction scores with the new tooling were 4.7/5. This experience reinforced that the best technical decisions emerge from genuinely integrating domain expertise, even—especially—when it initially appears as opposition.
Sample Answer (Staff+) Situation: As a Staff Engineer at a major e-commerce company, I proposed migrating our monolithic checkout service to an event-driven microservices architecture. The VP of Engineering, who had built much of the original system, was publicly skeptical, calling it "unnecessary complexity that will destabilize our highest-revenue flow." His position carried enormous weight—he had operational responsibility for site reliability, and checkout represented 40% of company revenue. Several engineering directors were waiting to see how he positioned himself before committing their teams' resources.
Task: I needed to shift his perspective from seeing this as a risky architectural fad to recognizing it as a strategic enabler for business capabilities we couldn't build otherwise. The challenge was that his concerns about stability were completely valid—checkout downtime cost us roughly $50K per minute. I couldn't dismiss his skepticism or circumvent his authority; I needed to genuinely address the risk profile while demonstrating the opportunity cost of not evolving our architecture. This required changing not just his opinion, but his mental model of the problem space.
Action: I invested three weeks in deep research before engaging him directly. I analyzed our incident history and found that 70% of checkout outages were actually caused by tight coupling in the monolith, not by distributed system issues. I built a detailed migration plan that sequenced changes to reduce risk—starting with read-only services and leaving core transaction logic until we'd proven the approach. I then requested a two-hour working session with him and our CTO where I presented not just the technical plan but a business case showing how the current architecture was blocking three major initiatives on the product roadmap, representing an estimated $15M in potential annual revenue. Critically, I framed the conversation around his goals: improving reliability and enabling business growth. I also acknowledged where his skepticism had identified real gaps in my initial proposal and incorporated his suggestions around observability requirements and circuit breaker patterns.
Result: He became the initiative's executive sponsor. He presented the revised architecture plan to the board and secured $4M in additional engineering investment. More importantly, he volunteered to personally lead the incident response planning and reliability review process, which strengthened the technical approach significantly. The migration took 18 months, during which checkout availability actually improved from 99.7% to 99.95%. The new architecture enabled the launch of features like buy-now-pay-later integration and multi-merchant checkout that drove $23M in incremental revenue in the first year. The VP later told me that the turning point was when I'd used the incident data to reframe the risk question—he'd assumed the monolith was stable, but the data showed it was already fragile. This taught me that changing senior technical leaders' opinions requires addressing both the technical merits and the business context, while genuinely respecting the experience behind their initial skepticism.
Common Mistakes
- Treating disagreement as obstruction -- failing to recognize that skepticism often reflects valuable experience and legitimate concerns
- Leading with your solution instead of their concerns -- jumping to persuasion before deeply understanding why they hold their negative view
- Relying solely on authority or data -- not building the relationship foundation necessary for genuine perspective shifts
- Declaring victory too early -- confusing compliance with genuine opinion change; real buy-in shows up in their advocacy when you're not in the room
- Making it a win/lose dynamic -- positioning the conversation as proving them wrong rather than collaboratively finding the best path forward
Result: He became the initiative's executive sponsor. He presented the revised architecture plan to the board and secured $4M in additional engineering investment. More importantly, he volunteered to personally lead the incident response planning and reliability review process, which strengthened the technical approach significantly. The migration took 18 months, during which checkout availability actually improved from 99.7% to 99.95%. The new architecture enabled the launch of features like buy-now-pay-later integration and multi-merchant checkout that drove $23M in incremental revenue in the first year. The VP later told me that the turning point was when I'd used the incident data to reframe the risk question—he'd assumed the monolith was stable, but the data showed it was already fragile. This taught me that changing senior technical leaders' opinions requires addressing both the technical merits and the business context, while genuinely respecting the experience behind their initial skepticism.