Search for Problems

Everything on a resume is written by the person it describes, for the purpose of being selected. For most of the last twenty years that was workable, because writing a convincing resume took effort, and the effort was itself a signal. That part broke. In 2025, LinkedIn was processing about 11,000 applications a minute, up 45% in a year^[1]. Around the same time recruiters were quickly figuring out what an AI-generated resume looks like. A candidate can now generate a five-page resume tuned to your job description in under a minute, and so can the next thousand applicants.

The deeper problem is that technical keywords are an unreliable signal even when the candidate is completely honest. Across a dozen WiFi roles, 40% of applicants wrote "WiFi" on their resume. That word covers the person who integrated a WiFi module into a thermostat, the person who wrote its driver, and the person who designed the MAC the module runs on. Three different jobs, three different skill sets, one word.

In August 2000, an engineer on the Linux kernel mailing list claimed he could build threads that were faster than anything Linux had, in under 8KB each^[2]. Linus Torvalds replied with six words: "Talk is cheap. Show me the code." For twenty-five years that was the right instinct in technical hiring. Now code is cheap too. The instinct still holds. It just has to point at something that is still expensive to produce: proof that someone has solved the problem you are hiring for, on a team that shipped.

What we tested

In our last post, I showed that a keyword search built from a job description misses most of the strong candidates in a technical applicant pool. This time we tested what to search for instead.

We ran six different searches against ~100k applications across 40 roles. We wanted to find out which search surfaced the people the hiring team chose to interview, and the people who were eventually hired.

In the 33 specialized engineering roles, covering hardware, wireless, RF and signal integrity:

• The keyword search built from each job description surfaced under 25% of the candidates who were interviewed.
• A search on past employers or on the problems a resume describes surfaced 57%, from the same pools.
• None of the people hired into these roles matched the keyword search written from their own job description. Two thirds of them turned up in the employer-or-problem search.

Two signals did that work, and they do different jobs.

Employers tell you where to look

The people who can build a thing are concentrated in the organizations that have built it. That sounds obvious, and almost nobody searches that way.

Which employer matters more than whether. Inside the WiFi pools, alumni of Broadcom were strong candidates at nine times the pool's base rate. Alumni of another prominent company came in at half of it. Both make WiFi chips. The useful unit is not the company. It is the team that shipped the thing you are building.

Harvard's Boris Groysberg^[3] found the same thing on Wall Street. He tracked more than 1,000 star analysts. The ones who changed firms alone slipped, and stayed below their old numbers for five years. The ones who moved with their team did not slip at all. A large part of what looked like individual talent belonged to the team. So when you know which team shipped the product, you know where the people who can do it again are standing. Anyone hiring for consumer hardware knows the value of someone from Apple's hardware teams. Anyone building an AI accelerator wants the people who shipped Nvidia's.

What an employer filter does not do reliably is rank people. The spread in candidate quality inside a single employer's alumni was wider than across the entire pool. Where someone worked narrows the search. It tells you little about the specific person. Two engineers from the same team on the same chip are not the same engineer.

Problems tell you who to read

The search that did the most with the least reading was not a company or a tool. It was a problem.

For each role we wrote a short list of problems the engineer would have had to solve on the job. For a WiFi MAC role, that meant rate adaptation, block acknowledgment and packet aggregation. For signal integrity, eye diagrams. For EMC, radiated emissions. Resumes that described two or more of them surfaced 40% of interviewed candidates while returning only 8% of the pool.

This is the part of a resume closest to showing the code. A tools list describes what was in the room. A problem describes what went wrong and what the person did about it. People who spent a year fighting rate adaptation say so. People who were near a WiFi product write "WiFi."

Problems also catch the career pivot, which a keyword search cannot. An engineer who built link-layer scheduling for LTE has worked on the same class of problem as a WiFi MAC engineer, and has almost none of the WiFi keywords.

Where this works, and where it doesn't

The study included six general software roles as a control. There the result flipped: keyword search surfaced 59% of interviewees and the employer list 23%. That is the method telling you when to use it.

Two questions tell you which kind of role you have.

How many organizations have ever built this? A custom MEMS sensor, an RF front end or a high-speed SerDes takes tape-outs, test labs, certification and years of accumulated know-how. Much of that know-how never gets written down. Intel learned this the hard way^[4]: new fabs kept losing yield to differences nobody could explain, so Intel stopped trying to document the process and started copying the original fab exactly. Once it did, new plants matched yield from the first wafer. The knowledge lived in the team and the line, not on paper. A few dozen organizations worldwide have built this kind of capability at scale, so an employer list samples the people who have done the job. A web backend gets built at nearly every company with a product, and many of the strongest engineers work at startups and on open-source projects no employer list would include.

How standard is the vocabulary? In software, the tool is the job. Kubernetes is called Kubernetes everywhere, and someone who lists it has usually used it. In hardware, as the last post showed, the same work goes by different names at different companies. The words vary, so keyword search fails. The builders are few, so employer search works.

Most roles sit somewhere on that spectrum. The fewer places the work gets done, and the less consistent its vocabulary, the more you should search on employers and problems instead of terms. Specialized hardware design roles sat at the far end: employer search surfaced 70% of interviewees, against 30% for keywords.

The signal that arrives already evaluated

Searching gets you to the right people. Deciding among them takes evidence that someone other than the candidate has already vetted, and the strongest version of that is a referral.

A study of nine large firms, published in the Quarterly Journal of Economics^[5], found referred hires were 10% to 30% less likely to quit. At the tech firm in the study, they also produced more patents. The referrals from a firm's own strong performers were worth the most. The reason is simple. A referral carries someone's judgment of the actual work, and it carries their reputation. The more the person referring has to lose, the more the referral is worth.

Most pipelines still treat a referral as one more application in the stack. For a staffing or engineering services firm, the referral network you need already exists: the engineers you have placed, the ones you have worked beside, and the candidates you already vetted for other roles. Ask them who they would hire. It is a sourcing channel that costs almost nothing and arrives pre-screened, and few firms work it on purpose.

References work the same way, on one condition: ask every reference the same specific questions. What did this person own? What would you hire them for again? What would you not?

When you get to the interview, the research is clear about what to measure. A 2022 re-analysis of decades of hiring studies^[6] put structured interviews and tests of job knowledge at the top of the list of predictors of job performance, and years of experience near the bottom. Measure domain knowledge directly. Don't infer it from a word.

Where education fits

Education is real evidence early in a career, and it fades as the work record grows. For an entry-level role, a strong program, a thesis or a research lab is often the most substantial evidence a candidate has. A few years in, what they built and shipped takes over. Google's own hiring data showed this: after two or three years, how someone performed in school had no bearing on how they performed at Google^[7].

The same is true of experience itself. What matters is what someone did, not how many years they did it. A 2019 review of 81 studies found years of prior experience barely predicted job performance at all^[8]. The record of the work carries the signal. The count of years does not.

What to do on your next search

1. Write the problem list first. Ask the hiring manager for five to ten problems this person will have to solve in their first year. Not tools. Problems.

2. Build a team list, not an industry list. Which organizations shipped this, which teams inside them did the work, and roughly when. Short and specific beats long and complete.

3. Search on either, then read for ownership. "Designed," "owned" and "debugged in the field" describe work. "Familiar with" and "exposure to" describe proximity.

4. Look one problem over. The engineer who solved the adjacent problem often transfers better than a weak match on the exact one.

5. Work your referrals on purpose. Your placed engineers and past candidates are a channel that arrives pre-screened.

6. Decide with evidence someone else can check. Structured interviews, job-knowledge questions and structured references.

Where AI tools fit

Most recruiting tools added AI as a faster keyword parser. They automated the step that was already wrong. We built Pairwise around the signals in this post: the problems a candidate has solved, the teams they solved them on, and the evidence someone else has already vetted. The aim is to surface the engineers keyword tools miss, so recruiters spend their reading time on the right people.