Refolk
May 20, 2026·9 min read

May's HN Thread Wants Two-Track Engineers. LinkedIn Has ~106,000 Wrong Profiles.

The May 2026 Ask HN hiring thread keeps asking for one engineer to ship core systems and LLM prototypes. Here is how to actually source them.

two-track engineer sourcingAI prototyping engineercore systems plus LLM engineerHacker News May 2026 hiringhybrid AI engineer sourcing
May's HN Thread Wants Two-Track Engineers. LinkedIn Has ~106,000 Wrong Profiles.

Scroll the May 2026 "Ask HN: Who is hiring?" thread (item 47975571) and you keep seeing the same shape: one engineer, two tracks. Production APIs, Kubernetes, cost SLOs on Monday. MCP servers, agent eval, browser automation on Tuesday. The job posts are explicit about it, and almost none of them map to a clean LinkedIn title.

That is the sourcing problem for the next 90 days. Recruiters with a boolean string and a title filter are about to hand engineering leaders the wrong shortlist.

What the May 2026 HN thread is actually asking for

The thread reads differently than it did even six months ago. The composite role is no longer a startup-CTO quirk. It is the default Senior/Staff ask.

A few concrete examples from postings live this week:

  • Brandfetch wants one backend engineer to own an MCP server that exposes structured brand data to LLMs and agents, plus sub-50ms vector search, plus real-time Stripe metering, on a Node/TypeScript/Python/AWS Lambda/DynamoDB/CloudFront stack. One person. Two tracks.
  • A Stream-style real-time infra company is hiring a single Lead Engineer to write code most of the day across Chat, Video, Activity Feeds, and AI Moderation that already serves Strava, Bumble, eBay, and Patreon at billions of API requests/month, while also owning cloud cost optimization, SLOs, and Kubernetes/CockroachDB architecture.
  • Emergences.ai posted an "AI / Systems Engineer" role that asks candidates to describe a system they have built across desktop software, AI infra, data pipelines, evaluation, or low-level debugging. The slash in the title is the whole point.
  • Loophole Labs is the extreme version: a single engineer fluent across Go, Zig, Rust, C, eBPF, CRIU, and Kubernetes. Their 70 public repos (logging, criu, gvisor, xdp, frpc-go, firecracker-go-sdk) confirm that the stack is not aspirational. It is what their code already looks like.

These are not "wear all hats" seed-stage ads. Brandfetch has paying customers. Stream powers Fortune 100 apps. Loophole Labs ships infra used by the firecracker/gvisor crowd. The two-track framing is now mid-market hiring, not founder LARPing.

Why LinkedIn boolean breaks against this role

The two tracks live in different vocabularies, and almost no one self-tags both even when they do both.

"Core systems" candidates list Kubernetes, Terraform, Go, Rust, eBPF, distributed systems. "AI prototyping" candidates list LangChain, RAG, agents, eval, vector DBs. Run a US filter for engineers carrying both Kubernetes and LangChain and you get a real but misleading pool: around 106,000 profiles, with the top titles skewing to CXO, Founder, and CTO. Those are small-company "I do everything" headlines, not the Senior/Staff IC who actually ships across both tracks.

106,000
US LinkedIn profiles carrying both Kubernetes and LangChain
Top titles skew to CXO/Founder/CTO, not the IC the HN thread is asking for.

There is a second, nastier failure mode: stack drift. A 2022 Data Scientist who picked up LangChain in 2024 is, in 2026, calling themselves an AI Engineer. Their LinkedIn skill tags look correct. Their last shipped production system is a Jupyter notebook. Title and skill filters cannot tell them apart from the engineer who just pushed an MCP server to a paying customer's stack.

The stack matters less than the deliverable. Look at what they have shipped, not what they list under skills.

So the boolean either over-collects (the 106k pool, full of generalists and stack-drifters) or under-collects (the handful who happen to list both vocabularies, who are mostly CTOs not open to IC roles). Neither is a shortlist.

The market is tighter than the title problem suggests

The macro numbers explain why founders are writing these composite JDs in the first place.

US median comp for AI Engineers is $185K (BLS OEWS 2026), with LinkedIn's Future of Work Report putting YoY demand growth at 74%. ML Engineers sit at a $165K median with 38% YoY demand growth. MLOps, the prototype-to-production specialty that the two-track engineer is really doing, has seen 9.8x growth over five years on LinkedIn and a 52% YoY demand bump in the last cycle.

Across the broader AI engineering category, there are roughly 1.6 million open positions against about 518,000 qualified candidates, or 3.2 openings per candidate. Narrow to production-grade AI agent work and credible estimates put the ratio at 6 to 8 openings per qualified engineer.

6 to 8
Open positions per qualified production-AI engineer
The two-track JD is a response to this ratio, not a vanity ask.

One small startup in the same May thread shared the unvarnished version: 93 candidates vetted across two months, one Senior AI/Backend Engineer hired to own a Gemini 3 Pro/Flash pipeline on a Django + Flutter stack with human-in-the-loop verification. 93 to 1. That is the funnel for this role today if your top of funnel is wrong.

Why founders are betting on consolidation, not specialization

Most AI staffing guides written in the last year argue the opposite of what the HN thread is doing. The standard line is that "the demand for AI-curious generalists is giving way to a need for highly specialized experts." HN founders, in aggregate, are betting the other way.

The reason is not budget. It is handoff cost. The bottleneck in shipping LLM features in 2026 is not "we cannot hire a prototyper" or "we cannot hire an SRE." It is the round-trip between them: the prototype that works in a notebook, the infra team that has to re-implement it, the eval harness nobody owns, the cost regression that lands in production a week later. Cutting that handoff by hiring one person who can hold both ends is, for a 20-person engineering org, faster than hiring two specialists and a tech lead to coordinate them.

That is also why "evaluation expertise" keeps showing up as the dividing line in the JDs. Measuring LLM quality, groundedness, and reliability is the seam where the two tracks actually meet. An engineer who can write the eval is, by construction, someone who has shipped both a prototype and the infra that grades it.

Where to actually source the two-track engineer

If LinkedIn boolean returns the wrong pool, the fix is not a better boolean. It is a different signal.

1. Read the HN thread the other way around

The companion thread, "Ask HN: Who wants to be hired?" (item 47975570), posts the same week. The two-track engineer is statistically more likely to read HN than to optimize a LinkedIn headline, and the candidates who post there self-describe in the same vocabulary the JDs use. FUTO (futo.tech), one of the Austin shops in the May thread, has said outright that they have hired five employees from these HN postings. That is a working channel, not a folk theory.

2. Mine specific GitHub contributor graphs

Loophole Labs is the cleanest case. If the JD names CRIU, eBPF, and firecracker, the candidate set is the contributor graphs of cilium/cilium, firecracker-microvm/firecracker, google/gvisor, checkpoint-restore/criu, and the company's own 70 public repos. That is a few hundred named humans, globally. LinkedIn will surface maybe a third of them, and the ranking will be wrong.

This is exactly the friction we built Refolk to remove: instead of stitching together a GitHub query, a LinkedIn boolean, and a guess about who is actually senior, you describe the person in plain English ("staff-level engineer who has shipped both an MCP server and a Kubernetes operator in the last 18 months, US or EU") and get a ranked shortlist across GitHub, LinkedIn, and the open web in one pass.

3. Use shipping evidence as the filter, not skill tags

Per Second Talent's read of the market, the right screen is "look at what they have shipped, not what they list under skills." Concretely: recent commits that touch both a vector store and a production deploy file; PRs that wire an eval harness into CI; blog posts that describe a prototype going to prod with cost numbers attached. These are searchable signals. Skill tags are not.

4. Treat OSS-adjacent communities as primary, not secondary

The MLOps Discord, LangChain Discord, Hugging Face spaces, and Kaggle profiles are where the two-track engineer actually argues about eval methodology. Synthesia, hiring across DE/UK/CH/ES/IE/SI/DK/CZ/BE in the same May thread (Series E, used by over 90% of the Fortune 100, backed by Accel, NVentures, Kleiner Perkins, GV), is fishing in exactly these ponds, not in LinkedIn Recruiter's "AI Engineer" filter.

5. Stop screening on title. Screen on the seam.

The interview question that separates the two-track engineer from the stack-drifter is some version of: "Walk me through the last time you took an LLM prototype to production, and tell me what broke that you did not expect." If they cannot describe an eval that caught a regression, a cost spike that forced a rewrite, or a latency budget that killed a model choice, they are one of the 106,000, not one of the few hundred.

A 14-day plan for one of these roles

If you have a Brandfetch-shaped or Loophole-shaped req open right now:

  1. Day 1 to 2. Pull the JD apart into two skill graphs (core systems vocabulary, AI prototyping vocabulary) and the seam (eval, MCP, cost on inference, latency budgets).
  2. Day 3 to 5. Mine GitHub contributor graphs for the named repos in the JD's adjacencies. Cross-reference HN "Who wants to be hired" posters from the May thread. Refolk handles both passes in one query if you would rather not script it.
  3. Day 6 to 9. First-touch the top 40 with a message that quotes one specific thing they shipped. No "saw your profile" openers. The two-track engineer ignores those at a higher rate than the median candidate.
  4. Day 10 to 14. Screen on the seam question above. Expect a 93-to-1 funnel if your top of funnel was wrong, and a 20-to-1 funnel if it was right.

The companies winning this hire in May 2026 are not the ones with the best LinkedIn Recruiter seats. They are the ones who have stopped pretending the title exists.

FAQ

Is "two-track engineer" a real title I should search for?

No, and that is the point. It is a hiring shape, not a label candidates use. Searching for the literal phrase on LinkedIn returns essentially nothing useful. The candidates who fit the shape describe themselves as Senior Backend Engineer, Staff Infrastructure Engineer, AI Engineer, or just "engineer." Source on shipping evidence, not on the phrase.

How is this different from hiring an MLOps or AI Platform engineer?

MLOps and AI Platform roles are real and growing fast (9.8x on LinkedIn over five years, 52% YoY demand). The difference is direction: MLOps engineers productionize models other people built. The two-track engineer in the May HN thread is expected to build the prototype and productionize it, often in the same sprint. The seam is internal to one head, which is what cuts the handoff cost the founders are optimizing for.

What signals on a profile actually predict the two-track engineer?

Recent commits that touch both inference code and deployment config in the same repo. A public eval harness, even a small one. A write-up that includes a cost or latency number from a real deployment. Maintainership of an OSS project at the seam (vector stores, agent frameworks, observability for LLMs, MCP tooling). These beat any combination of skill tags or job titles.

Can I do this without leaving LinkedIn?

Partially. You can find some two-track candidates with a careful boolean, but you will miss the OSS maintainers and HN regulars who are the highest-signal portion of the pool. The pragmatic move is to use LinkedIn for outreach and a tool like Refolk to assemble the shortlist across GitHub, LinkedIn, and the open web in one pass, so the candidates you message are the ones the JD was actually written for.

Read next