I agree with some of what you said here, and maybe i have misunderstood what you're trying to convey, but allow me this little rant here... Some of it seems ex

I agree with some of what you said here, and maybe i have misunderstood what you're trying to convey, but allow me this little rant here... Some of it seems excessive. I've been developing in C and Java for 11 years now. I make a tad under $100k and live in Atlanta, Ga. I have yet to need to know or discuss failure modes of the GC by heart, how to detect them and work around them by heart, how the JVM team did generics and possible alternatives, nor to know keyboard shortcuts by heart. I have however come across these things in my career and had to takle them. Guess what I did? Googled. Then I got back to writing code, what my job soley exists for. It seems absurd that any company would require these things. If I was interviewed at a company asking me to talk about these things in the interview, I would walk out simply because I would feel it was completely irrelevant to how good of a software engineer I am. I really hate being interviewed by people who are more interested in asking obscure questions that just want to prove how smart they are (when we all know they probably just looked up that question/answer before the interview), rather than talk to me about coding and problem solving. Things like memory use, basic algorithms, what design patterns are, collections, code quality, software development life cycle, unit testing, general coding problems, maybe some things about hibernate (if you use it), basic database knowledge, their favorite language and why and let's not forget overall personality and how they will fit into your team are far more important areas to cover. Not some obscure questions that will be used maybe once in your lifetime or on extremely rare occasions at the new job that can also be looked up on google when you need an answer for that rare occasion. I even shutter when I think about design patterns being discussed because they're so over used and bad developers focus way too much on putting well known ones into their code base even when it may not be called for and just create so much more bloat for no good reason other than to feel like they're smart. An understanding of design patterns is great, but forcing people to describe any of them but the well known basics is just dumb. The interviews my team gives exist around these things and I can honestly say we have yet to hire someone that didn't know their stuff very well and fit into the team nicely from the start. I have only been without a job for a max of 3 months when I was laid off once and I have job hopped a lot, especially in my early career (which, there is a dirty secret there... That's how you make more money when you're staring off!). I have walked out in the middle of interviews before when it was clear that the person was asking obscure questions just to feel superior. I don't want to work with people like that... Interviewers need to focus more on asking questions that software engineers face on a daily basis and less on odd and obscure things that can easily be researched in a short amount of time online when and if the problem ever presents itself. I apologize if I got off topic or missed your point entirely. I was just having a conversation with someone about this very thing and it seemed relevant based on what I read.