One of the strongest signals in a technical interview is not whether a candidate knows every answer. It is what they do when they do not know.
That sounds simple, but it is easy to get wrong. Candidates often feel pressure to keep talking, fill the silence, and sound certain. Interviewers often reward speed and fluency even when the answer is fragile. In production-facing work, that is a dangerous incentive.
Fake confidence is an operational risk
In infrastructure, security, cloud, SRE, and production engineering, uncertainty is not the problem. Hidden uncertainty is the problem. The engineer who guesses confidently can create more risk than the engineer who pauses, states the boundary of their knowledge, and defines a verification path.
This is why technical interviews should test judgment under uncertainty, not only recall. Real systems rarely fail in textbook form. They fail with partial logs, incomplete context, ambiguous dashboards, and business pressure. That connects directly to how I think about <a href=”https://runwithran.com/2026/06/09/engineering-probation-feedback-metrics/”>engineering leadership and software-development judgment</a>: good operators make uncertainty visible before they act.
The answer I want to hear
A strong answer to an unknown technical question is not just “I do not know.” That is a good start, but it is incomplete. The stronger version is: “I do not know for sure. My assumption would be X because of Y. Before touching production, I would verify it through Z.”
- Knowledge boundaries: the person can separate facts from assumptions.
- Diagnostic thinking: they can form a hypothesis without pretending it is truth.
- Operational discipline: they know when verification must happen before action.
- Communication quality: they make risk legible to the team instead of hiding it behind confidence.
What interviewers should change
If an interviewer only says “do not guess,” they may still miss the better signal. The useful follow-up is: “How would you find out safely?” That moves the conversation from trivia to practice.
For senior candidates, I would go further. Ask what they would do if the system is already degraded, the runbook is outdated, and the obvious answer might make the incident worse. That is where maturity shows up. It is also where <a href=”https://runwithran.com/2026/06/07/ai-assisted-development-engineering-process/”>clear engineering process and leadership expectations</a> matter more than memorized commands.
A practical interview rubric
- Ask one question outside the candidate’s memorized zone. The goal is not to trap them; it is to observe their response to uncertainty.
- Listen for assumptions. Do they label assumptions clearly, or present them as facts?
- Ask for a verification path. What logs, docs, metrics, tests, or safe environments would they use?
- Look for production restraint. Would they touch the live system immediately, or reduce blast radius first?
- Reward process, not theater. Confidence is useful only when it is attached to evidence.
The career lesson
For candidates: do not sell certainty you do not have. Show how you think, how you verify, and how you protect production while learning. For interviewers: do not punish missing knowledge. Test how the person handles it.
In real systems, “I do not know yet” is not weakness. Sometimes it is the most professional sentence in the room.
Context: this article was inspired by a practitioner discussion about a tense sysadmin interview, then expanded into a practical rubric for evaluating technical judgment under uncertainty.
Originally posted on LinkedIn: <a href=”https://www.linkedin.com/feed/update/urn:li:activity:7470712711409049600/”>Hebrew version</a>
