Tell me about a time you had to negotiate or close a difficult deal
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you handle meaningful disagreement when something important is on the line and another party is not immediately aligned. They are looking for your ability to understand the other side's incentives, shape a workable proposal, and stay constructive under pressure. A strong answer shows you did more than argue your position: you navigated tradeoffs, adapted your approach, and helped land an outcome.
Key Insights
- You do not need a literal sales deal. In engineering interviews, a 'difficult deal' can be an agreement on scope, timeline, design direction, resourcing, priorities, or risk tolerance as long as something meaningful had to be negotiated.
- Don't tell a story where success came from simply repeating your opinion louder or escalating quickly. You should show that you understood why the other party resisted and changed your approach based on that understanding.
- Make the stakes and the constraints explicit. If the interviewer cannot tell why the negotiation was genuinely difficult or what each side was trying to protect, your story will sound smaller and less credible than it may actually have been.
What interviewers probe atlevel
Top Priority
Strong junior stories show flexibility: you found a compromise or alternate path instead of treating negotiation like winning.
Good examples
🟢Once I understood the concern, I suggested shipping the core behavior now and leaving the more complex validation for the next iteration, which both of us were comfortable with.
🟢I offered to add a small test case and a short walkthrough so the reviewer could be confident in a lighter-weight version of the change.
Bad examples
🔴I just kept explaining the benefits until they eventually agreed, which showed I was persistent.
🔴I compromised by doing what they wanted first and planning to add my version later without really discussing it.
Weak answers equate persistence with effectiveness; strong answers show the candidate changed the proposal to make agreement possible.
Valuable
Example answers atlevel
Great answers
In my first year, I was building a small reporting feature and a designer asked for several validation rules and edge-case states that I hadn't accounted for. Once I started implementing it, I realized adding all of them would likely push us past the release date, so I set up a quick conversation instead of just saying no. I asked which parts were most important, and I learned their biggest concern was preventing users from submitting obviously broken data, not every possible error case on day one. I proposed that we launch with the core validation and one clearer error message, and then add the less common cases in the next iteration after we saw real usage. We agreed on that plan, I updated the ticket and test cases, and we shipped on time without the user confusion they were worried about.
At my internship, I was helping a small nonprofit migrate their donor spreadsheet into our new system, and they wanted a bunch of custom fields added before they would agree to move forward. I was initially trying to fit everything into the first version, but after talking with them I realized their real concern was not losing data they used for tax receipts and follow-up calls. I explained what we could deliver quickly, what would take longer, and showed them a sample import so they could see their most important information would still be preserved. We agreed to launch with the core fields first and keep the extra custom fields as a second phase once the team had settled into the new process. That conversation helped us keep the project moving, and it also taught me that being honest about tradeoffs can build more trust than saying yes to everything.
Poor answers
One time I had to close a difficult deal with QA because they wanted more testing time before we shipped a feature I worked on. I explained that the code was straightforward and I had already tested it locally, so I pushed pretty hard to keep the original date. They eventually agreed, and we released it that day. For me the key was being confident and not overthinking every concern when you know the work is ready.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Mid January, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.