Senior Platform Engineer

$60–130/hrrate as listed

Work with micro1 on AI training and evaluation tasks drawn from real platform engineering practice — Kubernetes, CI/CD, Terraform, observability, and cloud infrastructure. You write and review infrastructure problems, grade model output against production standards, and explain why a plausible-looking config would fail in a real cluster.

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

Most days you are producing or reviewing infrastructure-flavored evaluation data. That can mean authoring a realistic task — a Helm chart that drifts from its values file, a Terraform plan that silently destroys a stateful resource, a GitHub Actions pipeline that passes locally and fails in CI — then writing the reference solution and the rubric a grader will apply. Other days you sit on the review side: comparing two model attempts at a Kubernetes debugging trace, ranking them, and writing the justification that explains which one an on-call engineer could actually act on.

The judgment being measured is specific. Models are fluent about YAML and cloud APIs and frequently produce output that reads correctly while being operationally wrong — deprecated API versions, IAM policies that are broader than stated, health checks that mask a real failure, retries that amplify an outage. Your value is catching those and articulating the failure mode in a sentence a non-specialist reviewer can verify.

What the platform screens for

micro1 runs an AI-led interview before any project match. Expect it to probe depth rather than breadth: you will be asked to talk through concrete systems you have built or broken, and follow-ups will push on the details a resume can't fake — what the rollout strategy was, why you picked that state backend, what the postmortem concluded. Communication clarity matters as much as technical range, because the deliverable is usually written reasoning. Candidates who describe generic "DevOps best practices" without specifics tend not to advance.

Logistics

Fully remote and predominantly async; work is claimed from a queue rather than scheduled
Part-time is normal — many contributors commit 10–20 hours per week alongside a full-time role
Observed rates for this category run $60–130/hr, varying with specialization and review responsibility; not guaranteed
Engagements are contract-based, often starting with a paid calibration batch before steady volume

What they look for

Cloud Benchmark Task Authoring
Cloud and Distributed Systems Architecture
Production Infrastructure Ownership

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 authored and deployed production Terraform, Helm, CloudFormation, or equivalent infrastructure-as-code in at least two different cloud providers or on-premises environments?
Infrastructure as Code hands-on experience · required
Have you diagnosed and resolved at least three production incidents in a Kubernetes cluster or equivalent orchestration platform?
Kubernetes or container orchestration production experience · required
Have you regularly reviewed infrastructure-as-code pull requests or changesets from other engineers, including identifying non-obvious operational or security issues that automated checks missed?
Code review rigor on infrastructure changes · preferred
Have you written postmortems, runbooks, architecture documentation, or similar technical prose intended for an audience without hands-on experience in your specific infrastructure?
Clear technical writing · preferred

0 of 4 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 understand the gap between local testing and production behavior, and whether you can articulate a specific failure mode (not just 'it broke').
A strong answer: Name the system, describe the exact condition that triggered the failure (e.g., retry logic amplifying timeouts under high concurrency, a deprecated API version breaking in production only), and explain why local testing didn't catch it. The answer should let someone unfamiliar with that stack understand the root cause.
Where people lose it: Saying 'the deployment failed' or 'we had latency issues' without naming the actual operational failure—e.g., health checks masking cascade failures, IAM policies silently allowing unintended access, or state corruption in the backend. Vague incident descriptions signal you can't isolate the technical root cause.