Why don't engineers reply to recruiters, and why is the search slow after layoffs?

Why don't engineers reply to recruiters, and why is the search slow after layoffs?

Engineers reply to recruiters at low rates because most of them already have a job, and the ones who reply the least are the ones a hiring manager wants most. The strongest engineers are heads-down on a system they know well, at a company that pays them fairly. A message about a new opening competes with a full inbox of similar messages for a moment of attention that mostly does not come. That single fact, a strong candidate who is employed and content, explains most of what feels strange about an engineering search: the low reply rate, the long timeline, and the way a round of tech layoffs changes nothing about how hard a specific req still is to fill.

All of this is market shape, and a leader who has never hired an engineer can hold the shape once the pieces are named: how many people are available, what a normal reply rate looks like, how long a search runs, and why the pool for one role stays small even when a headline says thousands of engineers lost their jobs.

What is a passive candidate market?

A passive market is one where the strongest candidates already have a role and no reason to leave it, so almost nobody worth hiring is applying to postings. Outreach has to start the conversation instead of waiting for it. In an active market, a posting draws in the people worth talking to. In a passive one, they have to be found.

Software engineering runs almost entirely on the passive side. Unemployment for the field stays low even in a slow year. A working senior engineer with in-demand skills gets contacted by other companies on a normal week without doing anything to invite it. The people worth pursuing have to be found and reached, one at a time, in the middle of jobs they are not trying to leave.

How many engineers are actually applying?

Fewer than a leader used to hiring for other functions expects, and the shortfall is normal for the field. A posting for a senior engineering role commonly draws a modest stack of inbound applications. A meaningful share of those are a poor match on the tech stack, the seniority, or both. A strong senior engineer with the exact combination a req needs rarely needs to apply anywhere, so the fit inside the inbound stack runs thin.

This is why a serious engineering search runs on outbound conversations layered on top of whatever inbound trickles in. The inbound pool answers "who applied." The outbound pool answers "who is qualified and reachable," and for a specific senior req those are two different lists with only partial overlap.

What do realistic reply rates look like?

Lower than in most other functions, and that gap is the market shape showing up as a number. A message about a role that does not describe the developer's actual stack, scope, and daily work reads as evidence nobody looked at what they build, and gets skipped along with the rest of a crowded inbox. A message built around specifics, the exact technology, the scale of the system, the part of the stack the role actually touches, does noticeably better, but even a strong message is competing with dozens of others that week.

The practical result: the top of an engineering funnel has to be wider than the top of a funnel for a role with a larger active pool, to land the same number of real conversations at the bottom. A low reply rate on an engineering search is the baseline the function runs at, and a plan built on that baseline holds up in front of a hiring manager.

How long does an engineering search take?

Eight to sixteen weeks, from opening the req to a signed offer, is a normal range for a specific senior role. Three things stack to produce that length. The qualified pool is small to begin with. The people in it are mostly employed, so each one has to be found and persuaded. And the process itself has several technical stages once a conversation starts, and each stage takes calendar time to schedule around two busy people's weeks.

Why did the layoffs not fill this req?

A round of layoffs at large technology companies looks, from a distance, like it should flood the market with exactly the people a company needs. It rarely does. A layoff releases whole teams and whole specialties at once, and the combination a specific req needs is usually a different one. A wave of layoffs concentrated in one product line releases people who worked deeply in that product's stack and domain. A req for a different stack in a different domain draws on a different, and often still scarce, slice of the market.

The overall count of engineers released in a bad quarter is a real number, and it says very little about the pool for one open role. The number that matters is how many of them match this specific req, and a layoff rarely moves it by much.

What makes the pool small for this specific role?

The scarcity is combinational, which means each added requirement multiplies the filter instead of adding to it. Start with everyone doing the work at all, narrow to senior, narrow again to the specific stack, narrow again to a domain the role needs, like fintech or healthcare, and narrow one more time to a location or timezone. Each cut removes a share of whatever the previous cut left behind, so four ordinary-sounding requirements can turn a national market of many thousands into a pool of a few hundred people.

Adding a specific discipline on top, an ML engineer rather than a general backend engineer, or a security specialist rather than a generalist, applies the same multiplication again. None of the individual filters looks unreasonable on its own. Stacked together, they explain why a req that sounds ordinary on a job description can still take four months to fill.