Web Developer Resume Screening

How to filter through resumes to find good Web Developer applicants

What makes a good web developer these days? An alphabet soup of skills that are simply an effort at search engine optimization for Monster.com, HotJobs or Dice? Don’t waste your time and the applicant’s time by bringing them in for a three hour interview unless you know there is a chance of a good match. Do a phone screen first. It will save you a lot of time and frustration. Before you call, however, you should review not only their resume, but their portfolio of work as well.

Web Developer Resume & Portfolio Screening

When reviewing a resume, use the resume as a guideline of possible skills, not gospel. In deciding who to interview and when to pass, check the resume for stated skills and match that skill set with the skill set displayed in a review of the sites the applicant coded. An understated resume that shows matching skills should be considered as much, if not more, than an overstated resume that shows those same skills. Don’t think a woman is less qualified than a man simply because her resume is modest because his may in fact be exaggerated.

The question has to be, "does the person know how to code correctly?" In reviewing an applicants portfolio there are certain indicators that display whether or not the applicant knows what they are talking about.

  • Elements coded in capital letters or mixed syntax
    <P><A Href="Link.html">Click me</a></P>
    Skip this candidate
    correct: <p><a href="link.html">Click me</a></p>
  • Overlapping elements
    <strong>Hi, my name is <em>estelle</strong></em>
    If it happens once, and otherwise the candidate looks good, it may show a sloppy error, but otherwise the applicant may know how to code.. If the code generally looks like the above, get the shredder!
    correct: <strong>Hi, my name is <em>estelle</em></strong>
  • Gratuitous use of table layouts, frames and flash navigation
    <table><tr><td>&bull;</td><td>should be a list</td></tr></table>
    If the applicant shows no samples of semantic navigation, or displays no samples of tableless layout, then take a look at your other applicants.  If generally everything is semantic, with little exceptions, consider the applicant’s client: sometimes clients insist on development methods. If it’s common, then the applicant doesn’t understand semantic markup and you should pass.
    correct: <ul><li>should be a list</li></ul>
  • Sloppy, pointless CSS
    a {text-align: left; margin: 10px;} // links are default inline elements.
    Take a look at the CSS, not just the HTML. You will likely find errors. The erroneous application of margin on an inline element if it occurs once may be the sloppiness of not cleaning up code or leaving in some CSS from a previous element.  If the style sheet shows a lack of understanding the difference between inline and block elements, doesn’t grasp positioning or floating, move on. If they really know CSS, and they are just sloppy with small clients, then keep reviewing the candidate. If they are both sloppy and have limited knowledge, you can find better.
    better: a {display: block; float: left; margin: 10px;}
  • Abuse of inline javascript event handlers
    <a href="javascript:void()" onmouseover="document.images[0].src='on.gif'" onmouseout="document.images[0].src='off.gif'"><img ... /></a>
    Give bonus points to those who separate behavior (javascript) from structure (html). Take away points (or throw out the resume) or those who use links for presentation, as in the above sample.
    Separating behavior and structure can be taught. But, in the example above could have been done purely with css. If that is the crap they display, toss their resume: they are not even trying. If you see multiple href="#", or href="javascript:void()", then Next!
    better: <div id="myImg"><img ... /></div> with the content and background controlled via CSS
  • Missing doctypes, two xml prologs, conflicting encoding (xml prolog and meta charset)
    <html><head><title>Untitled Document</title></head>
    Value an applicant who declares the wrong doctype over one who doesn’t declare a doctype at all. Value an applicant who declares an inappropriate charset over one who doesn’t declare a character set. The right answer can be taught more easily that teaching someone to care about web standards.
  • Non-breaking space and br alignments
    <br />&nbsp;<br />&nbsp;
    Web developers should be held completely responsible for the shell of their pages: the templates. In shell of page, using markup for presentation means the applicant isn’t trying to code well. If you find this coding style in the content of the page, and not the guts and the template portion of the site is correctly coded, assume they know how to code and that their client is responsible for the poor content maintenance. Clients will update their own content, and they do the screwiest things.
  • Overreliance of WYSIWYG Editors
    .style1 {color: #ff0000;}
    .style2 {color: #ff0000; font-weight: bold;}

    There is nothing wrong with using Dreamweaver, but you don’t want to hire someone who relies on it. If all javascript functions in the applicants code start with MM, such as MM_showHideLayers, or styles are named in order from style1, style2 .... style65, then they are using Dreamweaver as a crutch and don’t actually know how to code CSS or JavaScript (and perhaps not even XHTML).

Valid Excuses for Samples of Questionable Code

  • Client’s Budget:
    When looking at a sample of code, consider who the site is for. If the site is for a large corporation with funding, be a little stricter in analyzing the code. If the site is built for a small client on a pay per hour basis, consider being a little more lenient. When building sites for small clients, developers may cut corners a few ways to save them money. For example, they may not spend the time cleaning up or commenting the CSS. While you may want to pass on someone who repeats "text-align: left;" 16 times, since it should have been set as the outer element, don’t hold someone who puts three extraneous "text-align: right;"s at major fault.
  • UED or Designer Specifications may have been questionable :
    I coded a site for a designer who created a different layout for the content of every page. While I used an external style sheet for the shell of the page, I used inline styles for the wacky positioning of images within the page. While I should have removed inline styles and create classes, the classes would never have been re-used, the client was on a budget and the graphic designer was going to have me move the images around anyhow.  Your applicant may have similar clients.  I thought it best not to spend my time or the client’s money cleaning up the CSS.
  • Someone else is maintaining the content:
    Sometimes clients maintain their content which can be the cause of bad code. In the shell of the document (the template), if there is mixed case XHTML that’s bad since that is most likely definitely the developers mark. However, if the template code looks great, and only the content is coded like crap, give the applicant the benefit of the doubt.  Perhaps it was being maintained by the client rather than the coder. You may find some mso=normal’s (don’t you love microsoft), unclosed <p> and <li> in the code. These may be signs that the applicant’s clients are maintaining their own pages or using CMS. One of my sites has a table layout for the home page since I was unable to get the client to understand that WYSIWYG editors render pages differently than actual browsers.  Other than the home page the site is well coded, but that home page currently has 30 instances of <p style="margin:0; padding: 0;">&nbsp;</p>.
  • Useless Flash and other Tacky Design elements:
    Sometimes clients insist on flash navigation or intros. If the applicant’s portfolio samples all have flash navigation and few or no samples of semantic navigation, skip the candidate. However, if a few of their sites have flash intros or navs, but it’s evident that they know how to do a standards compliant unordered list navigation from other sites, then don’t hold a flash component against the applicant.

In conclusion, if someone obviously doesn’t know what they’re doing, don’t bother interviewing them. However, if the only crap code you see is the html of their portfolio ("the cobbler’s children have no shoes"), and they show some examples that show that they can definitely be up to par, then do a phone screen.

Note: See also my list of interview questions for web developers.

This entry was posted in Web Development. Bookmark the permalink.

5 Responses to Web Developer Resume Screening

  1. Robert says:

    Very good guidelines. I think I can apply some of those to my own resume and portfolio. Thanks

  2. Dav id says:

    I’m doing some phone screens for my company…good info here, thanks.

  3. Really very informatiive and important guideline. it is very helpful for all those candidates who are preparing interview related to web designer.

  4. Asifa says:

    Really very useful guidelines. Good job!!

  5. ur-sexist says:

    You could also add – Don’t think a man is less qualified than a woman simply because his resume is modest because hers may in fact be exaggerated.

Leave a Reply

Your email address will not be published. Required fields are marked *