While I don't disagree with your perspective on this, I think it is fair to say that the practice of CS has become broad and granular to the point where it is i

While I don't disagree with your perspective on this, I think it is fair to say that the practice of CS has become broad and granular to the point where it is impossible to teach it all. There's a massive difference between becoming a software engineer 30 or 40 years ago and now. To state the obvious, most of what we do today did not exist back then. The three bodies of knowledge you list (DB's, Concurrent and Network programming) are not mainstream at all. Someone can go through an entire career in software engineering and never touch any of these areas except for, perhaps, superficially through libraries, etc. Is, it, then, fair to judge recent CS grads based on a test of these skills? Again, while I agree with the general sentiment that the average CS graduate has serious gaps in knowledge, skills and experience, I have to temper my thinking. I am not sure it is fair to use such skills tests as a metric any more than giving someone 60 minutes to complete 60 Calculus problems is a measure of their understanding of the topic, their ability to apply it and learn what they don't know. That last part, to me, is the most important thing I try to learn about someone in an interview. I could not care less what they know today. The basics have to be there, of course. Past that, I need to understand how their mind works, if they are adaptable and what their approach to learning and applying something they don't know looks like. Some examples of the stunts I will pull: - Implement something in LISP, Forth or APL, knowing they don't know the languages. I want to see how they react and solve that problem. No, not the code challenge, the matter of being asked to do something they don't have a clue how to approach. - Write an FPGA module in VHDL when they have never used anything other than Verilog. - Design a multi-failure tolerant circuit when they have never done such a thing - Explain how to design an electrical DDR4 interface (again, knowing they have never done it). - Expanding on that, explain how to design an SDRAM memory controller from scratch Etc. This isn't at all about looking for the correct or perfect answers. In my 40 years in engineering I can probably say 75% to 90% of what I have worked on has had an element of "How the hell do I do this?". You want people who are able to deal with that, adapt and deliver. Engineering is constantly evolving, what someone learned in school, at some point, becomes irrelevant. When I went to engineering school FPGA's, the internet and digital circuits running in the GHz range did not exist. I had to learn all of that, and more, as life and career progressed. I think the right paradigm and metric is to evaluate the person rather than the contents of the mental database they happen to have stored at that point in their journey.