Influence and Persuasion Questions

Skills and tactics for persuading and influencing decisions and behaviors when you do not have formal authority, and for scaling influence across teams and organizations. Candidates should demonstrate how to build credibility and trust tailor messages to stakeholder priorities, use data and customer insight to make the business case, tell compelling stories that connect to outcomes, recruit allies and champions, negotiate and compromise, and create operational changes such as standards processes or tooling to lock in gains. Interviewers will probe for examples of influencing technical and non technical stakeholders resolving disagreements building consensus and measuring the impact of influence on adoption quality speed or other business outcomes. For senior levels include examples of cross organizational influence and governance for sustained change.

MediumTechnical

79 practiced

You're the author of a breaking API change that simplifies server responses but requires clients to update. Design a rollout plan that persuades consuming teams to migrate within 3 months: include communication cadence, migration guides, automated migration tooling or scripts, incentives or SLAs, staggered deprecation phases, and dashboards to show migration progress.

Sample Answer

Situation: I own an API that will simplify responses but break clients. Goal: get all consumers migrated within 3 months with minimal disruption.

Plan (high-level timeline):- Week 0: Announcement + kickoff- Weeks 1–4: Migration resources, automated tooling, and office hours- Weeks 5–8: Incentives + aggressive support, start deprecation phase 1- Weeks 9–12: Final cutover window and removal

Communication cadence:- Day 0: Executive announcement (email + Slack + docs) with migration deadline and impact summary- Day 3: Technical kickoff call + recording- Weekly: Status email + changelog diff + FAQ- Biweekly: Office hours + dedicated Slack channel- Real-time: Pager for production breakages

Migration guides & content:- Migration quickstart (1-page): request/response diffs, minimal code changes- Detailed guide: schema mapping, example requests, error mapping, performance notes, backward-compatibility edge cases- Code samples for common languages (Python/JS/Java)

Automated tooling/scripts:- Provide a CLI tool that validates client payloads against new schema and auto-transforms responses for local testing.Example validator stub:

python

# python validate_migration.py
import jsonschema, json
schema = json.load(open('new_schema.json'))
def validate(resp):
    jsonschema.validate(resp, schema)
# usage: validate(response_from_test)

- Migration library (small adapter) that can run as a compatibility shim in client apps for quick opt-in- CI job template (GitHub Actions) that runs the validator and fails pull requests that still depend on deprecated fields

Staggered deprecation phases:1. Deprecated but supported (month 1): new responses sent alongside old (dual-mode) where feasible2. Advisory-only (month 2): logs and dashboard show noncompliant clients; limited rate-limiting for old clients3. Removal window (month 3): hard cutoff; measurable rollback plan and hotfix SLAs

Incentives & SLAs:- SLA: 48-hour priority bug fix for compliant clients, 5 business days for noncompliant- Incentives: Credits on invoicing or feature-priority for teams completing migration by month 1- Escalation paths for blockers (PO + eng + platform owner)

Dashboards and metrics:- Public dashboard per consumer showing: - % of endpoints migrated - Last successful CI validation timestamp - Number of failed requests to old contract - Estimated migration blocking changes- Weekly leaderboards emailed to consuming teams- Alerts for high-error consumers and stalled migrations

Success criteria and rollback:- Target: 90% clients migrated by week 8, 100% by week 12- Have a toggle to revert new responses for up to 72 hours if systemic issues appear- Post-mortem after cutover and update SDKs/docs accordingly

Why this works:- Clear, frequent communication reduces surprises- Practical tooling lowers migration cost- Incentives and SLAs motivate teams- Staggered phases and dashboards provide safety and visibility so teams can plan and execute within 3 months.

MediumTechnical

99 practiced

You are responsible for recruiting and onboarding engineering champions from 10 product teams for a new CI pipeline. Describe the selection criteria for champions, incentives or recognition to motivate them, the onboarding tasks you'd assign, and the success metrics you'd use to evaluate the champion program over three months.

HardTechnical

61 practiced

Propose a model for a technical review board that helps make architectural decisions across multiple domains without centralizing authority. Define membership composition, decision criteria and scoring, service-level SLAs for review turnaround, a fast-path for urgent decisions, and how you'd encourage teams to partner with the board rather than bypass it.

Sample Answer

Situation: As organizations scale, architectural consistency and domain autonomy both matter. I propose a federated Technical Review Board (fTRB) that guides cross-domain architecture without centralizing decision power.

Model overview:- Membership: 7–9 members — 1 rotating representative from each major domain (product/infra/platform/data/security), 2 permanent architects (platform & enterprise), and 1 customer/PM advocate. Rotate domain reps quarterly; permanent architects provide continuity.- Governance: Board issues non-blocking recommendations by default; only formal vetoes (rare) require a 2/3 supermajority. Final execution stays with owning teams unless a veto is used.

Decision criteria & scoring:- Use a weighted scoring rubric (0–5 each): - Safety/Security (25%) - Operational cost / run rate (20%) - Scalability / performance (20%) - Developer productivity / time-to-market (15%) - Interoperability / standards (10%) - Reversibility / rollout risk (10%)- Sum weighted score; thresholds: Acceptable (<2.0) = green, Caution (2.0–3.5) = conditional changes, High-risk (>3.5) = escalated.

Service-level SLAs:- Standard review: 7 business days to initial response; full written recommendation in 14 days.- Complex/large-impact reviews: triage within 3 days; timeline agreed with owning team.- Metrics: % of reviews meeting SLA, avg time, number of vetoes.

Fast-path for urgent decisions:- 24–48 hour emergency lane: submit brief doc + business justification; emergency subpanel (3 members: owning domain rep + 2 perm architects) gives provisional approval within 48 hours. Provisional approvals expire in 30 days unless full review completed.

Encouraging partnership (reduce bypass):- Embed reviewers in PR/process: lightweight “architecture consult” tickets with office hours and asynchronous async reviews in Slack.- Make the board a service: provide templates, automated impact analysis (cost/traffic/scope), and a clear playbook that minimizes friction.- Incentives: prioritize funding for projects with board-approved architectures, faster infra provisioning, and recognition (internal blog + awards) for good partnership.- Lightweight enforcement: require board stamp for org-level billing, security attestations, or cross-domain deploys; otherwise, teams can proceed but accept risk and must log technical debt and mitigation plans.

This federated, service-oriented board balances domain autonomy with enterprise guardrails, uses transparent scoring and SLAs, and reduces bypass by making engagement low-friction and value-adding.

MediumTechnical

78 practiced

You are tasked with introducing a unit testing culture in a team that is skeptical of tests. Provide a 4-week plan with specific weekly activities (training, pairing, quick wins), recommended tooling and templates, enforcement or encouragement strategies, metrics to show early improvement, and how you would influence the team to sustain the practice after the pilot.

Sample Answer

Framework: run a 4-week pilot that combines training, hands-on pairing, quick wins, and measurable gates to build momentum.

Week 1 — Foundations & alignment- Training: 90-min workshop on unit-testing principles, TDD basics, mocking, and testing pyramid (language-specific—JUnit/Mockito, pytest, Jest).- Deliverables: team agrees on minimal “Definition of Unit Test” and adds test checklist to repo.- Quick win: add tests for 1 high-value, low-complexity module (bug-prone function).

Week 2 — Pairing & templates- Pair program: schedule 2-hour pairing sessions where an advocate writes tests with an engineer for their module.- Provide templates: PR template with “tests added” section, unit-test checklist, example test using project style.- Quick win: convert 1 recent bug fix into a regression test.

Week 3 — Tooling & CI enforcement- Integrate tools: test runner (pytest/jest/junit), mocking libs, coverage tool (coverage.py/nyc), and static analysis. Add coverage report to CI and Slack.- Soft enforcement: CI warns on PRs with no tests for modified logic; mandate tests for files in critical directories.- Quick win: enable automated flaky-test detection and quarantine.

Week 4 — Metrics, review & handoff- Run retrospective, measure impact, and document patterns.- Deliverables: playbook, recording of training, champion roster.- Transition: select 2-3 rotating test champions to continue pairing and onboarding.

Recommended tooling & templates- Tools: pytest/pytest-cov + tox, JUnit + JaCoCo + Maven/Gradle, Jest + Istanbul, Mockito/MockK. CI: GitHub Actions/GitLab CI. Coverage dashboard (Codecov or SonarCloud).- Templates: PR template with “Test impact”, unit-test checklist, sample test file, flaky-test report template.

Enforcement & encouragement- Start with “soft” nudges (PR checklist, CI warnings), escalate to gates only for critical paths.- Positive reinforcement: public callouts in standups, “Test of the Sprint” shout-out, small rewards.- Pairing and office hours for help; managers include testing goals in one-on-ones.

Metrics to show early improvement (track weekly)- Tests added per week; % of PRs including tests.- Coverage delta for targeted modules.- Mean time to detect/regress bugs (should decrease).- Flaky-test rate and build-pass rate.- Cycle time for PRs (should stabilize or improve).

Sustaining after pilot- Hand off playbook, training recordings, and champion rotations.- Bake test requirements into Definition of Done and sprint acceptance criteria.- Quarterly “test health” dashboard and 30-min brown-bag sessions to share lessons and refactor brittle tests.- Reward & career recognition for contributors who consistently improve test quality.

Why this works: quick wins build trust; pairing reduces fear and spreads skills; metrics demonstrate business value; soft enforcement lowers resistance while champions institutionalize the practice.

EasyTechnical

56 practiced

As a software engineer, list the core principles and actionable tactics you would use to build credibility and trust with cross‑functional stakeholders (product, design, support). For each principle, include a concrete example of something you would do in week 1 and something you would do by week 6 to demonstrate credibility.

Unlock Full Question Bank

Get access to hundreds of Influence and Persuasion interview questions and detailed answers.

Join thousands of developers preparing for their dream job.