| N = 1 but here we go. Let's look at the CS bachelor/master offered at the Vrije Universiteit Amsterdam [0]. The truth is probably somewhere in the middle and I understand that university programs are heterogeneous. So let's look at my university experience and use your post as a checklist, for funzies! :D Functional programming: covered Dev tooling: covered to some extent through electives where you'd teach it yourself (I also call it the Magical Course) [1] MVC: Magical Course event programming: never heard of it :) Reading the wikipedia page, the following courses will probably help in aiding understanding: + Hardware interrupts: kernel programming, binary and malware analysis and hardware security + User events (e.g. via JavaScript): The Magical Course and Computer Graphics CQRS: never heard of it :D And while I get the need when reading the article from Martin Fowler, I do not have a backlog of knowledge where I've encountered this before. Simple app: computer graphics, the Magical Course, Distributed Multimedia Systems (the practical assignments were in HTML5/JS). Cloud vendors: nope, I learned about that when I started teaching for a coding school zipkin, istio, helm, grafana: never heard of it :D be able to grok a explain analyse and fine tune a 500GB dB: No. We did learn SQL though and how to model relationships with UML and entity diagrams. it is unlikely a fresh grad has production experience: I do, because my thesis was harder than whatever production experience I was acquiring. Going to work as a web dev and web dev instructor was my form of fleeing for my much more difficult thesis. Also, computer graphics taught me volume as my OpenGL engine was 10K lines of code. The Magical Course allowed me to produce an app that I sold for 2000 euro's. Diving into a 1 million line codebase: We did that way too briefly (the Linux OS) for just 15 minutes, unfortunately. The startups I've been at had about 100K lines of code for their complete product. In other words, a lot of companies don't have a 1M+ codebase. Anyways, when you have someone from the Vrije Universiteit Amsterdam, you can have some idea of what they do learn ;-) [0] My knowledge of the curriculum is a bit stale, so it could've changed. [1] Whenever I use this sentence, I happen to refer to one course where the teacher decided not to really teach but coach and the goal was to teach yourself whatever you wanted. I happen to have learned a lot of practical stuff that otherwise wouldn't be covered. So did many others. What did I specifically do? I created an iOS app by following Hegarthy's Stanford-based iOS course online ( https://www.youtube.com/watch?v=gI3pz7eFgfo ). |
Yours is above the par learning experience than most fresh graduates I have encountered. When we hire in Eupope I would very interested to try and convince some of your juniors to join!
> The startups I've been at had about 100K lines of code for their complete product. In other words, a lot of companies don't have a 1M+ codebase.
Most large companies who are also large employers sadly do have such complexity. In a startup it may not a single repo at 100k+, however overall 100+k lines for the product is very low for Saas product over two-three years it easily goes beyond.
My N=1 in a startup: we went from one monolithic 300-400k+ L repo to a ton of repos with each one perhaps < 100k . Traditional large codebases are not designed for releasing 4 times a day, even builds can take a lot of time [1], Smaller repos does not mean complexity goes away, developers need to still document, read and understand how it works. It applies also when you use libraries or third party services, while number of lines have become less, you need a lot more domain understanding.
> be able to grok a explain analyse and fine tune a 500GB dB: No. We did learn SQL though and how to model relationships with UML and entity diagrams.
The reality is that most jobs are not developing new apps from scratch, it is lot more likely to work on older codebase that has its fair share of kinks.
That means I am going to throw you deep end into large sized DB. Schema perhaps has evolved over time as product vision keeps changing, a dozen 'architects' have messed about it. In a typical job, you will be fixing bugs more than developing new features, handling tech debt - it doesn't matter stupid mistakes were made before, you still to work with/around those mistakes as someone will have to work with yours.
Even on theoretical level NoSQL is not well taught in universities. Purpose built dbs for graphing, Time Series, KV , document DBs, search indices are all important to really understand. Each has solutions to specific problem set and come with their limitations. In a typical basic storage stack there is going to probably be something like Redis|PostgreSQL|ElasticSearch: all of them solve more than one type of storage problem in more than one way.
This isn't to say the that is it all bad. Education is evolving , universities are more open to longer internships, while most don't think software engineering (not CS) should be treated as vocational course, there are positive trends. Alternative learning avenues have opened up like Coding Schools and Bootcamps who do lot better job at focusing on job skills.
[1] https://news.ycombinator.com/item?id=18442941 This is infamous post, and of course the extreme example, but you get the idea.