Ask an AI infrastructure company what it is hiring for and the answer usually arrives as a list of technologies. A serving framework. An orchestration layer. A vector store. A cloud. Sometimes a specific accelerator.

Ask the same company what that person will actually own, and the answer is different in kind. Keeping inference cost per request flat while usage triples. Holding p99 latency under a number the sales team has already promised. Making sure a node failure at peak degrades the service instead of ending it.

Those are two different briefs, and only the second one survives contact with the roadmap.

Why Tool-Named Briefs Age Badly Here

Every technical market has some churn. AI infrastructure has more of it, for reasons that are structural rather than faddish.

The workloads themselves are unstable. Model sizes, context lengths and usage patterns change what is expensive, and what is expensive determines what the architecture optimises for. A retrieval design tuned for short contexts and small corpora is not obviously the right design when both move by an order of magnitude. A serving setup built for steady batch traffic behaves differently under interactive agentic workloads that fan out unpredictably.

The supply side is unstable too. Accelerator availability, pricing and the economics of committed capacity shift what a sensible fleet looks like from quarter to quarter, and teams change strategy accordingly.

And the tooling layer is young. Categories that did not exist three years ago now have four credible entrants each, which means most infrastructure teams are running at least one component they expect to replace.

Against that background, a hiring process that takes eight to twelve weeks from brief to start date, plus a ramp, is making a bet on stack stability that the company itself is not making.

The Cost of Hiring for Familiarity

The obvious cost is a narrow pool. Requiring three named tools in combination can reduce a market of thousands to a few dozen people, most of whom are not looking, and the ones who are tend to be expensive precisely because the requirement is over-specified.

The less obvious cost is worse. Tool familiarity is a weak predictor of performance at this level, and it is easy to demonstrate. Someone who has operated a system for two years can describe it fluently without ever having been responsible for its cost curve or its failure modes. Screening on the tool rewards exposure. The job requires ownership.

There is also a selection effect that quietly damages the team. Candidates whose experience maps neatly onto the current stack are, by definition, the candidates who have seen one way of doing it. Infrastructure teams get stronger when someone in the room has watched a different architecture fail for reasons the incumbent design has not hit yet.

Hire Against the Constraint

The alternative is to define each infrastructure role by the constraint it owns, and to interview against that.

• Name the constraint, not the component. “Owns cost per thousand requests as traffic scales” is a role. “Experience with framework X” is a preference. The first one tells a strong candidate whether the job is interesting.
• Interview on decisions, not on surface area. Ask what the candidate measured, what tradeoff they chose, what they gave up and how they knew it worked. People who have genuinely owned a constraint answer in numbers and regrets. People who have been adjacent to it answer in architecture diagrams.
• Test transfer explicitly. Give a scenario on a stack the candidate has not used and watch how they reason about it. Strong systems people ask about workload shape and failure domains before they ask about tooling.
• Treat tools as ramp, not as requirement. A competent distributed systems engineer learns a new serving framework in weeks. Nobody learns judgement about tail latency in weeks.

This does not mean tooling is irrelevant. It means it belongs in the context section of the brief rather than the filter, and that the filter should sit on the thing that will still be true in a year.

Where the People Actually Come From

Hiring against the constraint changes where the search runs. The people who have held cost, latency and reliability at scale have usually done it somewhere other than an AI company: large-scale cloud platforms, database and storage internals, streaming and event infrastructure, high-traffic consumer backends, trading systems.

Very few of them describe themselves as AI engineers. Many of them screen out of an AI infrastructure process at the keyword stage, which is a straightforwardly self-inflicted wound.

The screening question that tends to work better than any keyword is simple: what was the hardest thing you have had to keep fast and cheap at the same time, and what did it take? The answers separate people quickly, and they separate them on the dimension the job is actually about.

The Same Logic Applies on the Commercial Side

Go-to-market hiring in AI infrastructure suffers from a mirrored version of the problem. Briefs specify experience selling a named category, when the thing that determines success is whether the seller can hold a conversation with a platform lead who has already built a worse version of the product internally.

That buyer does not respond to narrative. They respond to benchmarks, migration risk and total cost of ownership, and they will bring their own numbers.

So the same substitution applies. Hire sellers and sales engineers who have carried technical evaluations rather than sellers who have carried a logo, and expect the sales engineering hire to arrive earlier in the sequence than a standard software playbook would suggest. In infrastructure the proof of concept is the sales process.

What This Looks Like in a Hiring Plan

Practically, three changes do most of the work.

Rewrite the top third of every infrastructure job description so the first thing a candidate reads is the constraint and the scale it operates at, not the stack. Move the tool list down, and label it as the current state.

Add one transfer exercise to the loop, on unfamiliar ground, and weight it at least as heavily as the stack-specific round.

And check the sequence. If the roadmap for the next two quarters is a migration, hiring deep expertise in the thing being migrated away from is an expensive way to staff a deprecation.

The stack will keep moving. The constraints will not.

At Vector we build technical and go-to-market teams for AI and infrastructure companies from seed to Series B, and this is the conversation we have most often at the start of a search. If you are scoping infrastructure roles into a roadmap that is still changing, I would be happy to talk it through. More on how we work with infrastructure teams here: The Recruitment Agency for AI Infrastructure Companies.