[scarface74]

Let’s take TurboTax as something I would call a complex piece of software. I’ve never worked on TurboTax, but I have had to develop software with a more complex set of business requirements.

The complexity in much of software engineering comes from understanding the business requirements translating that to code and making a system usable.

Most development is not about leetCode and DS&A.

The most we can expect from a junior developer who just graduated from college with a CS degree is for them “not to eat the chalk.” At least the boot camp grad can hit the ground running and add features.

The type of theory companies care about isn’t how to invert a binary tree and whether you know how to write a merge sort. Heck even C had the built in qsort that was good enough.

[learc83]

>The most we can expect from a junior developer who just graduated from college with a CS degree is for them “not to eat the chalk.” At least the boot camp grad can hit the ground running and add features.

This is the exact opposite of my experience. Bootcamp grads tend to come in well below early college interns.

>The type of theory companies care about isn’t how to invert a binary tree and whether you know how to write a merge sort. Heck even C had the built in qsort that was good enough.

I don't really care whether you can implement merge sort from memory. But, I've been on both sides. And understanding the relational model, graph theory, set theory, computer architecture etc... has made translating business requirements to code a hell of a lot easier.

[scarface74]

I did C bit twiddling for the first 12 years of my career and I worked in assembly a little bit as a professional and a lot as a hobbyists growing up. I had to understand simple data structures but the most complicated algorithm I had to implement was the “shunting yard algorithm” for a preprocessor I wrote.

I’ve even had to maintain a bespoke development environment/IDE/compiler/VM for Windows CE written in C when I was transitioning to an “enterprise developer”.

But, for the last 10 years, I can honestly say that nothing I have done takes any level of advanced computer science understanding that you would learn in school.

Schools don’t teach what I consider “computer engineering” - how to build a maintain complex system within a team that translate business requirements to working maintainable systems.

Most developers aren’t doing anything new or complicated, they are just taking preexisting tools, frameworks, packages and putting them together. They aren’t even working in non memory managed languages anymore.

[learc83]

>But, for the last 10 years, I can honestly say that nothing I have done takes any level of advanced computer science understanding that you would learn in school.

I don't work at a FAANG company. We mostly work on boring line of business apps, but I use CS theory every single day. If I take what you say literally, my experience is so different from yours that we might as well be working in different industries.

My guess is that we have different definitions of "advanced" computer science theory, and that you've internalized a lot of what I'd consider computer science theory to the point where it seems like common knowledge to you.

When I went back to school, the programming classes weren't super helpful because I'd already been programming for professionally for 7 years or so. But in every single theory class I constantly discovered much better solutions to problems I'd had in the past, or in many cases I realized that I'd spent a day or 2 rediscovering a solution to a problem that was solved 50 years ago.

There were so many holes in my knowledge that I didn't know were there, and if you'd told me just how valuable having a more complete understanding of CS theory (and hardware) I wouldn't have believed you, but it has been immensely helpful.

>Schools don’t teach what I consider “computer engineering” - how to build a maintain complex system within a team that translate business requirements to working maintainable systems.

They do. I had several software engineering classes that focused on building large projects in a team--estimation strategies, design patterns, how to gather requirements and talk to business people etc...

[scarface74]

I’ll give you that. I did graduate from college with a CS degree over 20 years ago. When I think of “advanced computer science”, I’m thinking of the leetCode, hackerRank, DS&A type of topics or even how different gossip and consensus protocols work.

I’m not considering design patterns, continuous integration and deployment, or something like the “Well Architected Framework” https://d1.awsstatic.com/whitepapers/architecture/AWS_Well-A... (not too AWS specific) as the stereotypical whiteboard algorithm type of questions that I keep hearing about but I have never had to endure.

If the typical school is teaching software engineering and not just theory, I find it amazing that graduates have never heard of unit testing, automated deployments, or even how to use git for source control. I end up having to come in as adult supervision for both types of developers - boot camp or recent graduates.

[learc83]

> leetCode, hackerRank

I think that broad knowledge of CS theory is useful, but I agree that being able to replicate specific algorithms from memory is not particularly helpful.

In fact I think that FAANG style whiteboard interviews are one of the worst interview systems ever devised.

>If the typical school is teaching software engineering and not just theory, I find it amazing that graduates have never heard of unit testing, automated deployments, or even how to use git for source control. I end up having to come in as adult supervision for both types of developers - boot camp or recent graduates.

Almost every class I had required us to submit projects using github (they wanted to teach source control, but they also wanted to see version history to discourage cheating). This was at both a middle tier state university for undergrad, and a top 5 university for grad school.

I've also hired plenty of people who were bad at unit testing, but I can't recall ever working with a junior who hadn't at least heard of the concept.