Hiring with Cursor: review candidates the way you review pull requests

Think about the last pull request you merged.

You didn't merge it because the author went to a good school. You opened it in Cursor, read the diff against what it was meant to do, ran it, asked the agent where it would break, and left a comment on the one line that worried you. Ten minutes, and you knew more about how that person thinks than any interview could tell you.

Now think about how you hired them.

A résumé. A recruiter screen. A 90-minute pairing session where two of your engineers watched a nervous stranger type in an unfamiliar editor, with the agent switched off "to be fair". You learned how they perform under observation. You learned almost nothing about how they'd work in your codebase on a Tuesday, with Cursor's agent doing half the typing.

This guide is about hiring the way you already review code: on the work, in your editor, against clear criteria. It covers how to do it with Cursor alone, the rules file and checklist to use, and an interview format that shows how someone steers an agent. Then I'll show you how Laand runs the whole thing: you start the hunt from the code your hire will own, and review their verified work in Cursor before you ever meet them.

People worth hiring want to be reviewed, not interviewed

On Laand's talent side, we see the same pattern over and over: the strongest people stop sending résumés and start sending solutions.

Emmanuel Omole, a senior product designer, put it in one line: "I stopped sending standard resumes, started sending solutions, and got the interview." He was interviewing with Miro's Head of Design 48 hours later.

That's what high-agency people do.

They don't wait for a process to discover them; they show the work. If your process can't receive that, can't read it, review it and act on it as fast as you'd review a pull request, the best ones go to the company that can.

Why the pairing interview stopped working

Live pairing was the best hiring tool engineering teams had: watch someone code, see how they think. Three things broke it.

The agent changed what "coding" means. In the 2025 Stack Overflow Developer Survey, 84% of developers use or plan to use AI tools. Pairing with the agent switched off tests a workflow nobody uses. Pairing with it on tests how fast someone can read a stranger's codebase while being watched.

The real skill is invisible in 90 minutes. The same survey found 66% of developers' top frustration is AI output that's "almost right, but not quite". The engineers you want catch the "almost". That shows up in a few hours of real work with a log, not in a timed session where everyone's trying to look fluent.

It's expensive. Count it: four finalists, two engineers each, 90 minutes plus prep and debrief. That's 16 to 20 engineer-hours per hire, most of it your senior people. On a team of nine, that's a week of someone's output, spent learning how people handle nerves.

What you're reviewing for

Read a candidate's work the way you'd read a PR from a new teammate. Here's the checklist, with the steering signals that matter in a Cursor-native team.

How to hire with Cursor today

1. Find the work in the code

Open Cursor in the repo your hire will own and ask the agent to find the job.

Look at src/onboarding and the TODO/HACK comments in it. What's the one
outcome a new product engineer should own in their first 90 days? Name
the files, the user-facing symptom, and what "fixed" would measurably
look like.

Your codebase already knows why you're hiring. A comment like // 61% of trials never finish step 3. Nobody owns this. is a better job description than most job descriptions.

2. Write success criteria like acceptance criteria

Turn that outcome into 3 success criteria for a 4-hour micro-project,
each one checkable: a test, a measurement, or a visible behaviour.

3. Build the micro-project on a fictional copy

Ask the agent to recreate the problem in a small standalone app, with none of your code or names. Same shape of problem, safe to share.

4. Add a review rules file

Create .cursor/rules/candidate-review.mdc in the repo where you'll review submissions:

When reviewing a candidate submission:
- Judge against the success criteria in BRIEF.md, one by one.
- Read DECISIONS.md and ai-log/ before the code. Compare what they say
  they did with what the diff shows.
- Flag any change to tests or test config.
- Never use names, commit authors or links to judge the work.
- For every concern, cite file and line.
- End with three interview questions about their own decisions.

Now every reviewer on your team, and the agent, reads every submission the same way.

5. Replace pairing with a "steer your own work" session

This is the interview format I'd recommend to any Cursor team. Thirty minutes, on a video call, in the candidate's own submission:

"Extend your solution so it handles a 50,000-row import without blocking. Use the agent however you normally would. Talk us through it."

You're not watching them type. You're watching them steer: how they frame the ask, whether they read the diff, when they overrule the agent. Because it's their own code, nerves matter less, and a proxy or a faked submission falls apart in minutes.

Where it breaks on a small team

The playbook works. But before you've hired anyone, you've also had to:

1. find candidates worth reviewing;
2. build a fair work sample with checkable criteria, without leaking your code;
3. create repos, invite people, start each person's clock fairly, and freeze each submission;
4. keep reviewers from seeing names and GitHub handles before the work;
5. pay people, and keep the record of who decided what.

That's the part Laand does by default.

Hiring with Cursor, end to end, with Laand

Step 1: Connect Laand to Cursor

Add Laand to your Cursor MCP settings (mcp.json):

{
  "mcpServers": {
    "laand": { "url": "https://laand.me/mcp" }
  }
}

Cursor asks you to sign in to Laand the first time you use it. Each engineer connects their own Cursor, with their own role.

Step 2: Start the hunt from the code they'll own

With the repo open, in the agent panel:

Laand, hire a product engineer to own onboarding. Start from src/onboarding and the TODOs in it.

Laand fills the hunt from what the agent read (milestone, core problems, stack) and asks only for the stipend and the start date. Only the summary reaches Laand. Its Deep Analysis turns it into core problems and micro-projects with checkable success criteria, recreated in a fictional app.

Step 3: Laand builds the work sample and runs the gates

For code micro-projects, Laand generates the starter, writes hidden acceptance tests, proves they fail on the starter and pass with a solution, and has a second model review it for leaks and fairness before anyone sees it.

Candidates then clear your gates: a Fit Score against your milestone (you set the bar), a High-Agency Assessment (partly on camera or by screen share), and the paid micro-project in their own private repo, with a fair clock, a DECISIONS.md and their AI log. Cursor chat exports are accepted as the log.

Step 4: Review in Cursor, against the criteria

Unlock a candidate and their frozen submission comes to your agent as a read-only clone. Open it next to their brief:

Check Swift Falcon's submission against the hunt's success criteria.

Two criteria met, one flagged at a specific line, and a note from the AI log that they caught the agent's off-by-one themselves. That's your interview, written for you. Before unlocking, you still see everyone's scores, hidden-test results and Laand's recommendation, under a made-up name.

Step 5: Leave your say from the editor

Leave a "Yes" on Swift Falcon: strong on verification, ask about cycles.

Everyone on the team can leave Yes / Not sure / No with a note, from Cursor, Laand or Slack:

Owners can move someone to the final stage. Paying and the hire stay in Laand.

The real cost of the pairing loop

A nine-person AI startup hires a product engineer at $160,000.

The data behind it

From the Laand Hiring Index, built from 896,475 job descriptions read sentence by sentence:

• AI companies ask for high agency three times as often as the rest of the market.
• 79% of ads asking for high agency ask for nothing but a résumé to prove it.
• Only 7.2% of ads mention AI fluency, even as most teams ship with agents.

The skill everyone wants is the one almost no one checks. A pull request checks it.

FAQ

Is it fair to ask candidates for unpaid work? No, which is why Laand's micro-projects are paid. Paying is also what gets strong, employed people to say yes.

Can candidates use Cursor on the micro-project? Yes, and any other agent. They include the chat export as their AI log. You're hiring for how they steer, so you need to see it.

What about roles that aren't pure engineering? Product engineers, designers and PMs all get micro-projects. Written and design work arrives as documents and files; code arrives as a repo you can open in Cursor.

Does Laand see our repo? No. The agent sends a summary of what it read. The micro-project is a fictional app with the same shape of problem.

What does it cost? Publishing and connecting are free. $750 per talent unlocked, only after they've submitted. No subscription.

Merge the right person

You'd never merge a pull request because the author interviewed well. Don't hire that way either.

Let the code your hire will own write the job. Let the work show you who can steer an agent through it. Then review it the way you review everything else: in Cursor, against the criteria, before you've even said hello.

Start a Talent Hunt · Set up Laand in Cursor · Watch how it works (2 min)

Victor Eduoh, Founder, Laand

The teams and candidates in the product screens are illustrations. Laand isn't affiliated with Anysphere (Cursor), Ashby or any company named here. Emmanuel Omole's quote is from Laand's talent receipts. Hiring Index figures were taken on 13 November 2026; see the Index for today's. Competitor prices are from their public pages, November 2026.