How to Spot a Fake Senior: Three Honest Tells

What you need to know

• The senior developer title is applied to roughly three to four times as many developers as actually perform at a senior level. This is not dishonesty from most developers. It is credential inflation that has become the market norm.
• The three tells are behavioral, not technical. You do not need to read code to observe them.
• A fake senior who gets the role will perform adequately on well-defined tasks and struggle on ambiguous ones. The ambiguous situations are the ones that matter most in the first three months.
• The interview process is the cheapest place to find the gap. The alternative is a six-month engagement that surfaces it gradually.
• A developer who is honest about being mid-level and actively developing is often a better hire than a fake senior who is not aware of or not honest about the gap.

The core argument

Tell one: a fake senior cannot describe tradeoffs without prompting. A real senior engineer explains every significant decision as a tradeoff. They chose PostgreSQL over MongoDB because the data model is relational and consistency matters more than flexibility for this use case. They chose a monolith over microservices because the team is small and the operational overhead of microservices would outweigh the separation of concerns benefit at this scale. Every significant technical choice has a cost that they name. A fake senior describes choices as correct without naming the cost of the alternative. The absence of the tradeoff is the tell.

Tell two: a fake senior does not push back on scope. Real senior engineers push back frequently and specifically. They tell you when something will take twice as long as you think, when a feature you want will create technical debt that costs more than the feature is worth, and when the right answer to a user request is not the feature they asked for. This is not difficult behavior for a real senior. It is how they think about problems. A fake senior processes the scope as given and builds what is described, even when the scope has visible problems. They are performing the job title, not doing the job.

Tell three: a fake senior deflects questions about failure with team-level answers. When I ask a developer what went wrong on a project, a real senior gives me a specific account of a decision they made that turned out to be incorrect. A fake senior gives me a story about a difficult stakeholder, an unrealistic timeline set by the product team, or a technical problem introduced by a colleague. The subject of the failure is external. A real senior is the subject of their own failure stories because that is what senior accountability looks like.

Common mistakes

1. Accepting jargon as evidence of depth. A developer who can use the right terms fluently sounds like a senior. A developer who can explain why a specific choice was made in plain language actually is one. Test for the second, not the first.

1. Not asking about specific past decisions. Generic questions about approach produce generic answers. Specific questions about specific decisions produce the specificity you need to evaluate.

1. Interpreting confidence as competence. Some of the most confident developers I have interviewed were also the ones with the shallowest depth. Confidence is a performance. Specificity is evidence.

1. Not asking a follow-up question when the answer is vague. "Can you give me a specific example?" or "What exactly did you decide?" are the two follow-up questions that turn every vague answer into a useful data point.

1. Assuming the trail they have done elsewhere transfers to your context. Senior in a large enterprise environment is different from senior in a five-person startup. Ask about work done under conditions similar to yours, not just work done.

Where to start

1. Prepare three specific questions for the next interview. One about a technical tradeoff they made, one about a time they pushed back on a scope or a decision, and one about a failure they own personally. Have the follow-up ready: "can you give me a more specific example?"

1. Listen for the subject of their failure stories. If the developer is never the subject of the failures they describe, note it. One team-level answer is normal. Every answer being about external factors is a pattern.

1. Compare the tradeoff language in their answers. The candidate who says "I chose X because of Y, even though it meant giving up Z" is the candidate who has genuine senior-level thinking. The one who says "X is the best approach" is not there yet.

Related reading

• How to Run a Technical Interview as a Non-Technical Founder
• The Vetting Framework: How to Verify a Developer's Real Experience
• Red Flags in a Developer's Portfolio
• Hiring Mistakes That Founders Repeat Endlessly