Hire AI infrastructure engineers remotely from China

A hardware constraint that produced an unusual skill

This is the one role on this site where a restriction created the expertise. Limits on advanced accelerators meant Chinese labs could not answer a training problem by buying more hardware, so they had to answer it by engineering. The result is a cohort that is genuinely good at making a fixed amount of compute go further — which is the problem every company with a finite training budget actually has.

Where that shows up in a training run

Specifically: communication-bound scaling, mixed precision, activation checkpointing, the choice between pipeline and tensor parallelism, kernel-level work when the default was not fast enough, and getting real throughput out of domestic accelerators such as Huawei’s Ascend line alongside the usual stack.

The habit that comes with it is more useful than any single technique. An engineer who has had to care about the interconnect rather than the accelerator count tends to look for where training time is actually going instead of assuming it is going where the documentation says. Candidates from this pool are also comfortable with the ordinary substrate — Kubernetes, containers, Terraform, observability — which makes the work considerably more portable than the specialism sounds.

Export control comes first for this role, not last

For every other role on this site this is a footnote. Here it belongs at the top, because the analysis genuinely bears on how you scope the job.

The constraint is on the nature of the work rather than the nationality of the person doing it, and the line runs roughly between advancing frontier model capability and operating models that already exist. Training infrastructure for the former sits closer to the restricted end. Inference optimisation, platform tooling, observability, scheduling and cost engineering generally do not, and that is where most companies’ actual need lies anyway.

So it is usually designable around, and it costs nothing to establish at the briefing stage. Our note on export controls and remote AI work sets out what we ask and why. We would rather narrow a brief than place somebody into work that should not have been scoped that way in the first place.

Screen on figures, not on the tool list

This is the role where the good candidates have numbers and the weak ones have a list of technologies. Ask for throughput, accelerator utilisation, tokens per second, cost per thousand requests — and what each of those was before and after their work.

It is a question that survives a video call and a language difference far better than a whiteboard exercise does, because the answer is either specific or it is not. A candidate who says utilisation went from thirty-one per cent to sixty-eight and can explain which change did it has told you more than an hour of architecture discussion would.

One more worth asking: how they have handled being the only person awake when something broke. You are testing for the habit of writing things down as they go, which is what makes an asynchronous handover work at all, and against the habit of fixing things silently.

What they need access to, and why it decides the brief

The obvious practical problem: infrastructure work needs the infrastructure. Decide early what the engineer actually gets — a dedicated development cluster, a scoped project in your cloud account, a staging environment that resembles production closely enough to be worth optimising against. The answer determines what can reasonably be asked of them, and a strong infrastructure engineer with read-only access is an expensive consultant.

Overlap matters more here than for most roles, because this work is entangled with everybody else’s: when the cluster misbehaves, several people need to be awake at once. Five or six hours is a better target than four, and worth paying for. The note on overlap hours explains why an arrangement that quietly depends on somebody working until midnight does not survive the second month.