Every snapshot starts with a number: how many people actually match. Get the search wrong and you either drown in false positives or shrink a real pool to zero. This is the craft of counting right.
A pool number is only as good as the search behind it. Four things quietly corrupt the count before you even read it.
One job hides behind a dozen titles. An analog designer is also "mixed-signal," "AMS," or a company's "Member of Technical Staff." Search one title and you miss most of the pool.
The real signal lives in the experience section, not the headline. Someone who designs in Cadence Virtuoso may never put "analog" in their title. Title search alone undercounts.
ANDing every nice-to-have collapses the pool to a handful. Each extra must-have cuts the count — only AND the 3 to 5 that genuinely gate the job.
Search too broad and you sweep in students, professors, technicians, and sales engineers. A count without exclusions is inflated and won't survive scrutiny.
Two ways to count. Title-based is fast and wrong at the edges; skills-based is accurate and slower. The pros use both.
Anchor on skills, validate with titles. Build the search around the must-have tools and capabilities, then sanity-check the result against expected titles. Labor-market platforms like Lightcast and Draup solve title sprawl for you with normalized occupation taxonomies — you search the concept, not the raw text — which is why they often beat a hand-built LinkedIn string for pure sizing.
A good string has four blocks. Get the structure right and the rest is just filling in synonyms.
OR within a block to widen (catch every variant). AND between blocks to narrow (require each must-have). NOT to clear the noise. Each AND block should be one of your 3 to 5 true must-haves — no more.
("analog design" OR "analog IC" OR "mixed-signal" OR "analog/mixed-signal" OR "AMS design" OR "Member of Technical Staff")
AND ("Cadence Virtuoso" OR Spectre OR SPICE OR "Verilog-A")
AND (CMOS OR "circuit design" OR schematic OR layout)
NOT (intern OR student OR professor OR "teaching assistant" OR sales)
("CUDA" OR "GPU kernel" OR GPGPU OR "parallel computing" OR "compute kernel" OR "ML systems")
AND ("C++" OR Triton OR cuDNN OR ROCm OR "kernel optimization")
AND ("high performance computing" OR HPC OR "low-level" OR performance)
NOT (intern OR student OR recruiter OR "game developer")
("RFIC" OR "RF IC" OR "RF design" OR mmWave OR "millimeter wave" OR "RF integrated circuit")
AND (ADS OR HFSS OR "Cadence AWR" OR Spectre OR "Smith chart")
AND ("5G" OR transceiver OR "power amplifier" OR LNA OR PLL)
NOT (intern OR student OR "RF technician" OR sales)
Platform note. In LinkedIn Recruiter, push titles and companies into the dedicated filters and keep Boolean for skills — cramming everything into one string fights the native filters. For free searching, a Google X-ray (site:linkedin.com/in + Boolean) works but has coverage gaps. On Lightcast or Draup, search the normalized occupation, not raw titles.
AI is fastest at the tedious parts: turning a job description into a string, expanding every synonym and acronym, and reconciling counts that disagree across platforms.
Here's a job description. Build me a LinkedIn Recruiter Boolean string.
Rules:
- OR together all realistic title variants, including company-specific
titles like "Member of Technical Staff" where relevant
- AND only the true must-have skills (3-5 max); OR their synonyms,
acronyms, and spelling variants within each block
- Add a NOT block for likely false positives: students, professors,
technicians, sales engineers
Don't include the wishlist — just what genuinely gates the job.
[PASTE JOB DESCRIPTION]
For the role of [analog IC designer], give me:
1. Every job-title variant used across industry, grouped by seniority
2. Company-specific titles (e.g. Member of Technical Staff, Principal
Engineer) and which companies use them
3. The canonical must-have tools/skills, each with all common synonyms,
acronyms, and spelling variants
Format it so I can paste the groups straight into a Boolean search.
I sized the same role on three platforms and got different counts: - [Platform A]: [n] - [Platform B]: [n] - [Platform C]: [n] Help me reconcile. Which gaps are coverage bias vs. real differences, and what's my best single estimate of the addressable pool for [role] in [geo]? Flag anything I should NOT do (e.g. summing across platforms).