A semester long class is about 45 hours of learning. You learn in your first two weeks on the job than any one class will teach you.
Also, usually what you're learning in class are the fundamentals that undergird what you need to know for software development in the job. The basic underpinnings and context to understand what you're learning those first two weeks on the job.
And if you're going to be that dismissive about what you learn in a college course, I'll tell you most of what I learned the first two weeks on the job: how to use the specific IDE the team I was hired onto preferred, how to build their specific project (barely applicable outside the project), how to contact IT to get a ticket to get them to install the IDE because I didn't have permission to, how to use the timecard website to log my hours, where the people on my team prefer to go out for lunch, a few hours of HR sexual harassment and cybersecurity training, how to set up my 401k and medical benefits, etc. etc. Basically, nothing to do with "computer science" which is what the original post was about.
Assuming your semester is twelve weeks long (as is the case at my university), that's less than 4h/week. I'm guessing you're only counting lectures as learning. If you only go to lectures for learning and don't do any kind of work on your own, no tutorials, no office hours, no revising for exams, no practice exercises, no homework, no discussions with your peers, nothing... Yeah, you'll probably feel like your first two weeks at the job is a crash course. But I'd say you failed at taking advantage of learning at a university to its fullest.
When I was in school mostly the poor kids and lower middle class had jobs, but I wonder if that's still the case.
They are still only 21 years old, and just literally haven't had as many afternoons to spend tinkering.
Those 45 hours of lectures are usually condensed material with little to no time to practice. It's expected that you practice during the other 90 hours (and on your own time if you plan on having straight A's).
While you may get more hands-on experience in a few months of working full-time, you usually learn much fewer concepts.
Once you get into a job, you're constantly revising past mistakes, doing new things and all the while you have coworkers who are helping you- they don't want to wait for you to make a mistake, they want to help you get it right the first time if you need the help.
Uni courses rarely cover real-world knowledge that you will use on the job. Aside from some specialized jobs, most of what they teach you is either too low-level or mostly useful as background knowledge. So many practices aren't covered in college courses- even things as simple as version control have only recently started to become common.
You're going to be learning a lot on the job, and at a decent job what you learn will make what you went through in college pale in comparison.
I genuinely don't think most of workplace actually reassemble this ideal. Sometimes you learn ... plenty of times you do something repetitive. Sometimes you don't even learn about own bugs (hello agile). And sometimes they give you great advice and plenty of time they just don't.
In CS, we regularly had courses worth 300h in a semester, fe. analysis, system architecture or software engineering.
In practice, students start to complain once a course tries to enforce their full "hour contingent".
Related: one of the faculties here recently announced the introduction of a threshold grade. If you were bad at school, you are not taken into consideration, even if there are available places.
I had a couple coworkers who were in the same classes as me and as part of trying to improve my time management I'd ask them how long the homework took and would get ridiculous answers like 'an hour' (2+ week assignments usually take tens of hours). I couldn't tell if they were smarter than I thought, braggarts, or liars, but after I switched from a support role to a coding role, in the space of a semester I was doing my homework in 2-3 hours. Often those homework problems are just a bit harder than an interview question, but without practice you're improvising the whole thing and that's a lot of effort.
Before we started talking about 10,000 hours, I already had a rule of thumb that your competency as a developer tends to ratchet up at 100 hours, and rather substantially around 1000 hours. An internship will definitely hit 100 hours, but 1000 is still easily achievable in a year. 10k hours might as well be an imaginary number. That's longer than they've been in school and so feels like an unreachable finish line. Demotivating for sure. 1k just means "work hard for a bit".
There were certainly a lot of people who didn't really understand the question, and I couldn't really help them much without risking the poorly worded guidelines on what would earn you an expulsion, but there were a lot of people spending a lot of time banging their heads against typos and simple structural errors.
I learned early on that the facts and tasks I biff on are often the things I remember the clearest later on, but also that most people are not like that. They remember the things that they got right easily on the test. I'd wager that for most of them, that time spent wrestling with the computer provided very little to no growth opportunities at all. 10 hours on a homework assignment might have yielded at most 90 minutes of actual progress.
For the more difficult classes, that number can be even higher.
So for a class that has 3 hours of lecture time per week, that's 9+ hours per week on that subject alone.
On the job training only works for certain types of skills
This whole “gaps” argument is just people who’ve bought into a system. People coming out of uni have “gaps” as well just different gaps… gaps rich kids have so it’s ok with Google.