Networking Engineer — Real-Time Collaboration

• Design the data model and sync protocol that let a timeline be edited by more than one participant at once — human or AI — without conflicting changes silently overwriting each other.
• Decide, and defend, how conflicts actually get resolved: last-write-wins is not an option when the "last writer" might be Oz mid-generation and the other might be an editor mid-trim.
• Build the connection layer that carries those edits with the latency a live editing session demands, plus the presence layer — who's in the project, what they're looking at, where their playhead is.
• Get ahead of scale before it's a fire drill: think through what breaks between a two-person session and a much larger one, and fix the architecture before the team hits it, not after an incident forces the issue.
• Set the bar for what "working" means here — not generic uptime, but sync latency and consistency numbers grounded in what an editor actually notices and tolerates.
• Own it end to end when it breaks: root-cause the failure, fix the architecture that allowed it, not just the symptom.
• Bring the rest of the team along — explain a consistency/latency tradeoff to platform, collaboration or leadership teammates in terms they can act on, not just in terms that are technically correct.
• Keep a working knowledge of how other people have solved pieces of this problem — CRDTs, operational transforms, rollback netcode from multiplayer games — and know which ideas actually transfer to a video timeline and which don't.

Required

• Real hands-on experience shipping a system where multiple participants edit shared state live — CRDT/OT-based document collaboration (Figma, Notion, Google Docs-class systems) or real-time multiplayer game networking.
• Working fluency in the actual mechanics: CRDTs or operational transforms, WebSockets/WebRTC, and the latency-hiding tricks (client-side prediction, interpolation, rollback) that make a laggy connection feel instant.
• Solid distributed-systems grounding — consistency models, conflict resolution, failure modes — and the judgment to reason about a system where "just retry" isn't good enough because the thing being edited is somebody's project.
• A track record of owning a live system's reliability yourself, incidents included, not just designing it and handing it off.
• Comfort defining a brand-new system from a blank page — there's no existing spec here to implement against, you're writing it.
• The ability to explain tradeoffs clearly to people who aren't networking engineers — editors, designers, the CTO.

Nice to have

• Multiplayer game networking background — rollback netcode and client prediction map surprisingly well onto this problem.
• Direct experience with CRDT libraries (Yjs, Automerge) or having built an equivalent yourself.
• Experience running WebSocket or relay infrastructure at global scale, including NAT traversal and reconnection handling.
• Time at a company where "real-time collaboration" was the actual hard problem being solved (Figma, Notion, Linear, a multiplayer studio) rather than a "live" label bolted onto a request/response app.