About fab2 The fab2 team can build anything. We design all the hardware and software needed to make chips and we make the fabs, tools, and components ourselves. We're looking for exceptional, hands-on people who can iterate to the limits of what's possible. fab2 was founded by Sam Zeloof https://www.youtube.com/@SamZeloof and Jim Keller https://en.wikipedia.org/wiki/Jim_Keller_(engineer). Sam is best known for making chips in his garage, and Jim has been a leader in the semiconductor industry for the past 40 years. About the team We are building the software that silicon chip designers should have had 20 years ago. Designing a chip today means stitching together a pile of desktop software, much of it decades old. We have a lot of respect for those tools, but in many ways they are behind. They've carried the industry this far, but we see enormous room to do better. For example: real version control, real collaboration, and interfaces that give you intuition rather than requiring it. We've concluded that we must build a lot of it from scratch. Studio is a fast, browser-based, multiplayer platform for designing and assembling whole chips. Figma plus GitHub, for silicon. The primary goal is simple: a user should never have to install anything or leave our app to take a chip from idea to finished design. Schematic capture, physical layout, and simulation, all in one place, end to end. Studio is one half of a bigger idea at Fab2: making chips should be fast. We build our own fab equipment for the same reason we build our own software, because the components for what we want don't exist yet. Studio is the design side of that, and we want to close the feedback loop between designing a chip and fabricating it, so the whole cycle gets faster instead of just one part. Your users include the chip and process engineers sitting near you, which means the feedback loop on your own work is short too. It's a deep application, dozens of complex tools and the heft of Photoshop, but we want it to feel as intuitive and powerful as Figma. It's Rust across the stack, compiled to WebAssembly, with custom rendering with wgpu/WebGPU, one code path native and in the browser. About the role Fullstack, Rust end-to-end, working on the application itself. You will own major features from design through shipping and touch the whole stack. These are some of the problems on the table right now: - Deeply interactive, low-latency editing tools: drag a wire and watch it auto-route, place a block, measure, annotate, catch mistakes the instant they happen. Careful handling, some algorithms and computational geometry. We need to constantly fight to keep the tools simple. - A document model that can be diffed and merged like source code and at the same time real-time collaborative. This is the foundation everything else sits on. - The sync engine streaming edits between clients, so chip designers can work together without sending files back and forth. More like a game server than CRUD: eventual consistency, high bandwidth streaming, correctness. Whether the wire format decodes to owned data or stays zero-copy so it holds up when the design is very large is a decision you own. - A GPU canvas that renders millions of polygons and stays smooth: spatial indexing, culling, level of detail, all in one Rust code path for web and native. - Simulation you can feel: waveforms that stream onto the screen as the solver produces them, with an interactive tier that answers in milliseconds while heavier analysis runs behind it. There is also plenty nearby as the application grows: a plugin system built on sandboxed WebAssembly components, a scripting API where a script is the same first-class client as the mouse, and integrations that send finished designs to the fab. Who does well here The people who have done well on this team tend to come from deep, rich applications: tools and engine programmers, people who have built game level editors, DAWs, CAD tools, rendering pipelines, or software where the hard problems live in the seams between data, rendering, and input. It is tools programming where the output of the tool is silicon. You don't need to know anything about chip design, but you need to be willing to learn. If you've drawn a schematic, run SPICE, or built RLC circuits, you'll ramp faster and probably care more about getting it right, but we can teach, and fresh eyes are part of the point. We are building tools intuitive to new users, not just folks used to the old silicon design tools from the 90s. We take on ambitious goals and work hard. We build complex things quickly. We care that you own every line you ship, and care about clean code. A portfolio (GitHub is fine) is required. We currently use things like: Bevy's ECS, wgpu, Axum, WebAssembly, PostgreSQL. Required Experience - Strong Rust, or serious C++/systems experience and the obvious curiosity to go deep in Rust. - Solid systems fundamentals: memory, performance, concurrency. You profile before you optimize. You've taken something slow and made it fast, and you can tell us about why it was slow. - A track record of non-trivial software you built from scratch and can walk us through end to end. The weird side project, engine, or tool you wrote because the existing one annoyed you. Nice-to-have - A game, engine, or real-time background: ECS, scene graphs, spatial indexing, physics engines, frame budgets, GUI, low-latency input. - Some EE, analog and digital. You don't need to be a chip designer. - Time lived inside deep, serious software, and opinions about it: Blender, Ableton, KiCad, CAD tools, DAWs, game engines. - Distributed or real-time systems: write-ahead logs, event sourcing, replication, CRDTs, OT, websockets. Data pipelines. - Geometry, graph, and routing algorithms; spatial data structures; optimization. - Familiarity with schema evolution and serialization formats like Protobuf, Flatbuffers, Cap’n Proto