How to Answer "Tell Me About a Time You Pushed Back on a Request"
Why Interviewers Ask This
Not every request that lands on a data scientist's desk is well-formed. Sometimes a stakeholder asks for something based on a flawed premise, an unrealistic timeline, or a request that risks producing a misleading answer. This question tests whether you have the judgment to notice that and the professionalism to raise it constructively instead of either silently complying or refusing outright.
Interviewers are also testing whether you protect quality and rigor under pressure. It's easy to just deliver whatever was asked for; it's harder to say "I don't think this is the right question to ask" or "this timeline isn't realistic if you want it done correctly," especially to someone senior. Candidates who never push back on anything can come across as order-takers rather than analytical partners.
Finally, this question distinguishes pushback from obstruction. A strong answer shows you tried to find a path forward — an alternative scope, a faster but still valid method, a partial answer now and a fuller one later — rather than simply saying no and stopping there.
Interviewers also use this question to probe for a specific kind of backbone: whether you'll protect the integrity of an analysis even when the person asking for it outranks you. Data teams lose credibility slowly, one quietly-delivered-but-questionable number at a time, and the analysts who prevent that erosion are the ones willing to have an uncomfortable conversation before the work ships rather than let a flawed request become a flawed result with their name on it.
What a Strong Answer Includes
- A request with a real, specific problem — not just something you didn't feel like doing.
- Why the problem mattered — a risk of a misleading conclusion, an unrealistic timeline, a privacy or data quality concern.
- How you raised it constructively, including proposing an alternative rather than just objecting.
- How the requester reacted, and how you navigated any resistance.
- The resolution, stated honestly, even if it wasn't a clean win.
Example Answer (Analyst Level)
Situation: "At a mobile app company, a marketing manager asked me to pull a list of users' email addresses segmented by a sensitive inferred category — likely income bracket, based on device type and app usage patterns — for a targeted ad campaign."
Task: "I was asked to deliver the segmented list within two days for an upcoming campaign launch."
Action: "I raised a concern before starting the work: income bracket wasn't something we had explicit consent to infer and use for targeting under our privacy policy, and using inferred sensitive categories like that carried real legal and reputational risk, not just a technical concern. Rather than simply declining, I looped in our privacy lead to confirm my read of the policy was correct, and proposed an alternative to the marketing manager: segmenting by explicit, already-consented behavioral data, like purchase history and app engagement level, which could achieve a similar targeting goal without the legal risk."
Result: "The marketing manager agreed to the alternative segmentation once the privacy risk was made concrete, and the campaign launched on the original timeline using the behavior-based segments instead. The campaign performed comparably to prior campaigns using demographic-style segmentation, and the privacy lead later used the episode as an example in a training session about flagging inferred sensitive attributes before they became a larger compliance issue."
Example Answer (Senior Level)
Situation: "A VP of Product asked my team to deliver a definitive answer on whether a major redesign had 'caused' a subsequent drop in user engagement, based on a simple before-and-after comparison, with a board meeting in four days where the finding would be presented as fact."
Task: "I needed to protect the integrity of the conclusion without simply telling a VP their request couldn't be done in the timeline they wanted."
Action: "I pushed back specifically on the word 'caused' rather than the request itself: a simple before-and-after comparison couldn't rule out seasonality, a concurrent marketing campaign change, and a competitor's product launch in the same window, all of which had also happened around the redesign. Rather than refusing to deliver anything, I proposed a two-part answer within the timeline: a correlational finding, clearly labeled as such, alongside a recommendation for a proper causal analysis — a difference-in-differences comparison against a similar product line that hadn't been redesigned — that I could deliver within two additional weeks with much higher confidence. I made the risk concrete for the VP: presenting an unqualified causal claim to the board that later turned out to be wrong would be far more costly than a slightly less definitive answer now."
Result: "The VP accepted the two-part plan. The board meeting included the correlational finding with appropriate caveats, which was still useful directionally, and the follow-up causal analysis two weeks later confirmed the redesign was responsible for about 60% of the engagement drop, with the remainder attributable to the competitor launch — a much more precise and defensible number than the original request would have produced. The VP later specifically asked for my team to review similar causal claims before they went to the board going forward."
Common Mistakes
- Pushing back on something trivial or personal, like disliking a deadline, rather than a real risk to quality or accuracy.
- Refusing outright without offering an alternative. A strong answer shows you tried to find a path forward, not just that you said no.
- Making the pushback sound combative in the retelling. Emphasize the constructive, evidence-based framing you actually used.
- Skipping the resolution. If the story doesn't say what actually happened next, the interviewer can't tell if the pushback worked.
Related Questions
- How to Answer "Tell Me About a Time You Disagreed With a Stakeholder"
- How to Answer "Tell Me About a Time You Missed a Deadline"
- How to Answer "Tell Me About a Project With Messy or Incomplete Data"
For more on how interviewers evaluate judgment under pressure, see our culture fit interview questions.
Frequently Asked Questions
How do you answer 'tell me about a time you pushed back on a request'?
Describe a request that was reasonable on its face but had a real problem, such as a flawed premise, a privacy or quality risk, or an unrealistic timeline, explain how you raised the concern constructively while still trying to help, and share the resolution, whether the request changed, was delayed, or you found an alternative.
Is pushing back the same as disagreeing with a stakeholder?
They're related but not identical — disagreeing with a stakeholder is usually about differing interpretations of evidence, while pushing back on a request is more often about the request itself being flawed, unrealistic, or risky, and a strong answer to this question focuses on protecting quality or feasibility rather than winning a debate.
What if I've never pushed back on a request before?
Think of a time you raised a concern about scope, timeline, data quality, or feasibility even if you eventually did the work as originally requested — interviewers are mainly listening for whether you speak up when something seems off rather than silently complying with requests you have real reservations about.
Ready to test your skills?
Practice real Culture Fit interview questions from top companies — with solutions.
Get interview tips in your inbox
Join data scientists preparing smarter. No spam, unsubscribe anytime.