Linear interview questions for software engineers

Linear runs the most taste-driven engineering interview loop among well-known startups. The team is small, the bar is high, and the loop is short — typically 3-4 rounds plus a paid work trial. Engineers are expected to have opinions about software craft, write well async, and bring product sense to every decision. There's no algorithm puzzle round in the FAANG sense. This guide synthesizes Linear's public engineering posts, their published founder writing, and public Glassdoor reports.

The Linear interview process

The loop is short and deep. Recruiter screen (30 minutes, often with a founder or engineering lead at small headcount). Technical screen (60 minutes, conversational coding — closer to pair programming than a quiz). Take-home or paid work trial (a few days of part-time real work). Final round (60-90 minutes, often with the hiring manager and a founder, covering technical depth, product sense, and team fit). Timeline: 3-5 weeks. Linear is known for fast, clear decisions.

The work trial is the load-bearing piece. Linear pays for it because they want a real signal: how do you handle ambiguity, how clean is your code, how well do you write async. It's not a test in the traditional sense. Treat it like real work — ask clarifying questions, write a short design doc before coding, push back on unclear requirements. The candidates who score highest treat the trial as a preview of working at Linear, not an exam.

Top 10 technical questions to prepare

Linear questions reward clean code, modern JS/TS fluency, and pragmatic design. Algorithm complexity matters only at the boundary; production thinking matters more.

1. Implement a debounce or throttle function in TypeScript. Hint: clarify leading vs trailing, write a few test cases out loud.
2. Build a simple state container — subscribe, dispatch, immutable updates. Hint: this is Linear-flavored; they care about how you reason about reactivity.
3. Optimistic UI update with rollback on failure. Hint: model the local state explicitly; handle the failure path as a first-class case.
4. Real-time text editor with conflict resolution — basic OT or CRDT thinking. Hint: pick CRDT; explain why it's eventual-consistency-friendly.
5. Filter and sort a large list of items in React — performance considerations, memoization, virtualization. Hint: discuss tradeoffs, not just implementation.
6. Implement keyboard shortcut handling — multi-key sequences, conflict resolution between contexts. Hint: Linear is keyboard-first; this round is real.
7. Design and code a small API client with retry, deduplication, and caching. Hint: think about the developer experience of using the client.
8. Build a small Markdown parser or renderer. Hint: scope tightly; deliver clean code with explicit tests.
9. Implement undo/redo for a stateful UI. Hint: command pattern, snapshots, or operation log — pick one and articulate why.
10. Refactor a complex React component the interviewer hands you. Hint: explain each change as a tradeoff, not just a preference.

Top 5 system design topics

1. Local-first sync engine — Linear's core technology. CRDTs, offline support, conflict resolution, server-side authority.
2. Real-time collaboration system — presence, cursors, optimistic updates, server fan-out.
3. Notification routing — preferences, debounce, batching, async delivery via email/push/in-app.
4. Permissions and access control — workspace/team/project granularity, role inheritance, query-time enforcement.
5. API and webhook design — GraphQL vs REST tradeoffs, rate limiting, webhook delivery guarantees.

For Linear's sync engine specifically: read their published engineering blog posts before the loop. They've written publicly about local-first architecture and CRDTs. Showing up having read the materials lands well; showing up not having read them is a quiet red flag for senior+ roles.

Top 5 behavioral questions

1. What do you love and hate about Linear as a product? Be specific — surface things you'd change and things you admire.
2. Tell me about a product you've used recently that you thought was particularly well-designed. Articulate why — taste questions are real signal at Linear.
3. Describe a project where you had to write your way to a decision, not meet your way. Async writing culture.
4. Walk me through how you'd structure a week without standups or status meetings. Autonomous prioritization is the test.
5. Tell me about a time you pushed back on a feature request that came from a customer. Product-first thinking matters more than customer-pleasing.

Tips specific to Linear's culture

Linear ships product opinions through code. Engineers are expected to care about visual polish, interaction details, and copy. In every round, look for natural ways to surface product thinking. "I'd implement this with a 200ms transition because instant feels jarring for this size of change" lands much higher than "I'd add a transition". Specific taste signals are scarce and prized.

Async writing is a core skill, not a nice-to-have. Linear's culture pushes decisions through written docs rather than meetings. The take-home or work trial will produce written artifacts (design docs, code comments, PR descriptions) that are evaluated as carefully as the code. Clear writing scores as highly as clean code.

Small team means high signal. There's no "land somewhere in the org and figure out the team" path at Linear. The hiring manager will be your manager. The founder may be your skip-level. Every interaction is a real assessment of fit. Be the person you'd want to work with on Monday — specific, calm, opinionated but not dogmatic, and able to admit "I don't know" without flinching.

Frequently asked questions