There is a bias toward backend engineers at the principal engineer level. This leaves frontend engineers heavily disadvantaged when it comes to promotion time.
When someone says they’re a fullstack engineer, what they usually mean is one of two things: 1) They’re a coding bootcamp grad that has minimal experience with Node.js and an emphasis on the frontend. Or, 2) they’re an experienced backend engineer that knows a little bit of HTML and CSS. A truly fullstack software engineer is a rare find.
That being said, principal engineer job requirements focus almost entirely on backend engineering skills. The companies I’ve worked for in the past have had requirements for expertise in areas like networking, system design, database design, building scalable microservice architecture, or designing fault-tolerant systems.
And while all those things are important, especially for someone at a principal level with a backend emphasis, these lists of requirements are often missing many skills that may be unique to frontend engineers but that are equally important.
Valuable Frontend Skills for Principal Engineers
What about the ability to build scalable design systems? Are you able to build atomic-level components that can be built up into molecules, organisms, templates, and eventually pages? Do you understand what should or should not be included in a design system’s component library? Do you understand how to provide clear design constraints to create a consistent UI while also allowing for flexibility in the usage of your components?
What about the ability to build accessible web applications? Accessibility is an often-overlooked skill but one that is becoming increasingly important, especially for software as a service companies in a competitive market. Are you able to build apps that conform to the WCAG 2.1 AA specifications? Do you understand basic design principles and common UX patterns for various widgets? What’s fascinating about accessibility is that so much of it is provided for you, right out of the box, with HTML. Yet most developers don’t create widgets that are operable using a mouse, a keyboard, and a screen reader, opting instead to focus on mouse users only and to ignore common UX patterns.
What about the ability to think clearly about microinteractions in the app? Are you able to create a seamless user experience that keeps users from becoming disoriented? Are you good at thinking through edge cases in how widgets function? Do you have a good design sense? Do you practice inclusive design? Piggybacking off of the previous paragraph, so much of accessibility is really just usability.
What about the ability to optimize performance on the frontend? Do you understand how dev, peer, and regular dependencies work? Do you understand how to optimize bundle size for your frontend app and how to avoid downloading the same resources multiple times?
Conclusion and Invitation
These kinds of skills and many more are extremely important in frontend architecture, and yet they are rarely included in skills requirements for principal engineers.
My advice to engineering leadership everywhere is to look for the valuable skills that frontend engineers bring to the table and find ways to include those skill sets in your requirements for promotions, especially for those positions at higher levels.
Top comments (18)
Front end skills are so often thought of as both beginner skills and "too hard to even bother with, lol" among a lot of the developer culture.
It can't be both for beginners and so hard that it's not worth doing. There's a stigma-oriented misalignment.
Interesting..I would say that there is a bias towards frontend engineers in the whole webdev area. I understand that YMMV, but this is my mileage. Sure, FE can be a fine principal engineer, but generally I would say it's not a trend that FEs are neglected.
Yeah, this has been my experience as well. There are far more front-end engineers at my company than any other kind of engineer (back-end, SRE, QA) by an almost 3-to-1 ratio. Everybody loves doing React and Vue, very little interest in digging into the GraphQL or REST back-ends. That's always reserved for a "specialist" or "Sarah does that for us".
Guessing that Principle Engineer is a more general position than specifically front or back end, I think you basically answer your own question. The position values general software engineering skills, like "networking, system design, database design, [...] or designing fault-tolerant systems". While, for the most part, the front end skills you bolded are just that, front end skills.
Don't get me wrong, I've focused on GUI design and development for the majority of my career, so I value UI skills very highly, but web accessibility, design concepts like microinteractions, and front end performance as skills aren't very portable outside the (mostly web) front end.
and networking & fault tolerance isn't portable outside backend
I would disagree here. Networking is very important if you build highly interactive multi-user front-end experiences. You MUST know networking, timing, interpolation, and queuing theory to properly build the client. This is a vital part of our front-end that heavily uses web sockets. It's also what you see being a big part of web-UI based mobile games or web UI's interacting with large worker queues or data visualization.
As for fault tolerance, as the infra scales, load balancing in the backend and the caching involved makes the client now have to be capable of handling these issues as well. What does your client do when the cache isn't hot and loaded? What happens when you're loading from an edge API as well as a more remote (less hot) API? A lot of this stuff is client side code and very relevant for a senior level front-end engineer to know!
What I'm getting at is that all of this knowledge and these skills cross the front-end and back-end barrier if you go up high enough in your career. The more responsibility you take on, regardless of background, the more you are required to learn and know!
I agree with all this
Thanks for reading, Ben!
Some of full-stack developers I know came from freelancing as a one-person band, myself included. It's hard, sometimes impossible, but inevitably teaches you the value of diversity.
I definitely see a dedicated front end developer in charge of consumer oriented product as a much better fit than a backend. But then a backend would be a better fit for a purely technical B2B company.
And I certainly agree that front-end is not by any means simpler, or, in the words of my fellow mobile developer: "It's pretty much the same, but you don't need to care about the view"
Points 2 and 3 are probably ignored in the case of companies with a dedicated UI/UX design team/person, where they want the front end dev to just implement the design. But other than that I totally agree that's way more useful than being able to solve the knapsack problem
Right now one of the biggest problems that businesses are concerned about is scalability, data is increasing and the bottleneck is usually the backend infrastructure. Ex, doesn't matter how good YouTube's UI is if videos don't load.
Because of this businesses put UX in the back burner, using pre built solutions and cutting as many edges as they can, heck they even do that with the backend. The backend is just the first point of improvement they focus on once they realize their business can't function anymore with a subpar product.
And even in design focused companies, what that usually translates to is hiring more designers, better UI mockups and design systems. Frontend engineers are mostly just treated like code monkeys that have to translate those designers into the product directly. No code level implementations of design systems, accessibility reviews, standard compliance, etc.
I agree. But there are companies which have separate teams for FE and BE engineers. There the leads for front end are usually specialist only on FE side. Same goes for BE.
What I would say is that there are less companies which have separate teams. Most of the companies just try to get "FULL STACK"
What's missing here is the concept of a T shaped developer.
Think of the vertical line as a deep understanding of a single area like front end (design, components, accessibility, responsive, UX etc), networks (routing, spanning trees, redundancy, capacity, monitoring, etc), databases (structure, scale, transactions, sql/nosql, redundancy, scalability, monitoring, consistency, etc. ), micro services (api, server/serverless, messaging, events, scalability, availability etc) , cloud infrastructure, etc... Every area has more depth than most people appreciate.
Now the horizontal line is breadth of skills which are not so deep, so the backend dev who knows about HTML, CSS, and JavaScript may come across more T shaped.
My advice is don't over emphasis your depth in a single area and work on developing the wider skills. Remember as a good senior it's more about working with a skilled team who have depths you do not and not so much about being better than your peers.
If you are in even in semi-big corp you are hired to do one specific thing. If thats frontend you are missing most of the info about BE because well its not necessary to be part of those meetings / watercooler discussions.
That being said If company has its core business in the backend (which in most cases it is), BE sr. dev is more likely to be chosen as Principal.