## Driving a Project Forward Despite Internal Opposition Walk me through the most significant project you've worked on. Tell me what it was, what **your** role was, and what the most challenging part was. Then go deeper on one specific aspect: when you started the project, **someone pushed back or opposed doing it**. Who opposed it, and why? How did you understand their objection, and how did you ultimately persuade them — or otherwise get the project moving? ```hint Pick the right story Choose a project where *you* drove the effort and personally owned the persuasion — not one where a manager cleared the path for you. The interviewer is probing your influence *without authority*, which is exactly what they expect from a senior engineer. ``` ```hint Name the objection honestly A strong answer treats the opposition as legitimate, not as an obstacle to steamroll. Be specific about *who* (a senior peer? another team? your manager? a stakeholder?) and *what their actual concern was* (risk, cost, priorities, prior failure, ownership). Steel-man their position before you describe winning them over. ``` ```hint Show how you changed minds Lean on the mechanics of persuasion: data, a small prototype/proof-of-concept, a scoped pilot, addressing their concern directly, or finding the shared goal. "I convinced them" is weak; "here is the specific thing that moved them" is strong. ``` ### Constraints & Assumptions - This is a ~30-minute hiring-manager / behavioral round for a **senior** software-engineering role; depth and ownership are expected. - Answer in **STAR** form (Situation, Task, Action, Result) and keep most of the time on *your* actions and the persuasion itself. - Specifics matter: name the stakeholders (by role), their actual objection, the concrete evidence or step that shifted them, and a measurable outcome. - Assume the interviewer will interrupt to ask "why did they oppose it?", "who specifically?", and "how did you convince them?" — your story should already contain those answers. ### Clarifying Questions to Ask - Do you want a project where the opposition was technical (architecture/approach), or one where it was about priorities/resourcing/politics? (Either can work — pick the one with the cleanest persuasion arc.) - Are you more interested in how I built consensus, or in the technical substance of the disagreement? - Should I focus on a single decisive moment of opposition, or the sustained effort to keep a skeptical group bought in over the life of the project? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - What if you had *not* been able to win them over — would you have dropped the project, escalated, or proceeded anyway? How do you decide? - Looking back, was the skeptic partly right? Did their objection change the design for the better? - How do you tell the difference between healthy pushback you should incorporate and resistance you should push through? - Tell me about a time the persuasion *failed* — you couldn't get a key stakeholder on board. What happened, and what did you learn?