Why everyone is looking for fullstack engineers

In the last couple of years, demand for full-stack engineers went out of control.

It’s hard to put it into numbers, because many roles defined as backend require frontend skills, and many frontend roles require backend skills.

In practice, it’s even more mixed because many companies prefer engineers that are able to deploy their own code, so whatever the role they’d need some DevOps skills too.

It never made much sense to me. You don’t want your frontend engineers write backend code, let alone CI/CD pipelines. You don’t want backends writing frontend either, these jobs require different mindsets and soft skills.

Frontends are competent in UI, UX and design, which is why they are so good at frontend engineering. Backends seldom have these skills. They are stronger in security and software architecture, which is why they are so good at the backend engineering.

Why are some many companies looking for full-stack engineers?

The origin of full-stack engineering

The idea of full-stack engineering has a precise birth date: 27 May, 2009, the day Node.js was released.

Node.js was created to let engineers use the same language in both frontend and backend - full-stack engineering. JavaScript was the only language that could run natively in browsers, so they figured out a way to run JavaScript on servers, as backend.

It was invented with a specific scenario in mind: small companies that didn’t have a need for different kinds of engineers. We’re talking about companies with 3-4 engineers, for which Node.js was an improvement of their existing workflow.

Instead of hiring backend engineers that knew JavaScript, they’d could just hire JavaScript developers and have them work in the backend.

Why not the other way around? It was unlikely that a frontend would dip into backend, as they were more interested in UI and UX. Infact, frontends were usually designers that ended up learning JavaScript. Sometimes they would learn PHP, and get familiar with WordPress and others, to make complete websites.

The idea of bridging the gap between frontend and backend was not a new one. Java and Python had been trying to do the same, in the other direction: write backend code that runs in browsers. They weren’t very successful.

Node.js was an instant success and plenty of frameworks and libraries for full-stack development were written. It also brought JavaScript developers into backend development, but the results were mixed.

Node.js developers are still known for their messy coding and focus on speed vs quality, a strategy that worked for frontend but was problematic for backend engineering.

The benefits of full-stack engineers

For small companies, there was a clear benefit in hiring full-stack engineers. However, as it often happens in software enginering, managers forgot, or never cared to do a technical assessment on why full-stack works for small companies but is problematic for larger businesses.

At small companies, there isn’t enough workload to keep specialized engineers busy. If one engineer is not available, they’d have to stop development.

Larger companies deal with sophisticated projects that require high security and performance, on top of being under additional scrutiny from large customers and regulators.

Minimising bugs and lowering long-term development costs require specialized engineers, as it’s the deeper understanding of their part of the stack that enables them to engineer better solutions.

Full-stack proliferation

Over time, full-stack’s meaning was widened and deepened. From JavaScript engineers that work on frontend and backend, to any engineer that does so and deepened to include DevOps and UI/UX work.

Higher demand brings higher salaries and wider skillset means more engineers could apply to full-stack roles.

Does the hiring manager need a backend/DevOps with some frontend or do they prefer backend/frontend with some DevOps? Without knowing, evaluating full-stack candidates can be a nightmare.

Managers rarely have clear ideas on what they’re looking for and rely on feedback from senior engineers, which know even less about what the company needs. Under this light, hiring a full-stack is seen as low risk.

Regardless of the engineering needs, they can put full-stacks on the project and pretend to have it covered. If that’s not enough, they can hire more, a win-win scenario: they can put on their resume they managed more people and upsell themselves as an effective manager.

After all who would you hire for a managing role, a manager of a 5 or manager of 30? The manager of 5 might have a good success story, but at most companies the main decision criteria is hype.

A growing number of managers and CTO are becoming convinced that an engineer should be able to do everything from DevOps to frontend. And that’s again something that can work at a small company, but becomes an unrealistic expectation for mid-sized companies.

Evaluating full-stack engineers

So, you have a full-stack role and need to figure out who’s who. The easiest way is to understand what kind of full-stack the hiring manager wants.

There are two kinds: frontenders that have learnt to write backend code and backenders that have learnt to write frontend.

A good full-stack has to have a few years of experience, as most engineers start as either backend or frontend and add to other part when they’re confident of their initial domain. And no, junior full-stack doesn’t make sense.

Understanding which full-stack candidates are a better fit, will never be straightforward. By definition a full-stack role means the company isn’t sure about who they need, and it will be down to who they like best.

Reminding the candidates to do the interviews with good lighting might be the best plan to get them hired.