How to get Front-End Developers

Javascript has won the internet. It beat out Actionscript/Flex in mobile, while a new breed of MVC, client-side frameworks are taking over jobs that used to employ server-side code (e.g., your Rails’s, Djangos, and CakePHPs). For the first time, Javascript is popular for more than its copy-paste-ability into an HTML document.

Which means that there’s a much higher demand for front-end web developers. I was casually browsing the HireSF boards when I saw the listings for front-end engineering – I’m guessing companies are having even a tougher time hiring for this position now than in the past1. Previously, I had a theory: most companies didn’t need a FE-focused engineer to tie together design and engineering until its product reached a certain level of maturity. With today’s startups, though, design has become a differentiating factor and a competitive advantage, and I’d argue that a FE dev fits in any company that wants to do things on the web (so, every company).

It’s been nigh impossible to nail down a definitive job description for front-end engineering, but the things I look for:

• Good eye for design,
• Great HTML, CSS and JS knowledge,
• Good understanding of backend systems and frameworks; can code an API endpoint,
• Can collaborate well with product, design and engineering.

Evidently these people don’t exist, which would explain why it’s been such a difficult position to hire. The candidates I talk to comprise two distinct flavors:

• Developers from a design background – possibly frustrated by engineering messing with their perfect comps – decide to code their own designs. These are the pixel perfectionists; they care about their HTML and CSS, can fiddle with animations for hours, and are fluent in design tools and lingo.
• Developers from an engineering background, who see the potential to write powerful, clean client apps in the browser. Somehow, almost every engineer I meet who fit this category are ex-Rails devs; they’re competent, technical people, up to date with the latest open source practices and methodologies, whose canvas just happens to be Javascript.

Front-end work is irregular in nature – much of the interesting work is gated by design – so companies typically do not have full-time FE devs. As most are consultants, they don’t do well in interviews: they’re typecast into generalist engineers and forced to talk with interviewers with backend engineering experience on unfamiliar systems2.

When looking for a FE eng, start by determining what needs to be built, then cater the requirements and the work to either type of engineer. Design-centric devs, unsurprisingly, work well with good designers3 who can push their skills to create innovative UIs. Eng-centric devs do best when they’re tasked with building mobile or desktop-level apps in the browser, the famed single-page web application4.

From there, I feel like the easiest way to build out a FE team is then to convert other engineers and designers into the discipline. Honestly, HTML/CSS/Javascript is not hard to learn, but people get turned off when they encounter the browser blackbox, with its seemingly countless and arbitrary rules for deciding how code renders into a webpage. Someone who understands these rules can guide others to make front-end development a lot less daunting and much more enjoyable, and I’ve had my share of success helping other designers and engineers alike enjoy building user-facing features.

Building an engineering team is already hard; building one around a rare skillset is harder still. It means hiring one or two individuals who then transfer their knowledge to other engineers and grow out the team organically. And once the team proves itself by producing products with great UI, that only helps attract more great front-end people.