Your ideal candidate looks perfect on paper: degree from a top university, three years at a FAANG company, impressive GitHub profile. You move to code reviews and pair programming sessions, and something is obviously wrong. The code is sloppy. The problem-solving is surface-level. The candidate struggles with questions a mid-level engineer should breeze through.
This happens a lot in tech hiring right now, and we think it’s because the signals we’ve used for the past fifteen years to evaluate developer quality have stopped working.
Three shifts in the tech industry have undercut the old credential-based hiring model:
- Credential inflation - Bootcamps, online degrees, and self-taught developers have diluted the signal value of formal education.
- Company prestige decoupling - Working at a big tech company no longer guarantees quality or learning.
- AI as a productivity multiplier - Developers with LLMs can appear competent in shallow evaluation while being unable to think independently.
The companies winning at hiring aren’t waiting for perfect credentials anymore. They’re looking deeper - at how candidates actually think, what they’ve shipped, and whether they can navigate ambiguity and learn quickly.
Here’s what’s changed and how to adapt your hiring process to account for it.
Why Credentials Stopped Working (And When This Started)
The old hiring model was simple: degree from a respected university meant you understood fundamentals. Multiple years at Google or Amazon meant you could scale systems. Open source contributions meant you could write good code.
These signals correlated with quality for a long time because there was relatively high friction to obtaining them. Getting a computer science degree required four years of sustained effort. Getting hired at a FAANG company meant passing a gauntlet of technical interviews. Contributing meaningfully to open source required enough technical depth to produce code that project maintainers would accept.
The correlation made sense. Credentials were evidence of both ability and sustained competence.
We’d date the breakdown to roughly the mid-2010s. That’s a judgment, not a measured date.
Bootcamps changed the education equation. Bootcamps promise junior-ready in a matter of months. Many graduates are genuinely good developers, but quality varies so much between programs that the credential alone tells you little.
FAANG interviews became gameable. The interview format is standardized and widely prepped for. A competent candidate can prepare for the coding interview format, get through the gauntlet, and get hired without ever having shipped anything hard. The FAANG credential now proves you could pass standardized interviews - not that you can think deeply or build systems.
Open source became a mixed signal. Some of the strongest developers maintain significant open source projects. But a merged PR can mean anything from a typo fix to a deep change, and from the outside they look alike. Treat it as a prompt for a question, not a filter.
Generative AI broke surface-level competence. A developer without deep understanding can now use Copilot, ChatGPT, or Claude to write code that passes surface-level review - code that compiles, looks reasonable on first read, and might even pass basic test cases. In a one-hour pair programming session or on a take-home coding test, this is almost invisible. It surfaces later, when the code breaks under stress, needs to be modified, or has to integrate with the rest of a system.
What Actually Predicts Developer Quality
If credentials don’t work anymore, what does?
The strongest signals are the ones that are hardest to fake:
1. What They’ve Actually Shipped
This is the best signal available and it’s almost always ignored.
Not “contributed to a project” or “was on a team that shipped.” What did this individual person architect, build, or ship? What decisions did they make? What trade-offs did they navigate? What would have happened differently if they hadn’t been involved?
The specificity matters. If a candidate says “I led the architectural redesign of our payment system” but can’t explain the design decisions, the constraints they were optimizing for, or what went wrong and how they handled it - they didn’t lead it. They were there.
Real shipping experience is hard to fake in conversation, because the details (what broke, what you’d undo) are hard to invent.
How to evaluate: Ask specific questions about something they’ve built. What would happen if you removed their contribution? What would they do differently if they did it again? What constraints did they have to work within? The depth and specificity of their answers tell you more than any coding interview.
2. How They Think About Problems
Technical problem-solving has two layers: can they implement the solution, and do they understand the problem deeply enough to know which solution to implement?
Surface-level developers can implement. Strong developers can think.
The distinction shows up when you ask questions where the implementation is secondary. How would you approach this problem? What’s the first thing you’d do? What information would you need? What trade-offs matter here?
Weak thinkers will either jump to implementation immediately or give you generic answers. Strong thinkers will ask clarifying questions, push back on unstated assumptions, and think out loud about constraints. They’re uncomfortable with ambiguity and work to resolve it.
AI tools have made implementation easier and less distinctive. Thinking deeply is still something you have to do yourself.
How to evaluate: Give them a problem that’s deliberately underspecified. Don’t fix the ambiguity. Let them navigate it. The way they ask questions, the constraints they identify, and the frameworks they use to think about the problem tell you far more than whether they can write a working sort function.
3. What Happens When They Get Stuck
Everyone gets stuck eventually. The difference is in what they do about it.
Weak developers panic, guess, or give up. Medium developers try obvious things and hope one works. Strong developers get calm, break the problem into pieces, identify where the uncertainty is, and test hypotheses systematically.
This is hard to fake in an interview.
How to evaluate: Watch what happens when they hit an obstacle in a technical conversation or coding problem. Do they have a systematic approach to debugging? Do they make progress even when they’re not sure? Do they communicate what they’re thinking? The quality of their thinking under pressure is a very strong signal.
4. Whether They’ve Invested in Mastery
The developers who keep getting better are the ones who invest in understanding the foundations of their craft.
Not everyone does this. Some developers hit a level of “good enough to get hired” and stay there forever. Others keep diving deeper - they read deeply about the tools they use, they understand the tradeoffs of design patterns, they can explain why their language does something the way it does.
This doesn’t require a fancy degree. It requires intellectual curiosity and the willingness to struggle through material that’s hard.
How to evaluate: Ask them about something deep in their domain. Not “what’s a design pattern” but “why is immutability important in a language like JavaScript” or “what’s the actual problem that a message queue solves” or “why does distributed consensus matter for databases.” Not asking them to recite answers, but asking if they’ve ever actually thought deeply about these things.
Strong developers have opinions about why things are built the way they are. They’ve thought about the trade-offs.
5. The Track Record of Decisions They’ve Made
Over time, developer quality shows up in the decisions they’ve made that have aged well.
Did they build something that still works three years later? Did they make technology choices that held up as the team grew? Did they make tradeoffs that the company still sees as smart?
This is backward-looking, so it doesn’t help with new hires from outside companies. But it’s available for internal candidates or candidates coming from places where you can reference.
How to evaluate: With reference calls, ask specifically about decisions. Not “was this person good” but “what’s a technical decision they made that turned out to be really smart? What’s a decision they made that didn’t age well, and how did they respond?”
Why Companies Still Use Credentials (And Why It’s Hurting)
If credentials are broken, why is every job posting still asking for “5+ years of experience with X” or “degree in CS required”?
Inertia, mostly.
The credential-based filter is easy to apply before you talk to anyone. It scales. It reduces the number of applications. It feels like a quality screen because it used to be.
But it’s now a filter that removes good candidates while letting through plenty of mediocre ones. Companies that optimize for credentials are systematically eliminating self-taught developers, bootcamp graduates who are stronger than degreed candidates, and talented mid-career switchers who spent time in adjacent fields.
And they’re doing it to make screening easier.
The cost: a smaller talent pool, longer searches, and people you never interviewed because their resume looked wrong.
Signal-based screening has its own cost. It takes more of your team’s time per candidate than a resume filter does.
How to Build a Hiring Process That Works
If you’re going to abandon credentials, you need to rebuild your hiring process around signal instead.
Here’s a framework that works:
Screen for Signal, Not Credentials
Post your job asking for “experience shipping software” instead of “5 years of React.” See what happens. You’ll get more applications and more to read, but they’ll tell you more than a CS degree would.
When you’re reviewing applications, look at what they’ve built. Ask them to explain a project they’re proud of. If you like their thinking, move to the next stage.
Use Technical Conversations, Not Coding Tests
Coding interviews are useful if you’re screening for leetcode skills. They’re nearly useless for evaluating whether someone can think through a complex problem.
Replace the take-home coding test or algorithm whiteboarding with a conversation about a real problem. Describe a system design challenge you have. Ask them how they’d approach it. Let the conversation go deep.
Pay attention to how they ask questions, how they identify constraints, how they think about tradeoffs. You’re evaluating their thinking, not their ability to implement a binary search.
Reference Reality, Not Credentials
When you talk to references, don’t ask “is this person good?” Ask “describe a technical decision this person made that you think was really smart. What about it was smart?” and “Describe a time this person got stuck on something hard. What did they do?”
These are harder to bluff than “is this person good?”
Close with Operational Evaluation
Before you make an offer, pair the candidate with a few people on your team for a few hours of actual work. Not a test, just collaboration. Use it to evaluate:
- How do they ask questions?
- Do they think out loud or work silently?
- Can they integrate feedback quickly?
- Do they have opinions and explain the reasoning?
This is the closest you can get to “what is it actually like to work with this person” without hiring them.
Where This Stops Working
Conversations can be gamed too. A fluent talker can sound deeper than they are, and AI tools make rehearsed answers easier. That’s why we’d pair the conversation with the working session above, and check the decisions with references.
If you’d like help running that evaluation, book a discovery call.
More Insights
October 2026
The Real Cost of a Senior Developer Hire Is Not the Salary
The salary is the number on the budget. The real cost of a senior hire is the empty seat, the ramp-up and the risk they leave. Here is how to count it, and how to cut it.
September 2026
The 18-24 Month Question: Why Developer Growth Stops — and How Your Hiring Approach Determines Everything
Why top developers leave after 18-24 months: the growth stall that signals turnover. Hiring for career trajectory and using nearshore vetting predicts retention far better than salary alone.
September 2026
The Developer Market Just Shifted - Why Your Hiring Strategy Is Out of Date
The post-AI hiring market changed faster than most teams adapted. Your 2024 hiring playbook is burning money. Here is what changed and what to do instead.
