Tell me about a time you pushed back on a requirement or technical direction.

Push back on a risky requirement

Builds a story about challenging a risky requirement while staying constructive and product-oriented.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I pushed back on a requirement to let support staff impersonate users without much friction. The goal was valid: faster troubleshooting. The risky part was invisible privileged access. I explained that impersonation needed a session boundary, reason, expiry, audit trail, and blocked sensitive actions. Then I proposed a smaller version that let support view the account context without allowing destructive changes.

Full answer below

Practice focus

Constructive pushback, risk framing, alternatives, product judgment, communication, and alignment.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Healthy pushback is not stubbornness. It shows the candidate can protect the product while still helping the team move.
I pushed back on a requirement to let support staff impersonate users without much friction. The goal was valid: faster troubleshooting. The risky part was invisible privileged access. I explained that impersonation needed a session boundary, reason, expiry, audit trail, and blocked sensitive actions. Then I proposed a smaller version that let support view the account context without allowing destructive changes.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I tried to make the pushback actionable. I did not just say no; I separated the support need from the risky implementation. We agreed on a first version with explicit start and stop, visible banner, actor and target identity in audit logs, and no payment or permission changes during impersonation. That still solved most support cases while avoiding the highest-risk behavior. I also asked what deadline or customer pressure was behind the request, because that changed which safer alternative was realistic.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Saying no without offering an alternative.
Arguing from preference instead of user or business risk.
Accepting a dangerous requirement to avoid tension.
Missing the real problem behind the requested solution.

Tell me about a time you pushed back on a requirement or technical direction.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Go deeper

Tech stacks

Skill areas

Suggest an improvement