Senior Software Engineer

$50–100/hrrate as listed

Senior engineers work with micro1's AI training clients to write, review, and grade code — producing reference solutions, unit tests, and written critiques of model-generated output. Pay has been observed in the $50–100/hr range depending on language stack, screening results, and project tier.

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 production-grade engineering applied to model training rather than shipping features. On a typical project you might author a non-trivial task in your primary language (a bug to localize, a refactor to perform, an API to implement), write the reference solution and test suite, then run a model against it and document precisely where and why the output fails. Other weeks skew toward evaluation: comparing two model attempts at the same pull request, ranking them against a rubric, and writing the justification that teaches the reward model what "correct" means beyond passing tests — readability, edge-case handling, idiomatic style, security posture.

Expect a mix of:

Task authoring: repo-grounded problems with deterministic tests and clear acceptance criteria
Output critique: line-level annotations on model diffs, explaining root causes rather than restating symptoms
Preference comparison: side-by-side ranking with written rationale
Rubric feedback: flagging where the grading spec is ambiguous or gameable

What the platform screens for

micro1's intake is AI-led — a structured async interview covering your background, then live technical depth with follow-up probing. Screeners are looking for verifiable specifics: which systems you owned, what you'd do differently, how you reason about a failure you can't reproduce. Vague seniority claims don't survive follow-up. Beyond coding ability, the bar is writing: your critiques are the training signal, so terse-but-complete English prose matters as much as your ability to spot the bug. Take-home or live coding in your stated primary language is standard, and self-reported expertise is verified against it.

Logistics

Fully remote and largely asynchronous, with occasional overlap calls for calibration or project kickoff. Commitments range from roughly 10 hours a week to full-time; most contributors set their own hours against weekly task quotas or throughput targets. Work is contract-based and project-scoped, so volume fluctuates with client demand — treat it as variable rather than guaranteed, and expect a paid calibration round before full-rate work begins.

What they look for

Python3
JAVA
Rust
Algorithms
Basics C++
Typescript
bug fixing
feature implementation
codebase refactoring
performance optimization

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 code to a production system that was deployed to real users or systems, and can you name the primary language you used?
Production coding experience · required
Can you code fluently in at least one language, and are you willing to demonstrate that in a technical exercise during the screening?
Primary language depth · required
Have you reviewed code professionally—either as a reviewer in a team or as part of open-source contribution—and written feedback on others' work?
Code review experience · preferred
Can you write clear, detailed English prose—e.g. documentation, postmortems, or technical explanations—without requiring heavy editing for clarity?
English writing capability · required
Have you worked in a role where you managed your own time or hours, such as freelance, contract, or open-source contribution at significant scope?
Asynchronous work experience · preferred

0 of 5 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 can name a concrete system with measurable scope and real failure modes, not just 'improved performance' or 'helped the team.' Ownership means accountability for decisions, not just execution.
A strong answer: Specific system (message queue, auth service, data pipeline), quantified scope (handled X requests/day, served Y services), a real failure with root cause you identified or should have, and a concrete change—architectural, testing strategy, monitoring—you'd implement to prevent it.
Where people lose it: Naming a system but describing only the happy path or someone else's decision. 'I worked on the payment service' without saying what it did, how it broke, or what you'd change is indistinguishable from shadowing.