Minecraft Client Engineer · Java / Modding

Read this first

We're hiring multiple people for this. This one is for people coming from Java and Minecraft modding. If you come from low-level graphics or C++ engine work, read the Graphics Engineer listing instead.

About Dawn / InPvP

InPvP is one of the biggest companies in the Minecraft space, with four featured Bedrock servers, plus 2 more coming later this year, as well as other major unannounced projects and acquisitions coming by EoY. We deliver high quality experiences and value our partnership with Microsoft/Mojang.

We took over the Feather Client to do right by its community. Dawn, formerly Feather Client, is InPvP's cross-platform launcher + client built for PvP performance and strong modding features. It is the fastest growing Minecraft client in the space and is currently undergoing major rewrites and bug fixing from tech debt accumulated over the past year. We need a perfect product before we start marketing, so it's all hands on deck.

What you'd work on

This track is broad. Depending on what you're good at and what's currently on fire, you might work on any of:

• ·Feature modules: the 100+ in-game modules (HUD, combat, UI, cosmetics, server integrations) and the systems behind them.
• ·Mixins and access wideners: hooking into Minecraft and keeping the hooks alive as the game shifts under them from one snapshot to the next.
• ·Performance: profiling and cutting JVM-side cost (allocations, GC pressure, JIT behavior), where most of the frame budget goes.
• ·Testing and tooling: the e2e image-regression suite, the benchmark mode.
• ·Mod compatibility: detecting other mods and deciding what module Dawn disables, overrides, or works around for maximum compatibility.
• ·Rendering, if you want it: the render graph, the RHI, the Vulkan and OpenGL backends. A plus here, not a requirement.

What everyone needs

You're a strong low-level engineer who is deep in at least one of two areas: low-level graphics, or JVM internals plus Minecraft modding. Be strong in one and willing to get deep in the other. What we actually care about is that you debug by understanding what's happening, not by trying things until the error goes away.

What fits this track

• ·Solid Java in production, and you understand the runtime, not just the syntax.
• ·Minecraft mod experience. You've shipped or maintained mods and know how Mixins and mappings really behave when they run into other mods.
• ·JVM internals, the heart of the role. You can explain how to make Java fast and why it gets fast: the JIT (C1/C2, tiered compilation, inlining, on-stack replacement, deopt, intrinsics), escape analysis and scalar replacement deciding whether an object ever touches the heap, megamorphic call sites and why they hurt, allocation rate measured against GC pauses (G1, ZGC, Shenandoah), and how HotSpot, OpenJDK, and GraalVM differ and where each wins. You read compilation logs and reach for async-profiler or JFR before you start guessing.

Performance role, first

This is a performance role first. A Minecraft client spends its whole frame budget in a few milliseconds, and most of what eats it is on the JVM side: allocation churn, boxing, oversized object graphs, cache-unfriendly data, and call sites the JIT can't inline. If you enjoy driving that number down and proving you did, this is the job.

Graphics is a plus here, not a requirement. If you've got Vulkan or OpenGL experience too, great, and there's plenty of rendering work to pick up if you want it. But you can do this job well and never touch a shader.

Nice to have

• ·Any exposure to Vulkan or OpenGL, in any language.
• ·Linear algebra and the usual graphics math.
• ·GLSL or SPIR-V shaders, and time spent around shader mods.
• ·Profiling, on the GPU (RenderDoc, Nsight) or the CPU (Tracy, async-profiler, JFR).
• ·JNI or JVMTI, LWJGL, large long-lived codebases, Gradle.

What's hard about it

None of this is easy and I want to personally say this upfront: if you can't keep up with pressure and a fast-moving environment you will get cut. InPvP, across all of its projects, moves fast, ships fast, and has no tolerance for slacking.

26 versions and multiple mod loaders is a lot of surface area, and a fix in one version is sometimes a new bug in three others. You'll still meet AMD driver bugs, NVIDIA quirks that only show up on Linux, and macOS doing its own thing entirely. Validation layers will confidently lie to you. We support Vulkan because Mojang added it in 26.2, and a graphics backend that new comes with plenty of its own surprises. And every so often there's no documentation at all and you reverse-engineer behavior until it makes sense. If that sounds miserable, this isn't the job. If it sounds a little bit fun, apply.

Logistics

• ·Fully remote
• ·Independent contractor
• ·Minimum 40 hrs/week
• ·Pay is competitive and not tied to your location, with a performance review and a raise every six months. InPvP pays the highest rates in the space, across all positions for all of our projects.

Applying

Email [email protected] with a CV and send something interesting like a mod you shipped, a performance project, a pull request or writeup where you chased a hard bug all the way down. Tell us the worst performance or correctness problem you've fixed, and how you knew it was actually fixed.