I'm a Microsoft full stack developer (with a little Java and PHP thrown in) and this is what my experience has been...
Often it means that a company wants someone who can handle a project solo or almost solo, from designing the database to the middleware to the front end. This more common in corporate IT type situations than tech companies. This can be good or bad, depending on the management of the company and departments involved. At best, it can be a very rewarding project and job. At worst, it can lead to a rapid burnout.
Another scenario is that a full stack developer is a utility player, capable of fitting into any project where they're needed. This kind of developer needs to be a quick learner, able to get up to speed quickly. They won't be as knowledgeable as a specialist but are capable of making a significant contribution to a project quickly. They can also be effective in bringing different team members, or even teams, together since they have a generalist view.
The problem I've had with interviewing for what's been advertised as a "full stack developer" position is that interviewers tend to expect that you are a specialist at everything. That's not the case. Nobody can be that.
My name is Lewis Menelaws. I am a developer and entrepreneur located in Sarnia, Ontario focusing on creating great things for the web. Currently I am Lead Developer and Co-Founder of TMRRWinc.
In general, it's about the same so far as the corporate IT market goes. (I'm too old and uncool to be allowed to work for an actual tech company.)
Some specializations do command higher compensation due to their rarity in the market. This is usually a temporary situation since often the expertise becomes more common (for example: Angular, React) or that particular language/tool falls out of favor (Delphi, Powerbuilder). The specializations I've seen with longevity are ones with limited access to training and usage and that have a tight lock on corporate IT and finance organizations, such a SAP or IBM Websphere.
Listings for higher than average pay full stack positions may indicate a company looking for someone to dump a huge, probably impractical, workload onto. The position may be open because the previous developer burned out. They may also be looking for someone who can fulfill more of an architect or team lead role than an actual hands-on developer.
The best full stack jobs are those where you can be a utility player, bringing value across the board by being able to work well in any role. While you may not be the expert, you are able to get up to speed quickly and either augment the expert or fill the role sufficiently.
The problem I've had with interviewing for what's been advertised as a "full stack developer" position is that interviewers tend to expect that you are a specialist at everything. That's not the case. Nobody can be that.
This!
In my experience, a full-stack developer is expected to know everything about the front-end AND the back-end in web development, for instance. When this was possible in the past, nowadays it just does not make sense with all these big web applications that are usually built.
Specialize and focus on one part (again, in web development for instance) and you're much better off.
Not everything is a big web application, especially in the corporate IT world. There are a lot of legacy apps that need to be ported and many smaller, more narrowly focused, applications that are needed as well. As I mentioned, this is where a full stack developer can find a good fit, provided the management isn't awful and the expectations are realistic.
For example, if somebody hands an Angular specialist or a DBA a legacy, monolithically designed, ASP.NET application (or, even worse, a VB6 desktop app) and asks them to modernize it, they'll probably have trouble pulling it off. A well rounded full stack developer would be able to analyze it and break it into actionable items, even if they didn't necessarily do all the work themselves.
Is it a good career move to position yourself as a full stack developer today? Probably not, especially if you want to work in the cool tech company space rather than the corporate IT space. But, then again, what do you do when your preferred language/framework/database goes out of style?
It's always a good idea to have knowledge of all sides of an application to a certain degree. Of course, the "full-stack" developer is a good fit to modernize or fix any legacy application.
But as you already mentioned, nowadays it might be better to focus on a particular field. Looking beyond the horizon is a good idea, but again, just to a certain degree, I think. There are already so many technologies that want to distract you, better dive deep into the technology you like most.
And regarding your preferred language going out of style: This can happen to any technology. As a software developer, you should always have the skills to learn another language/framework/whatever. Again, let's have a look at web development. So many different languages and tools out there. But if you write your code in C# or Java (just an example!) should not matter. Switching technologies might take you some weeks. But then you know how it works.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm a Microsoft full stack developer (with a little Java and PHP thrown in) and this is what my experience has been...
Often it means that a company wants someone who can handle a project solo or almost solo, from designing the database to the middleware to the front end. This more common in corporate IT type situations than tech companies. This can be good or bad, depending on the management of the company and departments involved. At best, it can be a very rewarding project and job. At worst, it can lead to a rapid burnout.
Another scenario is that a full stack developer is a utility player, capable of fitting into any project where they're needed. This kind of developer needs to be a quick learner, able to get up to speed quickly. They won't be as knowledgeable as a specialist but are capable of making a significant contribution to a project quickly. They can also be effective in bringing different team members, or even teams, together since they have a generalist view.
The problem I've had with interviewing for what's been advertised as a "full stack developer" position is that interviewers tend to expect that you are a specialist at everything. That's not the case. Nobody can be that.
If you don't mind me asking, what's the pay like in comparison to more focused dev work? Not looking for specifics just an idea of comparison.
In general, it's about the same so far as the corporate IT market goes. (I'm too old and uncool to be allowed to work for an actual tech company.)
Some specializations do command higher compensation due to their rarity in the market. This is usually a temporary situation since often the expertise becomes more common (for example: Angular, React) or that particular language/tool falls out of favor (Delphi, Powerbuilder). The specializations I've seen with longevity are ones with limited access to training and usage and that have a tight lock on corporate IT and finance organizations, such a SAP or IBM Websphere.
Listings for higher than average pay full stack positions may indicate a company looking for someone to dump a huge, probably impractical, workload onto. The position may be open because the previous developer burned out. They may also be looking for someone who can fulfill more of an architect or team lead role than an actual hands-on developer.
The best full stack jobs are those where you can be a utility player, bringing value across the board by being able to work well in any role. While you may not be the expert, you are able to get up to speed quickly and either augment the expert or fill the role sufficiently.
This!
In my experience, a full-stack developer is expected to know everything about the front-end AND the back-end in web development, for instance. When this was possible in the past, nowadays it just does not make sense with all these big web applications that are usually built.
Specialize and focus on one part (again, in web development for instance) and you're much better off.
Not everything is a big web application, especially in the corporate IT world. There are a lot of legacy apps that need to be ported and many smaller, more narrowly focused, applications that are needed as well. As I mentioned, this is where a full stack developer can find a good fit, provided the management isn't awful and the expectations are realistic.
For example, if somebody hands an Angular specialist or a DBA a legacy, monolithically designed, ASP.NET application (or, even worse, a VB6 desktop app) and asks them to modernize it, they'll probably have trouble pulling it off. A well rounded full stack developer would be able to analyze it and break it into actionable items, even if they didn't necessarily do all the work themselves.
Is it a good career move to position yourself as a full stack developer today? Probably not, especially if you want to work in the cool tech company space rather than the corporate IT space. But, then again, what do you do when your preferred language/framework/database goes out of style?
It's always a good idea to have knowledge of all sides of an application to a certain degree. Of course, the "full-stack" developer is a good fit to modernize or fix any legacy application.
But as you already mentioned, nowadays it might be better to focus on a particular field. Looking beyond the horizon is a good idea, but again, just to a certain degree, I think. There are already so many technologies that want to distract you, better dive deep into the technology you like most.
And regarding your preferred language going out of style: This can happen to any technology. As a software developer, you should always have the skills to learn another language/framework/whatever. Again, let's have a look at web development. So many different languages and tools out there. But if you write your code in C# or Java (just an example!) should not matter. Switching technologies might take you some weeks. But then you know how it works.