Questions d'entretien Linear pour software engineers

Linear mène la boucle d'entretien d'ingénierie la plus orientée goût parmi les startups réputées. L'équipe est petite, l'exigence est élevée et la boucle est courte — généralement 3 à 4 tours plus un work trial rémunéré. On attend des ingénieurs qu'ils aient des opinions sur le craft logiciel, qu'ils écrivent bien en async et qu'ils apportent du product sense à chaque décision. Il n'y a pas de tour de puzzle algorithmique au sens FAANG. Ce guide synthétise les articles d'ingénierie publics de Linear, les écrits publiés de leurs fondateurs et les rapports publics Glassdoor.

Le processus d'entretien Linear

La boucle est courte et profonde. Screen recruteur (30 minutes, souvent avec un fondateur ou un engineering lead vu le faible effectif). Screen technique (60 minutes, coding conversationnel — plus proche du pair programming que du quiz). Take-home ou work trial rémunéré (quelques jours de vrai travail à temps partiel). Tour final (60-90 minutes, souvent avec le hiring manager et un fondateur, couvrant profondeur technique, product sense et adéquation à l'équipe). Calendrier : 3 à 5 semaines. Linear est connu pour ses décisions rapides et claires.

Le work trial est la pièce porteuse. Linear le rémunère parce qu'ils veulent un vrai signal : comment gérez-vous l'ambiguïté, à quel point votre code est-il propre, à quel point écrivez-vous bien en async. Ce n'est pas un test au sens traditionnel. Traitez-le comme un vrai travail — posez des questions de clarification, rédigez un court design doc avant de coder, contestez les exigences floues. Les candidats les mieux notés traitent le trial comme un aperçu de la vie chez Linear, pas comme un examen.

Top 10 des questions techniques à préparer

Les questions Linear récompensent le code propre, l'aisance moderne en JS/TS et le design pragmatique. La complexité algorithmique ne compte qu'à la marge ; la pensée production compte davantage.

1. Implémentez une fonction debounce ou throttle en TypeScript. Astuce : clarifiez leading vs trailing, énoncez quelques cas de test à voix haute.
2. Construisez un conteneur d'état simple — subscribe, dispatch, mises à jour immuables. Astuce : c'est très Linear ; ils s'intéressent à votre raisonnement sur la réactivité.
3. Mise à jour d'UI optimiste avec rollback en cas d'échec. Astuce : modélisez explicitement l'état local ; traitez le chemin d'échec comme un cas de première classe.
4. Éditeur de texte temps réel avec résolution de conflits — raisonnement OT ou CRDT basique. Astuce : choisissez CRDT ; expliquez pourquoi il est compatible avec la cohérence à terme.
5. Filtrez et triez une grande liste d'items en React — considérations de performance, mémoïsation, virtualisation. Astuce : discutez des arbitrages, pas seulement de l'implémentation.
6. Implémentez la gestion des raccourcis clavier — séquences multi-touches, résolution de conflits entre contextes. Astuce : Linear est keyboard-first ; ce tour est bien réel.
7. Concevez et codez un petit client d'API avec retry, déduplication et cache. Astuce : pensez à l'expérience développeur de l'utilisation du client.
8. Construisez un petit parseur ou renderer Markdown. Astuce : cadrez le périmètre serré ; livrez un code propre avec des tests explicites.
9. Implémentez undo/redo pour une UI à état. Astuce : command pattern, snapshots ou operation log — choisissez-en un et articulez pourquoi.
10. Refactorez un composant React complexe que l'interviewer vous remet. Astuce : expliquez chaque changement comme un arbitrage, pas comme une simple préférence.

Top 5 des sujets de system design

1. Sync engine local-first — la technologie cœur de Linear. CRDTs, support offline, résolution de conflits, autorité côté serveur.
2. Système de collaboration temps réel — présence, curseurs, mises à jour optimistes, fan-out serveur.
3. Routage de notifications — préférences, debounce, batching, livraison async via email/push/in-app.
4. Permissions et contrôle d'accès — granularité workspace/team/project, héritage de rôles, application au moment de la requête.
5. Design d'API et de webhooks — arbitrages GraphQL vs REST, rate limiting, garanties de livraison des webhooks.

Pour le sync engine de Linear en particulier : lisez leurs articles de blog d'ingénierie publiés avant la boucle. Ils ont écrit publiquement sur l'architecture local-first et les CRDTs. Arriver en ayant lu ces ressources fait bonne impression ; arriver sans les avoir lues constitue un signal d'alarme discret pour les postes senior+.

Top 5 des questions comportementales

1. Qu'est-ce que vous adorez et détestez dans Linear en tant que produit ? Soyez précis — faites ressortir ce que vous changeriez et ce que vous admirez.
2. Parlez-moi d'un produit que vous avez utilisé récemment et que vous trouviez particulièrement bien conçu. Articulez pourquoi — les questions de goût sont un vrai signal chez Linear.
3. Décrivez un projet où vous avez dû écrire pour parvenir à une décision, plutôt que de la régler en réunion. Culture de l'écriture async.
4. Décrivez-moi comment vous structureriez une semaine sans standups ni réunions de statut. La priorisation autonome est le test.
5. Parlez-moi d'une fois où vous avez contesté une demande de fonctionnalité venant d'un client. La pensée product-first compte plus que de faire plaisir au client.

Conseils propres à la culture Linear

Linear livre des opinions produit à travers le code. On attend des ingénieurs qu'ils se soucient du polish visuel, des détails d'interaction et de la copy. À chaque tour, cherchez des occasions naturelles de faire ressortir une pensée produit. « J'implémenterais ça avec une transition de 200 ms parce que l'instantané paraît brusque pour un changement de cette ampleur » passe bien plus haut que « j'ajouterais une transition ». Les signaux de goût précis sont rares et prisés.

L'écriture async est une compétence cœur, pas un bonus. La culture de Linear pousse les décisions à travers des docs écrits plutôt que des réunions. Le take-home ou le work trial produira des artefacts écrits (design docs, commentaires de code, descriptions de PR) évalués aussi soigneusement que le code. Une écriture claire est notée aussi haut qu'un code propre.

Petite équipe signifie signal élevé. Il n'y a pas de parcours « atterrissez quelque part dans l'org et trouvez votre équipe » chez Linear. Le hiring manager sera votre manager. Le fondateur sera peut-être votre skip-level. Chaque interaction est une vraie évaluation d'adéquation. Soyez la personne avec qui vous voudriez travailler lundi — précise, calme, avec des opinions sans être dogmatique, et capable d'admettre « je ne sais pas » sans broncher.

Questions fréquentes