Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

For the first time I'm in the position where I'm helping interview potential front-end developers. The other interviewer is more business & PM-focused, although he is a former developer. I probe for knowledge and background in CSS, Javascript, and other related technologies, but those questions are really just testing for lingo. I feel that it would be unfair to ask very specific questions about CSS when we're not in front of a computer.

I've also been given websites that these web developers have written. Is that enough to go on for interviewing front-ends? We're also looking for general aptitude, rather than a databank of knowledge.

share|improve this question
1  
Check out User Experience Stack Exchange for inspiration on good / interesting questions. –  Yannis Rizos Nov 11 '11 at 1:38

6 Answers 6

up vote 7 down vote accepted

I've faced several interview styles over the years. They seem to break down as follows:

  1. Do you seem as the right sort of person?

    When I have worked in these companies they seem to hire and fire quickly. At interview they make a judgement about whether you could fit in, and that you seem to be talking the right stuff, and if after a few weeks you are not demonstrating this, the new recruit fails probation and is removed.

  2. Asked 20 random facts.

    These kind of interviews are very revealing to the candidate. They tell the candidate what problems the interviewer has faced, and the level of work involved. The problem is that they positively select people who have read the book, rather than identify programming talent. When I have worked in these environments the quality of the other programmers has been variable, and generally poor.

  3. Demonstrate skills.

    This is the interview technique I primarily use. I give the person a role related task and then observe how they perform. Do they ask key questions about the brief? Are they familiar with the subject? Does their performance seem consistent with their CV? Do they have a design? Did they actually implement their design or did it stray? If you ask questions about their design decisions do they give a considered answer as to why? Or did they mentally flip a coin? If you introduce a constraint that should cause a design decision to change do they recognise that?

With regards to asking specific CSS questions whilst not on a computer, I'd agree that a 20 random question approch would not identify the best candidates for you, but I would be looking for evidence of a suitable level of familiarity of CSS issues with open questions. e.g. can you give me an example of how you could improve the presentation of...

In my experience its best to be patient whilst recruiting, at times rejecting 90%+ of candidates and insisting on the best.

share|improve this answer
    
How is one asked a fact? –  Maxpm Nov 11 '11 at 3:57
    
Its easy to follow up an open question with a direct question asking for a fact. However, the point is this. If on the job one particular fact is really important then by all means ask about it. However, also think about how challenging it would be for some one to learn this fact on the job? How plausible is it that a skilled and competent programmer could have avoided the need to learn this fact by working in different environments? –  Ptolemy Nov 11 '11 at 8:07

I'd also ask about how to structure a site, such as navigation and folder layouts. This should give you a feel for how well they can put together a site as a whole rather than just laying out a page.

If your site is public facing, see what they know about search engine optimizatiion (SEO).

If they have public facing websites, visit them during the interview and quiz them about their design choices and how they did what they did.

Ask them what they would do if they were given a Photoshop layout for a site and how they would break down the task of building a functioning site from it.

share|improve this answer
    
Good suggestions! thanks. –  Civilian Nov 10 '11 at 23:54
1  
+1 for the 3rd paragraph. Review their portfolio with them side by side, ask why, how, and what could have been done better. –  Andrew Heath Nov 11 '11 at 6:42

If you are expecting the designer to work with programmers, In addition to what have been listed before you need to check the personality of the person and how he/she views the programmer-designer relationship. Also, if the designer is expected to amend or maintain existing sites, then they should be comfortable in the tools and the code in those sites as well as the existing code and the used tools. It helps to ask them about their opinion in style of existing sites either internal or external and see how this view fits the culture of your organization.

share|improve this answer

For front-end developers there are some ways to gauge his skill and experience:

Websites/Portfolio

Considering that front-end developers usually have worked with things that are clearly visible, it's not difficult for them to give up a list of websites that they've worked on. One could argue that they can't due to non-disclosure agreement, but it is also not uncommon for them to have portfolio websites that you can check.

If they can't show off what they've done or what they can do then I'd be fairly suspicious. It's so easy to create projects on the Internet today (with tools such as jsfiddle, github, etc.) that it's inexcusable for a front-end developer to not do so.

This is generally what you should ask for prior to the interview so you can examine the material. That way you can have a two-way conversation and discussion with the candidate on how he works. If the candidate is unable discuss his work then it's a clear red flag.

Demonstrate skills

During the interview you can ask them to demonstrate their skills. You can tell them to create a short Javascript/HTML demo. That way you can see if they're up for the task of front-end web development or not.

The drawback with this exercise is that it takes time both for you and your candidate to sit this through to completion (and still may not lead to a hire if the candidate is right but decided to go elsewhere).

share|improve this answer

Give them a test page to build. Then the interview would be more about whether or not you would actually like to sit beside them in an office for 10 hours a day.

share|improve this answer

Ask them about why modal dialogs are bad -- not because you think they are bad necessarily, but to see if they've thought about it. Ask them if they know what "mental model" means. Ask them to give you two examples of what they think are particularly good websites, and have them explain why they think they are good. Ask them to define what is meant by the css "box model".

In other words, don't ask them about specific syntax, ask them about what they know about the difference between good and bad websites. Syntax is easy to look up, a good design sense... not so much.

The goal isn't to make sure you only hire candidates that believe what you believe, but to find candidates that have actually thought about these things. I'd rather hire someone that disagrees with my personal opinion about modal dialogs but know why others think differently than they do, then hire someone who has the same beliefs that I do.

You want candidates that think. There are so many programmers who just code the way someone else has showed them to code without giving it a second thought. It's like the eternal battle of curly braces in C-like languages. It's not important (to me, anyway) that someone agrees with me, only that they are aware of the debate and that they have formed their own opinion rather than just doing it the way they were told to do it.

share|improve this answer
2  
"Ask them about why modal dialogs are bad". Demanding the candidates adhere to a certain dogma is whats bad. What if they happen to disagree? Do you want robots, or people who are willing to think outside the box? Asking them when they would or would not use modal dialogs is a lot less preachy, and probably a lot more productive. –  GrandmasterB Nov 11 '11 at 4:59
    
I'm not suggesting you demand anything -- just ask their opinion. Honestly, you should hope that they do disagree. You want people with strong opinions, especially if they differ from your own. If you have a fundamental issue with dialogs, then ask why globals are bad, or table based layout is bad, or hard-coding fonts is bad. A good candidate will know why some people consider these things bad, even if they don't think that themselves. The goal is to see if they've actually thought about the way they write software. –  Bryan Oakley Nov 12 '11 at 21:39
    
But modal dialogs aren't bad. When it really is critical to stop somebody and make them aware of potentially painful consequences before moving forward they make a lot of sense. It's when they're used to hamfistedly put the user on a rail because people don't want to think through the problem more carefully that they're awful. –  Erik Reppen Feb 27 '13 at 5:40
    
@ErikReppen: you are right - modal dialogs aren't bad. They are a tool, and like most tools they aren't inherently good or bad. However, the way most UI designers use them is bad. You say they are good where it is critical to tell the user something, which is true, but they are used way too often to make up for bad design or to tell users something they already know, or could learn in a less disruptive way. –  Bryan Oakley Feb 27 '13 at 12:05
    
This is something my current project manager groks. She's not a big fan of lightboxes for their own sake. –  Erik Reppen Feb 28 '13 at 4:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.