“Tell me about a time you were asked to do something you weren’t comfortable with” is one of the harder behavioral questions, and it’s asked more often at senior levels. The interviewer is trying to learn how you behave when doing the right thing has a cost: a manager is unhappy, a deadline looks worse, a relationship gets awkward. They’re also checking something less obvious: whether you can tell a real integrity problem from a decision you just didn’t like, and whether you can talk about a sensitive situation without exposing anyone.
What the question is testing
Four qualities sit behind it.
Judgment. Can you tell a genuine problem (misreporting, hiding a security issue, ignoring a legal obligation) from ordinary disagreement about priorities?
Proportion. Does your response match the stakes? Going straight to HR over a wording issue is as worrying to an interviewer as staying silent about something serious.
Constructiveness. Did you offer an honest way to meet the legitimate need behind the request?
Discretion. Can you tell the story without naming people, clients or confidential details?
The IEEE Computer Society and ACM’s Software Engineering Code of Ethics frames the professional side of this. Among its eight principles, engineers should act consistently with the public interest, and “maintain integrity and independence in their professional judgment.” You don’t need to cite it in an interview, but it describes the standard interviewers have in mind.
The steps between silence and whistleblowing
Candidates sometimes picture two options: go along with it, or blow the whistle. In practice there’s a ladder, and most situations are settled on the first or second step.
- Ask a clarifying question; sometimes the request was a misunderstanding.
- Raise the concern privately with the person asking, and offer an honest alternative.
- Put the concern in writing, so there’s a clear record of what you flagged.
- Involve your own manager, or theirs.
- Use formal channels: compliance, security, legal, an ethics line.
- Decline to do it.
A strong answer shows you started at the bottom and climbed only as far as needed. It also shows you knew the higher steps existed.
Worked example: a status report that said “done”
Here’s an illustrative scenario. Use it to see the structure, and choose your own example carefully (see the next section on discretion).
Your manager is preparing a quarterly report for a steering committee. The draft lists a data-retention feature as complete. The feature deletes customer records after 90 days, which some customer contracts require. In fact the deletion job has only run in staging; the production rollout is waiting on a permissions review and is about three weeks away. Your manager is under pressure, and the team is genuinely close.
Weak version, over-escalated (illustrative):
My manager asked me to lie on a report, so I refused and reported it to HR the same day. I believe in doing the right thing no matter what.
Weak version, went along (illustrative):
I noticed the report was a bit optimistic, but it wasn’t really my place to say anything, and it was only three weeks, so I let it go.
The first skips every step between noticing and escalating, and casts a colleague as a villain. The second leaves a false statement about a contractual commitment in front of senior leaders.
Stronger version (illustrative; adapt to a situation you can discuss safely):
My manager shared a draft quarterly report that listed a data-retention feature as complete. It wasn’t in production yet; the deletion job had only run in staging, and we were about three weeks from rollout. Because some customer contracts required that deletion, I thought the wording could cause real problems if a customer audit asked about it.
I raised it with her privately that afternoon. I said I understood why she wanted to show progress, and suggested wording that was accurate and still positive: built and tested, production rollout scheduled for a specific date, pending a permissions review. I also offered to add a line on what we were doing to speed the review up, so the report showed a plan rather than just a delay.
She was worried it would look like we were behind, but agreed once she saw the alternative wording read as on track with a known dependency. The report went out with the accurate status. I then chased the permissions review, and we went live about two weeks later. If she’d insisted on the original wording, my next step would have been to raise it with our compliance team, because it involved a contractual commitment, and I’d have told her first that I was going to.
The candidate recognized why this mattered (a contractual obligation, not just optimism), started with a private conversation, offered an honest alternative that met the manager’s real need, helped fix the underlying delay, and knew the next step without needing to take it.
Telling the story without exposing anyone
Integrity stories carry their own risk in an interview. If you name the person, the client or the company, or share confidential figures, the interviewer will wonder what you’d say about them. Describe roles (“my manager,” “a large customer”), keep numbers vague unless they’re public, and leave out anything covered by a legal process or a confidentiality agreement.
If the only examples you have are too sensitive to tell even in outline, choose a smaller one. A story about correcting an inflated estimate in a planning meeting is less dramatic but perfectly good, and far safer than one that requires breaching a confidence to explain.
Also avoid criticizing a former employer. The story is about your choices, not about how bad the organization was.
Not every discomfort is an ethical issue
Advanced candidates show calibration. Being asked to ship with a known cosmetic bug, to work on a feature you think is pointless, or to accept a design you’d have done differently are disagreements, not ethical problems, and treating them as moral stands sounds rigid. Being asked to misreport status on a contractual commitment, hide a known security issue from customers who are owed notice, or collect data users haven’t agreed to share are different in kind.
If an interviewer pushes on where you draw the line, it’s reasonable to name it: accuracy in what you report, users’ safety and data, and legal obligations.
Mistakes that weaken the answer
- The hero story. Self-righteous framing makes the interviewer wonder how you’d treat a colleague who made an honest mistake.
- Escalating first. Skipping the private conversation looks like poor judgment.
- Vagueness. “I always do the right thing” without a story isn’t evidence.
- Oversharing. Names, clients or confidential details are a red flag in themselves.
- Justifying going along. If you did, admit it and say what you’d do now.
Follow-up questions to expect
“What if your manager had insisted?” Say you’d decline to sign off on the inaccurate version, explain why in writing, and take it to the appropriate channel, telling them first.
“Did it affect your relationship?” Answer honestly. Often a well-handled conversation builds trust; sometimes there’s a period of awkwardness worth mentioning.
“How do you decide when to go beyond your manager?” Point to the stakes: legal obligations, user harm or security issues justify it; disagreements about priorities don’t.
Interview practice: the pre-ticked checkbox
A product manager asks you to make the sign-up form’s “Send me marketing emails” checkbox ticked by default, pointing out that a competitor does it. How do you respond?
Answer and reasoning
Start by recognizing that this is more than a product preference. For users in the EU, the GDPR’s recitals state that pre-ticked boxes don’t constitute consent, so this could create a legal problem as well as an honesty one. Similar rules exist in other places. You don’t need to be a lawyer to raise it, but you do need to raise it.
Then follow the ladder. Talk to the product manager first, acknowledging the goal (more marketing sign-ups is reasonable) and offering an alternative: an unticked box with clearer copy about what subscribers get, perhaps tested against the current wording. If they still want the pre-ticked version, suggest checking with the privacy or legal team before building it, and put your concern in writing.
A strong answer avoids both extremes. It doesn’t quietly build the feature because “competitors do it,” and it doesn’t treat the product manager as acting in bad faith. It shows you understood why this crossed a line, offered a way to meet the real goal honestly, and knew which team should make the final call.