The JD Is Not the Brief
The JD tells you what to hire. It won't tell you how and where to look. Here's a quick review on how some Semiconductor and Product Engineering roles were dealt with.
When a hiring manager sends a JD, most recruiters read it, pull the keywords, and build a search around them.
Logical. Fast. And exactly what everyone else is doing.
The JD describes the role. It doesn't describe the person. That's the gap this post is about.
The DFT Problem
A Semiconductor client came to us with a Design for Testability Engineer requirement. Standard JD. Keywords pulled from it pointed to DFT profiles, but also to PCB Design engineers. Two very different disciplines. One search, two talent pools, a lot of noise.
The JD said DFT. It didn't say how to find a DFT engineer.
So we went a level deeper. DFT practitioners work with specific tools. They write about specific workflows. A PCB engineer doesn't mention Tessent. Doesn't mention DFTMAX or Modus. Doesn't write about scan chain insertion or ATPG pattern generation. Doesn't use Verilog or VHDL in that context.
The boolean that cut through the noise:
((Tessent OR DFTMAX OR Modus) AND (Verilog OR VHDL))
Not a single one of those terms appeared in the JD. But every serious DFT engineer has them in their profile, because those are the tools of their trade, not the vocabulary of a job description.
The Analog Circuit Design Problem
A Low Power, Low Noise Analog Circuit Design Lead. The JD used exactly those words — low power, low noise. Accurate, but generic. Those terms appear on profiles across analog, mixed-signal, RF, and even some PCB engineers.
What does someone who has genuinely done this work write about?
They write about LDOs, bandgap references, OTAs, op-amp compensation. They mention PSRR, CMRR, noise figure. They've run HSPICE or Spectre simulations, sweated over Monte Carlo analysis, and debugged layout parasitics. They've worked in Cadence Virtuoso. They know what a subthreshold design is because they've had to make trade-offs in one.
A PCB engineer doing analog work at board level doesn't carry that vocabulary. A firmware engineer who's interfaced with analog blocks doesn't either.
Search for the practitioner vocabulary, not the JD vocabulary. And the pool sharpens dramatically.
The Android Multimedia Camera Problem
A product engineering role: Android Multimedia Framework Lead, Camera module, HAL layer on Qualcomm hardware.
Search "Android Multimedia Camera" and you'll pull in application-layer Android developers who've used Camera2 API to build camera apps. Competent engineers, completely wrong layer.
The real profile is embedded. Someone who has worked Camera HAL3 on Qualcomm writes about CamX and Chi pipeline architecture. They've worked with the Spectra ISP, dealt with sensor bring-up over I2C, debugged MIPI CSI-2 lane issues. They've written or modified V4L2 drivers, worked inside the Qualcomm camera middleware stack, and have opinions about 3A algorithm integration — AWB, AEC, AF — at the HAL layer, not the app layer.
That vocabulary doesn't appear on an Android app developer's profile. It appears on someone who has been elbow-deep in BSP and camera firmware on Qualcomm silicon.
(CamX OR "Chi pipeline" OR "Camera HAL3") AND (Spectra OR MIPI CSI OR V4L2) AND (sensor bring-up OR device driver OR BSP)
Zero of those terms were in the JD. All of them are on the right profile.
The Pattern Across All Three
Different industries. Different roles. Same underlying problem.
JDs describe outcomes. Practitioners describe processes. The language doesn't overlap the way you'd expect and that gap is where most keyword searches break down.
The recruiter who searches JD language finds the candidate who wrote their profile for a job application. The recruiter who searches practitioner language finds the candidate who wrote their profile for their peers.
The second pool is almost always better. And smaller. Which is the point.
What This Requires
It requires knowing or being willing to research what the work actually involves at the tool and technique level. Not at the outcome level. Not at the category level.
That's the skill. And it compounds. Every role you go deep on, you build a sharper mental model of that domain. You start to recognise the difference between a profile that has lived the work and one that has described it from a distance.
The boolean string is just the output. The thinking that produces it is the differentiator.
