Guides

Hiring with Codex: run an engineering hire where the take-home can't be faked

Victor EduohFounder, Laand12 min read
Codex starting a Talent Hunt in Laand from a repository, with every field sourced from the codebase

Picture a CTO at a six-person devtools startup, and the take-home that just broke her process.

She sent the same exercise she'd used for two years: add retries to a flaky webhook consumer, four hours, send a repo. Ten candidates reply. Eight submissions are close to identical: same structure, same helper names, same tidy README with the same three headings. The ninth is brilliant. On the follow-up call, its author can't explain why the retry logic uses jitter.

None of them cheated, exactly. They did what every engineer does now: they opened Codex and asked it to do the task. Her take-home was built to measure whether someone can write code. Today, it measures whether someone has a Codex subscription.

That's the problem this guide solves. You'll get a complete way to use Codex to build, run and grade an engineering hire on agent-assisted work, where using AI is expected and the evidence is how well someone steers it. I'll also show you how we turned that into Laand: you type "Laand, hire a senior backend engineer" inside your repo, and Laand builds a verified work sample from your real problems, runs the hidden tests, and hands Codex everything it needs to review the results.

Starting an engineering hunt from inside the repo: Codex reads the codebase, Laand fills the hunt and asks only what it can't know
Starting an engineering hunt from inside the repo: Codex reads the codebase, Laand fills the hunt and asks only what it can't know

Take-homes didn't die. It changed what it measures.

The numbers explain the CTO's ten submissions:

The reflex is to fight it: ban AI, proctor the webcam, go back to whiteboards. That's backwards. You don't want someone who can write a retry loop without Codex. You want someone who can tell when Codex's retry loop is almost right.

That's the actual skill gap now.

In the same survey, 66% of developers said their biggest frustration is AI solutions that are "almost right, but not quite", and 46% don't trust the accuracy of AI output. The engineers worth hiring are the ones who catch the "almost": they frame the problem before prompting, verify what comes back, cut scope on purpose, and can explain every line they kept.

What the market asks for, and how rarely it checks

At Laand we track 678,125 open roles across 15,085 job boards, and read every description sentence by sentence. From the Laand Hiring Index this week:

  • Only 7.2% of job ads mention AI fluency at all, even though most engineering teams now ship with agents every day.
  • Only 11.4% ask to see a work sample, portfolio or trial project.
  • AI companies ask for high agency three times as often as the rest of the market (7.8% of roles against 2.5%).

So the companies building the agentic future mostly still hire for it with a résumé and a LeetCode round. For a team of six, that's not a process quirk; it's a coin flip on a sixth of your company. The fix is real, agent-assisted work, and it can start from your repo.

The agent-assisted take-home: how to build one with Codex

Here's how to design and run a work sample that measures steering, not typing. You can do all of this with Codex today.

1. Mine your repo for the real problem

Open Codex in your main repository and let it find what a new hire would actually own.

Read ingest/, queue/ and docs/adr/. What are the three problems a new
senior backend engineer would own in their first 90 days? For each,
point to the files, the symptom (with numbers if the code or ADRs have
them) and why it hasn't been fixed yet. Don't propose fixes.

2. Recreate it, fictionally

Never hand candidates your real code. Ask Codex to rebuild the shape of the problem in a small, fake service.

Create a standalone starter repo (under 25 files) for a fictional
service with the same failure as our retry storm in queue/worker.ts:
unbounded retries, no back-pressure. Use none of our names, code or
data. Outside systems are local fakes. It must install and pass its own
tests as-is.

3. Write hidden tests that only the right solution passes

This is what makes the exercise gradeable at scale, and it's where most hand-made take-homes fall down.

Write acceptance tests for the starter that (a) fail on the starter
with an assertion, not a crash, and (b) pass with a correct solution.
Then write that solution and prove both. Keep the tests out of the
starter repo.

Then check the opposite: ask Codex in a fresh session to solve the starter naively and confirm the hidden tests catch it. If an agent's first draft passes your tests, your tests are measuring the wrong thing.

4. Require the two files that show how they think

Ask every candidate for:

  • DECISIONS.md: what they changed, what they didn't, and why. At least a few paragraphs.
  • An AI log: the Codex, Claude Code or Cursor session export, or a written account. Using AI is allowed. Hiding it isn't.

5. Timebox it, and pay for it

Four hours, paid. The timebox is what reveals execution taste: knowing what to cut. The payment is what makes the best engineers say yes; the ones with options don't do free homework.

6. Grade with Codex, then read the evidence yourself

For each submission in ./submissions: run the hidden tests, read the
diff from the starter, DECISIONS.md and ai-log/. Score test results,
problem framing, verification, scope judgment and code quality. Flag
any edits to tests or test config. Quote the lines that support each
score.

That flag matters. In one illustrative run you'll see below, a candidate passed 7 of 12 tests after editing the test config. Without the flag, that looks like a decent score.

7. Interview on their own diff

Write five interview questions for this candidate that name specific
files and decisions in their diff. Each must only be answerable by the
person who wrote it.

That last line is also your best protection against proxy candidates and fakes: nobody can talk through trade-offs they didn't make.

Codex comparing three submissions: test results, approach, and what to watch for in each
Codex comparing three submissions: test results, approach, and what to watch for in each

The steering signals to grade

Use this alongside your technical scorecard. It's what separates engineers who steer Codex from engineers who follow it.

SignalStrongWeak
FramingRestates the real problem before prompting; spots the back-pressure issue nobody mentionedPastes the brief into Codex verbatim
VerificationRuns the tests, writes new ones, catches the agent's edge caseShips the first green run
Test integrityLeaves tests alone; adds casesEdits tests or config to pass
ScopeCuts on purpose and says so in DECISIONS.mdTries everything, finishes nothing
OwnershipExplains every kept line in their own words"Codex wrote that bit"
AI honestyLog matches the diffLog is missing, or tells a different story

Where doing it by hand breaks

I want to be honest about the cost of the playbook above. It works, but on a team of six:

  1. Building a fair starter with hidden tests is a day of senior engineering time. Doing it per role, and keeping it from leaking, is more.
  2. Grading is the hidden tax. Ten submissions at two hours each is 20 hours of your best engineer's week, usually the CTO's.
  3. You still have to find the candidates. Codex can build the exercise; it can't fill the top of the funnel.
  4. Repos and access are a mess. Creating private repos, inviting people, starting each person's clock fairly, revoking access, freezing the submission at a commit.
  5. Identity leaks bias in. A GitHub handle, a commit author or a personal site in the README tells you who someone is before you've judged the work.
  6. Nobody keeps the record. Who decided what, and why, ends up in DMs.

Every one of those is a solved problem in Laand.

Hiring with Codex, end to end, with Laand

You set the bar. Laand runs the proof-of-work engine: sourcing, a Fit Score against your milestone, a High-Agency Assessment, and a paid, verified code project built from your real problems. Codex connects to every step.

Step 1: Connect Laand to Codex

codex mcp add laand --url https://laand.me/mcp
codex mcp login laand

That's it. Sign in with your company account and press Allow. Each engineer connects their own Codex, with their own role.

Step 2: Start the hunt from your repo

Inside the repository the hire will work on:

Laand, hire a senior backend engineer. Read this repo to see what they'll actually own.

Codex reads the code and ADRs, and Laand fills the hunt with where every value came from. It asks only what Codex can't know: salary, the micro-project stipend, and the start date.

Codex starting a hunt in Laand: milestone, core problems and stack sourced from the codebase, with two questions left
Codex starting a hunt in Laand: milestone, core problems and stack sourced from the codebase, with two questions left

Only a summary of the codebase goes to Laand, never the code. Laand's Deep Analysis turns it into core problems and code micro-projects that recreate them in a fictional service, exactly like steps 1 and 2 of the playbook, done for you.

Step 3: Laand builds and proves the work sample

This is the part that takes a day by hand. For every code micro-project, Laand:

  • generates a starter repo on a pre-tested base (Node, React, Python or Go);
  • writes hidden acceptance tests, and proves they fail on the starter and pass with a solution, on real CI runners;
  • has a second, independent model review the brief, starter, tests and solution for leaks, fairness and fit to the time limit, before anyone sees it.

Micro-projects scoped from the hunt's core problems
Micro-projects scoped from the hunt's core problems

A project with a known problem is never offered.

Step 4: The gates, and a fair clock

Candidates come from Laand's talent network and your free careers page. Below your Fit Score bar, they're a count, not a card. Above it, they take the High-Agency Assessment, some of it on camera or by screen share. The best are invited to the code project:

  • a private repo is created for them, without the hidden tests or the solution;
  • their clock starts only once they have access, so a GitHub hiccup costs them nothing;
  • they must commit their own work, write a DECISIONS.md of at least 150 words, and include their AI log (Codex, Claude Code or Cursor exports are all accepted);
  • on submit, the repo is frozen at a commit, their access is removed, and the hidden tests run.

Laand then reads the diff, the test run, DECISIONS.md and the AI log; scores seven dimensions; flags any edits to tests; and writes interview questions that name files and decisions. Commit authors are never shown.

Step 5: Compare everyone in Codex

Compare the top three Backend submissions and draft interview questions.

Codex comparing three candidates: hidden tests, approach and what to watch for, with interview questions from each diff
Codex comparing three candidates: hidden tests, approach and what to watch for, with interview questions from each diff

Look at Bright Heron's row: 7 of 12 tests, and "tests edited to pass". That's the Test Integrity signal, caught automatically. Everyone stays anonymous until you unlock them; then Codex gets a read-only clone of their frozen commit (that one repo, for an hour), and you can run, extend or break it with your own tooling.

Step 6: Decide as a team

Leave your say from Codex, Laand or Slack:

Hiring with Slack via Laand
Hiring with Slack via Laand

Owners can move someone to the final stage from Codex. Paying, paid invites and marking the hire stay in Laand.

Prompts to try once Laand is connected

  • "Which Backend submissions are waiting on me?"
  • "Clone Swift Falcon's submission, run it against 50k events, and tell me where it falls over."
  • "Did anyone edit tests or config to pass? Show me the diff."
  • "Compare how each finalist used Codex, from their AI logs. Who pushed back on the agent, and were they right?"
  • "Leave a 'Yes' on Swift Falcon: strong verification, ask about cycles."

One backend hire, five ways: the real cost

A six-person devtools startup hires a senior backend engineer at $180,000. Here's what each route really costs.

RouteCashCTO timeWhat you see before the offer
Recruiting agency20–25% of salary is the norm for engineers (Dover): $36,000–$45,000Interviews for every shortlisted CVRésumés. Maybe a LeetCode score.
ATS + your own take-homeAshby from $400/month ($4,800 a year), billed whether you hire or notA day building the take-home, 20 hours grading ten of themTen submissions, eight of them the same Codex output
Generic coding-test libraryTestGorilla from about $142/monthLightPass rates on puzzles that aren't your problem, and that 28% of hiring managers have already seen AI beat
Codex + the playbook aboveYour seatAbout three days, end to endReal signal, if you have the days
Codex + LaandFree to publish and connect. $750 per talent unlocked. Five $400 stipends ($2,000) + unlocking your top two ($1,500) = $3,500An afternoon reviewing in CodexFrozen repos with hidden-test results, DECISIONS.md, AI logs, flagged test edits, and questions that name files

What stays human

How it works
Who decidesYour team. Codex reads, runs and compares; people decide. Actions are recorded as yours "from an AI agent".
IdentityAnonymous until you unlock someone who has submitted. Commit authors are never shown.
Your codeOnly a summary reaches Laand. Micro-projects are fictional recreations.
Money and the hirePaying, paid invites and marking the hire happen in Laand.
AccessClones are read-only, one repo, one hour. Each engineer connects their own Codex.

FAQ

Should candidates be allowed to use AI on the take-home? Yes, and they should log it. Banning AI tests a skill you don't use. Logging it shows the one you need: how they direct, check and overrule the agent.

How do I stop candidates editing the tests? Keep the acceptance tests out of their repo and run them after a frozen commit. Laand does both, and flags any edits to visible tests or config.

How long should an engineering work sample take? Three to four hours, paid, with a clear brief. Long enough to show judgment, short enough that strong people with jobs will do it.

Does Laand see our code? No. Codex sends a summary of what it read. The work sample is built on a fictional service with the same shape of problem.

Does this work for frontend and full-stack roles? Yes. Laand's bases cover Node, React, Python and Go. For non-code roles, the micro-project is written work, reviewed the same way.

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

The take-home is back

The take-home stopped working when every candidate got an agent. It works again the moment you stop asking "can they write this?" and start asking "can they steer this, verify it, and explain it?"

Codex makes that easy to build. Laand makes it run while you ship.

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

Victor Eduoh, Founder, Laand

The CTO and her startup are a made-up scenario; the company and candidates in the product screens are illustrations. Laand isn't affiliated with OpenAI, Ashby, TestGorilla or any company named here. Hiring Index figures were taken on 13 November 2026; see the Index for today's. Competitor prices are from their public pages, November 2026.

AI hiringCodexengineering hiringtake-homeAI agents

Stop applying blind.

Laand scores your fit for any role, then builds the application kit that proves you can do the job.

Join Laand

Start an engineering hunt from your repo

One line in Codex. Laand builds a verified work sample from your real problems, and you review the results where you already work.

Start a Talent Hunt