Eye-rubbing, then headsets coming off after a few minutes: that is the tester feedback on a hypothetical mixed reality build that runs smoothly in the Unity editor. Two things are going wrong at once. Frame time jumps every time a particular particle effect fires, and the virtual table that should sit on top of the real one slowly slides towards the wall. Working out why, and fixing it without breaking the build on a second vendor's device, is what you would be paid to do. This opening sits among the remote spatial computing engineer jobs on this board: full-time, remote, open to candidates worldwide, paying $95,000 per year USD.
You will develop AR, VR and mixed reality features in Unity using C#, with OpenXR underneath so the same project can reach more than one headset family. Day to day that means implementing tracking, input and spatial interactions, keeping frame rate stable on standalone hardware, and testing builds on real devices before anything goes to an app store. The spatial computing engineer job description sounds broad because it is. You sit between gameplay programming, rendering performance and device integration, and you prove each feature on the headset itself, because Play mode hides many problems.
This is an engineering seat. Asset optimisation and shader authoring belong to technical artists, and Apple-only visionOS work in Swift is a separate specialism. Your output is C# systems that hold up across devices.
Unity scenes, prefabs and scripts take up most of the working day. Expect to write interaction components, load scenes without hitches and keep garbage collection out of the per-frame path. Allocating a new list inside Update looks harmless on a desktop and shows up as a stutter on mobile silicon. Good C# here is boring C#: pooled objects, cached references and predictable lifecycles.
Read XR package changelogs carefully. Plugins move quickly and an upgrade can quietly change behaviour.
OpenXR is the open standard that lets an application talk to different XR runtimes through one common interface. In practice it handles the session, reference spaces, action-based input and a set of optional extensions that vendors add for features like hand tracking or passthrough. Your job is to write against the shared surface wherever possible and isolate vendor extensions behind clean abstractions, so supporting another headset means adding a module rather than rewriting the interaction layer.
Check which extensions a runtime actually exposes, and test the fallback path as carefully as the main one.
Input is where users decide whether an app feels trustworthy. You will map controller actions through OpenXR's action system, support hand tracking where the device offers it, and build interactions such as grabbing, poking, ray selection and two-handed scaling. Hands bring their own problems: tracking can drop when fingers overlap, and a pinch that registers a frame late feels broken even if it technically works.
Grab volumes larger than the visible object, a highlight before contact and controller haptics do more for comfort than any clever gesture.
That drifting table from the opening is an anchoring problem. Mixed reality depends on passthrough video of the room and on spatial anchors that pin content to real-world positions. You will create, persist and reload anchors, and decide what happens when tracking quality drops in a dim room. Sometimes the fix is technical, like re-anchoring after relocalisation. Sometimes it is design, like avoiding content that has to line up with a physical edge to within millimetres.
Plane and mesh detection vary by device, so assume some of them may be missing.
A standalone headset is a phone-class chip strapped to someone's face, rendering two views at a high refresh rate. Missing frames is not a cosmetic issue; it causes discomfort. Much of the work is profiling: using the Unity Profiler and Frame Debugger alongside the headset vendor's own performance tools to see whether a spike comes from the CPU, the GPU, or the thermal limits of the device. Typical culprits are too many draw calls, overdraw from transparent effects, expensive post-processing and scripts doing too much each frame.
You will batch where you can, cut what players will not miss, and agree performance budgets with artists before content arrives rather than after. That particle effect probably needs fewer, smaller particles and an opaque material. Fixing the asset itself is the technical artist's job; spotting it and proving the cost is yours.
You need working fluency with vectors, matrices, quaternions and coordinate space conversions. Most spatial bugs are a transform applied in the wrong space or a rotation composed in the wrong order.
The role is Unity-first, but exposure to Unreal Engine is expected. You should be able to read a Blueprint or C++ sample and discuss sensibly when a project weighs one engine against the other.
Every feature is verified on hardware before release. That means building to the device, running through comfort and interaction checks, capturing performance data and fixing regressions before they reach a store submission. Store requirements change, so read the current guidelines rather than last year's checklist.
For a work from home setup, you are expected to have access to a headset such as Meta Quest for testing. A practical setup is a development PC capable of running Unity and building Android-based XR targets, a good USB-C cable for tethered debugging, developer mode enabled on the headset, wireless debugging configured for quicker iteration, and a clear, well-lit play space so tracking behaves the way it will for users. Check the current developer account and device terms with each vendor, since they do change.
Typically you would hold a degree in computer science or a related field, with around three years building AR, VR or mixed reality apps. The core spatial computing engineer skills are strong C# with Unity, OpenXR experience, exposure to Unreal, 3D maths and performance profiling. XR courses from engine makers, universities and online platforms can fill gaps, but no single spatial computing engineer certification replaces shipped work. Check what any course covers before paying for it.
On spatial computing engineer salary, this position pays $95,000 per year USD, full-time and remote from any country. Being open worldwide also means competition from everywhere.
Beginners should know that entry-level spatial computing roles are thin on the ground, and this one asks for around three years. The way in is to build and publish small, finished projects. A tabletop MR app with persistent anchors, a hand-tracked interaction sample, or a VR scene you have profiled and optimised to hold frame rate on a standalone headset all show the right instincts. Share them in a public repository, or through a headset store's test release options where available, with short notes on what you measured and changed. That reads better on a spatial computing engineer resume than a list of tutorials.
Spatial computing engineer and AR/VR developer overlap heavily, and many teams use them interchangeably. Where there is a difference, the spatial computing title tends to stress mixed reality, real-world anchoring and cross-device systems, while AR/VR developer can mean anything from mobile AR filters to fully immersive VR games. Read the responsibilities, not the title.
The kinds of organisations that employ XR engineers include headset makers, game studios, enterprise training and simulation firms, healthcare and engineering visualisation teams, retail and architecture companies, and agencies building branded experiences. Hiring tends to rise after major headset launches and cool when investment slows. Engineers who can make an experience comfortable on modest hardware and portable across vendors tend to stay useful whatever the next device looks like. Interviews often include a practical task, so expect spatial computing engineer interview questions on quaternions, profiling a slow frame and structuring input across devices.