What does full stack engineering mean to you?

How long have you been working as a dev for?

I considered myself full stack for about 4 years. Near the end of the 4 years and beginning of my 5th year coding I started to shift to primarily backend work. Over the last year and a half I have gone from being a Software Engineer to a Site Reliability Engineer and have really started to solely focus on the backend. Whenever I decide to apply for a new job I will likely not apply as a fullstack engineer but as someone who wants to only work on the backend. I can still find my way around Javascript and CSS but not nearly as well as I used to.

In terms of interviewing, we give fullstack engineers a basic Ruby problem. Honestly, we don't really focus on asking them any frontend questions, its mostly general backend stuff. Kinda has me thinking now 🤔 I guess, besides our designers, we figure more people who brand themselves fullstack can work decently enough with front end technologies but we don't need them to be rockstars at it. Some of our fullstack devs kinda morphed into frontend rockstars so we are really fine with those who just have general frontend knowledge.

Also, this post is extremely fitting bc one of my mentee's and I just had a conversation about what makes a full stack engineer! I was actually going to do my own post on it but you beat me to it 😉

I think a good full stack developer needs three things:

1. Expertise in at least one frontend and one backend technology (could also be a hybrid framework like RoR) with a solid grasp on frontend fundamentals (HTML, CSS, JavaScript) and some experience with basic operations tools (Heroku, AWS, etc.)
2. A broad knowledge of the current landscape of web development and a general understanding of the many tools out there and their purposes (even if they haven’t used all of them.)
3. The ability to quickly learn how to use new tools to put something together.

That’s it. #3 is the most important.

Put another way, full stack developers should be confident with a few development tools, know enough about a lot of the tools available to them to identify when one of those tools would be beneficial to use, and be comfortable quickly learning those tools when the need arises.

I also don’t like the term full stack developer and second what Kasey said; I think everyone should just be labeled a developer with a few key specialties, and then figure out their own unique role within a company or team as time goes on.

Oh, and I think the list above applies to all web developers, not just full stack.

We are a small company. Developers might work on any side (front, back, customer, build/deploy, ops) when implementing a feature. So we don't really have a concept of full stack (vs not full-stack). The role is just "developer". For fresh developers, we start them on the front-end-only before they branch out.

We put them on front-end only because the tools we use for UI (MVU either in Elm or F# Elmish) are pretty beginner-safe. Early mistakes are normal and we are ok with them because we know we can fix them cheaply later. It also doesn't require as deep of a non-transferable investment as front end frameworks typically do.

There is a beautiful quote, from a book of Robert Heinlein, which - with minor edits - provides a pretty decent job description:

"A human being developer should be able to change a diaper the appearance of an HTML element with CSS, plan an invasion a normalized database schema, butcher a hog the tech interview, conn a ship a docker image, design a building REST API, write a sonnet unit test, balance accounts ever changing requirements, build a wall the application with a single command, set [up] a bone CI, comfort the dying project management, take orders [but not at face value or too seriously], give orders reliable estimates, cooperate, act alone, solve equations, analyse a new problem, pitch manure ideas, program a computer [well, duh...], cook a tasty meal, fight debug efficiently, die gallantly. Specialization is for insects."

But jokes aside, there is not one stack, there are dozens and dozens of them. Some folks around here might even maintain (or, heavens forbid, even build new) non-web desktop applications. Keep in mind, not every technology fosters a very clear separation of the conceptual layers of a software system. I know that first hand since I've spent a major part of my career in migrating a system that started out with a 2-tier (a classical fat client) to a 3-tier architecture with a mainly (but not exclusively) web-technology based UI. Building a system end-to-end with a single technology is, in my books at last, equally full stack as juggling with a dozend moving parts.

So, what is fair game for interviewing (full stack) developers? While I dislike whiteboard interview, i think probing for basic compentence is okay. For example, in my department, we have a printout which contain a selection of snippets which goes from very basic, over familiar with new(-ish) concepts, to rather intimate knowledge of the JVM, that we use in interviews. It serves well to weed out the candidates that lack even the most basic knowledge, but generally, after this part of the interview (not more than 5-10 minutes out of an hour), the conversation gets more conceptual.

Hmmm...That's really a tough question for me, I feel that being a generalist as a full stack developer is a great position if you plan to not be an independent contributor.

Since you draw from a wide range of specialisations (mental models) to solve a problem.

I believe that being a generalist has its perks in being able to communicate with a specialist to formulate a better solution to solve a problem.

Without being dogmatic in your approach by drawing from these mental models which are similar to how minds of Steve Jobs, Elon Musk or Jeff Bezos create product or services using it.

In terms of interview process or questions, we tend to ask them questions related to their specific specialisation of technologies or programming language that they had been working with.

Besides our culture questions that focus on looking for curiosity and adaptability in the individual.

Lastly, in terms of the technical test, we tend to give the interviewee assignments in the technology that they are familiar with that is a small part of what we do in the startup and building of bash scripts in Linux.

To me it is less about the skills you need and more about your areas of responsibility. It's ridiculous to expect one person to be an expert from A-Z. However, communicating that the developers may need to work in A-Z and more importantly are responsible for every aspect of it helps set the right tone -- assuming that's the tone you want to take for your company.

The advantage to "full stack" is that when something breaks the folks that are well versed in the backend and the folks that are amazing front end all step up to solve the problem vs the old not-my-problem attitude when the roles are clearly defined.

Our company hires full stack devs but it's clearly understood that people will have a specialty and favorites.

I honestly try to avoid the term, or at least I wouldn't call myself one even if I fit the definition. General knowledge of the server and client definitely qualifies. I suppose we need a lot of people who can effectively do all tasks "okay" but have one thing that they are exceptionally capable.

This is a viewpoint from Business Owner/Recruiter I agree with: hackernoon.com/the-backendificatio... there is no real "Fullstack" engineer or very rare they are only generalist ;)