What the work actually involves
You write engineering problems that a strong model should be able to solve and often cannot. That means defining a task end to end: inputs, assumptions, constraints, operating conditions, output metrics, and acceptance criteria that a grader can apply without re-deriving your intent. You then build the reference solution — a golden geometry, a mission plan, an airframe or route file — and score model-generated submissions against it. A meaningful share of the day is reviewing other engineers' tasks for technical correctness and completeness, which is where most quality problems get caught.
The tool list is specific: OpenVSP, XFLR5, FlightGear+JSBSim, OpenRocket, QGroundControl. Turing asks for genuine proficiency in at least two, plus scripting — parameterising geometry sweeps, batch-running cases, parsing output rather than reading it off a GUI. Note that the listing carries an Electrical Engineering title while the entire body describes aerospace and flight dynamics work; treat the body as authoritative and prepare accordingly.
What the platform screens for
Turing's screen is AI-led and follow-up heavy. It probes whether you can state assumptions explicitly, whether your sanity checks are real (order-of-magnitude, conservation, known-solution comparison) rather than "it looked right," and whether you can distinguish a model answer that is wrong from one that is merely different from yours. Expect to be asked what a particular tool cannot do — vortex-lattice limits, JSBSim aero-table fidelity, OpenRocket's assumptions — because naming a limitation is the cheapest proof of hands-on use.
Logistics
- Remote, contractor assignment, no medical or paid leave
- 40 hours per week with at least four hours of PST overlap — this is a full-time commitment, not a side engagement
- Stated duration of five weeks with immediate onboarding; extensions happen but are not promised
- Pay is undisclosed on this listing; ask for the rate and the scoring/throughput expectation before you sign