The problem with most technical hiring processes
Most technical interviews test the wrong thing. They test memory instead of reasoning, vocabulary instead of judgment. A candidate can recite the difference between TCP and UDP without ever having had to decide, under real pressure, which one to use in a production system. The right question is never "do you know what this is", it's "have you ever had to decide with this, and what happened when the decision was wrong".
This became clear while preparing for a Técnico de Informática interview, focused on networking and Linux systems. The preparation came down to five points, and each one reveals something broader about what separates candidates who know from candidates who can prove they know.
1. Fundamentals aren't the test, they're the license to take the test
A candidate who can't explain how a packet travels across a network, or what happens when a TCP handshake fails halfway through[2], doesn't reach the interesting part of the conversation. Fundamentals aren't what differentiates candidates from each other, they're the minimum requirement that grants access to the conversation that actually matters.
This has an uncomfortable implication: a candidate can know the fundamentals perfectly and still have nothing interesting to say about them. Fundamentals without decision-making experience are just vocabulary.
2. Practical experience is the one thing credentials can't fake
A certificate proves someone studied a set of material for a defined period. It doesn't prove that person ever had to deal with a system's real behavior under real conditions, at three in the morning, with no documentation, with a user asking why the service is down.
This is exactly the distinction that the discipline of Site Reliability Engineering formalized inside Google itself: the idea that operating a system in production is engineering work just as serious as building the system in the first place[3]. A homelab, personal infrastructure maintained outside of work, isn't a decorative hobby on a resume, it's the only way a candidate can have gone through real failures without an employer's institutional weight behind them. It's proof of operational experience that no certification can replace.
3. The dual profile isn't a weakness to hide, it's a misunderstood asset
Candidates who build software and also operate infrastructure are often viewed with suspicion from both sides: developers assume they know little about production code, infrastructure teams assume they know little about operations. That suspicion ignores the real value of the dual profile.
A cohesive system requires every component to know exactly where its own boundary ends[1]. A candidate who has written code and also operated the infrastructure that code runs on understands that boundary from the inside out, not just in theory. That isn't a tension to manage, it's a structural advantage most hiring processes still don't know how to evaluate correctly.
4. Anticipating questions means understanding what's being measured, not what's being asked
Google's internal hiring research found something counterintuitive: structured interviews, with standardized questions and explicit evaluation criteria, consistently predict real job performance better than informal, improvised conversations[4]. That means, on the other side of the table, most competent interviewers aren't testing random facts, they're testing a pattern of reasoning against criteria already defined before the interview even starts.
A candidate who understands this stops trying to guess the exact question and starts preparing to demonstrate the decision-making process the interviewer needs to see, regardless of which specific question reveals it.
5. The candidate's questions are the interview's only truly two-way moment
For nearly the entire interview, the candidate is being evaluated. In the final moment, when invited to ask questions, that dynamic briefly reverses, and it's the only point where both sides are genuinely deciding whether they want to work together. Asking about real technical debt, day-to-day autonomy, how the team handles incidents, says more about the candidate than any technical answer before it. Asking nothing at all remains the one truly indefensible move at that moment.
What these five points have in common
None of these points is about accumulating knowledge. They're about the ability to demonstrate, under observation and under pressure, that the knowledge you have survives contact with a real problem. That distinction, between knowing and being able to prove you know, is exactly what most technical hiring processes still haven't learned to measure well, and exactly why it's worth any candidate learning to measure it first, before walking into the room.