What is wrong with new generation of programmers?

> - What is DB indexing

Yeah I asked exactly same question, And instead of answering what it i, candidtate told me why they used it.

> - Can you think of any impact when indexing in this situation

That's Why I want to know if candidate understand what really index does, One cant tell a realistic answer of this question until S(h)e knows how index works.

> - What are you general thoughts about indexing, can you think of an example when you used it and how it helped.

Even if one used it in some situation in pastm and it helped, I would consider it not enough as it could be possible S(h)e used it by reading some blog/tutorial etc without understanding it fully, it's like ok switch it off and on, did it work? well forget about it then.

OP's question is a generalization over a whole generation and can thus hardly be true.

What might be true though is that knowledge in software programming is much more specialized than a couple of years ago. IMHO that is a sign of a growing industry.

That aside I have the feeling that some people did not have the pleasure of a good education in software development, which is the reason they miss some of the more fundamental bits (or they did not pay attention which is another issue). That may be due to the fact that it is easier for lesser-educated (sorry for my english) people to get into software development and that may be due to great demand for developers in general.

Somewhat related to the general discussion I'm reading in the comments: https://www.williamghelfi.com/blog/2015/12/26/william-versus...

Lets look at it from an evolution of technology angle.

10-15 years ago we had pain points with web apps and making them more fully featured/responsive and dealing with things breaking at scale. They were kind of clunky to build so, we did what all good engineers do and figured out how to make things easier to use for everyone. Now a days, the "kids" are learning how to build web apps that don't require a deep level of knowledge about the stack - we've done a fantastic job building out the tooling that abstracts a lot of these concerns away from the "average" developer. They know if I install framework X and use Library Y the two will communicate correctly. I might understand how they communicate, but don't need to know the intricacies at this time.

Technology is always evolving and what you need to know at a deep level is changing. 60s/70s/80s - The size of the program, how it was laid out on disk, disk sectors, memory layout. All that mattered to get the best performance. You needed to understand how the hardware worked intimately.

90s/ early 00s- Managed languages (Java etc.) become more of a thing and you need to understand less about all the gotchas the prior generations faced. The framework and language abstracted a lot of the prior generation's challenges away and increases in hardware capacity reduced the need to layout programs just so on the disk or in RAM.

Early 00s-Present - Hardware kept growing exponentially in terms of capacity and performance, and we started placing more emphasis on building out scalable, fully functioning web applications (thin clients) rather than thick clients running on a desktop. People figured out a lot of these applications were simply wrappers about DATABASE activities and wrote frameworks that made writing the backend for such apps KISS simple. RoR I'm looking at you! This freed up people to focus on the bells and whistles the user interacted with and reduced the need for anyone developer to know the intimate details of how their framework worked.

It's a changing world and the next generation of programmers is always going to be starting at our current level of abstraction, much like we started at our prior generation's and built our way up. Challenges we faced, overcame, and turned into libraries, become the starting assumption for the new kids that they'll build up from.

On the flip side, I gotta ask, what are you looking for? There are so many "full stack" combinations (language, server, SQL/NoSQL database, front end scripting library) now that the odds of finding a person with deep experience using everything you are using, unless you've reduced to the lowest possible common denominator, is low. Are you looking for someone you can train into the position and has enough knowledge not to blow their foot off, or do you want someone who you can plugin ready to go? Your expectations will influence how you're viewing the candidates, your expectations, and your relative measure of disappointment in them.

Your last paragraph resonates with my experience learning. After two years of working with Rails I realized it's like the Mac of frameworks. It does so much to prevent me from thinking or looking under the hood that I don't actually know what's going on. So part of my reading this year is on topics like REST so I actually get it, and also building things without a framework (rather than use the devise gem, build my own login system, build own router, etc). It's pretty painful because I'm so used to effortless progress through gems, but very worth it.

I think people in my situation just get comfortable and forget that they need to keep digging deeper. I think this also differentiates someone being just a programmer vs an engineer.