HTML y CSS son difíciles de entrevistar por varias razones:
Son demasiado básicos, comparados, por ejemplo, con un lenguaje de programación,
Dependen mucho del contexto del trabajo. Ejemplos:
Si crea una escala de Google, sitios web enormemente rápidos y optimizados, las personas que entrevista para el trabajo no pueden ignorar qué son los sprites CSS.
Si crea sitios web válidos XHTML W3C, debe asegurarse de que los candidatos sepan la diferencia entre XHTML 1.0 y XHTML 1.1, o cuáles son los atributos obligatorios <img/>, etc.
Si crea sitios web terribles llenos de hacks, debe preguntar a las personas que entreviste cómo harán tal o cual hack, cómo sirven CSS diferentes para diferentes navegadores, etc.
etc.
Si es un trabajo puro de HTML y CSS, la persona tendrá que trabajar con diseñadores por un lado y desarrolladores por otro lado. Deben saber HTML y CSS, pero lo que es mucho más valioso es su capacidad para interactuar con esas personas y comprender las necesidades de los diseñadores, los requisitos de los desarrolladores y las limitaciones de HTML y CSS.
Por ejemplo, deben saber cómo estructurar su HTML de tal manera que sea fácil para un desarrollador de JavaScript agregar interactividad más adelante.
Es posible que desee comenzar con algunas preguntas básicas:
¿Cuál es tu navegador favorito?
Si la persona responde "Internet Explorer", detenga la entrevista de inmediato: no necesita a alguien así.
No estoy bromeando. La respuesta es irrelevante. En cambio, puede preguntar lo siguiente:
Cuéntame sobre las herramientas de depuración que utilizas en tu navegador favorito.
Principal usando Chrome, trabajo a diario con las Herramientas para desarrolladores Esas herramientas me permiten:
Ver las solicitudes realizadas desde una página,
Estudie el tiempo que lleva cargar una página y los recursos relacionados, especialmente los tiempos de búsqueda, espera y recepción de DNS,
Estudie los encabezados de los elementos enviados, así como el indicador de caché,
Ver el DOM y estudiar cómo se aplican los selectores CSS,
También uso YSlow, que me sirve como una lista de verificación para la optimización de un sitio web que requiere una gran escalabilidad. YSlow también es una buena herramienta cuando se trata de determinar si el servidor está configurado correctamente (enviando encabezados correctos, etc.).
En Firefox, uso Firebug, la herramienta muy similar a las Herramientas para desarrolladores de Chrome. Las herramientas para desarrolladores también están disponibles en nuevas versiones de Internet Explorer, y también me permiten cambiar a las vistas de compatibilidad de IE7 a IE10. Esta última característica es muy útil, ya que sin ella, me vería obligado a instalar varias máquinas virtuales solo para pruebas heredadas, o para usar con mucha más frecuencia los servicios pagos como Litmus .
Por favor, explícame de qué <dl/>se trata la etiqueta. ¿Cuál fue el uso previsto para esta etiqueta? ¿Cómo se usa en la práctica? ¿Qué opinas sobre este uso extendido?
A continuación, desea que la persona sea capaz de explicar que <dl/>es para los diccionarios, que asocia una clave, <dt/>con uno o varios valores, <dd/>. Si bien el uso principal de esta etiqueta estaba puramente relacionado con la semántica, en la práctica se usó ampliamente para reemplazar tablas, un buen ejemplo es PHPBB3. Esto es algo bueno cuando las tablas retrasan el procesamiento de la página, pero debe usarse con precaución: no solo las tablas siguen siendo apropiadas en muchos casos para describir mejor los datos, sino que también puede haber otros medios, como el ordinario listas, para describir el contenido sin usar <dl/>.
¿Cuál es la diferencia entre diseños fijos y fluidos? ¿Cuáles son los pros y los contras de cada uno?
El diseño fijo tiene anchos predefinidos de los elementos. Los elementos de un diseño fluido dependen del ancho de la página.
El diseño fijo facilita el diseño de la página, especialmente cuando hay muchos gráficos de ancho completo. Incluso sin gráficos, es aún más fácil, porque solo te importa un caso preciso. Por ejemplo, Programmers.SE es un sitio web de diseño fijo, la columna que muestra las preguntas y las respuestas siempre tiene el mismo tamaño. Si se usara un diseño fluido para esta columna, esto crearía un problema: en pantallas pequeñas, el texto sería ilegible, porque las líneas serían demasiado cortas, mientras que en pantallas grandes, las líneas serían extremadamente grandes, por lo que el texto sería ilegible también.
El problema con el diseño fijo es que funciona bien para algunas de las resoluciones más utilizadas, pero falla más o menos para todo lo demás. Se vuelve especialmente importante desde la adopción de monitores muy grandes y anchos, y el uso cada vez mayor de Internet en dispositivos móviles pequeños.
El diseño fluido ayuda con eso, pero el diseño es más difícil de hacer para dicho sitio web. En algunos escenarios en proyectos mal administrados, esto puede conducir a hacks de HTML y CSS, páginas grandes, poca capacidad de mantenimiento y, durante el desarrollo, a mayores costos y plazos incumplidos.
En una página con un diseño fluido, ¿cómo puede evitar la situación en la que una columna de texto se vuelve demasiado grande para seguir siendo legible?
Puede limitar el ancho de una zona de texto mediante la max-widthpropiedad.
¿Qué opinas sobre este código <p color="Red" align="Center">Text here</p>:?
El fragmento de código tiene una falla para mezclar la lógica de presentación dentro de HTML. La lógica de presentación debe ponerse en CSS por varias razones:
- Ayuda a separar las preocupaciones y limpiar el código, lo que significa un mantenimiento más barato más adelante,
- Hace que los estilos sean reutilizables de una página a otra, lo que (fuera de las preocupaciones de mantenimiento) ayuda a garantizar que esté utilizando los mismos estilos en todo el sitio web,
- Ayuda a reducir el ancho de banda, ya que los archivos CSS se almacenarán en caché.
Después de algunas preguntas básicas como esa, puede hacer algunas más difíciles:
¿Cómo evita duplicar colores o fuentes en CSS, cuando esos colores o fuentes se aplican a múltiples elementos que no pueden ser seleccionados por un solo selector? ¿Hay inconvenientes?
Lo haces usando preprocesadores CSS, como Sass o LESS. Permiten definir colores, fuentes y otras partes del estilo dentro de variables que puede usar más adelante en sus estilos.
Los inconvenientes de los preprocesadores CSS son que:
A veces requieren cambiar el flujo de trabajo de desarrollo e implementación, para tener el código CSS actualizado en el navegador,
Solo unos pocos desarrolladores los conocen, lo que dificulta que una nueva persona se una o mantenga el proyecto más adelante,
No hay IDE buenos y rápidos para Sass o LESS, y la integración dentro de los IDE más populares es bastante decepcionante.
Dame un ejemplo del hrefvalor de una imagen que está en CDN, dado que esta imagen se muestra en un sitio web al que se puede acceder a través de HTTP y HTTPS.
Dado que HTTPS también necesita que todos los recursos llamados estén en HTTPS (de lo contrario, en muchos casos se mostrará una advertencia de seguridad al usuario), no es posible especificar el enlace como http://cdn.example.com/image.png. Para vincular correctamente a la imagen, se //cdn.example.com/image.pngdebe utilizar; el navegador se antepondrá http:o https:dependerá del contexto.
Dado que el tamaño de las páginas y el número de solicitudes en un sitio web no se pueden optimizar y el contenido no se puede cambiar ni se puede agregar AJAX, ¿cómo le da la impresión al usuario de que el sitio web es más rápido? ¿Qué implica desde la perspectiva HTML?
Si se utiliza HTTP 1.1, la página puede estar fragmentada . Esto significa que las primeras partes aparecerán más rápido, dando la impresión de que el sitio web es más rápido de lo que es en realidad. La codificación de transferencia fragmentada es imposible en HTTP 1.0, lo que significa que no hay nada que hacer en este caso.
Ser capaz de servir el contenido fragmentado requiere desde la perspectiva HTML reordenar los elementos, colocando los más críticos en la parte superior del archivo (lo que no significa que tendrían que aparecer en la parte superior de la página). Por ejemplo, en un sitio web de comercio electrónico, cuando el usuario desea ver los detalles del producto, el primer fragmento puede contener los <head/>detalles del producto. El siguiente fragmento puede contener los elementos principales, como el logotipo del sitio web, el menú principal, los derechos de autor, etc. Finalmente, el último fragmento puede contener la sección "Las personas que compraron esto también compraron", los comentarios y calificaciones del producto, el "Compartir en Facebook", etc.
Finalmente, puede pedirle al candidato que trabaje en un escenario del mundo real. Puede ser cualquier cosa, como la más fácil a continuación, en los escenarios complejos donde la persona tiene que lidiar con sprites CSS u otras técnicas avanzadas de optimización, con inconsistencias del navegador, etc.
Por favor, ¿puede crear una página XHTML con dos zonas: la izquierda, con una lista, y la derecha, con texto. Dos zonas están separadas por una línea vertical, que se extiende desde la parte superior hasta la parte inferior de la página. Lista y texto que varían en tamaño, no puede predecir cuál tendrá la mayor altura. No puedes usar <table/>s.
En realidad, es bastante simple, pero muestra si la persona tiene el reflejo de pensar en las alturas. Un candidato inexperto creará la float:leftzona y la border-left:solid 1px #ccc;zona, pero olvide agregar el borde a la zona izquierda y extenderlo para que dos bordes estén en el mismo lugar.
