>The downside is that they'll only learn skills that are valuable for that specific company.
In my experience, university did not provide any skills valuable for any company, other than being useful for networking and a little bit of politics if you're involved with organizations in the university.
The big value, at least for 18-22 year olds, is from proving that they have the discipline to put in the work to get into a selective school and/or achieve high grades in difficult subjects. As an employer, my main concern when hiring someone is if they are capable, and if they are disciplined enough to apply themselves. If those two are true for a 22 year old, then there is a good chance they can be useful regardless of their specific education.
Anecdotes aren’t data - but even though I knew how to code long before my university CS course - having to do a CS undergrad is the only way most people will learn the boring-but-essential - or hard-to-learn parts of CS or SE.
For example - I built commercially successful (by my standards) software while in high-school that used O(n^2) algorithms (!!) - who is is fine for small applications - but the difference between someone “who can code” and “someone who can code well” is typically a BSc and an understanding of how to make things that can scale.
We’re all familiar with the trope of the medium-sized business exec who scoffs at the invoice of an SWE consultant arguing “my 12-yo nephew could have built that!” - and they’re not superficially wrong - but their 12yo nephew couldn’t build something that scales to millions of users and petabytes of data.
I’ve found a quick-and-dirty way of identifying the unwarranted self-confident types is to ask them how they’d quickly put together a CSV parser - if they give an answer involving `String.Split` you can tell they don’t have a degree.
> BSc and an understanding of how to make things that can scale
That certainly is not the only way to learn how to write scalable applications. (e.g. reading about techniques and/or building them).
> We’re all familiar with the trope of the medium-sized business exec who scoffs at the invoice of an SWE consultant arguing “my 12-yo nephew could have built that!” - and they’re not superficially wrong - but their 12yo nephew couldn’t build something that scales to millions of users and petabytes of data.
Scaling to millions of users and petabytes of data is not needed in many cases and a simpler solution can get the product shipped faster and with fewer bugs. Part of being a good SWE consultant is taking the time to gather the real world requirements, the potential future uses, and clearly explaining the expected operational envelope to the client.
> I’ve found a quick-and-dirty way of identifying the unwarranted self-confident types is to ask them how they’d quickly put together a CSV parser - if they give an answer involving `String.Split` you can tell they don’t have a degree.
I'd rather have someone who bothers to ask what the parser will be used to process (and what will be consuming its output) and gathers the real world requirements. Someone who confidently assumes they know what the CSV "spec" is and start coding a parser for the RFC 4180 general case can waste lots of time and money building the wrong thing. There are certainly cases where splitting a string on line breaks and commas is a good fit for the problem. There are also cases where that will parse data incorrectly and explode on files over a certain size.
> I’ve found a quick-and-dirty way of identifying the unwarranted self-confident types is to ask them how they’d quickly put together a CSV parser - if they give an answer involving `String.Split` you can tell they don’t have a degree.
I'm pretty sure it would be faster to put together a CSV parser using String.Split than to write a streaming parser to handle the problem. You did specify that you want this done quickly, right?
My immediate thought would be to make sure commas that appear in field values don't cause spurious splitting. After that, yeah, String.Split.
Can you say more about why this means I don't have a degree?
The downside is that they'll only learn skills that are valuable for that specific company.
I think this is the best argument for a tech union. A way to learn with real world experience, while not being bound to a single company.