Advocacy and Constructive Disagreement Questions

Share examples of times you disagreed with leadership, colleagues, or customer requests and advocated for your perspective. Demonstrate healthy disagreement: listening to others' views, building evidence for your position, expressing concern diplomatically, accepting decisions even when you disagree. Show that you can influence outcomes through persuasion rather than authority. At mid-level, demonstrate both advocating for your views and respecting final decisions by others.

EasyBehavioral

43 practiced

Describe a time you gave difficult feedback to a colleague about their approach or code. How did you prepare, what language and structure did you use to keep the conversation constructive, how did you check for understanding, and what was the outcome?

EasyBehavioral

40 practiced

Define "constructive disagreement" in the context of a software engineering team. Describe specific behaviors you would demonstrate (active listening, building evidence, expressing concerns diplomatically, accepting final decisions) and give a brief real or hypothetical example showing those behaviors and the outcome.

HardTechnical

34 practiced

Two senior engineers are stuck in a heated disagreement about architecture and it's blocking the project. As an impartial staff engineer or manager, outline how you'd mediate: preparation questions, neutral framing of options, evidence collection, deciding who has final authority, and follow-through to restore trust and prevent recurrence.

Sample Answer

Situation: Two senior engineers disagree about architecture (e.g., microservices vs. modular monolith) and the conflict is blocking delivery.

Preparation questions (before meeting):- What are the exact technical proposals (diagrams, interfaces, deployments)?- What constraints matter: timeline, team size, operational cost, SLAs, data consistency?- What are measurable success criteria (latency, deployment frequency, MTTR, dev velocity)?- What assumptions underlie each proposal (scale, traffic, ownership boundaries)?- Has either side prototyped or measured anything?

Neutral framing of options:- Summarize both proposals using the same template: problem statement, proposed design, trade-offs, risks, required effort, rollback plan.- Use non-judgmental language: “Option A achieves X by doing Y; risks include R.”- Create a decision matrix of criteria (business impact, risk, cost, time-to-value) and score both options together.

Evidence collection:- Request short artifacts: architecture diagrams, cost estimates, performance models, small PoC results, failure-mode analyses.- Pull metrics: current load, growth forecasts, deploy cadence, incident history.- Time-box experiments: build a prototype or benchmark for the riskiest assumption (48–72 hours).

Deciding who has final authority:- Clarify decision-making model up-front (RACI): who is responsible, accountable, consulted, informed.- If this is a product/engineering trade-off, product or engineering manager may have final say; for infra/safety-critical, SRE/arch lead might decide.- If stakeholders disagree on authority, escalate to agreed role (e.g., tech lead or director) using the documented criteria and data collected.- Ensure the final decision is framed as “chosen for these reasons” not “my preference.”

Follow-through to restore trust & prevent recurrence:- Communicate decision and rationale in a blameless meeting; document in an Architecture Decision Record (ADR).- Assign concrete next steps, owners, and success metrics; set checkpoints (e.g., 2-week review).- Offer credit to both engineers for contributions; if a side’s approach is deferred, schedule a timeboxed follow-up or iteration where their concerns are validated.- Introduce process improvements: decision templates, required data for major architecture choices, pre-mortem practice, and a clear escalation path.- Run a short, blameless retro after implementation to capture lessons and update the ADRs and team norms.

Example (concise):- I’d run a one-hour joint session where each engineer presents a 10-minute summary using the template, then walk through a decision matrix. If pros/cons still tie, I’d propose a 72-hour spike to test the riskiest assumption. If time pressure prevents a spike, I’d apply the RACI model and the documented criteria to make a timely choice, then document it and plan remediation checks to keep both engineers engaged and trust intact.

This approach balances data, tempo, fairness, and clear accountability while building processes to reduce future conflicts.

HardTechnical

62 practiced

You need more telemetry to debug production issues, but legal and privacy teams worry about collecting PII. Draft a proposal balancing observability and privacy: which signals to collect or anonymize, retention policies, access controls, sampling strategies, and how you'd demonstrate compliance and minimize legal risk.

Sample Answer

Situation: We need richer telemetry to troubleshoot production failures, but Legal/Privacy prohibit collecting PII. Below is a technical proposal that balances observability and privacy.

Proposal summary- Collect high-value non-PII signals by default; collect PII-only when strictly necessary under strict controls and consent.

Signals: what to collect and how- Collect (keep full): service metrics (latency, error rates), infrastructure metrics (CPU, memory), request metadata (HTTP method, path template, status), trace IDs, sampling span data, feature-flag state.- Collect (anonymize/pseudonymize): user identifiers → hash with a per-service salt (HMAC-SHA256) stored separately; IP addresses → truncate to /24 or store as cryptographic prefix-preserving tokenization; email/phone → never store raw; store presence flags or hashed token if needed for debugging.- Avoid collecting content: never capture full request/response bodies, form fields, or files. If required for a specific bug, use on-demand scrubbing via a secured “redact pipeline” and short-lived access.

Retention policy- Short TTL for high-cardinality telemetry: traces and logs with identifiers 30 days by default; aggregated metrics retained 13 months for trend analysis.- Sensitive traces or logs (that include pseudonyms) retained 7 days unless approved extension requested and logged.

Access controls and audit- Role-based access control (RBAC) for telemetry: developers get aggregated/hashed views; only senior on-call or approved investigators can request access to raw or de-anonymized data.- Just-in-time approval workflow: access requests require ticket, business justification, and approval by Privacy officer; access granted with timebound tokens (e.g., 1–8 hours).- All access logged in immutable audit trail with SIEM forwarding and anomaly alerts for unusual patterns.

Sampling and cost/risk reduction- Adaptive sampling: 100% of error traces for 5xx; 10% for successful traces; tail-sampling to retain slow/rare paths.- Dynamic capture toggles: feature to increase sampling for specific service/route when investigating incidents; must record why change made and auto-revert.- Aggregation: roll-up logs to counts/histograms to reduce need for raw data.

Demonstrating compliance / minimizing legal risk- Privacy-by-design: document data flow diagrams, data classification, and threat model for telemetry.- Data Protection Impact Assessment (DPIA) for telemetry changes; share with Legal and Privacy teams.- Provide proof-of-controls: architecture diagrams showing pseudonymization, KMS use for salts, retention enforcement, RBAC/policy screenshots, and audit logs.- Maintain CI checks: linter/gate that prevents accidental logging of PII (logging library enforces redact markers).- Contracts & consent: update privacy policy and, if required, user consent flows; ensure third-party observability vendors sign DPA and support encryption-at-rest/in-transit.

Operational steps (practical)1. Implement structured logging + centralized pipeline (Log router with scrub/transformation stage).2. Integrate HMAC-based pseudonymizer library across services; store per-service salt in KMS.3. Configure sampling and retention in tracing backend (e.g., Jaeger/Tempo + Elasticsearch) and enforce TTLs automatically.4. Build access request UI with ticketing and auto-audit.5. Run DPIA and tabletop with Legal/Privacy; pilot for 2 weeks; iterate.

Trade-offs- Hashing preserves ability to correlate across sessions but is irreversible without salt—good for privacy but still considered pseudonymous in some jurisdictions. Work with Legal to decide if additional consent required.- Lower sampling reduces debug fidelity; dynamic toggles and error-first sampling mitigate risk.

This approach provides operational visibility needed to debug production while minimizing exposure of PII, ensuring legal compliance, and creating auditable controls.

MediumTechnical

40 practiced

Your team is split between adopting a new full-stack framework and incrementally improving the current stack. Create a concise case study you'd present to the organization: evaluation criteria, metrics to collect (training cost, dev velocity, performance), a rollout/migration strategy, and how you'd mitigate training and hiring concerns.

Sample Answer

Situation: Our product team is divided: some want to adopt a modern full‑stack framework (F), others prefer incremental improvements on the existing stack (S). I prepared this concise case study to guide a data‑driven decision and a low‑risk migration path.

Evaluation criteria (ranked):- Business impact: customer-facing features enabled, time-to-market- Developer productivity: onboarding time, cycle time, PR size- Technical health: performance, reliability, testability, security- Cost: training, hiring, infra changes, licensing- Risk: migration effort, rollback complexity

Metrics to collect (baseline + 3/6/12 months):- Training cost: hours per dev × fully burdened hourly rate- Dev velocity: story cycle time, completed story points, PR throughput- Code quality: bug rate, rollback frequency, test coverage- Performance: p95 latency, memory/CPU, startup time- Operability: build/test times, CI flakiness- Hiring: time-to-hire for roles requiring F vs S

Rollout / migration strategy:1. Pilot: pick a greenfield module or internal tool; build full feature with F for 1–2 quarters.2. Measure: compare metrics vs equivalent S implementation.3. Strangler pattern: incrementally replace backend pieces behind API gateways; keep interoperability via contracts.4. Dual‑run and dark launch critical paths; feature flags for quick rollback.5. Cutover in small slices per service; freeze consumer contracts and migrate clients iteratively.

Mitigating training & hiring concerns:- Training: allocate 2-week bootcamps + pair programming; create internal docs, recipes, and a “migration handbook”; rotate mentors.- Hiring: recruit for transferable skills (systems thinking, testing); offer short contractor bursts for expertise; amortize hiring cost by building internal champions.- Risk buffer: maintain support SLA for legacy stack during transition; budget for 6 months of dual maintenance.

Recommendation: run a 3‑month pilot with strict metric goals. If F shows >20% net gain in velocity or enables strategic capabilities that S cannot, expand migration following the strangler approach; otherwise invest in targeted improvements to S.

Unlock Full Question Bank

Get access to hundreds of Advocacy and Constructive Disagreement interview questions and detailed answers.

Join thousands of developers preparing for their dream job.