The 60-Minute Build: How May 2026's HN Hiring Thread Buried the Take-Home

If you skimmed the May 2026 "Ask HN: Who is hiring?" thread (item 47975571, posted May 1 by katee) and thought it read differently from a year ago, you're right. The job descriptions don't lead with languages or frameworks anymore. They lead with tools: Cursor, Claude Code, Copilot, Replit. And the screen most of them are running has quietly changed shape too. The take-home is gone. In its place: a 60-minute live build, screen shared, founder watching.

This isn't a stylistic shift. It's a funnel redesign, and if your loop still opens with a 4-hour async assignment, you're now competing for senior candidates against companies that promise an offer in two weeks.

What the May 2026 thread actually shows

Read the thread cold and three patterns jump out.

First, the JDs name AI tools by brand. IBM Research is hiring early-career scientists for LLMs combined with programming languages, formal methods, and compilers, with Rust as a plus. Mobian split its Senior/Staff posting into two tracks: Core Systems and "AI Prototyping" with LLMs and browser automation, requiring 10+ years and an explicit "AI-first mindset." A Technical Forward Deployed PM listing asks candidates to "build and prototype client deliverables using the latest AI tools." Loophole Labs, Estuary, OpenVPN: all carrying the same language.

Second, the screen has compressed. Several posts describe a 60-minute live build, often a multi-source LLM tool, with the founder on the call. The pitch is that an offer comes within two weeks if you clear it. Self-selection does most of the work before anyone gets on a Zoom.

Third, there is now a dedicated aggregator (AITMPL) that indexes job openings requiring Claude Code in their stack, updated daily from HN, RemoteOK, and elsewhere. When a job board exists for a single tool, that tool has become a screening axis.

The thread is a lagging indicator

Sierra published its new interview loop in late April 2026 and was explicit: they removed coding and algorithms interviews entirely and replaced them with a Plan/Build/Review onsite. The Build phase is two hours where the interviewer steps out and the candidate ships using whatever AI tooling they want. Sierra also did something subtler. They replaced the no-AI coding phone screen with a system design interview, on the logic that "vibe-coding an app is easy" and the harder problem is shipping it to production.

Canva went earlier, in mid-2025, with the inverse policy framed as permission rather than a redesign: backend, ML, and frontend candidates are now expected to use Copilot, Cursor, and Claude during technical interviews. Canva's own number is the tell.

~50%

And then there's Meta. In October 2025, Meta began piloting an AI-enabled coding interview that replaces one of the two coding rounds at the onsite: 60 minutes in a specialized CoderPad environment with an AI assistant built in. The model menu includes GPT-5, Claude Sonnet 4 and 4.5, Gemini 2.5 Pro, and Llama 4 Maverick. When FAANG runs a 60-minute AI-assisted round, the May 2026 HN thread isn't the leading edge. It's the wave hitting the shore.

Why the take-home died (it wasn't philosophy)

The convenient story is that founders had a collective epiphany about candidate experience. The honest story is that take-homes stopped producing signal.

A Karat survey cited by IEEE-USA finds 63% of U.S. employers still use automated code tests and 45% use take-home tests. Recruiter Mahesh Bhende, in the same piece, is blunt: "We're seeing a marked decline in the code tests because they're assessing skills that are no longer as relevant. I don't think these tests are currently on a trajectory to survive."

The structural reason is the candidate-side arms race. Interview Solver, LockedIn AI, and Ultracode openly market "complete undetectability during screen sharing" via desktop app architecture and global hotkeys, designed specifically against CoderPad, HackerRank, and CodeSignal. If you can't tell whether the candidate or the copilot wrote the take-home, the take-home has negative signal: it filters for honesty, not skill.

The live build, watched on screen-share, is partly a security response. The take-home died because cheating got too good. </pull>

pull The live build, watched on screen-share, is partly a security response. The take-home died because cheating got too good.

There's a real funnel number here too. One European vendor reports that three years ago, 30-40% of candidates who passed the take-home failed the live interview. With AI-assisted vetting and live-build formats, that drop-off compresses to 10-15%. That's not a small efficiency. That's the difference between an offer in two weeks and an offer in six.

## The contrarian read: 60 minutes is a senior filter

The reflex is to call the live-build format speed-based hazing. It isn't. A 60-minute build advantages engineers who can scope a problem, prompt a model usefully, and recognize when the output is wrong. Those are senior skills. The losers are mid-level engineers who memorized LeetCode patterns and never built the muscle of cutting scope under pressure. If your last three senior hires came in through 4-hour take-homes that they finished at midnight on a Sunday, you were probably already filtering on the wrong axis.

This is also why "top 1% Cursor user" in a JD is doing more work than it looks. The phrase is a self-selection trap: experienced engineers who use the tool daily read it and apply; everyone else scrolls past. The screen happens before the screen.

The hard part for sourcers is that "Cursor user" doesn't show up cleanly on LinkedIn. Skill listings lag tool adoption by 18-24 months, and most senior engineers don't update their profile to add a tool they've used for six months. You end up Boolean-searching GitHub for `.cursorrules` files, scraping Discord, reading commit messages for Claude Code attribution lines. It's the kind of search that's trivial to describe and miserable to execute, which is exactly the gap we built [Refolk](/) for: you describe the person in plain English ("senior backend engineer, ships with Cursor or Claude Code, has a public side project using an LLM API in the last six months") and get a ranked shortlist across GitHub, LinkedIn, and the open web.

## The "no AI" holdouts are signaling, not lagging

Before you copy Sierra's loop wholesale, read Anthropic's candidate guidance page. It's explicit: "During live interviews This is all you, no AI assistance unless we indicate otherwise. We're curious to see how you think through problems in real time."

That isn't a company that hasn't caught up. It's a company telling you what it values: research depth, first-principles reasoning, the ability to articulate a tradeoff without a model in the loop. If your actual work is safety research, low-level infra, or compiler-adjacent, copying the 60-minute live build will filter for the wrong skill. The right interview tests for the work, not for the trend.

The framing question is simple: on a Tuesday in week six, is the engineer reaching for Claude Code, or are they reading a paper? Build the screen for the answer.

## A retrofit playbook that doesn't scare off seniors

If you're a founder or eng leader staring at your current loop and wondering what to change first, here's the order that maps to what's actually working in the May 2026 thread.

### 1. Rewrite the JD before you touch the loop

The JD is the filter. Name the tools you actually use: Cursor, Claude Code, Copilot, Replit, Greptile, Lovable, whichever apply. Be specific about the kind of AI engineer hiring bar you have. "Comfortable with LLM tooling" filters nothing. "You've shipped at least one production feature where the majority of code came through Cursor or Claude Code in the last 90 days" filters hard, and the right candidates self-identify in the first sentence of their reply.

### 2. Replace the phone screen first, not the onsite

This is the Sierra move that founders miss. The phone screen is the part of the loop that broke first, because it's the cheapest place for a candidate to use an undetectable copilot and the easiest place to lose a senior to ghosting. Swap your no-AI coding screen for a 45-minute system design conversation about a real problem in your stack. You'll get better signal and better completion rates without redesigning the onsite.

### 3. Add a 60-minute live build, but scope it honestly

If you're going to add a live build, make the scope something a senior can actually finish. The representative HN post, "ship a multi-source LLM tool in under a day," is a real-job proxy, not a stunt. Give the candidate the API keys, the repo, and the goal. Step out of the room for the middle 40 minutes. Come back for a demo and a code review.

### 4. Commit to the offer timeline publicly

The reason "offer in two weeks" works as a recruiting line is that it's a forcing function on you, not the candidate. If your loop can't compress to two weeks, the live build alone won't save you, because senior candidates with three offers in flight will take the company that decides fastest.

5. Source against the JD you just wrote

This is where most loops break. You rewrote the JD to filter on Cursor and Claude Code interview fluency, but your sourcing is still keyword-matching "Python" and "AWS" on LinkedIn. The signal you actually want lives in GitHub commit messages, dotfile repos, blog posts about prompt patterns, and Discord communities for specific tools. That's the kind of cross-source query Refolk handles in one prompt instead of seven Boolean searches, which matters when your offer clock is two weeks.

What this means for the rest of 2026

The May 2026 HN thread is the most public artifact of a shift that's been brewing for 18 months, and it won't reverse. The ship in a day requirement won't show up in every JD, but the underlying logic (front-load the filter, watch the candidate ship, decide fast) will. Take-homes will keep dying because the cheating tools keep getting better, not because anyone wakes up and decides to be kind. Companies that want senior engineers will keep compressing the loop. Companies that don't will keep losing them to the ones that do.

The right response isn't to copy Sierra's onsite. It's to ask which part of your loop is currently producing the worst signal, replace that part, and source against the JD you actually wrote.

FAQ

Is the 60-minute live build appropriate for staff and principal engineers?

Yes, with adjustments. At staff and above, the build itself is less interesting than the conversation around scope, tradeoffs, and what the candidate chose not to do. Run the 60 minutes, then spend a second hour on the design review. The senior signal lives in what they cut, not what they shipped.

How do I know if a candidate cheated on a take-home using something like LockedIn AI?

You mostly can't, which is the point. Tools like Interview Solver, LockedIn AI, and Ultracode advertise undetectability on Zoom and CoderPad as a feature. The live, screen-shared, watched build exists because async assessments have negative signal in 2026. If you must keep a take-home, treat it as a filter for interest, not skill, and put the real assessment on a live call.

What if my engineering culture genuinely prohibits AI tools in production?

Then build the interview for the work, not the trend. Anthropic's candidate guidance is the model: explicit, principled, no-AI live rounds because the job involves research depth that a copilot would short-circuit. The mistake is being unclear. Tell candidates exactly which rounds allow which tools, and why, before they show up.

How fast does sourcing actually need to be to support a two-week offer cycle?

Faster than most teams currently run. If you've committed to an offer in two weeks, you need a qualified candidate in the loop within 48 hours of opening the role, which means sourcing has to be a same-day activity, not a same-week one. That's the use case Refolk was built for: a plain-English query returns a ranked shortlist across GitHub, LinkedIn, and the open web in minutes, so the bottleneck moves back to your loop where it belongs.