¿Qué evalúan realmente las entrevistas para frontend?

Con quién hablarás realmente

Una ronda de entrevistas para ingeniero frontend suele consistir en tres o cuatro conversaciones distintas, cada una evaluando algo diferente. Primero, un filtro con reclutamiento, principalmente logística y rango salarial. Luego una llamada con el hiring manager, que realmente verifica si puedes describir tu propio trabajo con claridad: qué construiste, de qué fuiste responsable, qué cambiarías. Después una o dos rondas técnicas, normalmente con un ingeniero del equipo al que te unirías, a veces dos ingenieros en la misma llamada para que uno observe mientras el otro conduce. Para roles senior suele haber una conversación separada de arquitectura o diseño de sistemas, a veces con un staff engineer o tech lead que no será tu manager. Si hay un ejercicio para llevar a casa, su revisión es una ronda distinta en sí misma: alguien lee tu código antes de hablar contigo, y la conversación posterior se construye enteramente alrededor de tus decisiones, no del hecho de que funcionó.

Quien conduce la ronda técnica casi nunca es de recursos humanos. Eso importa, porque las preguntas dejan de ser sobre tu CV y comienzan a ser sobre si tus explicaciones aguantan cuando alguien que hace el trabajo las cuestiona.

El filtro técnico: qué está verificando

La mayoría de los filtros técnicos para este rol se realizan en editores compartidos —CoderPad, CodeSandbox, una sesión de VS Code Live Share— y cubren una mezcla de JavaScript vanilla y trabajo específico de frameworks. Un patrón común: primero un pequeño ejercicio de JS vanilla (escribir un debounce, aplanar un array anidado, implementar un event emitter simple), luego una tarea de componente en lo que el equipo realmente usa: React, Vue, Svelte. La parte vanilla existe precisamente porque los frameworks ocultan los fundamentos. Un entrevistador que te pide escribir debounce a mano no está probando si puedes escribirlo de memoria; está verificando si entiendes closures y el event loop lo suficientemente bien como para razonar por qué debounce los necesita, lo cual se revela en el momento en que preguntan "¿qué pasa si el usuario desmonta el componente mientras el temporizador aún está pendiente?"

En el lado del framework, una tarea típica es: construir una pequeña pieza de UI con estado, una llamada a API, estados de carga y error, y quizás una lista con keys. Lo que se evalúa rara vez es si renderiza. Es si manejas las partes aburridas: race conditions si la llamada a la API se resuelve fuera de orden, qué pasa con una lista vacía, por qué pusiste la key en el item de la lista y no en el índice. Un candidato que obtiene un componente funcional pero no puede explicar por qué usó key={item.id} en lugar de key={index} ha producido resultado sin comprensión, y esa brecha es exactamente lo que esta ronda existe para encontrar.

CSS y layout: la parte que la gente menos prepara

Las entrevistas frontend todavía evalúan CSS directamente, a menudo separado de JavaScript, porque es la parte que los candidatos más frecuentemente simulan con clases de utilidad de un framework. Espera que te pidan maquetar algo con Flexbox o Grid en vivo, en una pizarra o en un editor compartido, a veces sin framework y sin preprocesador. La pregunta real detrás de "cómo centrarías esto" nunca es el centrado: es si entiendes el box model, los stacking contexts y la especificidad lo suficientemente bien como para arreglar un bug de layout que nunca has visto antes, en una página que no escribiste, bajo un poco de presión de tiempo. "¿Por qué usarías Grid aquí en lugar de Flexbox?" es una pregunta de criterio. Hay un razonamiento real y defendible: Grid para layout bidimensional, Flexbox para un eje con dimensionamiento dirigido por contenido. Un entrevistador que trabaja en esto a diario notará inmediatamente si estás repitiendo una regla que leíste en lugar de una que realmente has aplicado.

Las preguntas que suenan a conversación pero no lo son

Algunas preguntas se repiten en las rondas frontend precisamente porque son difíciles de responder bien sin experiencia real, por muy fluidas que suenen como charla:

• "Explícame qué sucede desde que escribes una URL hasta que la página aparece en pantalla." Esto verifica si entiendes DNS, el ciclo request/response, parsing, el critical rendering path, y dónde encajan cosas como scripts que bloquean renderizado o defer/async. Una respuesta superficial se detiene en "el navegador obtiene el HTML y lo renderiza". Una respuesta real menciona la diferencia entre parsing y renderizado, por qué CSS bloquea el renderizado y JS puede bloquear el parsing, y dónde encaja la hidratación si la app es server-rendered.
• "Cuéntame sobre un memory leak que hayas depurado." Esta filtra rápido. Quienes realmente lo han hecho nombran la herramienta —la pestaña Memory de Chrome DevTools, un heap snapshot, nodos DOM desconectados, un event listener nunca removido al desmontar— y describen una corrección específica. Quienes no, dicen "verificaría memory leaks en el código" y no van más allá.
• "¿Por qué elegiste [Redux / Context / Zustand / lo que hayas usado] para el estado aquí?" El entrevistador ya sabe la respuesta a "qué hace Redux". Está preguntando si lo sopesaste contra alternativas para ese problema específico: ¿el estado se compartía entre muchos componentes distantes, necesitabas time-travel debugging, o lo elegiste por hábito? "Redux es bueno para estado global" repite un hecho que todos en la sala ya conocen.
• "¿Cómo harías esta lista navegable por teclado / cómo leería un lector de pantalla este componente?" Las preguntas de accesibilidad son una señal fuerte porque muy pocos candidatos han usado realmente un lector de pantalla o leído WCAG más allá de un resumen de blog. Nombrar roles ARIA que has memorizado sin explicar qué elemento HTML nativo los habría hecho innecesarios se lee como conocimiento superficial, no práctica.

Cómo suena una respuesta superficial desde dentro

Alguien que revisa candidatos frontend regularmente puede detectar una respuesta ensayada en una o dos frases. Tiende a tener tres características: nombra la herramienta sin describir el mecanismo ("React usa un virtual DOM para rendimiento" sin mención de reconciliación o cuándo el diffing realmente ayuda versus cuándo no), trata una pregunta de trade-offs como factual ("CSS-in-JS es mejor porque tiene scope", sin reconocimiento del costo en runtime o alternativas en build-time como vanilla-extract), y no puede sobrevivir una pregunta de seguimiento. Si dices "mejoré el tiempo de carga" y la siguiente pregunta honesta —"¿cuánto, y con qué lo mediste, Lighthouse u otra cosa?"— te vuelve impreciso, esa es la brecha que la entrevista fue diseñada para encontrar. Lo mismo aplica a conceptos básicos de seguridad: nombrar XSS y CSRF no es lo mismo que explicar por qué React escapa valores por defecto y dónde se detiene esa protección (dangerouslySetInnerHTML, scripts de terceros, innerHTML de una respuesta de API).

La parte discutida: algoritmos y ejercicios para llevar

Hay desacuerdo genuino dentro de la industria sobre si los ingenieros frontend deberían enfrentar rondas de algoritmos estilo LeetCode, dado que el trabajo es principalmente UI, estado y comportamiento del navegador en lugar de diseño de estructuras de datos. Algunas empresas las mantienen porque son fáciles de calificar consistentemente entre candidatos; otras las han eliminado en favor de pair programming en tareas realistas de UI, argumentando que la ronda de algoritmos mide práctica de entrevista más que habilidad laboral. Ninguna visión ha zanjado el argumento, y encontrarás ambos tipos de entrevistador, así que vale la pena preguntar al reclutador directamente qué contiene realmente la ronda técnica en lugar de adivinar. Los ejercicios para llevar tienen una división similar: algunos equipos los usan para respetar el tiempo de los candidatos respecto al live coding, otros los han abandonado porque ejercicios no pagados de varias horas filtran personas con menos tiempo libre en lugar de menos habilidad. Si te dan uno, la conversación posterior sobre él suele importar más que el ejercicio mismo: espera que te pregunten por qué estructuraste los componentes de esa manera, no solo si funciona.

Qué hacer a continuación

Lee el anuncio de trabajo otra vez y anota cada framework, herramienta y patrón que nombra: React versus Vue, TypeScript, una biblioteca de estado específica, SSR versus CSR, un design system. Los entrevistadores preguntan sobre lo que está en la página frente a ellos. Elige dos o tres de tus propios proyectos pasados y ensaya, en voz alta, los trade-offs específicos que hiciste en cada uno: no qué hizo el proyecto, sino por qué elegiste un enfoque sobre la alternativa que no tomaste. Practica explicar una sesión real de debugging en detalle, nombrando la herramienta que usaste. Si las preguntas de layout CSS te ponen nervioso, dedica una hora a construir un layout con Grid y Flexbox desde cero, sin framework, hasta que puedas explicar la elección sin consultar nada.

jobmarket.pro lee el anuncio por ti, lo coteja con tu historial real de proyectos y prepara la aplicación a partir de eso, de modo que lo que llega al entrevistador ya está alineado con lo que puedes defender cuando lo cuestionen.