How We Hire Developers at Zenuity

Posted on September 30, 2011 by Brandon in Business, Development, Philosophy

Zenuity wouldn’t be what it is without our awesome team of developers. Unfortunately, this position is one of the hardest to fill, for two reasons:

1. We have pretty high standards.

We’re a close-knit, passionate team. We often take breaks from work to talk about new ideas and methods… or Step Brothers. That being said, we’re very picky about who we hire. We want someone with the same passion and thirst for knowledge that we all have. We take pride in our work and we want someone that will do the same. Someone who cares deeply about the quality of their code, because their code represents who they are as a developer. Someone always looking to get better. Most importantly, we need someone with talent. Their code needs to be clean, cross-browser compatible, semantic and standards-compliant. Consistently.

2. We don’t do interviews. We do assessments.

Interviews are just words. They’re great for getting a sense of someone’s personality and how they might mesh with the rest of the team. However, we’re not all that interested in what they say they can do. We’re interested in what they can actually do. That’s why we have applicants pass an assessment.

The Assessment

We actually created home page and article page mockups for a fictitious recipe blog called Recipe Queens. We tried to include every element we normally use on most websites. We bring applicants in for a day to code the mockups, while abiding by the following rules:

  • Make the coded pages look as similar to the mockups as possible. We’re not sticklers for pixel-perfection, however. If you think the design needs to be adjusted, do it. Just be prepared to explain why.
  • No image replacement for non-web friendly fonts. All fonts used are available via @font-face, Google Fonts or Typekit. How you handle this is up to you and which method you use is part of what we look at.
  • Make sure the design is flexible. Code so menus and content areas can expand without breaking the design.
  • Use the XHTML Strict or HTML5 doctype. We don’t care which, we check for standards-compliance and browser issues either way.

Applicants are given the entire day (8 hours) to complete the assessment (paid, of course). Once they’re done, we’ll review their code, paying careful attention to:

  • Code quality. Obviously, the first thing we’re concerned with is the quality of someone’s code. Is it clean? Do they use a lot of unnecessary divs, classes or ids, rather than relying on the cascade? Is it semantic? Is it standards-compliant? Do the pages look reasonably consistent across all major browsers?
  • Faithfulness to the mockups. Do the coded pages look like the mockups? What’s different? Why?
  • Flexibility. We purposely mess with text and images to push the boundaries of the various content areas to see how the design and layout reacts.
  • Browser consistency vs. CSS3. Did they use CSS3 properties? For what? Is anything lost for browsers that don’t support those properties?

Is this process hard? We have had applicants leave during the assessment and never come back. We think it’s very worthwhile, however. I’m not sure how different our process is from other companies, but it has not failed us yet.

Sitemap