What the work actually is
You are producing proprietary data, not shipping a product. On the SFT side, you take a prompt — sometimes handed to you, sometimes authored yourself — containing code and questions, then write the reference Python solution and the accompanying explanation the model should learn to imitate. On the RLHF side, you prompt two model versions on the same task, compare their outputs, rank them, and write a rationale that a researcher can act on: which one is correct, which one is merely plausible, where the concurrency bug hides, why one refactor introduces a regression and the other does not. Peer review is part of the job — reviewing other contributors' code and rationales and flagging where the reasoning is thin. The listing is explicit that you will not be building or fine-tuning models.
What the screen is looking for
Turing's evaluation process runs roughly 75 minutes: a 60-minute technical round plus a 15-minute cultural and offer conversation. The technical depth targeted by the requirements is specific — Python's testing ecosystem including property-based testing, multithreading and async, architectural patterns and regression-safe refactoring, and debugging memory and concurrency problems. Expect follow-ups that go a level past your first answer, because the role's value depends on whether you can explain why a solution is correct in prose, not just produce one. Written English fluency is a stated requirement and is functionally load-bearing: your rationales are the deliverable.
Logistics
- Fully remote, contractor assignment — no medical or paid leave.
- Three commitment tiers: 20, 30, or 40 hours per week; minimum four hours per day.
- Four hours of daily overlap with PST is required, which is the binding constraint for candidates outside the Americas.
- Initial contract is one month, with a start date typically about a week out. Pay is undisclosed on this listing; Turing rates in this category are usually set per hour and vary by seniority and region.
This suits an experienced Python engineer who enjoys writing the explanation as much as the code, and who can be decisive about which of two near-identical answers is actually better.