The work

You are grading kernel engineering, not writing it from scratch. A task arrives as a specification plus a candidate kernel — generated from a spec, translated from CUDA to Triton, migrated from GPU to a custom accelerator, debugged, fused, or performance-tuned — and your job is to decide whether it holds up. That means checking whether the reference implementation is a legitimate baseline, whether the tolerance regime (absolute, relative, ULP) is appropriate for the dtype and reduction order, whether the benchmark measures what it claims to measure or is quietly comparing a warmed-up kernel against a cold one, and whether the failure a task reports is the failure it actually has. You then write it up against a rubric so the judgment survives someone else reading it a month later.

Expect the work to skew toward disagreement-hunting. Much of what reaches you looks plausible: it compiles, it runs, the numbers are close. The value you add is catching the cases where it passes for the wrong reason — a test with masked-out edge tiles, an autotuner that silently fell back, a fusion that changed accumulation order enough to matter in fp16 but was validated at fp32 tolerance.

What the screen looks for

  • Hands-on depth in at least two of CUDA, Triton, NKI, and Pallas — the screener will follow up on specifics, and secondhand familiarity tends to surface fast.
  • Whether you can articulate why a tolerance or reference choice is right, not just that you've used one.
  • Profiling fluency: nsight, ncu, roofline reasoning, or framework-native profilers, described at the level of what you concluded from a trace.
  • Breadth across kernel task types — generation, translation, hardware migration, debugging, optimization, fusion — since the review queue mixes them.
  • Willingness to write a clear rejection. Reviewers who mark everything acceptable are not useful.

Logistics

Remote, US-based, around 40 hours per week; the listing states $70–$90/hour, which is the band as observed rather than a guarantee for any given contributor. Work is largely asynchronous against a review queue, with rubric calibration and occasional disagreement resolution. Compiler background, MLIR or IR lowering experience, and contributions to kernel libraries are preferred but not gating.