GPU Programming Software Engineer

$60–95/hrrate as listed

Write and optimize GPU kernels in CUDA, WebGPU, or GLSL as training data for large language models, with host-side integration in C++. Work is contracted per task on micro1, remote, with a weekly minimum submission requirement.

Summary, eligibility guidance and screening preparation are prepared by Sidequest from the platform's posting. Check the source listing before applying.

What the work involves

You author GPU programming tasks that become training and evaluation material for LLMs. In practice that means writing self-contained problems — a kernel that needs fusing, a shader with a memory access pattern that thrashes cache, a reduction that scales badly past one warp — then producing correct reference solutions, profiling evidence, and clear explanations of why one implementation beats another. Some tasks ask you to grade or repair model-generated GPU code: spotting the race condition, the missing `__syncthreads()`, the occupancy assumption that only holds on one architecture generation.

Expect a mix of CUDA, WebGPU/WGSL, or GLSL depending on project, with C++ on the host side for launch logic, memory management, and integration. Depth in any one of these matters more than breadth across all three.

What the screen looks for

Real hardware-level reasoning. Follow-up questions push on warp divergence, shared memory banking, coalescing, register pressure, and occupancy trade-offs — surface-level familiarity with API syntax is filtered out quickly.
Profiler fluency. Nsight Compute, Nsight Systems, or equivalent tooling, and the ability to name the metric that told you where the bottleneck was.
Correctness discipline. Whether you can explain how you verified a kernel, not just that it ran.
Evaluation judgment. Whether you can distinguish code that is wrong from code that is merely non-idiomatic, and write feedback a model can learn from.

Logistics

Fully remote and asynchronous. Compensation is output-based — paid per accepted task rather than per hour — and observed rates on this listing fall in the $60–85/hr equivalent range depending on task complexity and how efficiently you work; nothing is guaranteed. There is a weekly minimum task submission. micro1 typically fills these roles within about 48 hours and expects first tasks within 24–48 hours of onboarding, so it suits people with existing bandwidth rather than those planning around a future gap.

What they look for

CUDA
WebGPU
GLSL
C++

Before you apply

Would you pass this screen?

Drawn from what this listing actually requires. Answered in your browser — nothing is sent to us, and we do not store your answers.

Have you written and shipped production or near-production GPU code in CUDA, WebGPU, GLSL, HIP, or equivalent?
CUDA or GPU language production experience · required
Do you have hands-on experience writing and shipping C++ code (not just learning it from a course)?
C++ proficiency · required
Have you used GPU profiling tools (NVIDIA Nsys, Gprof, AMD Rocprof, Intel VTune, or similar) to measure and optimize kernel performance?
GPU profiling tool experience · preferred
Do you have professional or published work in graphics programming, ML acceleration, scientific computing, high-performance computing, or similar GPU-intensive domain?
Background in GPU-adjacent domain · preferred
Are you able to begin your first tasks within 24–48 hours of onboarding completion?
Availability for immediate start · required

0 of 5 answered

Included with this listing

Interview prep — 10 questions

Matched to what this platform's screening actually measures. Answer each out loud in 60–90 seconds: claim → concrete example → implication.

What it tests: Whether you've actually profiled real GPU code and understand latency vs. throughput trade-offs, not just theoretical optimization.
A strong answer: Name a specific kernel, identify the actual bottleneck you found via a profiler (memory bandwidth, compute utilization, occupancy), describe the concrete change you made, and cite the measured speedup or efficiency gain.
Where people lose it: Talking about 'optimization' in vague terms—'I made it faster' or 'I added parallelism'—without showing you've used a profiler (Nsys, Gprof, RMT, or similar) or can't quantify the improvement.