Hey everyone, Neil here. You're reading High-Signal Hiring. Hiring systems from 20+ years of global recruitment experience and 500+ technical hires. Zero noise and instantly actionable.
Last issue we covered the screen filter for the vibe coder. One question, three signals on whether your candidate is managing the AI or being managed by it.
This week, the macro hiring story everyone is reading wrong, and what that misread is costing founders right now.
Marc Benioff announced Salesforce didn't hire any new engineers in fiscal year 2026. The clip has been doing the rounds on LinkedIn for weeks, and I'm watching founders take two very different actions on the back of it. Some are pausing their own engineering hires, worried they're behind the curve. Others are hiring but optimising for the engineer who reads most like a Salesforce engineer, the one who closes tickets cleanly and ships features against well-defined specs.
Both are expensive mistakes. The Salesforce story is real, but it's not the story you think it is. The Pragmatic Engineer's 2026 state-of-the-market piece is the single read I'd recommend if you're hiring engineers right now. It's the data behind everything below.
Not a subscriber yet? Sign up here
| The split that's happening
Software engineer job postings are up 11% year-on-year. AI-skilled job postings are up 144%. The market is not contracting, it's bifurcating. Demand for one type of engineering work is collapsing. Demand for another type is climbing faster than anyone is hiring for.
The split is on task type, not company type. Agents have got genuinely good at well-bounded, spec-driven, repetitive work. Maintenance tickets on a legacy codebase, integration plumbing between known systems, internal tooling refactors, CRUD endpoints with clear requirements. Anything with a definition of done that can be written down before the code is written.
What agents still struggle with is the work where the spec doesn't exist yet. The problem is half-defined, the success metric is "did it move the number" instead of "did it pass the test", and judgment is doing more of the work than syntax. That category is shrinking nowhere. The market for it is heating up.
Salesforce engineering, like most enterprise engineering on a 25-year-old product, is heavily weighted toward the first category. Your startup is the opposite. Copying the Salesforce hiring playbook is copying the wrong company's problem.
| Read Salesforce's own data, not their press release
Benioff's "no new engineers" line is comms cover for a margin decision. The directional truth is real, agents are eating some of the work, but the size of the substitution is substantially overstated. Look at what the company is actually doing rather than what they're saying. Salesforce has publicly committed to hire over a thousand Forward Deployed Engineers across Agentforce and Data Cloud. That's the same labour pool, under a different title, for the work agents can't substitute. The headline says "didn't hire engineers." The hiring plan says "hired a thousand of a specific kind."
Meta and Microsoft are doing the same. Layoffs in one part of the org, aggressive AI hiring in another. The aggregate looks flat, the narrative says "AI replaced engineers", but the labour shift is happening on the task axis underneath the headline.
If you're a founder watching this and pausing your own hiring plan, you're reading the front page and missing the engine room.
| Your problem is the inverse of theirs
A startup engineering org has very little of the work agents are eating. You don't have a 25-year-old codebase to maintain. You don't have a backlog of well-specified tickets queued up by a PM org. You have the opposite: a half-built product, problems nobody has solved before, and a roadmap that's going to change next month.
That means two things for your next hire.
One, you cannot substitute agents for the work your startup actually needs done. The reflex to "do more with less" by leaning harder on Cursor and Claude Code is fine for the production code your existing engineers ship. It's not a substitute for hiring the engineer who is going to figure out what to build next.
Two, the engineer most at risk of being substituted in eighteen months is the one whose CV looks great today. The ticket-closer, the integration specialist, the engineer who delivers consistently against a well-defined backlog. They look senior because the work has been productised by clean processes around them. When the work itself becomes substitutable, the productisation goes with it. You'll have hired a comfortable maintenance engineer at a time you needed someone comfortable with chaos.
| Three questions to use now
Include these in your "Mission" interview (or founder screen…whatever you do first) Each question is anchored in actual work the candidate has done, not hypotheticals.
1️⃣ Walk me through a moment you shipped something without a spec
The ticket-closer reaches for a story about negotiating a clearer brief from a PM, then executing it well. That's a fine story for the wrong job. The ambiguity-builder describes a moment they wrote the spec themselves, or worked through a problem where no spec existed yet. They tell you what they decided not to do, and why. Spec authorship is the signal.
2️⃣ Tell me about something you deliberately didn't build
The ticket-closer doesn't have an easy answer. Their job is to build the next thing on the list. The ambiguity-builder has multiple answers, and the reasoning is product-oriented, not engineering-oriented. They killed a feature because it wouldn't move the metric, or pushed back on a project because the underlying assumption was wrong. You can't train this in.
3️⃣ Name a system you owned end to end. What would you do differently?
The word is "owned", not "contributed to" or "worked on." The ticket-closer has worked on lots of systems. The ambiguity-builder can name one, walk you through the architectural choices, and describe what they'd change with what they know now. Ownership plus reflective revision is the closest thing to a leading indicator of judgment.
Two strong answers out of three, you're talking to a startup-grade engineer. Two weak answers, you're talking to someone who needs a ticket queue to function and is about to find that queue heavily automated.
| Pair it with the vibe coder filter
Run this alongside the Issue #25 PR-walkthrough question. Together, they take eight to ten minutes inside the Mission interview / 1st round, and they cover the two failure modes that hurt startups most right now. One filters for engineer-as-agent-manager. The other filters for engineer-as-ambiguity-handler. Both signals matter. Neither shows up on a CV.
The Salesforce headline tells you very little about what to do in your hiring loop this month. The substitution happening underneath it tells you everything. The work you most need done is not the work that's being automated, and the engineer most worth hiring is the one whose value would not show up cleanly on a Salesforce performance review.
Cheers
Neil