Some people would argue that “full-stack” is a misnomer, that nobody can really know the whole stack. And of course I agree, in the sense that to know all levels, from quantum effects to CSS, with an expertise that allows you to write the reference text on the topic, is completely unrealistic.
But for those who developed an intuition for the interaction between the layers, and who are not afraid to dive into the source code even if it’s the kernel, full-stack is a frame of mind.
It means you are always willing to help improve things, even if the problem in question is not in the area of expertise printed on your badge. “Not my department” becomes “I don’t know, but I will find out”.
When you are ready to learn more about the work happening around you, the team will benefit immensely from deeper integration.
<Insert di Caprio Inception meme with squinting eyes.>
Every team draws the line somewhere. For example, if you are deploying functions-as-a-service on AWS Lambda, your stack has a defined bottom. Your insight into AWS will always be limited.
On the other hand, if your are like the fine folks at Oxide, your stack is a tower and you operate the elevator from the car park to the penthouse.
I think you can guess which approach is more my jam.
Full-stack for me conveys a flexibility in the role I can take in a team. Need a frontend person reifying pixel-accurate styles from Figma, XD, or Photoshop? I can do that. Need someone to create a resilient API to a vendor system? I can to that too. I will even play the role of system administrator, because I care about security and integrity.
If any of this resonated with you, check out my CV and see if I can fit into your team.