HTML et CSS sont difficiles à interviewer pour plusieurs raisons:
Ils sont trop basiques, comparés, par exemple, à un langage de programmation,
Ils dépendent beaucoup du contexte du travail. Exemples:
Si vous créez des sites Web extrêmement rapides et optimisés sur Google, les personnes que vous interviewez pour le poste ne peuvent ignorer les sprites CSS.
Si vous créez des sites Web valides XHTML W3C, vous devez vous assurer que les candidats connaissent la différence entre XHTML 1.0 et XHTML 1.1, ou quels sont les attributs obligatoires <img/>
, etc.
Si vous créez des sites Web épouvantables remplis de hacks, vous devriez demander aux personnes que vous interviewez comment elles vont faire tel ou tel hack, comment elles servent différents CSS pour différents navigateurs, etc.
etc.
S'il s'agit d'un travail HTML et CSS pur, la personne devra travailler avec les concepteurs, d'une part, et les développeurs, d'autre part. Ils doivent connaître le HTML et le CSS, mais leur capacité à interagir avec ces personnes et à comprendre à la fois les besoins des concepteurs, les exigences des développeurs et les contraintes du HTML et du CSS a beaucoup plus de valeur .
Par exemple, ils doivent savoir comment structurer leur code HTML de manière à ce qu'un développeur JavaScript puisse facilement ajouter de l'interactivité ultérieurement.
Vous voudrez peut-être commencer par quelques questions de base:
Quel est ton navigateur préféré?
Si la personne répond "Internet Explorer", arrêtez l'interview immédiatement: vous n'avez pas besoin de quelqu'un comme ça.
Non, je plaisante. La réponse est hors de propos. Au lieu de cela, vous pouvez demander ce qui suit:
Parlez-moi des outils de débogage que vous utilisez dans votre navigateur préféré.
Principalement en utilisant Chrome, je travaille quotidiennement avec les outils de développement. Ces outils me permettent de:
Voir les demandes faites à partir d'une page,
Étudiez le temps nécessaire pour charger une page et les ressources associées, en particulier les temps de consultation, d'attente et de réception DNS,
Etudiez les en-têtes des éléments envoyés, ainsi que l'indicateur de cache,
Voir le DOM et étudier comment les sélecteurs CSS sont appliqués,
J'utilise également YSlow, qui me sert de liste de contrôle pour l'optimisation d'un site Web qui nécessite une évolutivité élevée. YSlow est également un bon outil pour déterminer si le serveur est configuré correctement (envoi d'en-têtes corrects, etc.).
Dans Firefox, j'utilise Firebug, l'outil très similaire aux outils de développement de Chrome. Les outils de développement sont également disponibles dans les nouvelles versions d'Internet Explorer et me permettent également de passer aux vues compatibles IE7 à IE10. Cette dernière fonctionnalité est très utile, car sans elle, je serais obligé d’installer plusieurs machines virtuelles uniquement pour des tests hérités, ou d’utiliser beaucoup plus souvent les services payants comme Litmus .
S'il vous plaît, expliquez-moi de quoi <dl/>
parle le tag? Quelle était l'utilisation prévue de cette balise? Comment est-il utilisé dans la pratique? Que pensez-vous de cette utilisation étendue?
Ici, vous voulez que la personne soit en mesure d'expliquer <dl/>
est pour les dictionnaires, associant une clé, <dt/>
avec une ou plusieurs valeurs, <dd/>
. Bien que l'utilisation principale de cette balise soit purement liée à la sémantique, elle a été largement utilisée pour remplacer des tableaux, un bon exemple étant PHPBB3. C’est une bonne chose lorsque les tableaux ralentissent le rendu de la page, mais vous devez l’utiliser avec prudence: non seulement les tableaux sont toujours appropriés dans de nombreux cas pour mieux décrire les données, mais il peut également y avoir d’autres moyens, tels que des outils ordinaires. listes, pour décrire le contenu sans utiliser <dl/>
.
Quelle est la différence entre les dispositions fixes et fluides? Quels sont les avantages et les inconvénients de chacun?
La disposition fixe a des largeurs prédéfinies des éléments. Les éléments d'une mise en page fluide dépendent de la largeur de la page.
La disposition fixe facilite la conception de la page, en particulier lorsque les graphiques pleine largeur sont nombreux. Même sans graphiques, c'est toujours plus facile, car vous ne vous occupez que d'un cas précis. Par exemple, Programmers.SE étant un site Web à disposition fixe, la colonne qui affiche les questions et les réponses a toujours la même taille. Si une disposition fluide était utilisée pour cette colonne, cela créerait un problème: sur les petits écrans, le texte serait illisible, car les lignes seraient trop courtes, alors que sur les grands écrans, les lignes seraient extrêmement grandes. serait illisible aussi.
Le problème avec la mise en page fixe est que cela fonctionne bien pour quelques résolutions parmi les plus utilisées, mais échoue plus ou moins pour tout le reste. Cela devient particulièrement important depuis l'adoption de très grands moniteurs larges et l'utilisation croissante d'Internet sur de petits appareils mobiles.
La mise en page fluide aide à cela, mais la conception est plus difficile à faire pour un tel site Web. Dans certains scénarios sur des projets mal gérés, cela peut entraîner des piratages HTML et CSS, des pages volumineuses, une maintenance faible et, au cours du développement, des coûts plus élevés et des délais non respectés.
Sur une page avec une mise en page fluide, comment pouvez-vous éviter la situation dans laquelle une colonne de texte devient trop volumineuse pour rester lisible?
Vous pouvez limiter la largeur d'une zone de texte à l'aide de la max-width
propriété.
Que pensez-vous de ce morceau de code <p color="Red" align="Center">Text here</p>
:?
Le morceau de code a un défaut pour mélanger la logique de présentation dans HTML. La logique de présentation doit être mise en CSS pour plusieurs raisons:
- Cela aide à séparer les problèmes et à nettoyer le code, ce qui signifie une maintenance moins chère plus tard,
- Cela rend les styles réutilisables de page en page, ce qui (en dehors des problèmes de maintenabilité) permet de garantir que vous utilisez les mêmes styles sur l'ensemble du site Web,
- Cela aide à réduire la bande passante, car les fichiers CSS seront mis en cache.
Après quelques questions de base comme celle-ci, vous pouvez en poser d’autres plus difficiles:
Comment éviter la duplication de couleurs ou de polices en CSS lorsque ces couleurs ou polices sont appliquées à plusieurs éléments qui ne peuvent pas être ciblés par un seul sélecteur? Y a-t-il des inconvénients?
Vous faites cela en utilisant des pré-processeurs CSS, comme Sass ou LESS. Ils permettent de définir des couleurs, des polices et d’autres éléments du style à l’intérieur de variables que vous pourrez utiliser ultérieurement dans vos styles.
Les inconvénients des préprocesseurs CSS sont les suivants:
Ils doivent parfois modifier le flux de travail de développement et de déploiement afin de disposer du code CSS à jour dans le navigateur.
Ils ne sont connus que de quelques développeurs, ce qui empêche une nouvelle personne de rejoindre ou de gérer le projet ultérieurement,
Il n'y a pas à la fois de bons et de rapides IDE pour Sass ou LESS, et l'intégration au sein des IDE les plus populaires est plutôt décevante.
Donnez-moi un exemple de href
valeur d'une image qui est sur CDN, étant donné que cette image est affichée sur un site Web auquel vous pouvez accéder à la fois via HTTP et HTTPS.
Etant donné que HTTPS nécessite que chaque ressource appelée soit également sur HTTPS (sinon, un avertissement de sécurité sera affiché à l'utilisateur dans de nombreux cas), il n'est pas possible de spécifier le lien sous la forme http://cdn.example.com/image.png
. Pour lier correctement à l'image, //cdn.example.com/image.png
doit être utilisé; le navigateur sera alors ajouté http:
ou https:
dépendant du contexte.
Étant donné que la taille des pages et le nombre de demandes sur un site Web ne peuvent pas être optimisés et que le contenu ne peut pas être modifié ni AJAX ajouté, comment donnez-vous l'impression à l'utilisateur que le site Web est plus rapide? Qu'est-ce que cela implique du point de vue HTML?
Si HTTP 1.1 est utilisé, la page peut être tronquée . Cela signifie que les premières parties apparaissent plus rapidement, ce qui donne l'impression que le site Web est plus rapide que ce qu'il est en réalité. Le codage de transfert en bloc est impossible dans HTTP 1.0, ce qui signifie qu'il n'y a rien à faire dans ce cas.
Pour pouvoir servir le contenu fragmenté, il faut, du point de vue HTML, réorganiser les éléments, en plaçant les plus critiques en haut du fichier (ce qui ne veut pas dire qu’ils doivent apparaître en haut de la page). Par exemple, sur un site Web de commerce électronique, lorsque l'utilisateur souhaite voir les détails du produit, le premier morceau peut contenir les <head/>
détails du produit. Le bloc suivant peut contenir les éléments principaux tels que le logo du site Web, le menu principal, les droits d'auteur, etc. Enfin, le dernier bloc peut contenir la section "Les personnes ayant acheté cet article ont également acheté", les commentaires et les évaluations du produit, le "Partager sur Facebook", etc.
Enfin, vous pouvez demander au candidat de travailler sur un scénario du monde réel. Cela peut être n'importe quoi, comme le plus facile ci-dessous, dans les scénarios complexes où la personne doit faire face à des sprites CSS ou à d'autres techniques d'optimisation avancées, avec des incohérences de navigateur, etc.
S'il vous plaît, pouvez-vous créer une page XHTML avec deux zones: la gauche, avec une liste, et la droite, avec le texte. Deux zones sont séparées par une ligne verticale qui s'étend du haut au bas de la page. La liste et le texte variant en taille, vous ne pouvez pas prédire laquelle aura la plus grande hauteur. Vous ne pouvez pas utiliser <table/>
s.
En fait, c'est assez simple mais cela montre si la personne a le réflexe de penser aux hauteurs. Un candidat inexpérimenté créera la float:left
zone et la border-left:solid 1px #ccc;
zone, mais oubliez d’ajouter la bordure dans la zone de gauche et de l’étendre de sorte que deux frontières se trouvent au même endroit.