iOS Engineer at Linear (2026): CRDT Sync, Public Method, Small Team

What Linear publishes about the role

Linear's iOS roles are at linear.app/careers, posted as iOS Engineer or Mobile Engineer. The product surface is small but high-leverage:

• iOS app: The iPhone / iPad client for Linear. Built in Swift / SwiftUI with deep integration into the sync engine.
• macOS app: Native macOS client. Shares substantial code with the iOS app via SwiftUI's cross-platform support.
• Sync infrastructure contributions: The CRDT-based sync engine is shared between iOS, macOS, and web. iOS engineers at Linear regularly contribute to the TypeScript backend and the shared sync protocol — the cross-stack ownership is a hallmark of small-team Linear culture.

Linear's engineering content lives at linear.app/blog with periodic technical deep-dives. The canonical reads:

• 'Scaling the Linear Sync Engine' (2020, Tuomas Artman / engineering team) — describes the CRDT-based sync architecture, the choice of operation-based CRDTs, and how conflicts resolve across clients.
• 'The Linear Method' (linear.app/method) — not a blog post but a hosted document explaining how Linear builds product. Required reading.
• Tuomas Artman has given multiple public talks (e.g., Local-First Conf, RailsConf 'Sync Engines for Local-First Software') on Linear's sync architecture.

The interview: take-home heavy, craft-focused

Linear's iOS interview shape:

1. Recruiter screen. Career timeline and Method-fit signal. Linear screens hard for cultural fit with the Method.
2. Take-home project. Substantial — typically a self-contained iOS feature that mirrors how Linear thinks about product. Time estimate 8–12 hours; the spec is open-ended on purpose. The bar is craft: clean code, sensible architecture, considered animations and interactions, accessibility implemented from the start.
3. Code review. 60–90 minutes. The hiring engineer walks through the take-home with you, asks follow-up questions, requests changes live. This is where Linear assesses how you think about your own code under review.
4. Architecture / system design. 60 minutes. Conversational rather than whiteboard. Common asks: 'How would you sync data between iOS and a backend with offline support?' Strong candidates name CRDTs, operation-based vs state-based trade-offs, and the consistency / convergence story.
5. Cross-functional partner round. A designer or product partner. Tests collaboration shape and Method fluency.
6. Founder / leadership conversation. Karri Saarinen, Tuomas Artman, or another senior leader. Strategic conversation about Linear's direction; the candidate's questions matter as much as their answers.

The Linear-shaped specifics: craft is the dominant signal. Linear does not have a Big-Tech-style algorithmic coding round. The take-home is the coding bar; what you do with it determines whether you advance. Engineers who write competent-but-unpolished take-homes typically fail; engineers who ship a take-home that feels like a Linear feature typically advance.

The CRDT sync engine and what iOS engineers actually work on

Linear's sync engine is the technical centerpiece of the product. From Tuomas Artman's public talks (Local-First Conf, RailsConf) and the 2020 blog post, the architecture is:

// Conceptual — Linear's actual sync code is TypeScript on the backend
// and Swift / TypeScript on the clients. This is the rough Swift
// equivalent of how operation-based CRDTs feel from the iOS side.

// 1. Each user action is an operation
struct Operation: Codable, Sendable {
    let id: UUID            // operation ID, used for dedup
    let entity: String      // "issue", "comment", "label"
    let entityId: UUID
    let field: String       // "title", "state", "assignee"
    let value: AnyCodable   // new value
    let timestamp: Date     // hybrid logical clock in production
    let userId: UUID
}

// 2. Operations apply to local state immediately (optimistic update)
actor LocalStore {
    private var entities: [UUID: Issue] = [:]
    private var pending: [Operation] = []

    func apply(_ op: Operation) {
        // optimistic — update local state
        if let issue = entities[op.entityId] {
            entities[op.entityId] = issue.applying(op)
        }
        pending.append(op)
    }

    func confirmed(_ ids: Set<UUID>) {
        pending.removeAll { ids.contains($0.id) }
    }
}

// 3. Operations sync to the server via WebSocket
//    Server merges, broadcasts to other clients
//    Conflict resolution is built into the operation semantics
//    (e.g., last-writer-wins for scalar fields, set-add for tags)

// 4. Other clients receive the operation and apply locally — convergence
//    is guaranteed by the CRDT properties of the operation set

Why this matters for the interview: the system-design round at Linear often surfaces 'design a sync engine' as the prompt. Strong candidates: name CRDTs, distinguish operation-based from state-based, articulate convergence guarantees, and discuss the trade-offs vs OT (Operational Transformation, the older Google-Docs approach). Tuomas Artman's talks are the canonical reference Linear engineers have themselves watched.

Compensation: published bands, the equity story

Linear has been more transparent about salary than most peer growth-stage companies. The Linear handbook and individual postings publish salary ranges. As of 2026, typical published ranges:

Below FAANG-tier salary at the cash-comp level. The equity component is substantial given Linear's growth — 2024 valuation rounds priced the company in the $400M–$1B range per public press, and option-grant value at senior levels has tracked accordingly. Equity-vs-cash trade-off is the standard Linear-vs-FAANG decision.

Levels.fyi has limited Linear data given the small org size — the published ranges in Linear's own postings are the more authoritative source.