How to Spot a Fake “Senior” Engineer During Your Interview (5-Question Test)

You asked for a senior developer.

But the candidate you just interviewed couldn’t explain how they test their code. Couldn’t describe the architecture of their last project. Couldn’t answer a follow-up question without ChatGPT.

That’s not a senior engineer.

And yet this happens all the time.

Whether you’re hiring directly or working through a dev shop, you’ve probably seen this title inflation before. Someone shows up with “Senior” in their LinkedIn headline, but once you get past the surface, the depth just isn’t there.

And when you need someone to lead, that’s not going to cut it.

Here’s how to find out—fast—if a so-called senior is actually ready to carry the weight.

These five questions can save you weeks of hand-holding and technical debt down the line.

Seniority Is About Impact

First, let’s be clear: “Senior” isn’t about years.

Too many companies use resume math to define seniority:
5+ years = senior.
10+ years = very senior.

But we’ve interviewed developers with a decade of experience who’ve never led a project, mentored a junior dev, or made a single architectural decision. Years alone don’t guarantee seniority. 

As one client put it:

Someone could be a mid-level engineer for 20 years.

‍

Seniority isn’t just about time. It’s about impact.

What matters is whether they can deliver high-quality code, troubleshoot issues independently, and make solid technical decisions. Years might get someone past the initial screen, but they don’t tell you if they can actually lead.

The 5-Question Test to Validate Real Seniority

You don’t need a four-hour assessment to filter out the real seniors from the fluff. Just ask these questions early in the interview.

1. “How do you test your code?”

Every good engineer should have an answer to this. Testing is a basic part of writing responsible, production-ready code, not a nice-to-have. But it’s how they talk about testing that separates the truly senior from the rest.

Mid-level or junior engineers might say, “I just run it and see if it works,” or describe basic manual checks.

Senior engineers go further:

• They write unit, integration, and end-to-end tests
• They test for edge cases, not just happy paths
• They talk about reliability, coverage, and trade-offs
• They see testing as part of building, not a chore after the fact

This is one of the clearest ways to filter out folks who are operating in “vibe coder” mode.

If someone treats testing like a checklist item—or worse, an afterthought—they’re not ready to lead.

2. “Tell me about a project you owned end-to-end.”

You’re looking for ownership, not just participation.

Can they:

• Walk you through architecture decisions?
• Explain trade-offs they had to make?
• Connect their choices to product or business goals?
• Describe how they collaborated with product, design, or QA?
• Communicate clearly without getting lost in jargon?
  
  

If they can’t talk about what they built, why it mattered, and how they made it happen, that’s not a senior-level answer. And they probably weren’t leading anything.

And while you’re here, follow up with: “Did you mentor any junior developers during that project?”

Mentorship is one of the clearest signals of seniority. Even if they weren’t formally managing others, real seniors help others grow.

 3. “What’s a bug that took you days to solve? How did you fix it?”

This shows two things:

1. Whether they’ve ever touched complex systems (not just tickets)
2. Whether they have the persistence and problem-solving chops to get through it

You’ll learn a lot from how they talk about failure.

4. “If you joined a new team and inherited a messy codebase, what would be your first steps?”

This is a quick way to assess how they think about technical debt, structure, and collaboration.

A solid answer might include:

• Reading documentation
• Writing tests before changing anything
• Talking to teammates to understand context
• Identifying quick wins or risky areas
• Thinking through how changes impact the business or customers

It shows you how they balance speed and caution and whether they can clean up a mess without breaking everything.

This question also gives you insight into how well they simplify complexity. 

One of our senior recruiters, Federico Bilello, doesn’t explicitly ask candidates to explain this answer to a non-technical stakeholder, he just expects them to communicate clearly:

If they can’t walk through a decision in plain terms to someone outside their function, they’re probably not going to lead cross-functional work well either.

‍

 5.“Tell me about the last API you built? What tools did you use?” 

This one catches bluffers.

It’s easy to claim proficiency in a language or framework. But if a developer can’t clearly describe a recent project using that tech, they’re probably stretching their resume.

Listen for what language and framework they used, what the API actually did, and what challenges they ran into. 

If they can’t recall key details, or the last time they used that tool was years ago, that’s a sign they’re not as up to speed as they claim.

But if they walk you through it clearly and show working knowledge of the stack you care about, it’s a good signal they’re not bluffing.

And just to note, when you ask how long they’ve worked with a tool, always clarify: “How many years of professional experience?” That filters out resumes padded with school projects, weekend hackathons, or freelance gigs where they barely touched the tech. That matters when you’re hiring someone to lead.

Signals Someone Isn’t Ready to Lead

Even if a candidate looks like a senior on paper, these are the tells that they’re not ready to carry real weight on your team:

They’re deep but dangerously narrow.

You ask about their tech stack and they shine. But go one layer outside their core domain—networking basics, deployment, debugging tools—and they’re lost.

As one engineering leader, speaking about their frustrations trying to find senior talent on their own, told us:

He was great at Python. But couldn’t explain what a IPv4 subnet was. Couldn’t deploy a Docker container. 

‍

That’s not senior. That’s siloed.

You don’t need unicorns. But you do need someone who understands the system they're working in—not just their slice of it.

They can’t pinch-hit when it matters.

A real senior dev should be able to step up when someone’s out sick, unblock a teammate, or help keep the system stable when something breaks.

Again we’ve heard from clients,

If they can’t replace you for a week when you’re on PTO—or out with the flu—that’s a risk.

‍

Seniority isn’t just about what they’ve done before. It’s about whether they can step in and own something when no one else is around to hold their hand.

A strong senior dev has depth in their core stack and enough breadth to stay resourceful when the unexpected happens.

They claim “proficiency” in every language… but can’t explain one.

If someone lists five backend languages, but can’t tell you about a recent API they built in any of them, you’re likely dealing with title inflation.

They hide behind jargon or buzzwords.

Vague answers, bloated language, and lots of “we did this” without any “here’s what I owned” = red flag. Seniors don’t need to posture. They explain clearly, even when the answer is complex.

Final Thoughts

At Near, we’ve interviewed hundreds of developers from across Latin America.

And we’ve seen just how many companies have been burned by fake “seniors” before they came to us.

That’s why we don’t trust titles.

We validate for:

• Communication and professionalism (Recorded interviews before you even meet them)
• Technical skill and testing mindset (We always ask: How do you test your code?)
• Adaptability and ownership (Can they talk about their role in the product, not just the tech?)

And because we’re all-in on LatAm, we know what real top-tier talent looks like and what kind of comp they expect. We know who’s serious about long-term growth and who’s just trying to pass as senior to land a better gig.

Seniority isn’t something you can always see on a resume.

It’s in how someone communicates. How they solve problems. How they show up for the team.

So don’t settle for someone who’s “done this for ten years.”
Hire the person who can walk in tomorrow and move your product forward.

And if you want help finding those folks, we know where to find them.

We’ll send you pre-vetted LatAm devs who can code, collaborate, and actually ship.

Schedule a free, no-commitment consultation call today.