There Are More Developers Than Ever. Hiring Got Harder Anyway

Ask anyone hiring engineers right now and you will hear two things that should not both be true. There are more candidates than ever. And it is harder than ever to fill a role.

Both are accurate. They are also connected, and the connection explains something important about the current market.

Our CTO puts it simply: the market is oversupplied. There is no shortage of developers. What there is a shortage of is good ones.

That sounds like the usual complaint of everyone who has ever posted a job. It is not, and the reason is structural.

For most of the last decade, engineers grew by moving. You joined a company, spent two or three years, learned a stack, and left for a better offer. Every switch reset your salary and forced you into unfamiliar code. That churn was not just individual career progress. It was how skill circulated through the whole industry.

That mechanism has slowed down sharply. The market feels unstable enough that people with a decent job are keeping it. Nobody wants to be the newest person on the team when budgets are uncertain.

The result: the engineers who are actively looking are, on average, not the ones you want to hire. The strong ones are employed, busy, and not answering recruiters. The volume of applications went up while the quality of the pool went down.

If your process assumes that applying is a signal of quality, it stops working in this market.

You get more responses to every posting, so it feels like things are going well. Then screening takes longer than it used to, more candidates fail the technical stage, and the role stays open for months. The dashboard says demand is healthy. The reality is that you are fishing in the shallow end.

There is a second-order effect nobody talks about. If strong engineers are not moving, they are also not being exposed to new problems, new teams, or new architectures. Skill stops compounding across the industry, not just in individual careers. That is a slower and more serious problem than a hard quarter of hiring.

The thinner pool would be survivable if screening still worked. It does not, and the reason is the same technology that shows up everywhere else in this conversation.

A CV, a written technical answer and a take-home task used to carry signal because producing a good one required the thing you were testing for. None of that is true now. All three can be produced fluently, quickly, by someone who could not do the job. The written stage did not get harder to pass. It stopped being a stage.

We changed how we screen because of it, and the changes are less clever than they sound.

We watch for answers that arrive instantly, in complete paragraphs, to questions that should make a person stop and think. We watch for CVs where the experience is shaped correctly but hollow when you press on any part of it. We watch for a code sample that exists only as an archive, with no history behind it, because history is the part that cannot be generated after the fact. And we watch for a career on paper that leaves no trace anywhere else.

The weight moved to two things. The first is a live conversation with our CTO, screen shared, nothing assisting. The task itself matters less than what happens when you ask why three times in a row about a decision the candidate just made. That is where knowing something and having produced something come apart. The second is a verifiable footprint: a commit history with years in it, open source anyone can read, or people who worked alongside them and will say so.

Our rule is that at least one of those has to be strong, or we do not proceed. Not because written work is worthless, but because it is no longer evidence on its own.

This is slower than it used to be, and it certainly rejects people who would have been fine. We accept that cost, because the alternative is finding out on a client's project, which is a far more expensive place to learn it.

I want to be careful here, because the honest answer is less impressive than a methodology.

We do not have a clever system. What we have is seven years of accumulated relationships. Our roster came from networking, from referrals, from job boards, from meeting people in person, and from every other channel you can name. We have looked for engineers in every way there is to look. A large part of it is people who worked with us before and stayed reachable.

That is the whole difference between a talent pool and a resume database. A database is a list of people who were looking for work at some point. A pool is a list of people you have actually worked with, or who came recommended by someone you have worked with. The first tells you what someone claims. The second tells you what happened when they were on a real project with a real deadline.

It also means the market conditions I described above affect us differently. When strong engineers stop applying to job postings, a database goes stale. A pool does not, because it was never built on applications in the first place.

The uncomfortable part: this is not a strategy you can adopt when you need it. We did not solve this problem this year. We solved it slowly, starting seven years ago, without knowing that the market would eventually make it the difference between filling a role in days and filling it in months.

Which is the practical reason clients come to us instead of posting the role themselves. They are not outsourcing the interview. They are borrowing seven years of relationships they do not have time to build, and skipping the part where you screen forty applications to find nobody.

Three things worth taking from this.

Treat inbound applications as the least representative sample of the market, not the most. The people you most want to hire are the least likely to be in that pile.

Assume your timeline is wrong. If your process was calibrated in a period when strong candidates were circulating, it is calibrated for a market that no longer exists.

Invest in relationships before you need them. The engineers worth hiring are already working somewhere. The only way to reach them is to have known them before the vacancy appeared, through networks, referrals, and staying in touch with people you worked with once and would work with again.

None of that is fast. That is the point. In a market where the fast route leads to the worst candidates, slow is the only strategy that scales.

Or you borrow someone else's slow.

We do not open a job board when a client calls. We go back to engineers we have already worked with, on projects whose code we have seen. That is the whole reason the answer takes days instead of months. 70,000 hours delivered, clients in six countries.

Two or three matched profiles inside 48 hours, monthly terms, and if the fit is wrong in the first week we replace the engineer.

We work mainly in Ruby on Rails, React, Next.js, JavaScript, Java, Golang, iOS, Flutter and Rust.

Talk to us about a senior engineer