Deadline in Scrum

As an Agile transformation consultant, I completely agree with your response to the interviewer. Scrum does not have specific deadlines but has a time-bound iteration called a Sprint. It is the responsibility of the Development Team to meet the Sprint Goal, and if the team cannot complete it, the incomplete items move back to the Product Backlog.

The Product Owner manages the Product Backlog and prioritizes it based on the stakeholders' requirements. The PO should work closely with the Development Team to ensure that the backlog items are well-defined, achievable, and meet the objectives.

In some cases, external deadlines may exist, such as contract obligations or market demands. In such a scenario, the PO should work with the Development Team to ensure that the specific deadline can be met. Still, they should ensure that the team does not compromise on the quality of the product or their technical standards.

The main goal of Scrum is to promote transparency, inspection, and adaption. Thus, setting unrealistic or arbitrary deadlines may harm the development process and ultimately negatively impact the product's quality or outcome.

If it is obvious that the goal cannot be reached in the form it was planned for sprint, you should communicate to the team to re-think/re-scope the current sprint plan and current sprint goal to at least reach some clear result in a direction of the goal. In short, you should scope the goal to be more achievable. Cancelling the sprint in this case would be a mistake that would lead to unpleasant situation for all involved parties. "We realised that we cannot reach goal A by the end of the sprint, so we have re-scoped it to goal B that still allows us to start beta-testing and helps achieve A in the next sprint." is much better than "we realised that we cannot reach goal A, so we have cancelled our sprint and we are all in a very awkward situation now".

Now, about time-bound projects. Even in Scrum, we regularly face the case when time is a major requirement. You can pretty much treat this as a critical non-functional requirement for a feature - "deliver by ...". This is especially true for changes in laws (like GDPR a few years ago) or changes in third party services (like GA4 API update recently).

Product owner's responsibility is to solve users needs, not to implement the specific solution that that is provided to product owner by the client. Is it valid for a client to ask product owner to cover need A by date B? Yes, absolutely. The role of product owner here would be to find a balanced solution that covers client's need still allowing to cover it by required date.

And if requirements are delivered to you as a complete solution - you are not actually a product owner.

"If it is obvious that the goal cannot be reached in the form it was planned for sprint, you should communicate to the team to re-think/re-scope the current sprint plan and current sprint goal to at least reach some clear result in a direction of the goal. In short, you should scope the goal to be more achievable."

Actually its the team who should do it, not the Scrum master alone.

There is no requirement "to reach some result"

First of all "some result" does not count in Scrum. Either there is a increment or not; and if not the incomplete items go back to product backlog and issue is addressed at next retrospective. As simple as that.

Let me elaborate again. The situation when the team cant or does not meet definition of done of fails to deliver increment is not called "not meeting the deadline", because expiration of Sprint isn't deadine of any kind.

That's regular situation in Scrum, helping team to learn scoping velocity better and reducing long term  risks.

This situation is called "being not able to meet the sprint goal" or "not being able to make increment by the end of the Scrum.

Choice of words is very important thing, and Scrum framework particularly focuses on it, emathasing that if the proper vocabulary and terminology will not be used while running Scrum project, it may harm whole outcome.

My interviewer choose the word "deadline"

Eventually only thing in Scrum which can be considered "deadline" is an external deadline-either the bounding contract obligation of the Organization-the firm who has hired the Scrum team to deliver the product the client at certain date, without a possibility of prolongation, or market situation which dictates release of the product towards certain date.

Not meeting this deadline will make product obsolete because it's market value will be lost-which eventually means expiation of the product, and cancellation of scrum by Product owner.

In this event Scrum team should report its readiness for new product to the Organization, or re enter the labor market for new jobs if organization does not need or does not want to finance their services any longer

"Product owner's responsibility is to solve users needs, not to implement the specific solution that that is provided to product owner by the client. Is it valid for a client to ask product owner to cover need A by date B? Yes, absolutely. The role of product owner here would be to find a balanced solution that covers client's need still allowing to cover it by required date."

This is a right description of PO work, and good example of PO doing his work well.

But this situation is not called "not meeting deadline". In short it can be described "PO is negotiating new deal to extend the deadline an delivery condition for mutual benefit"

I was asked what PO should do if "team cant meet the deadline and everyone is certain about it"-sharp.

Considering that word "deadline" has quite straightforward meaning, there are no buts, ifs, of whys about it: it means if team does not meet deadline the whole Product loses its value to zero(why does this happen is another story-it can be market situation contract obligation or changes in laws, like you mentioned). And once product loses value to zero(disregard what work was done by the team, and how good it was) it ceases existing, making whole Scrum pointless.

Scrum is THE PART of Agile. Discussing difference is not logical.  It's like discussing difference between the hand and the whole body.

Yes the hand is certainly NOT the body, but it is not some independent thing or matter either