Manager at a FAANG here. It sounds like you’ve been mostly talking to people at small companies who use terms like “code ninja.” I have no idea what they’re looking for, and I honestly doubt they do, either.

What I’m looking for is someone who can help me solve the problems that I have and that will be coming up. A candidate should be able to answer some basic questions about the programming language(s) they claim to know if they’re relevant to what I need (sometimes people will simply list everything they’ve heard of in an attempt to game resume scanners). They should be able to whiteboard an algorithm (like an elevator controller) on the fly and explain their thinking on it. They should be able to walk me through their resume work history and explain the projects they listed, as well as detailing their roles. I want to know who made the decisions on the project - the tech, architecture, implementation, and so on. I want to know what the candidate did, and what they’d do differently knowing what they now know. If they lost publications, I’m going to do the same (and I might skim at least the abstract). Basically I’m looking for someone I can be working with for at least the next five years, and who can continue to learn and grow.

Oh, and don’t list emacs (or in one notable case, “emax”) as a technical skill.

Almost like as if people are looking to hire a one-man army to handle the entire department.

Not a hiring manager or a recruiter, but that’s exactly what full stack entails in most places. A company that’s looking for full stack is likely to be small and require wide skills. Otherwise, they would have dedicated teams for frontend/backend/devops.

If you want to avoid that, I’d recommend building a focus on frontend or backend (or devops/infra/sysadmin) depending on what you like more. I decided early on that I wanted to do backend, and I focused on projects and job applications that complimented my skillset. In my career, I’ve done work all across the stack (infra, frontend, backend) but I’d never call myself fullstack.

I like backend because it encompasses anything that’s not UI. Terminal applications, games, web APIs, FOSS contributions… All transferrable to backend skills. The rest of it is learning whatever web framework your company uses to build their services.

Almost like as if people are looking to hire a one-man army to handle the entire department.

Well yea, that’s usually the point of full stack. If you want to do something like that, you probably want to work a smaller scale company… Like if you’re in a team of 5 people, the situation arises of “Oh sysop thing needs to be done, who to ask? I guess @RonSijm (backend dev) is close enough…”

So to have a junior full stack is pretty counterintuitive. Otherwise the situation arises of “Oh xyz needs to be done, who to ask? - Well be have a dedicated senior backend engineer, a dedicated senior front-end engineer, dedicated senior sysops… ‘Oh let me ask @velox_vulnus@lemmy.ml, this junior full-stack’” - yea no.

Why are you aiming to be an intern/early-career full-stack engineer? The only kinda company I can think of where something like that would be something with barely any IT, where you’re just the “jack of all trades” goto guy for IT stuff - so that you can be the one-man army that does everything

So honestly I’d focus on one area first - backend, frontend, dev/sys-ops - especially as you’re mentioning

I’ve wasted most of my time worrying about the stack

Yea that gets even worse when you have worry about the entire stack, and work with an entire stack of components you’re not really familiar with. If you’re at least somewhat senior in one part - lets say backend - at least you’re in a position of “Ok, I have a backend that I’m comfortable about” - “Now lets see if I can make a frontend for it” - or - “Lets see if I can manage to dockerize this, and host it somewhere.”

And if you know the fundamentals of one stack-part first (data-structures, design patterns, best practices) - you can apply that knowledge to other areas and expand from there