HTML and CSS are difficult to interview for a few reasons:
They are too basic, compared, for example, to a programming language,
They depend very much on the context of the job. Examples:
If you create Google scale, hugely fast and optimized websites, the people you interview for the job cannot ignore what CSS sprites are.
If you create XHTML W3C valid websites, you should ensure that the candidates know the difference between XHTML 1.0 and XHTML 1.1, or what are the mandatory attributes for <img/>
, etc.
If you create terrible websites full of hacks, you should ask the people you interview about how they will do such or such hack, how they serve different CSS for different browsers, etc.
etc.
If it's a pure HTML and CSS job, the person will have to work with designers on one hand, and developers on other hand. They must know HTML and CSS, but what is much more valuable is their ability to interact with those people, and to understand both the needs of the designers, the requirements of the developers, and the constraints of HTML and CSS.
For example, they must know how to structure their HTML in a such way that it would be easy for a JavaScript developer to add interactivity later.
You may want to start by some basic questions:
What is your favorite browser?
If the person answers "Internet Explorer", stop the interview immediately: you don't need somebody like that.
No, I'm kidding. The answer is irrelevant. Instead, you can ask the following:
Tell me about the debug tools you use in your favorite browser.
Primary using Chrome, I work daily with Developer Tools. Those tools allow me to:
View the requests made from a page,
Study the time it takes for a page and the related resources to load, especially the DNS lookup, waiting and receiving times,
Study the headers of the elements sent, as well as the cache indicator,
View the DOM and study how CSS selectors are applied,
I also use YSlow which serves me as a checklist for optimization of a website which require high scalability. YSlow is also a good tool when it comes to determining if the server is configured correctly (sending correct headers, etc.).
In Firefox, I use Firebug, the tool very similar to Developer Tools from Chrome. Developer tools are also available in new versions of Internet Explorer, and also enable me to switch to IE7 to IE10 compatibility views. This last feature is very helpful, since without it, I would be forced to install several virtual machines just for legacy testing, or to use much more often the paid services like Litmus.
Please, explain me what <dl/>
tag is about? What was the intended use for this tag? How is it used in practice? What do you think about this extended usage?
Here, you want the person to be able to explain that <dl/>
is for dictionaries, associating one key, <dt/>
, with one or several values, <dd/>
. While the primary use of this tag was purely related to semantics, in practice it was extensively used to replace tables, a good example being PHPBB3. This is a good thing when tables are slowing the rendering of the page, but it must be used with caution: not only tables are still appropriate in lots of cases to better describe the data, but also there may be other means, such as ordinary lists, to describe the content without using <dl/>
.
What is the difference between fixed and fluid layouts? What are the pros and cons of each?
The fixed layout has predefined widths of the elements. The elements of a fluid layout depend on the width of the page.
The fixed layout makes it easier to design the page, especially when there are lots of full-width graphics. Even without graphics, it's still easier, because you care only for a precise case. For example, Programmers.SE being a fixed layout website, the column which displays the questions and the answers has always the same size. If a fluid layout would be used for this column, this would create an issue: on small screens, the text would be unreadable, because the lines would be too short, while on large screens, the lines would be extremely large, so the text would be unreadable too.
The problem with the fixed layout is that it works well for a few, most used resolutions, but fails more or less for everything else. It becomes especially important since the adoption of very large, wide monitors, and the increasing usage the internet on small, mobile devices.
The fluid layout helps with that, but the design is more difficult to do for such website. In some scenarios on badly managed projects, this may lead to HTML and CSS hacks, large pages, low maintainability and, during development, to higher costs and missed deadlines.
On a page with a fluid layout, how can you avoid the situation where a column of text becomes too large to stay readable?
You can limit the width of a zone of text by using max-width
property.
What do you think about this piece of code: <p color="Red" align="Center">Text here</p>
?
The piece of code has a flaw to mix presentation logic inside HTML. Presentation logic must be put in CSS for several reasons:
- It helps the separation of concerns and clean code, meaning cheaper maintenance later,
- It makes the styles reusable from page to page, which (outside maintainability concerns) helps ensuring that you're using the same styles on the whole website,
- It helps reducing the bandwidth, since CSS files will be cached.
After a few basic questions like that, you may ask some more tricky ones:
How do you avoid duplicating colors or fonts in CSS, when those colors or fonts are applied to multiple elements which cannot be targeted by a single selector? Are there drawbacks?
You do that by using CSS preprocessors, like Sass or LESS. They allow to define colors, fonts and other parts of the style inside variables that you can use later in your styles.
The drawbacks of CSS preprocessors are that:
They sometimes require to change the development and deployment workflow, in order to have the up-to-date CSS code in the browser,
They are known only by a few developers, which makes it harder for a new person to join or maintain the project later,
There are no both good and fast IDEs for Sass or LESS, and the integration inside the most popular IDEs is rather disappointing.
Give me an example of a href
value of an image which is on CDN, given that this image is displayed on a website which may be accessed both through HTTP and HTTPS.
Since HTTPS needs every called resource to be on HTTPS too (otherwise, a security warning will be displayed to the user in many cases), it is not possible to specify the link as http://cdn.example.com/image.png
. To properly link to the image, //cdn.example.com/image.png
must be used; the browser will then prepend http:
or https:
depending on the context.
Given that the size of the pages and the number of requests on a website cannot be optimized and the content cannot be changed nor AJAX be added, how do you give the impression to the user that the website is faster? What it involves from HTML perspective?
If HTTP 1.1 is used, the page may be chunked. This means that the first parts will appear faster, giving an impression that the website is faster than it is in reality. Chunked transfer encoding is impossible in HTTP 1.0, which means that there is nothing to do in this case.
Being able to serve the chunked content requires from HTML perspective to reorder the elements, putting the most critical ones at the top of the file (which doesn't mean that they would have to appear at the top of the page). For example, on an e-commerce website, when the user wants to see the details of the product, the first chunk may contain the <head/>
and the product details. The next chunk may contain the primary elements like the logo of the website, the main menu, the copyright, etc. Finally, the last chunk may contain the "People who bought this also bought" section, the comments and ratings of the product, the "Share on Facebook", etc.
Finally, you may ask the candidate to work on a real-world scenario. It may be anything, like the easiest one below, to the complex scenarios where the person has to deal with CSS sprites or other advanced optimization techniques, with browser inconsistencies, etc.
Please, can you create an XHTML page with two zones: the left one, with a list, and the right one, with text. Two zones are separated by a vertical line, which extends from the very top to the very bottom of the page. List and text varying in size, you can't predict which one will have the biggest height. You cannot use <table/>
s.
Actually, it's pretty simple but shows if the person has the reflex to think about heights. An inexperienced candidate will create the float:left
zone and the border-left:solid 1px #ccc;
zone, but forget adding the border to the left zone and extending it so that two borders will be at the same place.