Domina la chuleta de CSS para entrevistas con especificidad, box model, flexbox y grid. Responde con criterio y destaca en tu criba. Lee más.
La mayoría de los rechazos en entrevistas de CSS no son por falta de conocimientos. Candidatos que han pasado semanas repasando propiedades siguen tropezando cuando el entrevistador pregunta “¿por qué elegiste flexbox ahí?” o “¿qué pasaría si quitaras ese `overflow: hidden`?”. Ese es el problema real que esta chuleta de CSS para preparar entrevistas pretende resolver: no darte más propiedades para memorizar, sino la capa de razonamiento que convierte el recuerdo en respuestas.
CSS es fácil de aprender por fragmentos. Aprende flexbox en un tutorial, especificidad en una respuesta de Stack Overflow, el modelo de caja en un curso intensivo. El resultado es un mosaico que funciona razonablemente bien para construir cosas, pero se desmorona bajo la presión específica de una entrevista, donde la pregunta de seguimiento siempre va sobre la decisión, no sobre la definición. Las secciones siguientes están organizadas según cómo exploran los entrevistadores, no según cómo enseñan los libros de texto.
Empiece por los temas de CSS que primero compensan el esfuerzo
Organice el orden de repaso según lo que realmente evalúan los entrevistadores
La preparación de entrevistas de CSS suele fallar porque los candidatos estudian en orden de libro de texto — propiedades, luego selectores, luego diseño — en lugar de hacerlo en el orden que más suele aparecer en entrevistas. El orden de libro tiene sentido para construir modelos mentales desde cero. No lo tiene cuando le quedan tres días para una criba y necesita saber dónde caerán realmente las preguntas.
Según patrones observados en procesos de contratación frontend, los temas que aparecen con más frecuencia en cribas de frontend junior a intermedio se agrupan en cinco áreas: cómo llega CSS a la página (cascade, especificidad, herencia), el modelo de caja y sus modos de fallo, flexbox y grid con sus casos límite, el comportamiento responsive y, para perfiles intermedios, los conceptos avanzados que revelan si entiende por qué CSS se comporta como lo hace, no solo que lo hace. Float y clear siguen apareciendo, pero sobre todo como preguntas para situar el contexto, no como factores decisivos.
Cómo se traduce eso en la práctica
Una ruta de repaso de una sola sesión que refleje la prioridad de la entrevista sería así: empiece confirmando que puede explicar cómo se aplica CSS a la página y qué determina qué regla gana. Luego pase al modelo de caja y asegúrese de que puede describir un error de diseño causado por él. Después vaya a flexbox y grid juntos — no por separado — porque los entrevistadores casi siempre piden compararlos. A continuación, repase el comportamiento responsive y el CSS consciente de la accesibilidad. Deje BFC, stacking context y container queries para el final: esas son las preguntas que separan a quienes entienden el modelo mental de CSS de quienes solo lo han usado.
La documentación de CSS en MDN es la referencia más fiable para comprobar su comprensión de cada área antes de pasar a la siguiente. No la lea de principio a fin: úsela como capa de verificación después de haber intentado explicarse cada concepto en voz alta primero.
Explique cómo llega CSS a la página sin sonar como si hubiera memorizado un glosario
CSS en línea, interno y externo trata en realidad de alcance y control
La respuesta obvia a “¿cuál es la diferencia entre CSS en línea, interno y externo?” es: el CSS en línea va en el atributo `style`, el interno va en una etiqueta `<style>` dentro de `<head>`, y el externo vive en un archivo `.css`. Todo candidato da esa respuesta. Los entrevistadores lo saben. Lo que están escuchando después es si entiende por qué esas diferencias importan en un proyecto real.
La historia real trata de alcance, capacidad de sobrescritura y reutilización. El CSS en línea tiene la especificidad más alta de las tres opciones y reutilización cero: se aplica exactamente a un elemento, no se puede compartir y es el más difícil de sobrescribir de forma limpia sin recurrir a `!important`. El CSS interno está limitado a una página; es útil para sobrescrituras específicas de una página o para prototipado, pero crea un problema de mantenimiento en cuanto dos páginas necesitan la misma regla. El CSS externo es la opción por defecto en producción porque separa responsabilidades, permite caché y es la única solución que escala en una biblioteca de componentes o una aplicación de múltiples páginas.
Cómo se traduce eso en la práctica
Piense en tres escenarios: está construyendo un correo HTML en el que a menudo no se cargan hojas de estilo externas, así que el CSS en línea es la opción defendible porque no tiene una mejor. Está construyendo una landing page puntual que necesita una única sobrescritura de estilo que no se aplica en ningún otro lugar: ahí un bloque `<style>` en `<head>` está bien. Está manteniendo un sistema de diseño con componentes compartidos de botones, tarjetas y formularios: el CSS externo es la única elección sensata porque cualquier otra cosa le obligaría a actualizar la misma regla en varios sitios.
En la práctica, mover un estilo de inline a externo casi siempre ocurre porque alguien intentó sobrescribirlo y no pudo predecir qué regla ganaría. Eso es un problema de especificidad causado por un problema de alcance. La respuesta a las preguntas de entrevista sobre organización de hojas de estilo siempre vuelve a lo mismo: ¿qué está optimizando, la velocidad de escritura o la facilidad de mantenimiento?
Haga que la especificidad suene aburrida, en el mejor sentido posible
Quién gana cuando los selectores compiten
La especificidad es el algoritmo de resolución de conflictos de CSS. Cuando dos reglas apuntan al mismo elemento, el navegador necesita una forma de decidir cuál se aplica. La decisión se toma en un orden específico: los estilos en línea ganan frente a todo salvo `!important`. Después, los selectores de ID superan a los selectores de clase, a los selectores de atributo y a las pseudo-clases. Estos superan a los selectores de elemento y a los pseudo-elementos. Los selectores universales (`*`) y los combinadores no añaden peso de especificidad.
Los combinadores — descendiente (espacio), hijo (`>`), hermano adyacente (`+`), hermano general (`~`) — le dicen al navegador dónde buscar un elemento, pero no cambian la especificidad de los selectores que conectan. Una pseudo-clase como `:hover` o `:nth-child()` tiene el mismo peso que un selector de clase. Un pseudo-elemento como `::before` o `::after` tiene el mismo peso que un selector de elemento. El orden de la cascade — orden de origen, importancia, procedencia y especificidad — determina qué regla gana cuando todo lo demás es igual.
La especificación de CSS Cascade es la fuente autorizada aquí. Saber que existe y poder describir sus capas es en sí mismo una señal que los entrevistadores notan.
Cómo se traduce eso en la práctica
Imagine un componente de producción en el que un botón tiene un estilo base definido como `.btn { background: blue; }`. Más tarde, un desarrollador añade una regla más específica: `nav .btn { background: gray; }`. El botón dentro de la navegación pasa a gris, como era de esperar. Pero luego un tercer desarrollador añade `.btn--primary { background: green; }` esperando que sobrescriba la regla de `nav`, y no lo consigue, porque `.btn--primary` (una clase) pierde frente a `nav .btn` (un elemento más una clase). La solución no es añadir `!important`, sino entender qué cadena de selectores está ganando y, o bien igualar su especificidad, o bien reestructurar la jerarquía de selectores.
Por qué !important parece un atajo y normalmente lo es
Hay usos legítimos de `!important`: clases utilitarias en un sistema de diseño que están pensadas explícitamente para sobrescribir cualquier cosa (piense en el prefijo `!` de Tailwind), sobrescrituras de accesibilidad del navegador o reseteos de hojas de estilo de terceros que no puede controlar. En esos casos, `!important` es una decisión documentada con una razón clara.
La trampa de mantenimiento es usarlo para escapar de una lucha de especificidad que no entiende del todo. Cada `!important` que añade crea un suelo más alto para la siguiente sobrescritura. Una vez que tiene dos declaraciones `!important` apuntando a la misma propiedad, vuelve a la resolución por especificidad, pero ahora con una capa extra de confusión. La respuesta de entrevista que suele funcionar: “Usaría `!important` solo cuando quiera sobrescribir intencionadamente una regla externa o utilitaria que no puedo tocar, no para corregir un conflicto de especificidad que yo mismo creé.”
Use el modelo de caja para explicar por qué los diseños se rompen de formas molestas y familiares
El modelo de caja es donde las buenas intenciones se convierten en overflow
Todo elemento en CSS es una caja. Esa caja tiene cuatro zonas: contenido (lo que hay dentro), padding (espacio entre el contenido y el borde), border (el borde del elemento) y margin (espacio fuera del borde). La trampa de la entrevista no es explicar esas cuatro zonas, sino explicar qué pasa cuando añade padding o borde a un elemento con un ancho fijo y el diseño se rompe de una forma que parece inexplicable.
El comportamiento por defecto (`content-box`) significa que `width` establece solo el área de contenido. Añada `padding: 20px` a un elemento con `width: 200px` y el elemento renderizado medirá ahora 240px de ancho. Eso sorprende a quienes esperaban que el elemento siguiera midiendo 200px y que el padding viviera dentro de él. Este es el fallo del modelo de caja que aparece constantemente en rejillas de tarjetas, barras laterales y modales.
box sizing es la pequeña línea de CSS que ahorra muchos problemas
`box-sizing: border-box` cambia el modelo para que `width` incluya padding y border: el elemento sigue midiendo 200px de ancho, y el padding comprime el área de contenido en lugar de ampliar el elemento. La mayoría de los reseteos CSS modernos aplican `border-box` de forma global con:
A los entrevistadores les encanta preguntar esto junto con los modos de fallo por overflow porque revela si entiende por qué existe ese reset, no solo que lo ha visto en una plantilla inicial. La documentación del modelo de caja en MDN cubre ambos modelos con diagramas visuales que merece la pena repasar antes de su criba.
Cómo se traduce eso en la práctica
Un componente de tarjeta con `width: 100%` y `padding: 24px` desborda su contenedor en `content-box` porque el 100% de ancho más 48px de padding horizontal supera el ancho del contenedor. Cambie a `border-box` y la tarjeta se mantiene dentro de su contenedor porque el padding se absorbe dentro del 100% de ancho. El mismo patrón rompe sidebars y overlays de modal. La versión preparada para entrevista de esta respuesta nombra el modelo, explica el comportamiento por defecto, identifica el modo de fallo y nombra la solución: son cuatro frases que cubren todo lo que el entrevistador realmente quería saber.
Elija Flexbox o Grid como alguien que ha trabajado con ambos
Flexbox es para una línea, Grid es para un mapa
La forma más limpia de explicar la diferencia entre flexbox y grid: flexbox es unidimensional: gestiona una fila o una columna. Grid es bidimensional: gestiona filas y columnas simultáneamente. Esa única frase es un buen punto de partida para la respuesta de entrevista, pero no es toda la respuesta.
Flexbox es la herramienta adecuada cuando quiere que los elementos fluyan y distribuyan espacio a lo largo de un solo eje: una barra de navegación, una fila de botones, una lista horizontal de etiquetas. Grid es la herramienta adecuada cuando importa la relación entre filas y columnas: una rejilla de tarjetas de producto, un diseño de panel de control, una plantilla de página donde cabeceras, barras laterales y áreas de contenido deben alinearse en ambos ejes a la vez.
Los casos de fallo que la gente olvida mencionar
El caso de fallo de flexbox que muchos candidatos omiten: los elementos flex tienen por defecto un `min-width` de `auto`, lo que significa que un hijo flex que contenga texto largo o una imagen ancha no se reducirá por debajo del tamaño de su contenido. La solución es `min-width: 0` en el hijo flex. Sin eso, una fila de tarjetas que debería ajustarse o reducirse desbordará el contenedor. Este es el tipo de modo de fallo específico que separa a un candidato que ha implementado diseños con flexbox de otro que solo ha leído sobre ellos.
Las sorpresas de tamaño en grid vienen de `auto-fill` frente a `auto-fit`. Ambos crean tantas columnas como quepan en el contenedor, pero `auto-fit` colapsa las pistas vacías para que los elementos se expandan y llenen la fila. `auto-fill` conserva las pistas vacías, lo que significa que los elementos no se expanden. En una rejilla de tarjetas de producto en la que quiere que tres tarjetas llenen toda la fila en lugar de agruparse a la izquierda, normalmente querrá `auto-fit`. Los entrevistadores preguntan por esta distinción porque es el tipo de detalle que solo queda claro cuando un diseño se comporta de forma inesperada en producción.
Cómo se traduce eso en la práctica
Una fila de tarjetas de producto es trabajo de flexbox hasta que necesita que las tarjetas se alineen entre filas; entonces pasa a ser trabajo de grid. Un panel de control con cabecera, navegación izquierda, área de contenido principal y pie de página es trabajo de grid desde el principio porque la relación entre esas áreas es intrínsecamente bidimensional. La respuesta de entrevista para “¿cuándo usaría una u otra?” debe terminar con un ejemplo concreto, no con un principio general. Diga qué ha construido y cuál eligió.
La Guía completa de Flexbox de CSS-Tricks y su equivalente para Grid siguen siendo las referencias rápidas más fiables para las propiedades y su comportamiento.
Sepa por qué float y clear siguen apareciendo en entrevistas aunque perdieran la guerra
Los floats son una lección de historia con propósito
Float se diseñó para permitir que el texto rodeara imágenes, el mismo comportamiento que ve en maquetaciones impresas donde una fotografía se sitúa dentro de una columna de texto. Nunca se diseñó como herramienta de diseño. La comunidad frontend lo utilizó así durante aproximadamente una década porque no había nada mejor, y el resultado era funcional pero frágil. Limpiar floats — ya sea con `clear: both` en un elemento posterior o con el truco del clearfix — era la solución provisional al hecho de que los elementos flotados se sacan del flujo normal del documento y sus contenedores padres colapsan a su alrededor.
Flexbox y grid reemplazaron por completo los diseños basados en float en los proyectos nuevos. La razón por la que float sigue apareciendo en preguntas de entrevista CSS frontend es que los entrevistadores quieren saber si entiende por qué ocurrió el cambio, no solo que ocurrió. Entender los floats significa entender el flujo normal, lo que a su vez significa entender cómo se apartan de él las herramientas modernas de diseño.
Cómo se traduce eso en la práctica
El ejemplo clásico es una imagen flotada a la izquierda con texto envolviéndola a la derecha. Añada `float: left` a la imagen, y el texto fluye a su lado. Añada `clear: left` a un pie de página debajo, y el pie de página cae por debajo del float en lugar de seguir a su lado. En una base de código moderna, probablemente usaría en su lugar un contenedor grid o flex. La respuesta de entrevista que funciona: describa con precisión cómo funcionan float y clear, y luego diga que en un proyecto nuevo usaría flexbox o grid y explique por qué: el comportamiento del overflow es más predecible, la alineación es más controlable y no necesita trucos de clearfix para evitar que los contenedores padres colapsen.
Demuestre que está al día en CSS de nivel intermedio sin fingir que todas las funciones avanzadas forman parte de su día a día
BFC, stacking context y container queries son lo que expone el entendimiento real
Un Block Formatting Context (BFC) es un entorno de renderizado aislado dentro del modelo de diseño CSS. Los elementos dentro de un BFC no interactúan con los floats externos y el BFC contiene sus propios floats. Activar un BFC — con `overflow: hidden`, `display: flow-root` o `contain: layout` — es la forma limpia de evitar el colapso por floats sin trucos clearfix. Los entrevistadores preguntan por BFC porque revela si entiende por qué `overflow: hidden` soluciona el colapso de floats, no solo que lo hace.
El stacking context es el mecanismo que controla la superposición mediante z-index. Se crea un nuevo stacking context con elementos que tienen `position` más un valor de `z-index` distinto de `auto`, `opacity` menor que 1, `transform`, `filter` y varias propiedades más. El fallo habitual: un modal o un tooltip tiene `z-index: 9999` pero aun así queda oculto detrás de otro elemento porque su padre creó un nuevo stacking context con un z-index más bajo. La solución requiere entender la jerarquía de stacking context, no solo subir el z-index.
Las container queries — ahora ampliamente compatibles — permiten que un componente responda al tamaño de su contenedor en lugar del viewport. Esto cambia el diseño responsive de una preocupación a nivel de página a una preocupación a nivel de componente. Un componente de tarjeta puede refluír su diseño interno cuando su contenedor es estrecho, independientemente de lo que esté haciendo el viewport.
Las propiedades lógicas y las media queries responsive deberían sonar prácticas, no modernas por moda
Las propiedades lógicas (`margin-inline-start` en lugar de `margin-left`, `padding-block-end` en lugar de `padding-bottom`) se adaptan a la dirección de escritura del documento en lugar de a direcciones físicas. En un diseño de izquierda a derecha se comportan igual que las propiedades físicas. En un diseño de derecha a izquierda — árabe, hebreo, persa — cambian automáticamente. Usar propiedades lógicas es la decisión de CSS que hace que la internacionalización no sea una idea tardía.
`prefers-reduced-motion` le permite desactivar o reducir animaciones para usuarios que han configurado esa preferencia a nivel de sistema operativo. `prefers-color-scheme` le permite responder al modo oscuro del sistema. Esto no son casos extremos de accesibilidad: son las decisiones de CSS que hacen que un producto se sienta cuidado y no improvisado.
Cómo se traduce eso en la práctica
Un fallo de z-index en el que un desplegable queda oculto detrás de una tarjeta casi siempre es un problema de stacking context. La tarjeta tiene `transform: translateZ(0)` para una optimización de composición GPU, lo que crea un nuevo stacking context, y el desplegable — hijo de esa tarjeta — no puede salir de él por mucho valor de z-index que tenga. La solución es reestructurar el DOM para que el desplegable sea un hermano del stacking context, no un hijo. Ese es el tipo de historia de depuración que hace que una respuesta CSS de nivel intermedio suene vivida.
Responda a las preguntas de responsive y accesibilidad como alguien que sigue pensando en cómo se sienten los usuarios
CSS responsive no es solo breakpoints y buenas intenciones
CSS responsive trata de la resiliencia del diseño: asegurarse de que el contenido se refluye con fluidez cuando cambia el contenedor, no solo cuando el viewport cruza un breakpoint predefinido. El modelo mental centrado en breakpoints se rompe cuando un componente se usa en varios contextos con distintos anchos. Las container queries lo resuelven a nivel de componente. La tipografía fluida con `clamp()` lo resuelve a nivel de texto. La respuesta de entrevista que funciona trata el comportamiento responsive como una propiedad continua del diseño, no como un conjunto de sentencias condicionales.
La accesibilidad aparece en CSS más de lo que mucha gente admite
Las relaciones de contraste, la visibilidad del foco, la reducción de movimiento y el tratamiento del esquema de color son decisiones de CSS. WCAG 2.1 exige una relación de contraste mínima de 4.5:1 para texto normal. Los indicadores de foco — `:focus-visible` en lugar de `:focus` — deben ser visibles sin recargar la interfaz para usuarios de ratón. Quitar `outline: none` sin proporcionar un estilo alternativo de foco es uno de los fallos de accesibilidad más comunes en CSS de producción. `prefers-reduced-motion` debería envolver cualquier animación que no sea esencial para entender la interfaz.
Cómo se traduce eso en la práctica
Un componente de navegación que se contrae en un menú hamburguesa en un breakpoint necesita gestionar el foco, el contraste tanto en modo claro como en modo oscuro, y el movimiento en la transición de apertura y cierre. El CSS de esa transición debería envolverse en un bloque `@media (prefers-reduced-motion: no-preference)` para que los usuarios que hayan pedido movimiento reducido obtengan un cambio de estado instantáneo en lugar de una animación. Ese es el tipo de respuesta que señala a un candidato que piensa en las personas, no solo en los navegadores.
Preguntas frecuentes
P: ¿Qué temas de CSS es más probable que aparezcan en una entrevista frontend y en qué orden debería repasarlos?
Empiece por cascade, especificidad y herencia: sustentan todas las demás preguntas de CSS. Después pase al modelo de caja y `box-sizing`, flexbox y grid juntos, el comportamiento responsive y las media queries, y por último temas avanzados como BFC, stacking context y container queries para perfiles intermedios. Ese orden refleja la frecuencia en entrevistas y construye cada concepto sobre el anterior.
P: ¿Cómo explico con claridad la diferencia entre CSS en línea, interno y externo en una entrevista?
Dé primero la respuesta mecánica en una frase (dónde vive cada tipo) y, acto seguido, pivote al intercambio: el CSS en línea tiene la mayor especificidad pero reutilización cero; el interno está limitado a una página y es útil para prototipos; el externo es el estándar en producción porque separa responsabilidades y escala. Los entrevistadores escuchan el intercambio, no la definición.
P: ¿Cuándo uso Flexbox frente a Grid y qué casos de fallo comunes debería mencionar?
Use flexbox para un flujo unidimensional: una barra de navegación, una fila de etiquetas, una columna de campos de formulario. Use grid cuando filas y columnas deban alinearse simultáneamente: rejillas de tarjetas, paneles de control, plantillas de página. Los casos de fallo que merece la pena mencionar: los elementos flex no se reducen por debajo de `min-width: auto` sin `min-width: 0`, y `auto-fill` frente a `auto-fit` producen comportamientos distintos en rejillas con poco contenido.
P: ¿Cómo afectan realmente selectores, combinadores, pseudo-clases y especificidad a qué estilo gana?
La especificidad se calcula por capas: los estilos en línea superan a los selectores de ID, que superan a los selectores de clase y a las pseudo-clases, que superan a los selectores de elemento y a los pseudo-elementos. Los combinadores no añaden peso: solo acotan el objetivo. Cuando la especificidad es igual, decide el orden de origen. La respuesta práctica: siga la cadena de selectores de la regla ganadora antes de recurrir a `!important`.
P: ¿Cuáles son los problemas del modelo de caja y de `box-sizing` que suelen probar en entrevistas?
El principal problema es que en `content-box` (el valor por defecto), el padding y el borde amplían el elemento más allá de su ancho establecido. `box-sizing: border-box` incluye padding y borde dentro del ancho, haciendo que el tamaño sea predecible. Los entrevistadores lo prueban porque explica toda una categoría de desbordamientos de diseño que parecen misteriosos hasta que entiende el modelo.
P: ¿Cómo funcionan float y clear, y por qué se han reemplazado en gran medida en los diseños modernos?
Float saca un elemento del flujo normal y permite que el contenido adyacente lo rodee. `clear` evita que elementos posteriores se sitúen junto a un float. Se usaban para diseños de varias columnas antes de que existieran flexbox y grid. Hoy están en gran medida reemplazados porque los diseños flotados requerían trucos de clearfix para evitar el colapso del contenedor, y flexbox/grid gestionan la alineación y la distribución de forma más predecible.
P: ¿Qué temas avanzados de CSS debería conocer para entrevistas de nivel intermedio, como BFC, container queries y propiedades lógicas?
Conozca BFC lo suficiente como para explicar por qué `overflow: hidden` contiene floats (activa un nuevo contexto de formato). Conozca stacking context lo suficiente como para depurar un fallo de z-index causado por el `transform` o la `opacity` de un padre. Conozca container queries como la alternativa a nivel de componente frente a las media queries basadas en el viewport. Las propiedades lógicas merecen ser mencionadas en cualquier conversación sobre internacionalización o compatibilidad con RTL.
P: ¿Qué conceptos de CSS sobre accesibilidad y diseño responsive debería mencionar para sonar actual y práctico?
Mencione `prefers-reduced-motion` para animaciones, `prefers-color-scheme` para modo oscuro, `:focus-visible` para navegación por teclado y las relaciones de contraste WCAG para texto. En diseño responsive, mencione `clamp()` para tipografía fluida y container queries para responsividad a nivel de componente. No hace falta que sean el centro de su respuesta: mencionarlos sin que se lo pidan demuestra que piensa en las personas, no solo en los navegadores.
Cómo puede ayudarle Verve AI a prepararse para su entrevista de CSS
El problema estructural de preparar entrevistas de CSS no es no conocer el material: es que explicar una decisión de diseño bajo presión en vivo es una habilidad distinta de construir ese diseño usted mismo. Puede saber exactamente cuándo usar grid en lugar de flexbox y aun así dar una respuesta divagante cuando el entrevistador pregunta “¿por qué no flexbox aquí?” porque nunca ha tenido que articular el razonamiento en voz alta y en tiempo real.
Verve AI Interview Copilot está diseñado precisamente para esa brecha. Escucha en tiempo real la conversación mientras ocurre y responde a lo que usted dice de verdad, no a una consigna prefabricada. Así que, cuando practica una explicación de especificidad y la pregunta de seguimiento es “¿qué haría si `!important` ya estuviera en la base de código?”, Verve AI Interview Copilot muestra la siguiente capa de la respuesta según lo que acaba de decir, no una plantilla genérica. Las sesiones de práctica reflejan la presión real de una criba en vivo: una pregunta, su respuesta, un seguimiento que pone a prueba los límites. Verve AI Interview Copilot permanece invisible mientras hace esto, de modo que la experiencia es indistinguible de una entrevista real. En concreto para la preparación de CSS, eso significa que puede ensayar el modelo de caja, el overflow en flex y las explicaciones de stacking context hasta que suenen a decisiones, no a definiciones, que es exactamente lo que escuchan los entrevistadores.
Conclusión
Las buenas respuestas de entrevista de CSS son decisiones, no definiciones. Quienes superan las pruebas técnicas no son los que pueden recitar cada propiedad, sino quienes pueden decir “elegí flexbox porque el diseño era unidimensional y necesitaba que los elementos distribuyeran el espacio a lo largo de un solo eje, y esto es lo que vigilaría si empezara a desbordarse”. Eso es una decisión. Tiene una razón, un modo de fallo y una alternativa.
Antes de su próxima criba, vuelva en especial a tres secciones: la de especificidad (porque toda pregunta de CSS acaba siendo una pregunta de especificidad), la de flexbox y grid (porque la comparación casi seguro aparecerá) y la de responsive y accesibilidad (porque mencionar `prefers-reduced-motion` o `:focus-visible` sin que se lo pidan es la señal que separa a candidatos intermedios de candidatos junior). El resto de esta guía es repaso. Esas tres secciones son palanca.
Cameron Wu
Contenido