hiring front-end devs/an extensive checklist
Last week Smashing Magazine launched a pretty interesting question through their Twitter account: "What's the best way to test if your new front-end developer is really good at what he does". It's one of those questions that seems quite simple at first, but once you start writing down requirements there's a lot more to it than producing clean code and providing quick results. Let's run through a couple of criteria that determine the overall quality of your new recruits.
so what is front-end development?
This might be a silly thing to say, but first you should fully understand what a front-end guy does. Us front-end people, we limit ourselves to writing html, css and javascript. Flash is already borderline, but asking us to incorporate html code in a CMS system is not really part of our job description, so don't be offended if we give you a funny look. It's a skill that many of us have mastered though, but if you truly expect this from your future employee, it's probably best to list it as one of the main requirements right away.
And if you are specifically looking for a profile to incorporate front-end code in CMSes, make sure to find someone with a good feel for both front- and back-end coding. While many front-end developers have some experience with dropping their code in WordPress or Drupal, it's best to find someone who's had sufficient experience in both areas and willing to focus on this particular skill.
size matters
Not the size of your front-end developer mind, but the size of your own company. Before you start looking for people, consider what kind of profile you need for your company. There's a big difference between looking for a lone developer (who can tackle everything from html to javascript on small projects) compared to a team player (who can focus on one or two aspects of front-end, working on large-scale projects). If you're not interested in building a team of skilled front-end people, you should be looking for overall skills and the ability to balance quality across all three major aspects of front-end development.
If on the other hand you plan on building a team of experts, you should look for people who don't mind specializing a little. As a front-end developer you should definitely know the basics of all three fields, but it's not necessary to be able to execute all three. I for one don't feel very comfortable working on javascript-heavy projects, but I know the basics of good javascript code, being perfectly able to write html and css to go with the javascript. At the least, you should be able to find people who can recognize the quality of the code written in all three areas.
Finally, if you need to assign a team of 3 developers to 3 different projects, it's better to split responsibilities (html, css and javascript) and assign them as a team to all 3 projects, rather than giving them each a project and letting them do all html, css and javascript for a single project.
brainwash vs brainwar
Then there is the question of hiring a junior or senior profile. Both have their advantages and disadvantages and depending on your reason for hiring the outcome of your decision will be different.
Junior profiles are perfect if you are fortifying your team for the future. These profiles are easy to brainwash with your company's guidelines on quality coding and even though they are hardly billable at first, they will adapt quickly to the needs of your company. Junior profiles are best hired before the storm, when there is time to learn them about the tricks of the trade, not overwhelming them with stress and performance pressure. They will learn about that when their skills are sufficiently developed.
Senior profiles are perfect if you need quality output fast, without too much hassle. Sudden bursts in html and css work might require you to hire someone that knows what to do with a minimal amount of briefing and follow-ups. On the flipside, know that his ideals and preferred method of working might clash with your own quality standards. It's good to challenge your own standards once in a while, but make sure that you don't create schisms in your team and that you have one single person who has the power to decide when conflicts don't get resolved.
quality
It's hard to define the quality of someone's work, because we as an industry lack an extensive set of best practices. That's why you could probably use an internal document that lists your company's requirements for quality front-end code. If you don't have that, look for someone who has strong ideals and knows to defend them so he can make you such a document. Whatever the actual quality of your internal guidelines and whatever the critique from outsiders, just make sure you'll be able to stand behind your own ideals.
Also make sure to differentiate between html, css and javascript in this document, regulating just about anything you can regulate. This is easy when new guys join the company, ensuring standardized quality output that can easily be transferred to other developers.
do skills matter?
Well, yeah, of course skills matter, but know that most skills in our trade can be learned through experience. There is not much that cannot be learned through extensive reading and years of coding. You'd do better to look for certain characteristics in a person as this indicates how he can and probably will develop himself to become better at his job. Some of the more important characteristics are:
- Find someone with a clear opinion. Front-end work is quite messy, so if you hire someone who picks up ideas without critical reflection this will be reflected in the overall quality of his work.
- Find someone who writes clean code. This can also be taught through experience, but only to a certain degree. Make sure your front-end guy can stick to his own guidelines.
- Find someone who is willing to live by the general ideals of front-end development. HTML is not hard to learn, but it's much more difficult to understand. Find someone who is willing to invest the time to understand his job.
- Find someone who doesn't like to give up. Cutting corners is very easy in our profession because both clients and visitors will find it difficult to judge the actual quality job you've done, but providing sub-optimal work will no doubt have its revenge later on.
- Find someone who is dependent on his own skills. Don't believe people who'll tell you frameworks can solve everything.
there are no black, female nerds, right?
Finally, you're not hiring a demographic, you're hiring people. As long as they fit the profile, race, gender or any other personal, differentiating characteristic doesn't matter one single bit.
conclusion
If you want a front-end developer, start by deciding what kind of profile you're looking for. There are many people out there, with broad skills ranging from design to information architecture and html, but also front-end developers who like to specialize in a limited set of skills. One is not necessarily better than the other, but depending on the needs of your company it's good to know what kind of profile will fit your position best.
As for skills, examinations and questions are only profitable if you need someone good, fast. If you're looking for a long-term engagement, focus your attention on other things. And if all else fails, just depend on your gut feeling.
Comments
Kyle
What an excellent article, I start a new job as a front end developer in 2 weeks time. Im kind of stressing out though because my javascript coding is very novice, this is due to the fact that I've never really needed to use it that much in my previous job, I'm an extremely dedicated and motivated coder though and keen to learn whatever is required of me for the new job so I hope this stands me in good stead within the new company.
Allen
Interesting ideas, but I think you're being too limited in your initial accessment of what a front-end dev can/should do. In particular, I know that when I talk with other front-end people here at Google and at other tech. companies, they have no qualms about touching either Javascript, the CMS - or, in many company's cases, the custom Python/PHP/Rails server that runs the webapp. The ones with an engineering background can work up to the backend Java services and database layers, while the design-oriented ones can do the mocks and UI as well.
Of course, there's nothing wrong with concentrating and nailing HTML/CSS/JS, but I think to continue to grow you have to expand in either direction of the stack.
Niels Matthijs
Hi Allen, thanks for replying.
An interesting perspective no doubt, and I definitely agree that learning some javascript can only make you grow as a front-end dev, but I'm really not too sure about the rest. I'm a firm believer than if one person has too many conflicting responsibilities within one and the same project he will start compromising on quality in one job to make his other job easier.
These basic jobs (html,css, javascript) are continuously growing harder to master, so developing a broader skill set will ultimately lead to a lesser understanding of each separate skill.
I see you work at Google though, which as a company is usually more interested in performance rather than writing beautiful, flexible, correct and semantic front-end code. Now, performance is just another measure of quality and I do understand Google's choice to do so, but I also think that most front-end devs will have a hard time suppressing a little shiver when they take a look at the html/css of Google main search page.
I'd rather keep front-end and back-end development apart, bridged by a cross-over profile who has good knowledge of both fields.
Allen
Interesting perspective. I actually think the complete opposite - by understanding more layers of the tech stack, it makes writing core front-end code easier to write because you understand the implications of a front-end with regards to a backend, and saves you time from having to do unnecessary work or argue about what'd work.
My favorite example is the admin dashboard where the product manager and UI designer come up with some slick graphs for data. They take it to the front-end engineer, who tells them it'd be impossible without an expensive Flash graphing toolkit, and that still doesn't do the thing they want; then they take it to the backend guy, who tells them that the data they'd want lives on different databases and the JOIN operation would be much too expensive to compute on the fly like they want. In this case, wouldn't it be easier for a front-end eng, who knows the requirements but also all levels of the implementation, to internalize the issues and come up with something workable to begin with?
Niels Matthijs
Interesting example. First of all though, if you've still got front-end people running around who'd propose Flash for such a thing, it's probably best to replace them now :p. Then again, whatever technology you would choose to draw the graphs (html/js, canvas, Flash or any other available plugin/library), I don't see how that should matter to the back-end people. They just need to provide the data in a format both parties agreed on. And how the back-end guys assemble that data is really nothing front-end people should worry about. Whether they use JSON, on the fly generated XML files or pregenerated XML files, as long as the data is there, the front-end guy will use it to generate the graph.
Still, I've used to work on both sides of the fence for single projects too, and I know that it's often easier to match front-end and back-end code. The thing is that it's often easier for the developer, but never better for the quality of both front-end and back-end code.
I believe our difference in perspective lies with prioritizing aspects of our job. I have no idea what exactly you do at Google, but I can see that speed of development and website performance are important to you guys. I (or we - at the company I work for) put more focus on user experience, writing accessible and usable front-end code so as many users as possible have the best possible experience when visiting our pages. If back-end guys have more work or trouble implementing our suggested code, so be it, but that work needs to be done so people can have an optimal user experience.