Preguntas de entrevista de Linear para software engineers

Linear corre el proceso de entrevista de ingeniería más basado en el gusto entre las startups conocidas. El equipo es pequeño, el listón es alto y el proceso es corto — normalmente 3-4 rondas más un work trial remunerado. Se espera que los ingenieros tengan opiniones sobre el craft del software, escriban bien en async y aporten sentido de producto a cada decisión. No hay una ronda de puzles de algoritmos al estilo FAANG. Esta guía sintetiza las entradas públicas del blog de ingeniería de Linear, los escritos publicados de sus fundadores y reportes públicos de Glassdoor.

El proceso de entrevista de Linear

El proceso es corto y profundo. Screen del recruiter (30 minutos, a menudo con un fundador o un engineering lead dado el tamaño reducido del equipo). Screen técnico (60 minutos, coding conversacional — más cerca del pair programming que de un test). Take-home o work trial remunerado (unos pocos días de trabajo real a tiempo parcial). Ronda final (60-90 minutos, a menudo con el hiring manager y un fundador, cubriendo profundidad técnica, sentido de producto y encaje con el equipo). Cronología: 3-5 semanas. Linear es conocido por sus decisiones rápidas y claras.

El work trial es la pieza que soporta el peso. Linear lo paga porque quiere una señal real: cómo maneja la ambigüedad, qué tan limpio es su código, qué tan bien escribe en async. No es un test en el sentido tradicional. Trátelo como trabajo real — haga preguntas aclaratorias, escriba un design doc breve antes de programar, plante cara a los requisitos poco claros. Los candidatos que puntúan más alto tratan el trial como un anticipo de trabajar en Linear, no como un examen.

Top 10 de preguntas técnicas para preparar

Las preguntas de Linear premian el código limpio, la fluidez con JS/TS moderno y el diseño pragmático. La complejidad algorítmica solo importa en el borde; el pensamiento de producción importa más.

1. Implemente una función debounce o throttle en TypeScript. Pista: aclare leading vs trailing, escriba unos casos de prueba en voz alta.
2. Construya un contenedor de estado simple — subscribe, dispatch, actualizaciones inmutables. Pista: esto tiene sabor a Linear; les importa cómo razona sobre la reactividad.
3. Actualización de UI optimista con rollback en caso de fallo. Pista: modele el estado local de forma explícita; trate el camino de fallo como un caso de primera clase.
4. Editor de texto en tiempo real con resolución de conflictos — pensamiento básico de OT o CRDT. Pista: elija CRDT; explique por qué es amigable con la consistencia eventual.
5. Filtre y ordene una lista grande de items en React — consideraciones de rendimiento, memoización, virtualización. Pista: discuta tradeoffs, no solo la implementación.
6. Implemente el manejo de atajos de teclado — secuencias multi-tecla, resolución de conflictos entre contextos. Pista: Linear es keyboard-first; esta ronda es real.
7. Diseñe y programe un pequeño cliente de API con retry, deduplicación y caché. Pista: piense en la experiencia de desarrollador de usar el cliente.
8. Construya un pequeño parser o renderer de Markdown. Pista: acote el alcance con firmeza; entregue código limpio con tests explícitos.
9. Implemente undo/redo para una UI con estado. Pista: command pattern, snapshots u operation log — elija uno y articule por qué.
10. Refactorice un componente React complejo que le entrega el entrevistador. Pista: explique cada cambio como un tradeoff, no como una mera preferencia.

Top 5 de temas de diseño de sistemas

1. Sync engine local-first — la tecnología central de Linear. CRDTs, soporte offline, resolución de conflictos, autoridad del lado servidor.
2. Sistema de colaboración en tiempo real — presencia, cursores, actualizaciones optimistas, fan-out del servidor.
3. Routing de notificaciones — preferencias, debounce, batching, entrega async vía email/push/in-app.
4. Permisos y control de acceso — granularidad de workspace/team/project, herencia de roles, enforcement en tiempo de query.
5. Diseño de API y webhooks — tradeoffs GraphQL vs REST, rate limiting, garantías de entrega de webhooks.

Para el sync engine de Linear en concreto: lea sus entradas publicadas de blog de ingeniería antes del proceso. Han escrito públicamente sobre arquitectura local-first y CRDTs. Presentarse habiendo leído los materiales cala bien; presentarse sin haberlos leído es una señal de alarma silenciosa para roles senior+.

Top 5 de preguntas conductuales

1. ¿Qué te encanta y qué detestas de Linear como producto? Sea específico — saque a la luz cosas que cambiaría y cosas que admira.
2. Cuénteme un producto que haya usado recientemente y que le pareciera especialmente bien diseñado. Articule por qué — las preguntas de gusto son señal real en Linear.
3. Describa un proyecto en el que tuvo que escribir su camino hacia una decisión, en lugar de reunirse hacia ella. Cultura de escritura async.
4. Explíqueme cómo estructuraría una semana sin standups ni reuniones de status. La priorización autónoma es lo que se pone a prueba.
5. Cuénteme una vez en que plantó cara a una petición de feature que venía de un cliente. El pensamiento product-first importa más que complacer al cliente.

Consejos específicos de la cultura de Linear

Linear entrega opiniones de producto a través del código. Se espera que los ingenieros se preocupen por el pulido visual, los detalles de interacción y el copy. En cada ronda, busque formas naturales de sacar a la luz el pensamiento de producto. "Lo implementaría con una transición de 200ms porque lo instantáneo se siente brusco para un cambio de este tamaño" cala mucho más alto que "añadiría una transición". Las señales de gusto específicas son escasas y muy valoradas.

La escritura async es una habilidad central, no un extra deseable. La cultura de Linear empuja las decisiones a través de documentos escritos en lugar de reuniones. El take-home o work trial producirá artefactos escritos (design docs, comentarios de código, descripciones de PR) que se evalúan con tanto cuidado como el código. La escritura clara puntúa tan alto como el código limpio.

Un equipo pequeño significa señal alta. En Linear no existe el camino de "aterriza en algún sitio de la organización y ya verás el equipo". El hiring manager será su manager. El fundador puede ser su skip-level. Cada interacción es una evaluación real de encaje. Sea la persona con la que querría trabajar un lunes — específica, calmada, opinionada pero no dogmática, y capaz de admitir "no lo sé" sin pestañear.

Preguntas frecuentes