¿Cómo puedo evaluar el conocimiento de un candidato sobre HTML / CSS durante una entrevista? [cerrado]

Estoy tratando de determinar algunas buenas preguntas de entrevista para evaluar la capacidad de las personas que vienen para un trabajo de HTML / CSS, sin embargo, ese tema es extremadamente amplio, y no estoy seguro de qué tipo de preguntas puedo hacer para evaluar adecuadamente el HTML / Conocimiento de CSS.

¿Qué tipo de preguntas puedo hacer para evaluar las habilidades Html / CSS de un candidato durante una entrevista?

Idealmente me gustaría hacer algunas preguntas y luego darles un escenario de la vida real para combatir.

HTML y CSS son difíciles de entrevistar por varias razones:

1. Son demasiado básicos, comparados, por ejemplo, con un lenguaje de programación,

2. 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.

3. 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.

Aquí hay algunas preguntas que haría sobre CSS:

1. Modelo de caja CSS. Márgenes, relleno, etc. Modelo IE versus modelo W3C. ¿Cómo se puede cambiar entre los dos? ¿Cuáles son sus beneficios y desventajas?
2. Posicionamiento CSS. ¿Qué significa que un elemento esté "en el flujo" y "fuera del flujo"
3. inline-blocky otros valores de visualización. Diferencia entre display: none;y visibility: hidden; (esta es una pregunta buena y fácil para las personas nuevas en CSS)
4. inline-blockvs floatpara diseños.
5. Selectores
6. CSS se restablece. ¿Por qué son necesarios y qué logran?
7. Consultas de medios y diseño receptivo.
8. Cómo organizar estilos y cómo mantener pequeño el número de selectores. MENOS, Sass y otros preprocesadores CSS. CSS orientado a objetos.

Y algunas preguntas sobre HTML:

1. Doctype y modos de navegador.
2. ¿Por qué algunas etiquetas son más preferibles que otras (en emcomparación con, ipor ejemplo)?
3. ¿Cuáles son los principios básicos que se deben seguir para mantener HTML y CSS manejables y fáciles de mantener?

En general, pongo más énfasis en CSS, ya que es el área que a muchas personas les resulta difícil de entender y usar de manera efectiva. Me encuentro con muchos candidatos que ponen "CSS" en sus CV pero no pueden responder ninguna pregunta al respecto. La mayoría de la gente simplemente dice "No, no, sé que CSS es lo suficientemente bueno como para lidiar con él, pero no lo suficiente como para hablar de ello".

A veces es una buena idea dar una tarea simple y completar al entrevistado. Digamos, diseñe una página simple con diseño y estilo de bloque que admita múltiples tamaños de pantalla y se ajuste en consecuencia. Debería tomar aproximadamente una hora o dos y el candidato debería explicar lo que está haciendo y por qué.

¡Buena suerte con las entrevistas!

Si realiza una entrevista en vivo, la mejor manera es pedirle al desarrollador que escriba un código html / css.

Ejemplo (muy común en desarrollo real). Solicite al desarrollador que escriba el código html / css de la página con:

1. Ancho de fluido.
2. Encabezado con altura 100px;
3. Botón de inicio de sesión en la esquina derecha del encabezado
4. Paneles del lado izquierdo y derecho con 100px de ancho y 200px de altura;
5. Panel central para el texto del artículo.
6. Pie de página, que siempre estará en la parte inferior. Incluso si el artículo tiene 1 fila.

UPD: de cource, solicite al desarrollador que escriba el código utilizando solo divs (sin tablas).

Debería verse así:

Pero antes de la entrevista en vivo, le sugiero que evalúe a los candidatos en línea. Debido a que es más fácil evaluar a los candidatos en línea e invitar a la entrevista solo a desarrolladores calificados, que gastar su tiempo en cada candidato.

Me senté en algunas entrevistas con diseñadores web, y lo que hicimos fue imprimir un diseño de Blog muy simple en papel, y luego le pedí al candidato que simplemente escribiera algo de HTML y / o CSS en la página durante más o menos 10 minutos, para dar una idea básica de cómo lo codificarían. Esto nos permite saber si alguien REALMENTE sabía CSS o no. Solo buscábamos cosas básicas como flotadores frente a tablas, o lo que sea, y explicamos que no tenía que ser perfecto de ninguna manera.

Toneladas de personas reclamaron años de experiencia con CSS, pero cuando se les presionó para que lo escribieran, estaban escribiendo en conjeturas salvajes como " layout: floating; direction: up;" u otras tonterías. Más de 1 "CSS Ninja" ni siquiera tenía la sintaxis correcta, a la " div(margin=5)". Eso fue muy revelador para mí, ver cuántas personas simplemente mienten directamente en las entrevistas. Y es aparentemente más fácil mentir sobre CSS que sobre la codificación directa. No puede saber nada sobre CSS, pero busque en Google y sea capaz de lanzar la terminología adecuada con bastante rapidez. Realmente no puede hacerlo efectivamente con conceptos de nivel superior como OOP, por ejemplo.

Hay una prueba en línea en la que debe enumerar las etiquetas HTML o las propiedades CSS en 5 minutos.

Aunque esta no es una prueba de prueba completa, puede hacerle saber si el candidato está suficientemente familiarizado con HTML / CSS.

Sobre la pregunta, puede hacer una prueba con un código de muestra y pedirle que detecte errores de sintaxis / estructura.

En cuanto al escenario de la vida real, todo depende de en qué trabajará el candidato en su empresa. Si solo desea un desarrollador front-end, puede solicitar un diseño de sitio web sobre un tema aleatorio.

Un tipo de prueba que es aplicable a los lenguajes de programación y los lenguajes de marcado es una revisión de código. Cree una pequeña muestra (20 o 30 líneas) con una mezcla de errores de sintaxis, errores lógicos, casos de esquina, posiblemente un mal estilo ... Luego, pídale al candidato que identifique cualquier cosa que los considere sospechosa.

Es importante usar este tipo de prueba correctamente: como con cualquier pregunta de entrevista, la forma en que el candidato aborda la tarea es importante, y no solo los resultados.

No voy a publicar mi prueba, pero algunos consejos sobre cómo aplicar esto a CSS:

• Errores de sintaxis: faltan algunos puntos y comas. Como beneficio adicional, puede perderse algunos opcionales (estilo discutible) y ver si el candidato comenta.
• Errores de lógica: coloque una propiedad prefijada después de la no prefijada. Esto también prueba la familiaridad con CSS3 y puede provocar una discusión sobre la forma en que se desarrolla el estándar.
• Casos de esquina: por ejemplo, un margen con 3 valores: se sorprendería de cuántas personas no saben que es posible. Si el candidato no hace comentarios, puede preguntar cómo se interpreta para verificar que lo ignoraron por conocimiento y no por ignorancia.
• Otro caso de esquina: ejercita tus dos o tres errores IE7 favoritos. Esto distinguirá a aquellos con cicatrices de batalla (que deberían detectar al menos una de ellas) de los inexpertos o solo del Webkit.
• Estilo: especificidad excesiva, falta emy pxetc. Alguien que estudió la sintaxis para la entrevista probablemente no captará muchos de estos.

Por experiencia personal, trabajando con otros desarrolladores, creo que las preguntas sobre HTML y CSS no separarán a las personas que saben de lo que están hablando de las que saben lo que realmente están haciendo.

Recomiendo un simulacro de prueba / prototipo basado en la experiencia realista de las necesidades de su empresa.