How do you make technical decisions under pressure?
What is being assessed
A calm trade-off approach instead of heroics: can you quickly pick a "good enough" solution, record your assumptions and not leave a landmine behind. A red flag is "I did whatever worked, we'll sort it out later" with no "later".
Answer skeleton
- Criteria: user risk, deadline, reversibility. A reversible decision can be made fast; an irreversible one (data format, public API, database schema) deserves a pause even under pressure.
- Narrow the problem: the minimal change that removes the issue; a feature flag so you can roll back without a release.
- Record assumptions: a comment in the code, a ticket to "finish properly", a message to the team — so the temporary doesn't become permanent.
- Communicate: say what was chosen, why and at what cost; agree on time for the proper solution.
- Afterwards: a short review — why the pressure arose and how to avoid it.
Example answer
S: A day before release QA found that on iOS 17 the payment screen crashed because of changes in a third-party SDK updated that sprint.
T: Decide within hours: roll back the SDK, fix it, or move the release.
A: Criteria: users must not hit a crash; the release matters but isn't critical; rolling back the SDK is reversible, moving the release is expensive. I rolled the SDK back to the previous version (reversible, 30 minutes), wrapped the call in an if #available version check and added a feature flag for the new SDK version. I recorded in a ticket: "SDK rolled back, reason — iOS 17 crash in X, restore after the vendor fix". I told product and the team in a thread.
R: The release shipped on time with no crashes. The vendor released a fix a week later and we enabled the new version via the flag. At the retro we agreed to update third-party SDKs only at the start of a sprint and to run tests on the minimum supported iOS.