Senior Backend Engineer

$50–100/hrrate as listed

micro1 is contracting senior backend and infrastructure engineers to build reinforcement learning environments that test whether AI models can design, deploy, break, and recover production-grade cloud systems. Work is remote and output-based at roughly 20 hours per week, with observed rates of $50–100/hr.

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 are not answering questions about infrastructure — you are building the graded sandbox. Each task starts from a realistic scenario: a multi-service deployment behind a misconfigured load balancer, an IAM policy that silently over-grants, a queue consumer that loses messages under backpressure, a rolling deploy that half-fails and needs rollback. You spec the scenario, build a reproducible environment, write a golden reference solution, and then write deterministic validation tests that pass only when the model's actions produce the correct end state. You also produce intentionally defective variants — broken observability, corrupted durable storage, partial network partitions — so the model's diagnosis and recovery behavior can be scored rather than guessed at.

Documentation is part of the deliverable, not an afterthought. Architecture notes, edge cases, and operational flows need to be clear enough that a technical lead can reproduce your environment and a downstream reviewer can understand why a test asserts what it asserts. Expect iteration with technical leads on acceptance criteria, especially early on while you calibrate to the project's definition of "deterministic."

What the platform screens for

micro1 runs an AI interview of roughly 30 minutes, reviewed by recruiters, followed by hiring manager review. The screen is looking for depth that survives follow-up: not that you've heard of IAM, but that you can describe a specific privilege-escalation path you found and closed. Strong candidates can talk concretely about distributed systems they operated in production, describe failure modes they debugged under pressure, and reason about what makes a test flaky versus genuinely deterministic. No prior AI or RL experience is required; infrastructure judgment is the credential.

Practical logistics

Contractor engagement, fully remote, async — roughly 20 hrs/week
Compensation is output-based, paid per accepted task; observed band is $50–100/hr equivalent, never guaranteed, and effective rate depends on your throughput
Minimum weekly task submission requirements apply
Roles typically fill within 48 hours; first tasks expected within 24–48 hours of onboarding

What they look for

C++
Python
Rust
GoLang
JAVA
JavaScript
DevOps

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 experience building, deploying, or operating backend systems in production environments?
Backend systems experience · required
Have you worked with at least one major cloud platform (AWS, GCP, Azure) and built or operated distributed systems on that platform?
Cloud infrastructure expertise · required
Do you have hands-on experience writing and testing infrastructure-as-code (Terraform, CloudFormation, CDK, or equivalent) in a production context?
Infrastructure-as-code proficiency · preferred
Are you able to commit to and sustain at least 20 hours per week of work on this project starting within 24–48 hours of onboarding?
Availability for 20 hours per week · required

0 of 4 answered

Included with this listing

Interview prep — 12 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 operated systems under load and know the difference between theoretical architecture and what breaks in practice, especially around observability and root cause.
A strong answer: Describe a specific incident with concrete details: the symptoms observed (latency spike, error rate, resource exhaustion), your debugging approach (logs, metrics, traces), the root cause, and the permanent fix or architectural change implemented. Mention what monitoring gap it exposed.
Where people lose it: Vague incidents ('the database was slow') without diagnosis method or lasting fix, or describing someone else's incident as though you solved it—screeners can tell the difference between lived experience and retelling.