What the work involves

You are writing and reviewing the kind of container plumbing that data platforms actually run on: Dockerfiles that carry validation steps inside the build, LABEL metadata that records dataset version, schema identity and lineage, and Python or Bash scripts that assert schema conformance, row-level integrity and quality thresholds. The deliverable is not a demo — it is code that fails loudly and correctly when the data underneath it is wrong. Expect to wire those checks into CI/CD so that a bad dataset blocks a deploy rather than shipping quietly, and to document the labelling conventions and validation logic so other engineers can follow them.

Because this sits under Turing's research-acceleration work, your output doubles as training and evaluation material for frontier models. That changes the emphasis: the reasoning has to be explicit, the failure modes have to be realistic, and the Dockerfile has to be the one a careful engineer would actually merge — not the shortest one that builds. Work is done alongside data engineering, ML and DevOps counterparts, so interface questions (who owns the schema registry, what the registry tags mean, when a check belongs in build versus runtime) come up constantly.

What the screen looks for

Turing's process here is short — roughly 75 minutes, centred on a 30–60 minute technical discussion conducted in QODE, their coding environment. It is a conversation with follow-ups, not a puzzle round. Screeners probe whether your Docker experience is hands-on (layer caching, multi-stage builds, build-time versus runtime validation, what a LABEL can and cannot guarantee), whether you can write a schema check that distinguishes a genuine data defect from a tolerable variation, and whether you can articulate why a pipeline should fail rather than warn. Four-plus years of DevOps experience is the stated bar, and vague answers about "using Docker at work" collapse quickly under a second question.

Logistics

  • Fully remote, contractor assignment — no medical or paid leave.
  • Duration is short: 2–4 weeks, with a start date expected within about a week of selection.
  • Commitment options are 20, 30 or 40 hours per week, minimum 4 hours per day, with at least 4 hours overlapping US Pacific time.
  • Hiring is limited to India, Pakistan, Nigeria, Kenya, Egypt, Ghana, Bangladesh, Turkey, Mexico and Brazil.
  • Pay band is undisclosed on this listing; Turing typically sets an hourly rate during or after the technical discussion.