AI Software Engineering Domain Expert

$100–200/hrrate as listed

micro1 recruits practicing software engineers to write, review, and grade the coding tasks used to train and evaluate frontier models. Observed pay for this work has ranged from $100–200/hr, set by depth of experience and the language or subsystem you cover.

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 work on the data layer behind coding models: authoring problems that a strong model should plausibly fail, producing reference solutions, and judging model output against real engineering standards rather than surface plausibility. A typical batch might ask you to build a self-contained repository bug with a hidden failure mode, write tests that distinguish a real fix from a patch that games the test, then compare two model attempts and explain in writing which is better and why. Other batches skew toward critique — reading a model's diff or its chain of reasoning and annotating exactly where it went wrong: silent type coercion, an unhandled concurrency case, a fix that passes tests but breaks an invariant.

Task authoring: original problems in your primary language, with tests, edge cases, and rubric notes
Response grading: pairwise preference or rubric scoring on model-generated code, with written justification
Failure annotation: pinpointing the first wrong step in a long reasoning or agentic trace
Review passes on other contributors' work, once you've built a quality track record

What the screen looks for

micro1's process is AI-led and fairly fast: an async interview where an interviewer probes your resume, then live technical work observed for reasoning rather than just a passing test. Expect follow-ups that go one layer deeper than your first answer — if you claim distributed systems experience, you'll be asked what actually broke in production and how you diagnosed it. The strongest signal is specificity: named systems, real constraints, decisions you'd defend. Writing matters as much as coding, because a grade without a legible rationale is unusable as training data.

Logistics

Fully remote, contractor, and mostly asynchronous — you claim work from a queue and deliver against per-task deadlines. Most contributors run 10–20 hours a week alongside a full-time job; some projects offer heavier sustained volume for a few weeks. Work is project-based, so expect gaps between engagements and rate variation across them. Pay bands are as observed and depend on the specific project, not guaranteed.

What they look for

critical thinking
analytical reasoning
attention to detail
quality assurance
written communication
technica documentation
prompt authoring & refinement
AI Output Evaluation
Professional Writing
Report Writing
Business Communication
Problem Solving
Content Review
Data Interpretation
Logical Resoning
Professional Editing
Independent Research
Data Annotation
Rubric-Based Evaluation
Content Evaluation
AI Model Evaluation
Fact Checking
RLHF
Technical Editing
Prompt Engineering

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.

Do you have professional experience shipping production code in at least one of: Java, C++, Go, Rust, TypeScript, C#, or Kotlin?
Programming proficiency in at least one strongly-typed language · required
Have you spent at least 50% of your engineering work in the last two years reading, reviewing, or testing code written by others?
Code review and testing experience · required
Have you authored technical documentation, postmortems, design docs, or RFCs as part of your engineering work?
Written technical communication · preferred
Can you claim tasks and complete them within stated deadlines while working independently and asynchronously, with no guaranteed hours per week?
Availability for async work · required

0 of 4 answered

Included with this listing

Interview prep — 10 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've actually shipped code under pressure and can isolate root cause from surface symptoms; whether your thinking is systematic or lucky.
A strong answer: Name the system, the symptom users saw, the tools or logs you checked first, the false leads you ruled out, and the constraint or edge case that made the fix counterintuitive — then explain why a naive fix would have failed.
Where people lose it: Describing a bug that was obvious in hindsight ('the loop was off by one') or one you merely read about in a postmortem, rather than one you personally investigated under uncertainty.