I have no idea, I'm not either of those types of people for the current VR/AR/MR industry. And, even if I were, whatever I might say is not certain to be usefu

I have no idea, I'm not either of those types of people for the current VR/AR/MR industry. And, even if I were, whatever I might say is not certain to be useful to you. Normally, I'd recommend you interview people working in the space to understand what problems they're encountering now, and what they expect to run up against next, but when they're inventing as they go, by definition, they don't (and can't!) know. They could tell you their current problem(s), but neither you nor they know if that's a general-case problem, or a problem specific to their implementation. Plus, they'll solve it in parallel before you, because they have the compounded knowledge of all their work leading up to it. Only the people actually working on the problems know what those problems are, and they don't have time to stop and bring you up to speed. You have to catch up, or at least show you're on the way on your own. The job listings seem to support this: Apple wants either a PhD, which means having published papers advancing the field; or industry experience delivering products, which means having discovered problems and then solved them for real users and getting paid for them, end-to-end. Snap wants a Master or PhD, or "experience implementing, verifying, and optimizing," which is just short of being responsible for shipping a product. Magic Leap is an internship, but they want "Demonstrated experience," aka having built something yourself. In this, you can't be a generalist, up for solving any problem. I'm sure you're entirely capable of that, but the requirement is also that you can figure out what the problems are and will be, on your own. In a new industry, there aren't paths to follow, everyone's still cutting down brush. They're not publishing most of their work, so you have no idea what's solved, and even if they were, I think it's generally accepted that a published paper (or launched product) is a few years behind what's currently being tried in a lab. You will probably inevitably be redoing someone else's work, but you won't learn that for months or years. I'm not sure there's any advice I could give except to pick a problem domain, pick a use case, learn all the component pieces of that problem, make new and different tradeoffs, and figure out what's unsolved for the choices you made.