At my place the rule is that devs set up things so that all that is needed to release is pressing a button. QA tests to the last minute. And at the point in time where we planned to release, the boss asks QA: Can we release this software? If the answer is "Yes", it is released. If the answer is "No" or "Don't know" then the boss decides, most likely after asking "why".
In that situation it's easy. You found a major bug. The boss asks "Can we release". You say "Don't know, we just found a major bug, this is what it does, this is when it happens, and this is how often it happens". It's up to your boss then to decide if it gets released or no.
If there are no developers present, it obviously doesn't get fixed today. If there are experienced developers present, it will also not get fixed today, because experienced developers know that trying to fix a bug at the last minute will lead to trouble.
Now if your interviewer claims that you have the responsibility and the power to make decisions: You should have been told how much of the deadline the deadline is. Are you writing software for a telescope recording pictures of the next solar eclipse? That's what I call a deadline. You ship and pray. Not shipping = no recording, shipping = maybe a recording, maybe not, but never worse than not shipping. Company signed a contract that will bankrupt it if you don't ship today? You ship and pray. Not shipping = bankruptcy, shipping = possibly upset customers. Shipping is better.
But 99% of the time, deadlines are just arbitrary points in time set by management. So you try to figure out what is the impact if you ship today, with the major bug, and what is the impact if you ship in two days time. And then decide what's better.