A colleague pointed me to an interesting article by a senior Yahoo front-end engineer. It goes through what companies need to do to hire “great FE engineers”, that A developers are attracted by other A players but more importantly, companies need to foster an environment friendly to front-end web processes, from an attention to design to respect for the profession.
I agree in principle, but I believe reality makes this task incredibly hard and infeasible, save for a few unique firms. I’ve posited that it’s easier to train a FE team and onboard backend web devs than to try to build one via hiring: having been the primary and secondary1 FE across four companies, most are not equipped to make good use of a front-end team, and conversely, most candidates would not be able to fit into the work environment.
Lemme present the perspective from the other side.
HTML, CSS, and Javascript
Many of the FEs I talk with are undoubtedly strong performers in their chosen profession. They know how the web works, understand the in’s-and-out’s of a browser’s rendering quirks, and build webpages with brutal efficiency and style.
Many also outright refuse to venture outside of the their sandbox.
Now, I’d be the first to advocate fairer front-end engineering interviews; it’s frustrating, for both the interviewer and the interviewee, to go through questions that are completely mismatched to the candidate’s skillset. Front-end competency isn’t well-measured by traditional engineering metrics, and our computer-science-heavy interview culture has maligned and soured too many good developers.
The flip side, though, is that we should have a curiosity about the underlying systems that run the websites build, and we should not be exempt from being scrappy and getting things done regardless of language or platform. The browser has become a comfortable default, and I’ve encountered too many FE candidates who don’t want anything to do with a server or have opinions on design and product but stop short of taking the responsibility of designing or researching the product.
Perversely, we take pride in quizzing each other in esoteric knowledge which has defined the profession for the past decade. What has been an unfortunate effect of the lack of standardization has instead become an important qualification2.
Sporadic, but intense work
All that said, there is a place for front-end specialists, those who are focused on honing their craft and furthering their niche. In that role, however, FE engineers are inexplicably bound by a pair of dependencies: they cannot start working until the comps from design and the systems from the system engs are ready. Often, by the time the pieces are set for the FE specialist to roll up his or her sleeve and crank through the half-dozen pages, a hard deadline and a couple of API delays result in hard sprints to the finish line.
It’s not a surprise that the vast majority of startups and mid-sized companies have trouble justifying a front-end team given a lack of constant work, and without a team it becomes unreasonable to cater to front-end candidates. If a company has pure HTML/CSS/JS talent, it seems be just one engineer, responsible for the non-trivial parts of the company’s webpages.
Startups are, by and large, not mature enough to hire more than one or two great FE specialists over generalists, and big companies who did not start with strong FE cultures are too big to develop the necessary discipline. Watching Paypal attempt to pivot its engineering barge to “focus on design” has been amusing3, and if my LinkedIn inbox is any indication, companies – startups, mid-sized, and big public ones alike – want to make just a handful of hires to magically fix all their front-end issues.
Digging out of a niche
Front-end expertise has always been a rare talent; only recently has it also been a skill that is sought after from engineering organizations. FE engineers are a strange fit with other engineering disciplines, and often constitute a small percentage of a team’s headcount, even if their work is what’s most readily visible.
And while companies can certainly do more to attract front-end talent, the reverse is also valid: FE web developers can do more to make themselves more appealing to engineering organizations, by taking on more of the tech stack and perhaps even some design and product functions en route to becoming that mythical designineer. Pursuing front-end depth results in experiments like CSS-only graphics, but legitimate breadth of knowledge makes for more impact and opportunity.
I was chronologically bested by one Beau Smith when I arrived at Square.↩
This list of FE interview questions is not a good way to hire a productive engineer.↩
Yes, of course I’m biased.↩
Your links to the mythical designineer and CSS-only graphics needs some fixing… they have double http:/http:// Enjoyed the article though as it talks to what I’ve experience in my projects here. We’ve had open reqs for FE engineer types open for 2 years, and only just recently filled one, by me switching from being called an engineer into more of a designineer role (like that article and term too)
Thanks for the heads up. This is what happens why I try to edit a post in WP’s editor instead of out of Markdown.
Hi Allen, I’m the author of the blog post you linked to. Great points here, and I agree with most of them. Your points about most companies not being able to support specialist FE teams is particularly revealing of my biases – as I’ve mostly worked in larger companies myself. From a smaller company’s vantage point, I think it completely makes sense to hire generalists over specialists.
That being said, I think often times it’s not that FEs don’t want to move out of their sandbox. Rather, it’s just a longing to want to work on stuff they love – and you can’t fault FEs for wanting to work on, well, FE. I think great FEs are well attuned to solving problems while considering the “full stack”, as you allude to here. These are the ones that will be more than happy to learn new tech and new solutions that can somehow enable better user experiences. In my opinion, anybody else who is unwilling to move out of the browser tends to be more of a JS hacker/monkey than a great FE.
Lastly, I’d just like to mention that even at large companies, it’s almost never the case that FEs begin work only when the comps and designs are done. As with most SDLC, work begins as early as possible regardless of the current state of requirement lockdown. This results in a bit of a back and forth between engineering/product, and this is where you can truly separate the wheat from the chaff. A good FE (as good BEs do) are able to create and design implementations that are flexible enough to accomodate future changes, while making just enough assumptions about the current state of the UX/UI requirements to get the ball rolling. It’s a tricky dance, and something that can really only be gained through experience, IMHO.