AI trainer

$100–180/hrrate as listed

micro1 recruits working software engineers to train and evaluate coding models — writing problems, grading model output, and correcting code the model got subtly wrong. Engagements are contract, remote, and hourly, with observed rates in the $100–180 range depending on language depth and interview performance.

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

You spend most of your time reading code a model wrote and deciding whether it is actually correct — not whether it looks correct. A typical task queue mixes several formats: authoring a non-trivial problem in your primary language with hidden tests, comparing two model responses and writing a justification for which is stronger, or taking a near-miss solution and producing a corrected reference plus an explanation of the failure mode. Some projects lean toward agentic work: multi-file repositories, tool calls, terminal transcripts, and debugging sessions where you judge whether the model's reasoning path was sound even when the final diff passed.

The hard part is rarely writing code. It is writing the rationale — a reviewer or a downstream reward model has to understand exactly why an off-by-one in an async retry loop matters, or why an O(n log n) solution that silently mutates its input is worse than the slower one. Vague feedback gets rejected. Specific, reproducible feedback is the whole product.

What the screen looks for

Real engineering history — shipped systems, commit history you can talk about, specific languages you use daily rather than list
Depth under follow-up: the AI interviewer will push past your first answer on concurrency, memory, type systems, or whatever you claim
Ability to explain a bug in plain prose, quickly, without hedging
Calibration — knowing when a model output is wrong versus merely stylistically different from how you'd write it

micro1's process is an asynchronous AI interview followed by a project match. Expect coding under observation and verbal explanation of your reasoning; screen-recorded or proctored segments are common.

Logistics

Fully remote and largely async — you pull from a task queue rather than attend meetings. Most contributors work 10–25 hours per week, though some projects post full-time-equivalent capacity for limited windows. Pay is hourly and project-dependent; the $100–180 band reflects rates observed on coding projects and is not a guarantee. Work is typically 1099 or international contractor, invoiced per approved hour, with quality review affecting continued allocation.

What they look for

data annotation
prompt engineering
critical thinking
written communication
domain expertise
feedback delivery
remote collaboration
attention to detail
adaptability
ethical awareness in ai

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 shipped production code in at least one of the languages the project covers?
Professional coding experience · required
Do you currently write code in your primary language at least several times per week, in a work or maintained open-source context?
Daily language use · required
Can you demonstrate through commit history or a portfolio project that you write tests, fix bugs, and think about failure modes in your domain?
Testing and debugging acumen · 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 genuine production experience and can articulate concrete technical reasoning, not just name technologies. The listing emphasizes 'shipped systems' and 'commit history you can talk about' — this separates contributors from people who learned in tutorials.
A strong answer: Name a real system, describe the user or business problem it addressed, specify your role and the primary tech, and explain one design choice that required judgment — e.g., 'We used PostgreSQL over MongoDB because we needed ACID guarantees on order state; a document store would have left us vulnerable to race conditions in the checkout flow.' Avoid vague praise for your own code.
Where people lose it: Describing a system so generic or tutorial-like that you could not actually defend a design decision under pressure — or hedging with 'I mostly worked on the backend' without naming what the backend did. The interviewer will follow up; if you cannot go deeper, you signal weak ownership.