Too often I find "full-stack" developers who only know how frameworks operate, but have no idea about how the computer actually works.

"How do you do [x] in SQL?" > "I've always had the ORM handle that"

"How do you do [x] in CSS" > "I use this CSS framework and it will do it for me"

"How does a packet get between the front end and back end of your solution" > "I update the object state using [x] in the [y] framework"

Perhaps there's a reason why. The market generally doesn't need people who can do it all. In the same way it doesn't need people writing C++ or Rust to know how to write machine code or assembly. Sure, the ones that can are probably more knowledgable, but their experience with the high level language is more important.

I've done full-stack with no frameworks or non-std libraries (aside from PDO and OpenSSL, the limitations set by CEO decree) for about 8 years now.

I write my own schemas in IBM Db2. Hell, I wrote small application databases in IBM DDS in the AS400's SEU while I was still under the legal drinking age. I've always written our stylesheets from scratch, using SCSS. I've written C++ APIs that run in PASE, talk to the database with ODBC, then send back to a front end through sockets. I do graphic design and photography -- something I started back in middle school and took some formal classes on -- and have led the creation of marketing materials for multiple subsidiaries. I've spent 40 hour weeks working on sysadmin tasks in vim, 40 hour weeks writing libraries in JetBrains and VSCode, and 40 hour weeks working running around with my DSLR or working in Photoshop, Illustrator, and InDesign.

But when I look for full-stack jobs, most of them actually want somebody who is well versed in a framework. There's not much point in doing all of this from scratch. It's more tedious, more error prone, and it takes longer to get to market. Some interviewers have given the impression that I'm a little "less than" because I haven't used any major frameworks.

I think that's actually a valid take, and it's something I've started doing side projects to address. Frameworks improve velocity. Frameworks improve reliability. They reduce the risk of a developer coming up with an out-in-the-weeds solution to a problem they didn't properly understand. They make it easier to maintain the code. They make it easier to onboard new developers who are familiar with that tech.

I once did a take-home project for a full stack role that proclaimed any language/framework could be used to build a browser-based application that satisfied a particular task. I opted to use golang and its standard library to produce an application with no external dependencies and no javascript. In the rejection email they stated the use of outdated development methods was a point of disqualification. I'm sure other reasons for disqualification were present, I wasn't a great candidate in retrospect, but I'll never forget the naivety and hubris of their framing.

They were of course a NextJS shop.

Ultimately disregard role titles. It's a people problem that you have to pull teeth to find out what they really want, and what they really want they often won't say out loud. That's fine, it's their money (and usually a lot of it!) and they should be able to dictate the services that they want.

Really sucks for people new to the industry trying to learn the song and dance.

Sounds like you dodged a bullet in terms of culture mismatch. I think a good number of these mismatches could be mitigated by having some in-depth conversations about the job, team, interactions with other teams, and problem scope, before getting into any technical interviewing.

I think it is valid to expect some experience with major frameworks, but framework experience without understanding the underlying concepts usually indicates someone who is pretty limited in being able to solve more difficult problems.

I guess larger organizations have a role for these kinds of workers, but they’re not the kind of people I want on my team.

This is an exceptionally good question to identify people who have actually used a technology for real. I've used merely the second part ("what gripes do you have about X") in interviews successfully for nearly two decades.

If you've used a tool long enough, you've identified warts and misfeatures. And you will have opinions about them.

I always wonder how much that is influenced by the blog / social media world where a few (or even one) neat features in a product or language produces "I love this". So yeah they love it ... in so far as the social media expression goes.

I feel that’s more of an artifact of American culture. I remember discussions where the stakeholder declined to use a technology, and said something like “we love X, but are concerned about Y.”