“CUDA required”: how one word in a job spec kept a role open for months

"We need a developer with CUDA. Non-negotiable." That line opened one of the most instructive searches we ran last autumn. A product company building computer-vision solutions, an engineering team in a large city beyond the Urals. The role was rare: 3D graphics plus low-level GPU development, middle level. The vacancy had sat open for months with almost no strong candidates — and, as is often the case, the problem turned out not to be that "there are no people on the market".

Why one word in a spec closes the funnel

When a role is described through a specific technology, only those with that exact word on their CV reach the interview. Behind "CUDA" here stood a broader job: low-level computation on the GPU, graphics, optimisation, shaders. CUDA is one tool for that work, not the only one. An engineer who spent years writing shaders and tuning the graphics pipeline solves the task. Their CV simply lacks the keyword, and the filter drops them first. So the company spent months searching not for someone who would solve the problem, but for someone who matched the wording.

We did not propose "lowering the bar"

Lowering requirements and returning them to the task are different things. We took a few anonymised CVs and showed the hiring manager: here is a person without CUDA but with relevant low-level experience — do they cover what you need in the first months? Once the manager looked at concrete profiles, he agreed: shader experience is relevant here, and CUDA is more honestly kept as nice-to-have than as mandatory. Suitable candidates appeared within days.

The moment it nearly fell apart

Midway through, the client briefly leaned towards an internal candidate and asked us to stop. There was a fork: we could send rejections at once and close the matter. We chose otherwise — held a pause and checked whether the decision was final. A day later it changed. One of our candidates returned to the process, passed the technical interview and became the finalist. Had we rushed the rejection, getting both the person and their trust back would have been far harder.

What the client got

A finalist from the people we presented joined the company; in the first month the client gave positive feedback on them. We keep exact timelines as ranges, but the shape is this: the search had stalled for months, and once the requirements matched the task, weeks passed to the hire. And we kept relations with every candidate intact, even though the role status shifted mid-process. In a market where specialists in one stack know each other, that protects the company's reputation for future hires.

What follows from this

First understand what task a requirement serves, and only then search by technology. A keyword in a job spec saves the author five minutes and costs the company months of search. When a strong role will not close, the first thing we check is not the market but the spec: what it calls mandatory, and whether that mandatory thing solves the real task.