The Linear Technical Interview Process in 2026: A Complete Guide

The State of Linear Hiring in 2026

Linear enters 2026 as one of the most coveted engineering destinations in the industry, despite an organization that remains under 120 people total. The company has shipped its way into a position where it is now the default product-development tool for a meaningful share of the venture-backed software ecosystem, and the brand has compounded the gravitational pull on engineers who care about craft. Karri Saarinen's design-driven cultural thesis — that small teams of senior generalists outperform large teams of specialists when the bar on taste and ownership is high — is now a reference model rather than a contrarian bet.

What this means for candidates is sharp and uncomfortable: Linear in 2026 is selecting against the median engineer the same way Stripe selected against the median engineer in 2020. The application pool is enormous. The hiring rate is in the low single-digit percentages. The signal Linear is looking for has not changed since the company started — shipped work, design taste, async maturity, and TypeScript fluency — but the threshold for that signal has moved up materially.

Linear's loop also looks almost nothing like a traditional FAANG interview process. There is no algorithmic phone screen. There is no whiteboard system design round on URL shorteners. The entire loop is built around evidence of work and the work trial — a paid two-to-five-day engagement on the real product with the actual team. Engineers who prepare for Linear the way they would prepare for Google are preparing for the wrong company.

The Full Linear Interview Loop in 2026

A standard Linear loop in 2026 has four stages from application to offer. The total elapsed time is typically four to six weeks, with most of that time absorbed by the work trial scheduling and the asynchronous review of the work-sample submission.

1. Application and work-sample review (asynchronous, 1-2 weeks): Linear evaluates every application alongside a portfolio or proof-of-work submission. Resumes without a credible portfolio link are filtered out at this stage. The reviewers are practicing engineers, not recruiters.
2. Founder or staff engineer conversation (45-60 minutes): A direct conversation about your background, the work in your portfolio, and your reasoning about a specific technical decision you made. For most candidates this is a member of the founding team or a staff engineer; for senior candidates it is sometimes Saarinen or CTO Tuomas Artman.
3. Technical depth interview (60-90 minutes): A conversational deep-dive on shipped work. You walk through a non-trivial project you led, the architecture decisions you made, the trade-offs you considered, and what you would change. The interviewer probes for genuine understanding versus polished narration.
4. Paid work trial (2-5 days, scheduled around availability): You ship a real scoped project on the Linear codebase or in a sandboxed environment that mirrors it, alongside the team that would hire you. Senior product engineering roles typically run the full five days.

Some roles include a fifth stage — a values and culture conversation with a non-engineering member of the team — but that is treated as a conversation rather than a decision gate. The decisive signal is the work trial, and the team's blind vote after the trial is what drives the offer.

The Work-Sample Submission: Linear's First Gate

The work-sample submission is the most underrated stage of the Linear loop and the one where the majority of applications get rejected. Linear has been explicit that the company wants to see proof of work upfront — a credible portfolio of shipped software, ideally a product the candidate built and owns, plus a writeup or video that explains a specific technical decision in depth. Resumes alone are rarely sufficient.

The candidates who pass this gate share a few characteristics. They link to one or two production products with real users, not toy GitHub repos. They include a deliberate writeup of a specific technical decision — typically a paragraph or short video — that demonstrates how they think about trade-offs. Their portfolio shows that they have shipped end-to-end software where they owned the product surface, not just contributed a feature to a larger team's codebase. They communicate the way Linear engineers communicate internally: written, structured, opinionated, and short.

The candidates who get filtered at this gate share an equally clear set of patterns. They lead with credentials and logos. They link to a personal site that has been unmaintained for two years. They submit GitHub repos with the default README and no demo. They write cover letters that describe what they want from Linear rather than what they would bring to it. The asymmetry of attention is uncomfortable but real — Linear engineers spend more time evaluating one strong work sample than they spend rejecting twenty weak ones.

The Conversational Technical Rounds

The two technical conversations in the Linear loop are deliberately not coding interviews. They are deep conversations about shipped work. The interviewer's goal is to understand whether you actually built the things on your portfolio, whether you understand the decisions that went into them at a level that survives genuine probing, and whether you reason about engineering trade-offs the way Linear engineers reason about them.

The format runs as follows. You pick one or two non-trivial projects from your portfolio. You walk through the problem you were solving, the architecture you landed on, the alternatives you considered, the things you got wrong on the first iteration, and what you would do differently if you started today. The interviewer interrupts with specific follow-up questions, often pushing you to defend a choice that they suspect was either copied from a tutorial or made without enough thought. Strong candidates engage with the pushback genuinely and update their thinking when the interviewer surfaces something they had not considered. Weak candidates either defend their original answer rigidly or capitulate immediately to whatever the interviewer suggests.

Topics that come up consistently across these rounds in 2026: data modeling for collaborative software where multiple users edit the same object simultaneously; offline-first design and the trade-offs between optimistic UI and eventual consistency; the design of a sync layer over WebSockets including reconnection, ordering, and conflict resolution; the question of when to use IndexedDB versus a server-side cache for client data; and the tension between shipping fast and getting the data model right the first time. Familiarity with system design fundamentals at the small-team product-engineering scale matters more than familiarity with planetary-scale distributed systems.

What the Work-Sample Submission Looks Like in Practice

The kind of TypeScript work that signals well to Linear evaluators is product-engineering code: opinionated, well-typed, designed for the developer who has to maintain it six months from now, and clearly aware of the user-facing latency budget. The snippet below is the kind of small, complete example a strong candidate might attach to a portfolio writeup — a minimal optimistic mutation helper for a collaborative editing surface, with explicit handling of the failure modes that matter in a Linear-style sync model.

type MutationId = string;

interface Mutation<T> {
  id: MutationId;
  apply: (state: T) => T;
  revert: (state: T) => T;
  send: () => Promise<{ accepted: boolean }>;
}

interface OptimisticStore<T> {
  state: T;
  pending: Map<MutationId, Mutation<T>>;
  subscribers: Set<(s: T) => void>;
}

function createStore<T>(initial: T): OptimisticStore<T> {
  return { state: initial, pending: new Map(), subscribers: new Set() };
}

function notify<T>(store: OptimisticStore<T>): void {
  for (const cb of store.subscribers) cb(store.state);
}

export async function commit<T>(
  store: OptimisticStore<T>,
  mutation: Mutation<T>,
): Promise<void> {
  store.state = mutation.apply(store.state);
  store.pending.set(mutation.id, mutation);
  notify(store);

  try {
    const { accepted } = await mutation.send();
    if (!accepted) throw new Error("server rejected mutation");
    store.pending.delete(mutation.id);
  } catch (err) {
    store.state = mutation.revert(store.state);
    store.pending.delete(mutation.id);
    notify(store);
    throw err;
  }
}

A strong portfolio writeup attached to this kind of snippet would explain three things: why optimistic mutation is the right default for the surface in question, how the revert path interacts with subsequent mutations that depend on the optimistic state, and what the production version would look like once server-driven reconciliation and reordering are added. Evaluators are checking whether the candidate has thought about the second-order problems, not whether the code compiles.

The Paid Work Trial: Linear's Defining Stage

The work trial is the round that distinguishes Linear's hiring process from every other company in the industry. It is paid. It runs two to five days. You ship a real scoped piece of work on the actual codebase, alongside the team that would hire you. The output of the trial is the central piece of evidence in the offer decision, and the team votes blind on whether to extend the offer before any discussion happens.

The work trial is structured to look as much as possible like the candidate's first week as a full-time employee. You receive access to the codebase or a sandboxed environment that mirrors it, a scoped project with clear acceptance criteria, and direct collaboration with engineers via Linear's async channels — primarily written conversation in Linear itself, with synchronous video calls scheduled only when genuinely useful. Senior roles typically run the full five days. Junior roles and roles with narrower scope sometimes run two or three.

What evaluators are checking during the trial: do you ship something that actually works, end to end, by the end of the window? Do you communicate the way Linear engineers communicate — written, structured, asynchronous, and concise? Do you make reasonable decisions when the spec is ambiguous, document those decisions, and keep moving rather than waiting for permission? Do you produce code that another Linear engineer could pick up and ship the following week? Do you raise the team's energy, or do you cost the team time?

The most common reasons candidates fail the work trial are not technical. They are pacing problems (spending too long on the wrong sub-problem and not delivering anything shippable by the deadline), communication problems (going silent for a day and then surfacing with a half-finished PR), and ambiguity problems (asking the team to make every decision rather than making reasonable calls and documenting the reasoning). Treat the trial as a working week, not as a take-home exercise.

Linear Compensation in 2026: Bands and Equity

Linear compensation in 2026 sits at the high end of the late-stage startup band but does not match public FAANG cash compensation at the senior level. The trade-off is the equity component, which is still in pre-IPO units, and the quality of the work environment, which is genuinely differentiated. Levels.fyi data from May 2026 shows the highest reported Software Engineer package at Linear at $386,200 total compensation, with a median around $205,000 — numbers that are consistent with a small, senior team and a deliberate cap on cash burn.

Approximate total compensation ranges for engineering at Linear in 2026, calibrated against levels.fyi reporting and aggregated public offers:

Equity at Linear is in privately-held shares and the dollar value depends on a future liquidity event. The company has been deliberately patient about an exit path, which has compounded the value of grants for engineers who joined in 2022 or 2023 but also extends the time horizon over which new joiners realize value. Base salary is a higher share of total compensation than at companies like Stripe or Anthropic, which makes the cash floor more predictable but the upside narrower.

Negotiation reality at Linear is that the bands are tight by design. The company has been explicit that it does not want compensation negotiation to dominate the offer process and prefers to set bands that engineers can accept without an adversarial back-and-forth. Engineers with a credible competing offer from a public-company FAANG can sometimes move the equity component, but the cash component is rarely flexible by more than a few percent.

The Final Week Before Your Linear Work Trial

The work trial is the round that pays off targeted preparation more than any other stage of the loop. The week before the trial is the time to set up your environment correctly, validate that you can ship a complete change on a TypeScript codebase under time pressure, and arrive rested.

• Set up a clean development environment that mirrors what you will use during the trial. Run a real change through the full lifecycle — edit, type-check, test, commit, open a PR — on a TypeScript codebase you have written or contributed to. Confirm that nothing in your toolchain will slow you down on day one of the trial.
• Read Linear's public engineering content. The Pragmatic Engineer interview with Tuomas Artman, the public posts on Linear's sync engine, and the reverse-engineering writeups by external engineers are all directly relevant to the architectural mental model evaluators expect you to bring.
• Practice writing concise, structured async updates. The pattern Linear engineers use is short, opinionated, action-oriented written communication. If your default mode is long stream-of-consciousness updates, recalibrate now.
• Validate your home setup for the specific tools you will use during the trial — typically Linear itself, GitHub, and video calls on Google Meet or Zoom. If you plan to use AI assistance like TechScreen during synchronous calls, validate invisibility on Google Meet specifically before the trial begins.
• Sleep. The work trial is genuinely demanding and the candidates who burn out on day two underperform the candidates who pace themselves.

One specific piece of advice for the work trial: ship something complete on day one, even if it is small. A working end-to-end change in your first eight hours signals momentum and shipping orientation in a way that no amount of architectural discussion can match. Then iterate. Linear engineers value the candidate who delivers a small thing on day one and a larger thing on day five over the candidate who promises a perfect thing on day five and does not deliver it.