Agent Engineer

$100–500/taskrate as listed

Mercor is recruiting engineers who have shipped LLM agents that real users depended on, and who can speak in detail about reliability, evaluation, and internal adoption. The process is a conversational AI screen followed by a paid 30-minute live conversation, observed at $100–500 depending on depth of experience.

Summary, eligibility guidance and screening preparation are prepared by Sidequest from the platform's posting. Check the source listing before applying.

What the work involves

This is not a build-something engagement — at least not yet. The first ask is your knowledge. Mercor wants engineers who have operated agents in production to walk through how those systems actually behaved: what broke, how you noticed, what you changed, and how you knew the change helped. The screen is conversational and untimed in spirit — no coding exercise, no take-home.

The topics of interest sit deliberately below the usual demo layer:

Internal monoagents wired into company data and permissions
Shared company memory, and what happens when it goes stale or wrong
Reusable skills and playbooks, and who maintains them
Tool and MCP surfaces agents call, including failure and retry behavior
Observability and cost attribution — how anyone actually sees what an agent did and what it spent
Long-lived execution: scheduled jobs, multi-hour work, cloud sandboxes
Adoption reality inside your org: who used the internal assistant, and who quietly stopped

What the platform screens for

The AI interview is looking for specificity, not vocabulary. Expect follow-ups that press on numbers, dates, and decisions: which eval you ran before and after a prompt change, what your regression rate looked like, why you chose a judge model over human review or the reverse. Candidates who describe agents in the abstract tend not to advance. Candidates who tell one messy story with real tradeoffs — including the ones that went badly — tend to.

Evaluation judgment matters as much as engineering. Mercor cares whether you can distinguish a real quality regression from noise, and whether you have opinions about what agent evaluation still cannot measure.

Logistics

Fully remote and asynchronous for the first stage; complete the AI screen whenever it suits you, typically 20–40 minutes. Strong screens are invited to a live 30-minute call with the Mercor team, scheduled to your availability. Compensation for that call has been observed in the $100–500 range, paid on completion, with the figure tied to depth of experience — not guaranteed, and set by the platform. Every submission is reviewed.

What they look for

Production experience shipping and operating LLM agents that real users depended on
Hands-on agent evaluation: building test sets, regression checks, and before/after quality measurement
Familiarity with tool-calling and MCP surfaces, including error handling and retries
Experience with long-running or scheduled agent execution and cloud sandboxes
Observability and cost instrumentation for agent traces
Firsthand view of internal assistant adoption within an engineering organization

Before you apply

Would you pass this screen?

Drawn from what this listing actually requires. Answered in your browser — nothing is sent to us, and we do not store your answers.

Have you built and deployed an agent (LLM-driven system that takes autonomous actions) that real users or business processes depended on?
Production agent experience · required
Have you diagnosed or fixed a problem with an agent or AI system after it was live in production?
Post-deployment learning · required
Have you designed or implemented a way to measure whether an agent improved, degraded, or stayed the same after a change you made?
Evaluation of agent behavior · preferred

0 of 3 answered

Included with this listing

Interview prep — 11 questions

Matched to what this platform's screening actually measures. Answer each out loud in 60–90 seconds: claim → concrete example → implication.

What it tests: Whether you have hands-on production agent experience and can pinpoint a failure mode, not just describe an abstraction. The 'what broke' part tests whether you learned from operational reality or stayed in theory.
A strong answer: Name a specific agent, describe its user-facing job in concrete terms (not 'improved productivity'), and identify one actual failure—latency spike, hallucination on edge case, cost blowup, user abandonment—that forced you to debug or redesign.
Where people lose it: Talking about agents you read about, designed but never deployed, or deployed but never maintained through failure. Also: blaming the LLM vendor instead of owning the system design choice that exposed you to that failure.