DEV Community

Amanda Sopkin
Amanda Sopkin

Posted on

What does full stack engineering mean to you?

I entered the software engineering world as a full-stack engineer, a generalist expected to be able to work on a variety tasks from the low-level to high-level and anywhere in between.

Now, as I continue my software journey I find myself wondering if I continue to fit that mold. There are benefits to specializing in the software world, experts in Android, React and countless other technical subjects are able to reach a greater depth and often rise to higher levels as experts in their field.

On the other hand, while it may be more difficult to gain expertise in the general field of full-stack engineering, most companies are looking for full-stack/general software engineers--gobs of them.

In my case, I prefer backend engineering, but wonder if it's too early to specialize. Since particularly for less-experienced engineers, most companies want people that can pick up whatever task you might give them.

When it comes to interviewing, many engineers are divided on the subject. Some see full-stack engineering as an invitation to ask any question, some specific, some broad. Others believe that asking highly specialized front-end questions, like how to style something in CSS, is unfair for a full-stack engineer. Just this week I screened a candidate who was concerned about what kinds of questions might be asked for a full-stack engineer. General front-end questions or more specific?

What about you? What interview questions do you find appropriate for a full-stack engineer? If you moved from full-stack engineering to something more specialized, how did it go?

pancakes
Source: Giphy.com

Top comments (14)

Collapse
 
molly profile image
Molly Struve (she/her)

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 πŸ˜‰

Collapse
 
amandasopkin profile image
Amanda Sopkin

Thanks for the response! I've been a dev for a couple years, but I should probably keep my knowledge full-stack before specializing after some more time. And that's hysterical, great minds think alike I guess?

Collapse
 
joshhadik profile image
Josh Hadik • Edited

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.

Collapse
 
solkimicreb profile image
Miklos Bertalan

You made me remove the word full-stack from my bio here. 😎

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

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.

Collapse
 
attilavago profile image
Attila Vago

Not entirely sure why front-end is still regarded as suitable for more juniors than seniors. In today's development landscape I think they're both equally complex. I also see a lot of developers being pushed into front-end and they end up hating web dev as a whole because of having to deal with layouts, design and browser inconsistencies, whereas on the back-end they wouldn't have to and might feel a lot more productive.

Collapse
 
kspeakman profile image
Kasey Speakman

Since we have hired devs with no previous experience, and since we use MVU, front end is a very safe entrypoint to just learn to dev. The normal mistakes you make while learning are not overly penalized later... it takes some of the pressure off. Ultimately, the goal is to get our devs to have broad experience. And so far there is not enough of us to go around to specialize in only one area anyway.

Collapse
 
fnh profile image
Fabian Holzer • Edited

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.

Collapse
 
gabek profile image
Gabe Kangas

Some folks around here might even maintain (or, heavens forbid, even build new) non-web desktop applications

It's comments like this that make me laugh when most people say "full stack". They really mean "Server side web and client side web".

The best applications aren't on the web, and you need to be truly "full stack" to build them.

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao • Edited

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.

Collapse
 
phallstrom profile image
Philip Hallstrom

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.

Collapse
 
jacksonelfers profile image
Jackson Elfers

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.

Collapse
 
lepinekong profile image
lepinekong

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 ;)

Collapse
 
lepinekong profile image
lepinekong

You'd better not stay generalist for too long but look at the trend and specialize every 5 years. For example if you like backend nodejs is good choice, if it was front end react and vuejs.