Senior Software Engineer

$100–150/hrrate as listed

micro1 recruits senior software engineers to write, review, and grade code used for training and evaluating AI models. Work is contract-based, fully remote, and scheduled around your own hours, with observed rates of $100–150/hr depending on stack and screening outcome.

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

Day-to-day tasks vary by project, but most senior engineering work on micro1 falls into a few recognizable shapes: authoring non-trivial coding problems with hidden test cases, writing reference solutions in a specific language or framework, reviewing model-generated code for correctness and idiomatic quality, and producing detailed rationales explaining why one output is better than another. Some projects lean toward repository-scale tasks — reproducing a bug from an issue thread, writing a failing test, then documenting the minimal fix. Others are comparative: two model responses to the same prompt, and you decide which is better and defend the call in writing.

The bar is higher than "does it compile." Reviewers are expected to catch silent correctness bugs, unsafe concurrency, misused APIs, algorithmic complexity that will fall over at scale, and code that passes tests while solving the wrong problem. Written justification carries as much weight as the verdict itself, since the rationale is often the training signal.

What the platform screens for

Verifiable seniority. Expect questions about systems you actually shipped, decisions you owned, and tradeoffs you'd make differently now. Vague answers about "leading initiatives" don't survive follow-up.
Live technical depth. micro1's screen is AI-led and adaptive: it will pick a language or domain from your stated background and push until it finds the edge of your knowledge. Overclaiming a stack is the most common way candidates fail.
Communication under constraint. Can you explain a subtle bug in three sentences? Can you disagree with a plausible-looking solution and say precisely why?
Consistency. Graders who reverse their own standards across similar cases get filtered out during calibration.

Logistics

Fully remote and asynchronous. Most contributors work in blocks of a few hours, and project availability fluctuates — some weeks bring steady volume, others little. Ten to twenty hours a week is a common commitment, though a few projects request more sustained availability or overlap with US business hours for calibration syncs. Pay is hourly and per-project; the $100–150/hr band reflects reported senior-tier rates, not a guarantee, and depends on specialization, geography, and how you place in screening.

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 written and shipped code that ran in a production or live system, not just coursework, training projects, or code reviews?
Shipped production code · required
Do you have at least four years of professional software engineering experience (employed as an engineer, founding engineer, or equivalent)?
Professional engineering experience · required
Have you spent meaningful time reviewing others' code for correctness, style, or design—either as part of your role, as a mentor, or in an open-source capacity?
Code review and evaluation experience · 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've actually owned non-trivial system decisions and can articulate technical reasoning—not just execution—well enough to critique your own choices.
A strong answer: Name a real system, explain the decision and its constraints at the time, identify a specific failure mode or tradeoff that only became clear later, and say what you'd do instead and why. The reversal itself matters less than showing you think in tradeoffs and learned from the gap between theory and production.
Where people lose it: Staying abstract ('I led a migration to microservices') without naming the system, the decision, or what actually went wrong. Saying 'it was right at the time' without acknowledging what you'd change signals you haven't reflected on your own work.