I have gone to a few interviews at project-based companies for software developer positions. One common question they tend to ask, which is also the hardest to answer, is:

Given a scenario where you have a project on hand, and the deadline given is in X days, and you know that no matter how hardworking you are trying to pull up all nighters everyday, you will never meet the deadline. And the client mentioned that it is a hard deadline.

What answer should I give? What do they expect to hear?

  • Possible duplicate of Tough curveball interview questions
    – gnat
    Commented Aug 16, 2019 at 11:46
  • 9
    Isn't this a secret probing whether you will agree to do all-nigthers and unpaid overtime on a regular basis?
    – Val
    Commented Aug 17, 2019 at 8:14
  • X days? Unless X is a big number, the problem should have been known long before then. Commented Aug 17, 2019 at 16:54

12 Answers 12


What answer should I give?

This answer is for a software developer role (no direct reports):

The simple answer here is the truth. And in this specific instance if you know the deadline isn't going to be met, delivering the truth sooner rather than later is best.

Basically they want to know you are not going to hide the fact that you aren't going to make your deadline and aren't afraid to ask for help.

  • 8
    @Andrew, I'm unclear on your comment. I understand the point being made but why would you assume as a SME your job is absolutely not to communicate your knowledge of the situation you best know?
    – SemiGeek
    Commented Aug 16, 2019 at 15:30
  • 47
    @Andrew That's not a very good solution to that situation. This is a very real question because this happens all the time. People say deadlines are hard yet meeting that is unrealistic. All you can do is push-back and tell the truth. You can't just quit every time this arises.
    – Brad
    Commented Aug 16, 2019 at 20:01
  • 2
    Some companies may want you to lie and string the client along until they have had enough, but I would imagine the majority of reputable companies would expect the truth. Ideally, this should be discussed with management before the client.
    – David
    Commented Aug 17, 2019 at 4:22
  • 1
    @Andrew No, it really isn't. Commented Aug 17, 2019 at 19:51
  • 5
    This answer is spot on. It's really as simple as this. Actually a little concerned at how much controversy there's been over the question - do y'all not just tell the truth in situations like this? Why not? Commented Aug 17, 2019 at 19:55

You will never get a job like that by repeating an answer you were given on a site like this. You need to learn how to answer that question in your words using your experience and examples that you have actually been part of. That said, you can find a better answer to give them next time. They key is to understand why they are asking. They believe they know what to do and not to do in that situation, and they want to see if you do too.

A good answer will contain two things. First, you should easily be able to list your options: telling the client the deadline will not be met, dropping some part of the work, those sorts of things. And this list should not include things that won't work, like adding people to the project. Second, you should be able to explain how you would choose among those options and how you would communicate in the situation. If you just say "I would X" without any explanations of why X instead of Y, it's not a good answer.

If you're applying for a project management position, they will expect somewhat different options and thought processes than if you're applying as a developer working without the support of PM, but the basic "I would have a choice of X or Y, I wouldn't consider A or B, and I would choose X or Y based on Z" will still be there.

If you don't have a good answer for this and have been asked it more than once, get yourself a good answer. Surely you have faced this? Even if you saw someone else handle it rather than handling it yourself? What worked, what didn't, what have you done in that situation before? Get better at telling that story.

This is also an opportunity, after answering the question, to talk about how important it is not to get into that situation, and what you do to prevent it. This might be regular status meetings, frequent releases, resisting scope creep, monitoring progress, or any number of other techniques you have learned in your job. The interviewer wants to know what you know how to do.

  • Hint, the PM “iron triangle” is scope, schedule, resource... Flex one of those or punt early. They are basically asking if you know the basics of project management, which apparently you don’t but you can learn...
    – mxyzplk
    Commented Aug 16, 2019 at 11:58
  • 2
    What does "punt early" mean in this context? Commented Aug 16, 2019 at 12:05
  • "this list should not include things that won't work, like adding people to the project" - having more people working on a project making it later is called Brooks' law, but there are exceptions. Otherwise, taken to an absurd degree, the optimal number of people on any project with any deadline would be 1 person. Also, are you suggesting one should just entirely omit things that won't work? If so, how would the interviewer know you've discounted those as possibilities (as opposed to potentially just not having thought of it)? Commented Aug 16, 2019 at 23:30
  • 5
    I might say something like "adding more people rarely works, so that's not an option" and then go on to possible things. But the main point is not to say "I would get 5 people from another team to come and join us" because that doesn't work. Once the project is late, adding more people will just make it later. That's not the same as having a deadline. Commented Aug 16, 2019 at 23:41
  • 2
    @mxyzplk - Well ... I've been very successful as a project manager and didn't know what the "iron triangle" was, though I do understand that scope, schedule and resources are critical. Kate's answer was - in my opinion - flawless. This is a classic "lose-lose scenario" question which isn't aimed at testing a DEVELOPER'S project management skills, but testing their thought processes. Commented Aug 16, 2019 at 23:44

As a software developer, it's not my job to discuss that sort of problem with the client, and as a software developer there's nothing that I can do personally to fix the problem.

So the only sensible course of action is to contact the program manager as soon as possible to make them aware that there is a problem, and discuss with them what can be done to bring the project back on track.

The answer may be to assign more people to the job, to negotiate a later deadline with the customer, or several other options. But the decision isn't mine to take.

  • 12
    This answer shows exactly why people ask this question. What if you were interviewing at a place that didn't have project managers and expected software developers to handle this? This answer would eliminate your application from further consideration. (And you'd probably feel relieved about that.) Commented Aug 17, 2019 at 1:44
  • 4
    @KateGregory I believe your criticism cuts both ways. What if you were interviewing at a place that did have people who manage the relationship with the client? It would be pretty bad form to deliver this news to the client directly and without coordinating with the team or other responsible parties. I would be livid if one of my devs told this sort of thing directly to the client.
    – John Wu
    Commented Aug 17, 2019 at 6:46
  • Yes, you're right. The answer shows the way the person being interviewed expects their workplace to be. And for ANY answer, some workplaces will be a great fit for that and some will not. If the company expects PMs to handle this and developers to stay out of it, this answer will get you hired. Commented Aug 17, 2019 at 12:22
  • 2
    @KateGregory Then the interview has succeeded in its task, in both directions. Commented Aug 17, 2019 at 19:54
  • That was the point of my original comment. Sorry if it wasn't clear. Commented Aug 18, 2019 at 0:22

Or what do they expect to hear?

They are looking to see how you think through and process this sort of question.

They don't want to see you try to tell them what you think they want to hear. They don't want to hear a canned answer.

It's hard, but try not to guess what they want to hear. Instead, listen to the question, think it through, and answer honestly. Try to put yourself into the posed situation, and tell them how you would react.

And if you have actually encountered the situation, make sure you indicate that you have, what you did, and if you would do the same thing again.

  • 3
    I am skeptical of this. I suspect that there is one, or maybe a small handful, of answers that are far more "correct" than all others. Commented Aug 16, 2019 at 20:31
  • 6
    @SouthpawHare - No, because the goal really isn't "the answer". "Impossible questions" are always about examining the candidate's thought processes. Were I in this situation, I'd ask the interviewer 2 or 3 questions to understand the nature of the company's projects and clients, and then tailor my answer to that set of circumstances. It wouldn't be to recite one of 2 or 3 canned answers like "I'd negotiate a new feature set which was possible within the allotted time and maximum benefit to all parties." Which sounds a lot like "I want a puppy." Commented Aug 16, 2019 at 23:53

Funny that this was one of the questions, my answer to which (I think) gave me one of my previous jobs. It was not a good job, because such situations were common there. But it was relevant for that job (and should give me a hint not to take it).

I mentioned what we did on one of the projects I participated:

We were in an impossible situation: in a small company, we needed the contract to keep us alive for next few months. It was extension of our (accounting) system which we wanted to implement, but deadline to complete it was impossible. So we started implementing it anyway, with our best guesses how to do it, and published a big document with many questions asking how exactly they want the new functionality to be implemented. And we told them that it would take X months after we will receive the final answers.

Guess what: it took them months to agree between themselves what exactly they want, while we were implementing out best guess. We got the contract, got some milestone payments from the customer. In most cases we guessed right, few cases we had to redesign, few features were postponed to phase two, but company survived to fight another day.

I am not sure if you can just fake such answer (because this is a true war story, any follow-up question might disclose you as a fake if you did not lived through it).

In live-or-die situation, you are forced to take chances with hopes that you will have luck, because if not, company will die anyway. Nobody writes about the hundreds startups which failed, only the successful are mentioned. See survivorship bias - you assume you will survive.

  • Great strategy, which highlights well one of the most common causes of deadline misses: the customers don't know what they want, they just know they want it, and the developers' managers don't ask the customer for important details (in order to make the sale more likely), so to the developers the requirements almost create more doubts than they solve, so the developers will make too many guesses and assumptions. If after setting the deadline the customer takes months to agree between themselves what exactly they wanted, having the developers guess that instead will hardly be better. Commented Aug 17, 2019 at 11:19
  • @SantiBailors - I am not saying that trying to guess is "better". I am saying that guessing and developing, while customer is pondering the answers is better than losing the contract which company needs to survive. Commented Aug 17, 2019 at 18:31
  • I think my point came across to you upside down compared to what I meant, which was definitely not that trying to guess is better; by "will hardly be better" I wanted to mean that it's very unlikely that it will be better. Commented Aug 18, 2019 at 6:44

According to Team Software Process (by Carnegie Mellon University), you need to communicate with the Stakeholders as soon as the team knows that the deadline cannot be met. This allows all interested parties to either replan, remove features or do something to resolve the issue (of not meeting the deadline).

According to the Mythical Man Month, by Fredrick Brooks Jr., adding more people to a project will not shorten the schedule.

In terms of project management, there is the triangle with sides of scope, time and budget. If one of the sides changes (in length), the other two must also change.

So, to answer the interviewer's question:

  1. Calculate new deadline based on present circumstances. Determine probability of successfully meeting deadline.
  2. Calculate duration required to complete remaining requirements. Determine probability of meeting deadline with this technique.
  3. Calculate new deadline based on adding resources to the project. Do this for 1 person up to 5 people. Determine probability of meeting deadline with this technique.
  4. Call a meeting with the Stakeholders to discuss the situation and replanning. Use the information from items #1, #2 and #3 above.

The information from #1, #2 and #3 should come from the team members (doing the work). They are closest to the project and can give information with the highest degree of certainty.

IMHO, only plan overtime sessions if the completion time is small. There is no guarantee that overtime will improve the quality of the product; sometimes overtime can introduce more issues and extend the schedule.

At one shop I worked at, requirements were removed from the project in order to reduce the schedule.


This would be my answer, if my role was a Project Manager:

If I don't think we can meet a deadline, the first thing I need to establish is what it would take in terms of manpower and other resources in order to meet the target.

Then I should go to my management, and together we can perform an assessment if spending the additional resources is worthwhile in order to get the project completed.

If management pushes against additional resources, I would go to the client and explain the situation, and recommend a reduction in scope of the work, until such a point as the work becomes feasible in the timeframe. I would work with the client to prioritise the work in order to ensure client impact is minimised.

If the client refuses to reduce the scope or discuss work priority, I would analyse the requirements carefully to see what is the set of deliverables that limits the damage to the reputation of the my company, and in addition, any financial penalties that would apply. I would make it very clear to the client what will be delivered in that timeframe, in order to mitigate the client impact.

I would imagine in some situations, clients may be more receptive to renegotiation when they realise that they will not get everything they want, and they want to have better control over what they do get. They may also be willing to push back the "hard" deadline.

Obviously, it's regrettable that any project would get to a point where there is a major surprise towards the end. Ideally we would be tracking progress, and that would allow us to modify the scope of the work in a gradual manner to ensure the most important requirements are met.

  • Sorry I did not clarify earlier that I am interviewing for software developer position.
    – tnkh
    Commented Aug 16, 2019 at 12:33
  • 1
    @tnkh Then the situation is a lot easier for you. You need to discuss and be honest with your supervisor. Commented Aug 16, 2019 at 12:35
  • I agree that the question is most appropriate for the project manager rather than a software developer. You just can't have every developer on a project talking independently with a client. Even if you're a one man shop then you're doing multiple roles, on e as a project manager and one as a developer.
    – MaxW
    Commented Aug 17, 2019 at 0:23

I've got a question along these lines before, so it's not that uncommon. In my opinion the only correct answer is along these lines:

Somebody screwed up somewhere to get here at all, now we'll make the best of it by organizing an emergency meeting and see what is possible instead of what isn't.

Knowing you're going to fail and doing it anyway would be the wrong answer. If it can't be done, it can't be done. Yet you will often encounter situations that look like they're asking you to do the impossible.

The absolute key here is to find what is possible and work from there. This is not a question about hard software engineering. This is a question about managing expectations, dealing with the unexpected and keeping a project together.

It also means they're looking for more than someone who just writes code. They're looking for someone with a whiff of managerial capabilities or are at least finding out if you got those. Because no matter what answer you give them, how you give them the answer will tell them a lot about how you think about projects.

A possible follow-up might be (either as a question from them or as an answer from you if they expect long answers) how to handle the fallout and reducing the chance of it happening again.


So there's a deadline, and it is impossible to meet. Whatever you answer, whatever you do, one thing that won't happen is you meeting the deadline. Here's what you and your manager can do:

  1. Tell your manager as soon as possible to give them a chance minimising the damage. Missing a deadline with $10,000 financial damage is an awful lot better than missing a deadline with $100,000 financial damage.

  2. Don't panic, calm down, and calm everyone else down. Seriously. I have seen grown ups flapping around like headless chickens in those situations. I've done the same once when I was a lot younger and learned from that. Now I know that instead of flapping around and not getting anything done, you change the problem in your mind from the unsolvable "How do I meet a deadline that is impossible to meet" to "How do I minimise the damage".

  3. The method that doesn't work is trying to rush, or trying to add more people. What does help is getting people to do secondary things. For example if you are supposed to write code and try it out, you write the code and someone else tries it out. Another method that your manager can use is improve your ability to work more hours. There's a nice hotel 100m from my workplace. I can do more hours if my boss pays for me to stay at that hotel, and orders healthy food to arrive at lunchtime, and more healthy food to arrive at 5pm. On one occasion, someone had to be at my home to get a furniture delivery. My bosses wife did that. She wasn't happy, but my boss needed me to work. That kind of thing is also quite motivating.

  4. There are two obvious methods to get finished earlier: Reduce quality, and reduce features. That needs to be discussed.

  5. There is an obvious method to meet a deadline that people often forget (because see point 2): Move the deadline. Very few deadlines are unmovable. See Peter M.'s ingenious method. Congratulations if you can pull that off. Easier is often to just negotiate. That's likely done one or two levels above you. But if you make it clear to the customer that there's no chance he's getting the promised thing at the promised time, they have the choice of extending the deadline or not getting anything.

  6. I hope it doesn't come to this, but the first rat to jump off a sinking ship has the best chances to survive.


Between a rock and a hard place? Get on the other side of the rock. Offer the client a demo of partial functionality in 1/2 the time to their deadline. You will catch them off guard, and pull them into the conversation. Bringing them in weekly to discuss what functionality has been increased that week, you will quickly learn that their requirements were not 100% of what they needed, and by the time that deadline rolls around you may well have "something" that they can use, even if its 80% functional, you are way ahead of your waterfall competition.


I feel some of the others are constructing too weak a version of "hard deadline".

I have never been a PM but on more than one occasion I've had to tell the truth to the CEO when everybody else, including the PM who should have known, was silent. We have certain legal requirements, and when the requirements of the law change, we must change our code to match, and the deadlines are set by the government. The truth was "That day is already gone."

I had been there a long time. I knew how long it would take from internal engineering release to production. I had just looked at the test logs and knew how long the testing would take. I had a really good estimate for number of items sent back to failed testing, used a low figure for turnaround time, and a really good figure for retesting time. I added up the numbers and it said we had -1 days to continue development. I don't remember how the explanation of all this went (which did happen immediately), but I just remember my opening statement.

Due to source control limitations that management didn't care about before, we could not decide to drop completed features to relieve testing time so these things could not be improved upon.

Unfortunately I couldn't tell them how many days they could realistically expect, so they didn't accept my answer. But at the internal demo of the regulatory required features the next week management asked for sweeping changes to them. Go figure.

We ended up delivering a month and a half late.


Taking everything said at face value, the best option is to consider any more work on this project as a waste of time and instead skip to the next project. Which is not the decision of a software developer to make.

This does not happen in real life. I've been in situations such as this and the solution basically was to give the customer what they wanted to see. Which changed from unreadable data (not quite the right format but not intentionally so) to fake data (generated or test data passing the writing routines) to stuff prepared with manual intervention to hand-selected working examples to the real thing.

This may involve working with the actually contracting company in order to convinve downstream recipients to also play the waiting game: stuff needs to look as if there is so little missing that it would make little sense to abort.

I've taken subcontracts from incompetent contractors with good business relations and paying well where the main priority was to always keep your ass covered, calculate deadlines safely and produce working and well-documented material that you got them to sign off on every time since the governing project was most definitely headed for a crash landing and you did not want to be the scapegoat under the collapsing landing gear.

This garbage fire was cancelled about two years after the "hard" deadline, long after I've delivered and collected. This is the reason that the right response to sure-fire failure of a hard deadline rarely is to give up: some deadlines may trigger penalties one wants to avoid. But the deadlines killing a running project for good are rare and the final decision may very well fall at a time you are not aware of.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .