Senior Software Engineer

$80–120/hrrate as listed

Review and score AI-generated code, write reference solutions, and author test cases across production-grade repositories for micro1's model training work. Engagements are contract-based and remote, with pay observed in the $100–150/hr range depending on stack depth and screening results.

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 through batches of coding tasks where a model has produced a patch, a function, or a full multi-file change. Your job is to decide whether it actually works — not whether it looks plausible. That means reading the diff carefully, running it where a sandbox is provided, identifying the failure mode precisely (logic error, wrong API contract, silent data loss, missing edge case, plausible-sounding hallucinated library), and writing a short, unambiguous justification another engineer could audit. Other days you author the tasks yourself: pulling a realistic bug from a repo you know well, writing a gold-standard solution, and building tests that a competent-but-shortcutting model would fail.

Typical unit types include pairwise comparison of two model outputs, rubric scoring on correctness and maintainability, adversarial prompting to surface failures, and repository-level task construction. Reviewers who consistently score well are often moved into calibration or QA roles where they audit other reviewers' scores.

What the platform screens for

Verifiable seniority. micro1's screening is AI-led and follow-up heavy. Expect to be asked about a specific system you built, then pushed two or three layers deeper on the decisions behind it.
Language and stack depth. Python, TypeScript/JavaScript, Java, Go, C++, and Rust are all in demand; being genuinely strong in two beats being shallow in six.
Written reasoning. Vague rationales like "code is cleaner" fail calibration. The screen looks for engineers who can name the defect and cite the line.
Consistency. Calibration sets are re-run periodically; reviewers who drift get retrained or rotated off.

Logistics

Fully remote and mostly asynchronous — you claim tasks from a queue and complete them against a deadline rather than sitting in meetings. Most contributors commit 10–20 hours per week, though some projects run full-time for a fixed window. Onboarding usually includes a paid or unpaid calibration batch before live work opens up. Pay is per-hour or per-task depending on the project; the $100–150/hr band reflects observed rates for senior-level coding work and is not a guarantee.

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.

Do you have at least 5 years of professional software engineering experience, with at least 2 of those years in a senior or lead role?
Senior-level engineering experience · required
Are you genuinely proficient (can write production code without steady reference) in at least two of these languages: Python, TypeScript/JavaScript, Java, Go, C++, or Rust?
Depth in at least two of the platform languages · required
Have you spent at least 100 hours reviewing other engineers' code, assessing pull requests, or evaluating code quality in a professional setting?
Code review or evaluation experience · preferred
Can you provide links to public repositories, blog posts, or published code samples demonstrating your engineering work?
Public code samples or portfolio · preferred

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 can articulate concrete technical reasoning, not post-hoc justification. This role requires you to *explain* why a code change is wrong, so vague architectural fluency won't survive calibration.
A strong answer: Name a real system, describe the specific constraint (latency budget, memory ceiling, team size), show the alternative you rejected, and explain the measurable consequence of each choice—e.g. 'I chose a hash map over a tree because we needed O(1) lookup under 50ms SLA, and the tree's O(log n) would have triggered cache misses on hot paths.'
Where people lose it: Saying 'I chose readability' or 'it was the right fit' without naming what failure you were avoiding. Reviewers will probe deeper, and if you can't point to a specific line or metric, the score tanks.