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.
There is a beautiful quote, from a book of Robert Heinlein, which - with minor edits - provides a pretty decent job description:
"A
human beingdeveloper should be able to changea diaperthe appearance of an HTML element with CSS, planan invasiona normalized database schema, butchera hogthe tech interview,conn aship a docker image, design abuildingREST API, write asonnetunit test, balanceaccountsever changing requirements, builda wallthe application with a single command, set [up] aboneCI, comfort thedyingproject management, take orders [but not at face value or too seriously], giveordersreliable estimates, cooperate, act alone, solve equations, analyse a new problem, pitchmanureideas, program a computer [well, duh...], cook a tasty meal,fightdebug 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.
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.