Hiring at Zed: Building in Real Time

Zed's codebase spans a very wide range of concerns. From shader code running on the GPU to WASM binaries supporting real-time collaboration in the cloud. We love to take ownership of our abstractions. But the software you own can end up owning you, especially in the era of agents. It takes a special kind of engineer to navigate the trade-offs involved in moving quickly with quality while maintaining ownership of the full stack.

Where people come from

Zed is growing fast: in the past year, we hired 20+ engineers! While some came through the traditional hiring route, other candidates surfaced through open source contributions, conference conversations, Hacker News threads, or relationships built over time. Less than half of our hires ever submitted an application.

Applications are useful, but they don't capture what we care the most about: how someone engages with hard problems over time. How they work, think, and communicate the ideas behind their results.

The first 90 days

The first 90 days at Zed aren't a slow ramp: you're in the work immediately. Early on, engineers land a first PR and demo it on Demo Fridays, explaining what changed and why. They're also pairing with other developers (in Zed!) to think out loud, work through problems, and build in real time.

With a codebase approaching a million lines of Rust, mastery isn't expected right away. What matters is for new hires to gather context and make changes.

Within a few weeks, the pattern emerges. Some engineers bite off a series of small, scoped changes, while others tackle critical parts of the system early. The size of these early projects matters less than an engineers' follow through and their ability to get up to speed.

This works best for engineers who want to work on meaningful problems in collaboration with others. The signs surface early if a new colleague is struggling with this approach, and we talk it through with them so they understand.

What doing well at Zed looks like

Three things show up consistently in engineers who thrive here: a willingness to work at any layer of the stack, a preference for thinking out loud with others, and a high bar for craft. These are the grain of the wood of Zed: working with them is much easier than against them.

Understand vertical integration

Most software stacks are assembled from other people's abstractions. Zed is vertically integrated: we own the rendering, the UI framework, the editor, the collaboration protocol, and the cloud. That means fewer black boxes, but it also means every engineer has to think about how the whole system fits together. The goal isn't depth in one layer. It's minimizing the total complexity of everything we own.

Some examples:

We built GPUI because no amount of optimization on top of a retained-mode DOM and decades of backward-compatible web standards will outperform rendering graphics like a video game: (GPUI ownership)
Bringing Zed to Windows meant rethinking rendering and platform abstractions together: (Windows progress report)
Because we own the scheduler and async runtime, we can write deterministic tests that simulate network latency and failure — testing the UI, editor, and collaboration protocol together in a single harness, without mocking at every layer: (Head in the Zed Cloud)
DeltaDB records the operational history of development, giving AI models access to how code evolves over time rather than just a snapshot. This is only possible because we control the editor, the collaboration protocol, and the cloud: (DeltaDB)

Collaborate live

Pair programming is an important part of how we work, and it happens directly in Zed: shared buffers, multiple cursors, built-in audio. Some engineers pair almost all the time (great as long as they spend some of it driving), while others opt to pair less. But to do well here, you need to enjoy collaborating: it's part of our culture, and how we maintain our high quality bar. And, we think it's fun.

For many engineers, this is the biggest adjustment: thinking out loud, sharing half-formed opinions, being challenged, changing direction with another person in the loop the whole time.

Obsess over craft and performance

Developers live inside their editor all day. It has to be beautiful, reliable, and fast. It's extremely hard to get all three at once.

Some of what that looks like in practice:

One data structure — SumTree, a B+ tree with polymorphic summaries — powers the rope, the CRDT, and the syntax map. Byte offsets, line numbers, and UTF-16 offsets are all O(log n) seeks instead of linear scans.
We write GPU shaders per platform: Metal on macOS, Direct3D on Windows, and Vulkan on Linux. Text is rasterized into a glyph atlas and drawn as instanced sprites so the entire frame is a flat list of primitives batched to minimize draw calls.
The buffer is a CRDT with two ropes — one for visible text, one for tombstones — and every selection, diagnostic, and decoration is anchored to an insertion timestamp so it survives concurrent edits without drifting.
Keystroke dispatch is synchronous on the main thread with no locks. The window redraws before dispatching a key event so bindings always evaluate against current state. Everything heavy is offloaded to the background executor.

No matter what layer of the stack you're working in, the key ingredient is caring hard about getting it right.

Values

We try to be explicit about how we work so people can decide whether it fits.

Some of the tensions we live and navigate weekly: shipping fast and caring about craft, working intensely and staying humble about what we don't know, taking ownership of problems while staying collaborative. These don't resolve, and that's on purpose. The question is whether you find that energizing or exhausting.

The interview process

After an initial recruiter conversation, there are three conversations:

Technical discussion — a conversation about problems you've worked on and how you approached them.
Rust pairing session — a real pairing session on a problem relevant to Zed's architecture.
Values interview — a conversation about how work actually happens in practice.

Open source as a pathway

Some hires started as contributors because of how they showed up consistently and how they engaged in discussions with the team. In several cases, that led to pairing sessions, which became the clearest signal of how someone actually works.

If you're interested in exploring this route, here's a good place to start.

Whether you start with a contribution or an application, the thing we're looking for is the same: engineers who care about how the whole system fits together. Here's where we're hiring:

Check out similar blogs from the Zed team.