Hiring at Zed: Building in Real Time

Zed is built across rendering, real-time collaboration, and AI, all on the same system. Rendering decisions affect input latency. Collaboration shapes how state is represented. AI depends on how code is indexed and updated. Each part feeds back into the others.

Understanding how those pieces interact, and where they break down, is the actual job.

We hire engineers who can work from those constraints and keep going when the abstractions stop being helpful.

Where people come from

Over the past year, we've hired 20+ engineers.

Some came through traditional applications. Others showed up through open source contributions, conference conversations, Hacker News threads, or relationships built over time. Less than half of our hires ever submitted an application.

We look for the work and the thinking behind it — how someone engages with hard problems over time.

The first 90 days

The first 90 days at Zed aren't a slow ramp. You're in the work immediately, and the question is how well this way of working fits.

Early on, engineers land a first PR and demo it on Demo Fridays, explaining what changed and why. At the same time, they're pairing: thinking out loud, working through problems together, building in real time.

With a codebase approaching a million lines of Rust, mastery isn't expected early. What matters is picking up context and making changes.

Within the first few weeks, the pattern becomes clear. Some people start with a small change. Others take on critical parts of the system early. What matters is how they follow through and build context.

When it's not working, it shows up: progress is inconsistent, ownership isn't clear, pairing is hesitant or avoided. These things surface early, and we talk about them directly.

This works best for engineers who want to work on real problems in collaboration with others — not in isolation, not from a predefined list.

Engineers who thrive at Zed

Thinking past the machine

We use Rust, but that's not the point. The point is understanding how the system behaves under real constraints — not just how it's supposed to work.

The engineers who do well here don't stop at "this is how the system works." They keep going until they see how it actually behaves:

Working through constraints like latency, memory, and reliability, and how they shape design
Digging deeper when an abstraction leaks
Debugging across layers: rendering, input, networking, storage
Measuring and profiling before making claims about performance

A lot of the work starts where the straightforward approach stops. The system is too dynamic, the latency budget is too tight, or the underlying primitives don't behave the way you expect. Progress comes from finding those constraints and writing code that reflects them — reasoning from first principles rather than around abstractions.

Some examples from the past few years:

Bringing Zed to Windows required rethinking parts of the rendering and platform stack (Windows progress report)
Zed's cloud and collaboration model means treating the editor as a shared, evolving system from the start (Head in the Zed Cloud)
Designing GPUI required rethinking ownership and memory models for UI systems (GPUI ownership)

Collaboration is real-time

Pair programming is a default mode of working at Zed. Most engineering happens in pair sessions, and in Zed: shared buffers, multiple cursors, built-in audio. There isn't a traditional PR backlog. Pairing is the feedback loop.

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.

Craft and performance

Performance and reliability aren't properties you add at the end. They're constraints that run through the whole system.

Zed engineers work on:

Rendering pipelines that stay responsive under constant updates
Input handling at keystroke granularity
Data structures and memory layouts that scale with large codebases
Incremental indexing as code changes
Real-time collaboration built on CRDTs

Most of the work is simplifying systems, tightening feedback loops, and keeping the editor responsive under continuous change — including how it feels, not just whether it compiles.

AI systems inside a live editor

Most AI developer tools work on snapshots: a prompt, a file, a moment in time. But codebases don't stay still. Multiple developers edit and refactor in parallel. Context shifts constantly.

Zed's AI systems operate inside that environment.

The work spans context systems for large, changing codebases; evaluation frameworks built around real developer outcomes; latency, reliability, and cost tradeoffs; infrastructure connecting models to live editor state; and multi-developer collaboration where AI operates alongside humans, not ahead of them.

This builds on DeltaDB, a system that records the operational history of development so models can reason about how code evolves over time, not just what it looks like at a snapshot.

Values

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

Some of the tensions we actually live with: shipping fast and caring about craft, working intensely and staying humble about what we don't know, taking ownership of problems while staying genuinely collaborative. These don't resolve — you navigate them every week. The question is whether you find that energizing or exhausting.

The interview process

After an initial recruiter conversation, there are three conversations — no whiteboard puzzles, no LeetCode.

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.