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.
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 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.
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)
- Owning the scheduler and async runtime means we can write deterministic tests that simulate network latency and failure across the full stack — UI, editor, and collaboration protocol in one test harness (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 — possible because we control the editor, the collaboration protocol, and the cloud (DeltaDB)
Pair programming is an important part of how we work at Zed — and it happens in Zed: shared buffers, multiple cursors, built-in audio. Some engineers pair almost all the time, and that's great as long as they spend some of it driving. Others prefer to pair a bit less. Both work. But to do well here, you need to do a fair amount of pairing. It's part of our culture.
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.
Developers live inside their editor all day. It has to be beautiful, reliable, and fast — and 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, 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.
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.
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.
Some hires started as contributors — showing up consistently over time and engaging in discussions, not just submitting patches.
In several cases, that led to pairing sessions with the team, which became the clearest signal of how someone actually works.
Treat it as participation. The work is visible either way.
A place to start.
Zed is a small team. If this sounds like work you want to do:
Recent Posts
Check out similar blogs from the Zed team.
Looking for a better editor?
You can try Zed today on macOS, Windows, or Linux. Download now!
We are hiring!
If you're passionate about the topics we cover on our blog, please consider joining our team to help us ship the future of software development.
Instagram Engineering
Shopify Engineering