I am trying to determine some good interview questions to assess the ability of people coming in for a Html/CSS job, however that topic is extremely broad, and I'm not sure what sort of questions I can ask to properly evaluate someone's HTML/CSS knowledge.

What sort of questions can I ask to evaluate a candidate's Html/CSS abilities during an interview?

Ideally I would like to ask few questions and then give them a real life scenario to combat.

Can you show me your work? That would be a good one.
–
JeffOMay 11 '12 at 12:42

Indeed but anybody can copy and paste code at home for good examples. Making them answer questions on the spot lets you know what they know for themselves.
–
webnoobMay 11 '12 at 13:25

1

@Rachel - Many thanks for the edit and re-open. I think its a good resource for this site.
–
webnoobDec 15 '12 at 12:13

8

If you don't know what to ask, just use some online test (e.g. http://tests4geeks.com/test/html-css) to validate the skills of candidate. After that you can ask him to write the code of some html page. For example page with top menu with many sub-items and footer at the bottom.
–
JosephJul 14 '13 at 20:46

Ask 'em what they think of IE. Anyone who's had to do anything non-trivial knows it's a PITA. ;) Seriously you could ask them what browser bugs they've encountered.
–
Ben ThurleyNov 1 '13 at 10:44

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.

From personal experience, working with other developers, I think questions on HTML & CSS won't sort out the people who know what they are talking about from those that know what they are actually doing.

I'd recommend a mock test/prototype based on the realistic experience of your company's needs.

Footer, which allways will be at the bottom. Even if article has 1 row.

UPD: Of cource, ask the developer to write the code using divs only (without tables).

It should looks like:

But prior to live interview, I would suggest you to test candidates online. Because it's easier to test candidates online and invite to the interview only good skilled developers, than spend your time on every candidate.

One type of test which is applicable to programming languages and markup languages is a code review. Create a small sample (20 or 30 lines) with a mixture of syntax errors, logic errors, corner cases, arguably bad style... Then ask the candidate to identify anything which strikes them as suspicious.

It's important to use this kind of test correctly: as with any interview question, the way the candidate approaches the task is important, and not just the results.

I'm not going to post my test, but some hints for how to apply this to CSS:

Syntax errors: miss some semicolons. As a bonus, you can miss some optional ones (arguable style) and see whether the candidate comments.

Logic errors: put a prefixed property after the non-prefixed one. This also tests for familiarity with CSS3 and can provoke a discussion about the way in which the standard is developed.

Corner cases: e.g. a margin with 3 values - you'd be surprised how many people aren't aware that it's possible. If the candidate doesn't comment, you can ask how it's interpreted to check that they ignored it out of knowledge rather than ignorance.

Another corner case: exercise your favourite two or three IE7 bugs. This will distinguish those with battle scars (who should spot at least one of them) from the inexperienced or the Webkit-only.

Style: excessive specificity, missing em and px, etc. Someone who studied the syntax for the interview probably won't catch many of these.

I sat in on a few web designer interviews, and what we did was print out a very simple looking Blog layout on paper, and then ask the candidate to just jot some HTML and/or CSS on the page over 10min or so, to give us a basic idea of how they'd code it up. This let us know if someone ACTUALLY knew CSS or not. We were just looking for basic stuff like floats vs tables, or whatever, and we explained that it didn't have to be perfect by any means.

Tons of folks claimed years of experience with CSS, but when pressed to write it out, they were writing in wild guesses like "layout: floating; direction: up;" or other such jibberish. More than 1 "CSS Ninja" didn't even get the syntax right, a la "div(margin=5)". That was very eye opening for me, to see how many people just straight up lie in interviews. And its seemingly easier to lie about CSS than about straight up coding. You could not know a thing about CSS, but do some googling and be able to throw the proper terminology around pretty quickly. You can't really do that effectively with higher level concepts like OOP, for example.

CSS box model. Margins, padding, etc. IE model vs. W3C model. How can one switch between the two? What are their benefits and drawbacks?

CSS positioning. What does it mean for an element to be "in the flow" and "out of the flow"

inline-block and other display values. Difference between display: none; and visible: false;(this is a good and easy question for people new to CSS)

inline-block vs float for layouts.

Selectors.

CSS resets. Why they are needed and what they accomplish?

Media-queries and responsive design.

How to organize styles and how to keep the number of selectors small. LESS, Sass and other CSS pre-processors. Object-Oriented CSS.

And some questions about HTML:

Doctype and browser modes.

Why are some tags more preferable than the others (em vs i for example)?

What are the basic principles one should follow to keep HTML and CSS manageable and easy to maintain?

In general I put more emphasize on CSS since it's the area many people find difficult to grasp and to use effectively. I meet a lot of candidates that put "CSS" in their CVs but are not able to answer any questions about it. Most people just saying straight "No-no, I know CSS good enough to deal with it but not good enough to talk about it."

Sometimes it's good idea to just give a simple task for and interviewee to complete. Say, design a simple page with layout and block styling that supports multiple screen sizes and adjusts accordingly. It should take about an hour or two and the candidate should explain what he's doing and why.

Those tests are horrible> You can just bang away on the keyboard
–
Jan DoggenSep 10 '13 at 13:03

1

I must say, this is not a very informative test... I've been programming HTML/CSS/JS for years and I can't name every tag. The list of tags I haven't used in years is longer than the one in which I have!
–
Rob GibbonsJan 20 '14 at 4:27