A guide to hiring WebAssembly developers
WebAssembly, or Wasm, is a compact code format that runs inside the browser next to JavaScript. Developers write code in a language such as Rust, C or C++, compile it to Wasm and load it from a web page. The browser runs it quickly and in a sandbox, which means it has no free access to the user’s computer. A WebAssembly developer is the person who builds these modules and connects them to a product. This guide explains what the role covers, how it differs from nearby roles and how to set up the work so you get a module that is fast, small and safe. It suits a team with heavy work in the browser and a company that wants to reuse code that already exists in another language.
What WebAssembly developers work on
Typical projects include image and audio processing, video tools, games, data parsers, simulations, drawing and design tools, and scientific code. Others take an existing C, C++ or Rust library and make it run in the browser. Outside the browser, Wasm runs on servers and at the edge, where it is used for plugins and for running code from other parties in a safe sandbox. In all cases the developer chooses the language and tools, builds the module, designs how it talks to the rest of the app, and tests it.
How this role differs from nearby roles
A C++ developer writes fast systems code but may not know the web. A JavaScript developer knows the browser but may not write systems code. A web developer builds sites and apps in general, and a back-end developer works on servers and services, sometimes in Rust or Go. A game developer may use Wasm to bring a game to the browser. A WebAssembly developer sits across these: they need enough systems skill to write the module and enough web skill to ship it. Use this page when the question is how to get heavy or existing code running on the web, and who can do it.
When WebAssembly is a good fit
- Your page does heavy work that makes it slow or makes it freeze.
- You have a tested library in C, C++ or Rust that you would like to run in the browser.
- You want the same core code on the web, on servers and in other apps.
- You build tools for media, design, data or science that run on the user’s device.
- You need a safe way to run plugins or code from other parties.
When it may not help
Most pages are slow because of large images, too many scripts or slow servers, not because JavaScript is too slow. Wasm cannot fix those. It also adds a build step and another language to your project. A good developer will profile your page first and tell you if a simpler fix would do the job. Ask candidates when they would advise against Wasm. Their answer shows whether they think about your problem or about the tool.
What to decide before you hire
- What exactly runs slowly or has to be reused, and how you measure it today.
- The language the code is written in now, and who owns it.
- Where the module must run: the browser, a server, the edge or all three.
- Which browsers and devices your users have.
- Who will maintain the module after it ships.
Reading a WebAssembly developer’s portfolio
Ask for something you can open in a browser. Check that it loads in a reasonable time, that the page stays responsive during heavy work and that it behaves on a phone as well as a laptop. Ask what the person measured before and after, and which parts they chose to leave in JavaScript. A short write-up of the trade-offs is worth more than a list of languages. Be careful with a portfolio that shows only a demo that renders a fractal or runs a benchmark, because real products need loading, error handling and updates.
Interview questions to try
- How would you decide whether our slow feature needs WebAssembly at all?
- How do you pass large data between JavaScript and a Wasm module without copying it again and again?
- What do you do to keep the downloaded module small?
- How do you keep the page responsive while the module does long work?
- Tell us about a memory bug or a browser difference that you had to track down.
Listen for concrete examples and for plain talk about trade-offs. Doubt anyone who says Wasm is always faster.
Run a small paid task
Give each finalist a short brief from your own problem. Good tasks include a written review of the slow code with a recommendation, a small module that does one job from your list, or a proof of concept that compiles one function and calls it from a page. The time should be paid. Judge the result on clear measurement, a simple bridge to JavaScript and a short note on how to build and test it.
Give them tools and a rhythm
Your developer needs the code repository, the build pipeline and the project board, but nothing beyond that. The repository and accounts should be registered to you. Agree early on how the module is built, where the output goes and how it is tested, and write it down. A short written update each week and a demo every other week is enough, as long as the update follows the same shape each time.
Plan for handover
Wasm modules have a build chain that is unfamiliar to many web teams. Ask the developer to document the tools, the versions and the steps to rebuild the module from scratch. Add the build to your regular pipeline so it does not depend on one person’s laptop. Keep notes on what the module does, what it expects as input and where its limits are. This lets you change the team without losing the work.
Mistakes to avoid
- Using WebAssembly before measuring, when a simpler fix would have worked.
- Moving data between JavaScript and the module too often, which cancels the speed gain.
- Shipping a large module that makes the first visit slow.
- Skipping tests in other browsers and on phones.
- Handing the repository or hosting account to a contractor instead of keeping it in your name.
Need people for the wider team? Read about how to hire a software engineer or a web developer, and see how hiring works on our pages.