TL;DR: Make the decision on risk facts rather than on assertiveness: what the change touches, whether rollback exists and is rehearsed, who can support it over the weekend. Then either deploy with explicit guardrails (canary, monitoring, named rollback owner) or propose a concrete better slot, and put the trade-off in writing to your manager.
How to approach it
Do not perform bravado ("I would never deploy on Friday") nor obedience ("my manager decides"). Interviewers in services organisations are scoring judgment under authority: can you hold a technical line while respecting commercial pressure? Structure: assess first, then decide, then communicate.
A strong answer
Assess before opining. The right answer differs by change, so say what you would check:
- Blast radius: which services and customers does this touch? A config toggle behind a flag is not a schema migration.
- Rollback reality: has rollback actually been exercised recently, or only theorised? Time-to-restore is the number that makes weekend deployments survivable.
- Support coverage: if it breaks at 2am Saturday, who is around? On a services project with an offshore-onshore split, Friday evening in one geography is working hours in another, which changes the calculus entirely.
- Freeze context: is there a contractual or regulatory freeze window active? Some industries forbid this deployment outright, which ends the conversation politely.
If deploying is defensible, agree explicitly, with guardrails stated out loud: deploy behind a feature flag at low exposure first (internal users or one percent of traffic), watch the golden signals for thirty minutes against known thresholds, confirm rollback owner and decision time ("if error rate exceeds X by 8pm we roll back, no debate"), and post-deploy verification steps written down before starting. The discipline converts a scary deployment into a bounded one. Also name what makes it acceptable: this works because the change is small and reversible; the same request for a database migration gets a different answer.
If deploying is not defensible, refuse the action while serving the commitment. The shape matters: "I do not want us deploying an unrehearsed migration into an unsupported weekend. What I can offer: the feature is already safe on staging; I can have it live Monday 9am after one rehearsal pass, or tonight I can ship the config-only part that gives sales their demo. Which serves the customer commitment best?" You gave the manager two workable paths instead of a wall. Escalating the real constraint ("our rollback was never tested; that is the actual blocker") turns a conflict about dates into a fixable gap.
Close the loop professionally either way: whatever is agreed goes in writing (chat or email) with the risk statement, because memory of Friday-night conversations is notoriously self-serving. And afterwards, if you deployed, run the retro on how it went; if you deferred, note whether the Monday path held commercially.
What interviewers probe next
"What if your manager insists anyway?" Deploy under protest is wrong; so is silent sabotage. State your assessment in writing and ask the authorized risk owner to decide. For a permitted, accepted risk, execute with the agreed controls. If the deployment breaches a mandatory freeze, authorization rule or safety constraint, pause and escalate before deploying; a manager's insistence does not waive it.
"Is 'never deploy Fridays' just superstition?" Mostly yes as a rule, no as a heuristic. The rule's kernel: weekends lack support coverage and adjacent-working-days for detection. Teams with full weekend on-call, rehearsed rollbacks and progressive delivery deploy whenever they want; teams without any of those should fear every evening.
"What does this question have to do with DevOps skills?" Everything: the organisation's ability to deploy safely on Friday IS its engineering maturity. CI/CD, flags, observability and rehearsed rollbacks are what make the conversation boring.
Common mistakes
Answering with a slogan ("never deploy Friday") and no reasoning. The interviewer hears someone governed by folklore rather than risk analysis.
Treating the manager as the adversary. Commercial pressure is legitimate input; the failure being probed for is engineers who treat business needs as noise.
No mention of writing anything down. Verbal agreements about risk are how incidents get blamed on whoever kept the worse notes.