[YuriNiyazov]

You hear very often that the programmer industry is "age-ist", in other words, the older programmers have a hard time getting hired.

This post is the other side of the coin: older programmers think that when they entered the industry it was "the golden era", and everything since then has gone downhill. This is akin to someone in the late '90s asking all entry-level programmers "you mean, you don't regularly disassemble your object code to verify that the compiler did the right thing? What's wrong with you, why are you relying on your tools so much?"

The fundamental issue is that the industry is maturing, but the names of the positions for which you are hiring hadn't quite kept up with what you are looking for. People whose primary job is to make sure that data gets from the database to HTML and back really don't need to know what is under the covers. This position is called "product programmer". Their job is to translate whatever your UX guy cooked up into things that actually work. If you then need to make sure that whatever they made scales up to thousands of requests, you need to have a different person called a "performance developer" - these people really hate translating UX wireframes into code, but once that part is done, they can optimize everything up and down the stack with their eyes closed.

Also, this is a personal pet peeve of mine: if you are asking what a singleton is in a job interview, you are interviewing for the wrong thing, so no wonder you are getting the wrong interviewees.

[ChemicalWarfare]

Pretty much everything the OP mentions is reasonably basic "core IT" concepts. Depending on what he means by "intermediate sql" that might or might not fit into that category. I don't think it's unreasonable to expect a "full stack" dev to have at least a basic understanding of things like DB indexing, singletons, http get vs post. Where I would agree with you is to become proficient with these concepts it does involve spending some time in the industry so the age thing might be the factor here as well. Personally I would strongly prefer these types of questions to the "recent CS graduate" type questions some companies are notorious for and not just because I can answer these :)

[YuriNiyazov]

When people say "full stack", it means something very specific to me.

It means you can do both UI and server code, so you have a wide variety of knowledge in the many competing front-end and back-end frameworks out there, but you are not quite an expert in anything. At your last job you learned all the magic incantations of jQuery, Rails and MySQL, but but today you are expected to learn all the magic incantations of React, Node and Mongo. Specifically because you are expected to change your toolkit quickly, you do not dedicate any time to scratching the surface.

Certainly when hiring for "back-end developer", I expect deep knowledge of OS- and DB-level concepts like indexing and garbage collection.

Likewise, when hiring a "front-end developer", I expect deep knowledge of various mobile, desktop and tablet devices and the behavior various browsers exhibit on them.

[ChemicalWarfare]

"full stack" is definitely an overloaded term but then again I wouldn't consider the kinds of questions OP mentions to be something only the experts would (or should) be able to answer on the basic level.

Things like get vs post, encoding, basic headers (like accept etc) should be familiar to anyone dealing with the client side development regardless of the tools/frameworks.

And then on the backend some basic SQL, basic understanding of indexing, FKs, PKs, maybe simple inner joins is also something that someone doing anything DB-related on the backend should be familiar with (unless we're talking someone who is only familiar with nosql dbs) regardless of the tools/frameworks/orm etc.

[smileysteve]

> Also, this is a personal pet peeve of mine: if you are asking what a singleton is in a job interview, you are interviewing for the wrong thing, so no wonder you are getting the wrong interviewees.

I have to agree.

The database indexing "how" also seems to fall into this; Maybe you understand what the limitations of the decision are, but even this is moving more into Architect or DBA roles.