The short answer is- I don’t pay all that much attention to the sites listed on a candidate’s resume.

Don’t get me wrong, I look at sites and I prefer to see at least three or four examples when doing an evaluation. It’s just that I’m looking at sites mostly to exclude people. We see a lot of unqualified candidates at the resume level, so most of what we need to do at this point is to get rid of all the people who have no chance. Because of that, I’m visiting listed sites just to make sure the work looks professional and is done in a reasonably modern style. Basically I don’t want to see any tables, inline event handlers, or generated code and looking just a little deeper I want to make sure the JavaScript doesn’t look obviously insane. If they pass that test, then the real work of the hiring process begins. We’ll start the rest of the interview process in order to dig deeper into their front end knowledge and personality.

Why I Don’t Look at Source Code

I could view source and maybe learn a thing or two, but I’ve done this long enough to know how unreliable that can be for judging a candidate’s technical ability.

The problem with looking at sites to gauge talent is actually pretty straightforward:

• I don’t really know what the candidate is responsible for, so I could be crediting the candidate for something a co-worker wrote. I might be able to tease some of that information out in the interview process, but I’d rather focus my time on more generic technology questions which can expose more of what the person actually knows.

  This works in the other direction, of course. A senior resource might have been the lead on a project, but there could still be really weird, insane code on the site written by a more junior resource. I can’t know, off the bat, whether or not the candidate is responsible for the Lovecraft code.

• Even people who are really smart and experienced might write really generic, uninteresting code if the project doesn’t call for much more than the basics. While it’s nice to see clearly formatted library code and properly implemented plugins, that by itself doesn’t really guarantee anything more than surface knowledge and the ability to parse documentation. I mean, the point of something like jQuery is that it’s friendly enough for people inexperienced with JavaScript to pick up without too much trouble. So… seeing someone who can add some basic interactivity to a marketing site doesn’t really tell me much about their actual skill level in either direction.
• You’d be surprised how often people lie about the work they’ve done. Personally, I don’t get it because it’s kinda’ hard to fake your way through a fast-paced technical role. Still, people just make stuff up.

What I Do Look At When I Review a Portfolio

Before I go into the generics I should point out the one, big exception to this rule. While I still won’t pore over source code in this situation, I am more interested in a candidate with consulting/agency experience on large-scale web projects. I know what goes into making sites and applications like that, so seeing big, agency projects on a candidate’s resume is a positive signal to me. I know that person has been through the agency ringer. As a question of temperament that’s extremely important. Some people like the pace we work at every day. Others don’t. If they’ve done it and they still want to do it, that’s a good sign.

Another exception, which is actually pretty rare, is when a candidate has a really snappy portfolio site. Everyone has a site. Most of the time they’re pretty boring (look at this one.) Occasionally, people go beyond the call of duty. Those folks will get a second look at their code.

Beyond those exceptions, here’s the basic checklist I run through when evaluating a candidate’s samples:

• Does it look finished? Does it error in any way? Does it fail in Internet Explorer? Again, I’m looking to disqualify candidates, so it’s a bad sign if something looks broken at a surface level.
• Does it use tables? I still use the web developer toolbar, so I just use the “outline > table cells” command to uncover this obvious problem. People still fail this test, by the way. It’s not the same rate it would have been five years ago, of course, but it still happens.
• Are there any inline event handlers? Inline styles? Again, this happens less than it used to, but it still happens.
• Is the markup well formatted? Can I scan it quickly and see some structure? Are there comments?
• Is there any organization to the JavaScript? Is the global namepspace polluted? Are there comments? I won’t go over code with a fine-toothed comb, but I can quickly see if there’s anything that really sticks out when scanning a file. I’m hoping to see code that looks like it was written in 2011, not 2001.

Other than maybe running Yslow on a site or two (just for fun,) that’s the extent of my interaction with the sites in a candidate’s portfolio. With Firebug and the Web Developer toolbar I can churn through a site in just a couple of minutes, getting a basic feel for the level of a candidate’s work. With that and the rest of the story the resume tells I’ll make my recommendation as to whether or not we should be moving forward with the candidate.