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, and couldn’t answer a follow-up question without ChatGPT.

That’s not a senior engineer. And yet this happens all the time. 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.

In this article, I'll explain how to spot a fake senior developer with five questions that can save you weeks of hand-holding and technical debt down the line.

What Makes a Developer Senior?

What makes a developer senior is proven ownership: leading a project end to end, making architectural calls and living with the consequences, and explaining both to someone who isn't a developer. Years, titles, and degrees don't tell you any of that.

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 told us, a professional can be a mid-level engineer even with 20 years of experience. 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 lead.

Across the engineers and DevOps candidates I've placed for US clients, credentials are the weakest signal on the page. I usually tell clients not to make a degree a must-have on an engineering role: plenty of the strongest engineers I place started working before they graduated and never finished. 

Most rejections I see don't come from the resume at all. They come from the interview and the take-home assessment, which is where the real filter sits.

There's also a market reason so many people reach for the title. Hiring for mid- and senior-level roles recovered in 2024 while entry-level hiring kept shrinking, according to SignalFire's State of Tech Talent Report – 2025. The report draws on data covering 650+ million professional profiles. New grads are now just 7% of hires at Big Tech, down 25% from 2023, and under 6% of hires at startups.

The gap between the resume and the reality is getting harder to see too. A 30-year veteran of the IT industry, now running a US consulting firm, told us:

I've been in this industry for thirty years and I have never seen anything like what's happening right now with fake resumes. It's an epidemic. AI is generating entire work histories that never existed.

‍

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 engineers?
• 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.

This is the screen I run on every engineer I evaluate. I ask them to walk me through a project: what their role was, what they personally did, what they decided. I want to see if they can explain it without hiding behind the technical detail. Reciting terminology without owning anything isn’t a senior answer.

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. Candidates who steer away from mistakes altogether usually have thin real experience, thin self-awareness, or both.

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 someone outside engineering. 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.

— Federico Bilello, Senior Recruiter, Hire With Near

‍

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.

Pay attention to what language and framework they used, what the API 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.

One caution: don't over-weight the exact framework version. Engineers who understand core principles pick up a new one quickly, so test whether the production experience is real, not whether their stack matches yours line for line.

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.

If you want a longer bank to draw from for the rest of the loop, we keep a list of the 25 best tech interview questions for technical talent.

Signals Someone Isn’t Ready to Lead

Even if a candidate looks like a senior on paper, these are the senior developer red flags that mean 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 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.

That only works if they’re online when your team is. Support that only arrives after your office has already closed doesn't actually help you.

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

They’re running two or three jobs in parallel

If a candidate is holding two or three jobs at once, that’s a red flag for me, not a selling point: either they’re not performing at any of them, or the bar at all three is low. I’d rather see two to three years of average tenure per role, which is long enough to own something through a full cycle.

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.

Federico Bilello put a finer point on it when we asked what makes him pass on a resume:

A big red flag is when a candidate claims proficiency with an enormous variety of tools — to the point where it just doesn't make sense. There's no way someone has six years of experience with six different languages. I look for equilibrium: someone proficient with specific tools but with a background using different frameworks, so I know they're resourceful, not just a jack of all trades.

— Federico Bilello, Senior Recruiter, Hire With Near

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 Hire With Near, we’ve interviewed hundreds of developers based across Latin America.

IT and tech recruiting in Latin America is a core part of what we do, 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 them how they tested their code
• Adaptability and ownership: Can they talk about their role in the product, not just the tech?

Of the engineers we placed in the last reporting year, 98% were mid-level or senior, and 51% were senior, according to Hire With Near's 2026 State of LatAm Hiring Report.

That bar holds even when a client is in a hurry. One US healthtech startup came to us scaling engineering fast with only two internal recruiters, and refused to drop any of the eight steps in its interview process. It hired seven senior engineers, from backend through staff level, with a 14-day average time to hire and all eight steps intact, and saved $323,000 a year compared to what the same team would have cost in the US.

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 hiring software engineers in Latin America, we know where to find them. We’ll send you LatAm software engineers who can code, collaborate, and ship.

Schedule a free, no-commitment consultation call today.

{{latam-hiring-cta-v2}}