I’ve spent the last decade building and leading global platform teams, which means I’ve sat through hundreds of technical interviews. Trust me, I’ve seen it all. I’ve had candidates try to Google answers mid-sentence, others clearly reading off an AI response on a second screen, and—my personal favorite—the “bait and switch,” where one person shows up for round one and a completely different human being appears for round two. I’ve even had someone realize ten minutes in they were invited to the wrong interview and still try to power through a Kubernetes deep-dive despite being a Frontend dev.

But even among the ones who are actually in the right room, the vast majority fail for the exact same reasons. If you’re getting rejected after the technical screen, it’s rarely because you didn’t memorize a specific CLI flag. It’s because you’re falling into one of these six patterns.

1. The “We” vs. “I” Obfuscation

This is my number one red flag. When I ask about a specific project and the candidate says, “In my previous role, we migrated to AWS” or “we built a CI/CD pipeline,” I immediately dig deeper. Nine times out of ten, “we” is a mask for “my teammate did the work while I watched the Slack channel.” If you can’t describe your specific contributions, the architectural decisions you made, or the bugs you personally squashed, I assume you were just a passenger on the project.

2. The “Superhuman” Resume Hyperbole

I see resumes every day where a single candidate claims they “designed, built, and implemented a global multi-region service mesh” in six months. That’s a job for a team of ten engineers. When you load your resume with every buzzword in the CNCF landscape to pass a recruiter’s screen, you’re setting a trap for yourself. It’s incredibly easy for an experienced interviewer to spot these “God-mode” claims, and it’s impossible for you to defend them when I start asking about the nitty-gritty trade-offs.

3. The Fear of Saying “I Don’t Know”

In infrastructure, pretending you know everything is dangerous—it’s how production environments get nuked. I’ll often ask a progressively difficult series of questions just to find the candidate’s limit. The ones who fail are those who try to “fake it” by throwing out unrelated technical jargon. I once had a candidate spend five minutes hallucinating how BGP routing works instead of just saying, “I haven’t worked at that layer of the stack yet.” An honest “I don’t know, but here is how I would find the answer” is infinitely more valuable than a confident lie.

4. Zero Research: “Why Are You Here?”

I always ask some version of: “What interests you about our infrastructure challenges?” If your answer is a generic “I want to work with Linux,” you’ve already lost me. If we’re a FinTech company dealing with high-frequency trading and you haven’t researched our scale or compliance needs, you aren’t showing up as a problem solver. If you don’t care enough to spend ten minutes on our engineering blog, I don’t care enough to give you a job.

5. The “Value Proposition” Vacuum

The closer you get to the end of the interview, the more I’m looking for a reason to hire you over the other five people I talked to this week. When I ask, “Why should we hire you?”, most candidates just repeat their resume back to me. If you can’t articulate the specific value you bring—whether it’s your experience scaling during hypergrowth or your ability to automate manual Sysadmin toil—you aren’t giving me a reason to fight for your headcount.

6. The “Nice Guy” Fallacy

I’m sure you’re a delight at happy hour and your “active listening” is top-tier, but a sparkling personality doesn’t stop a kernel panic. I’ve interviewed candidates who can spend forty minutes talking about team dynamics but can’t tell me how to find a PID eating up 100% of the CPU. If your strategy is to charm your way past a technical gap, save us both the time. At 3:00 AM when the site is down, I need someone who actually knows how the stack works.

What the Top 1% Do Differently

The candidates I hire on the spot share a specific trait: Systems Thinking. They don’t just see a “broken server”; they see a bottleneck in a complex ecosystem. They prioritize “boring” stuff like documentation and observability over chasing whatever tool just hit the top of Hacker News.

I’ll give you an example. I once asked a candidate to walk me through how they’d troubleshoot a web app that was intermittently timing out. Most people start rattling off tools—“I’d check Datadog, I’d look at the load balancer, I’d run top.” This person started by asking what changed recently. Then they sketched out the request path on a virtual whiteboard—DNS, CDN, load balancer, app tier, database—and told me they’d start by isolating which layer was introducing latency before touching anything. When they hit the database layer in the walkthrough and I asked about something they’d clearly never configured, they said, “I haven’t managed connection pooling at that scale, but I’d start with the docs for our specific database engine and look at how max connections and idle timeouts interact.” No bluffing. No panic. Just a clear mental model and the honesty to flag where it ended.

That’s the difference. The top candidates show you how they think, not just what they’ve memorized. They have a framework for approaching problems they haven’t seen before, and they’re comfortable saying “here’s where my knowledge stops” without treating it as a confession.

But more importantly, they possess a humility that the “experts” lack. I would much rather hire an honest, fast learner who is eager to bridge their knowledge gaps than a brilliant “couch potato” who thinks they’ve already learned everything they need to know. In this field, the moment you stop being a student, you become a legacy system.

If any of this sounds familiar, I run realistic mock technical interviews that simulate exactly what you’ll face on the other side of the table—including the written debrief telling you where you stand. Book a session.