I have learned a lot of things at Berkeley, but very few things that have made me a better software engineer. As a current student, here’s my perspective on why a top cs school != a top software engineer (with focus skewed towards Berkeley because of my personal experience).

CS schools weren’t created for software engineers. Computer science departments came into existence long before the tech boom that made being a software engineer such a hot job, and as such, they’re not focused on the skills that are necessary for industry today. As one of my professors once said, “The target audience of the Berkeley EECS curriculum is not the majority of Berkeley EECS students.” You don’t write enough code. In Berkeley’s three intro courses, there are only four projects in each of the classes. Suppose you spend 20 hours on each of those projects and 20 hours on labs… that’s still only 100 hours a semester. Programming, like other skilled trades, is something you need way more practice with to master. The technologies taught don’t match the technologies used in industry. Although Berkeley just started using Git for its intro series, despite the large industry demand, there’s still no web or mobile development that is taught as part of the formal curriculum. Collaboration is key in industry. Sure, most projects allow you to have groups of 2–4 people. But in a bigger company, you’ll be dealing with a codebase that has hundreds or thousands of people working on it. There are all sorts of subtle questions that collaboration brings up like, “What methods should I expose to make my API most useful?”, “How do I make my code more reusable?”? Reading other people’s code is as important as writing code. Being able to easily parse and understand a codebase makes onboarding way faster. Finding elusive bugs is also dependent on code-reading ability, not code-writing ability. Code review isn’t present. In our classes, you often get your projects auto-graded without any feedback on design or style. When projects are graded by a human, there’s usually no incremental review, which means you don’t have feedback on the structure of your code before it’s too late (and you don’t care). There’s a huge difference between writing code and writing clean code that isn’t being made clear enough. Testing isn’t emphasized. You can get by on many projects without writing any tests. We usually have access to an autograder that automatically runs the tests our code will be graded on. This means you don’t learn how to come up with sufficient test cases yourself. And although writing unit tests is starting to be required in a couple lower-division classes, more advanced testing techniques (like using mocks and stubs) still aren’t taught. Students don’t learn how to use libraries and frameworks. In the real world, the first thing you do when you’re deciding how to create something is figure out if someone else has already done it. If you want your web developer to create some graphs, you should be able to say “just google d3.js” and have them figure it out. But projects at school are too constrained to teach students this kind of exploration.

That being said, the purpose of top cs schools isn’t to create software engineers for the majority of tech jobs needed today. And there’s nothing necessarily wrong with that.

But if a student’s goal is to become a software engineer, it’s a good idea to learn what your formal cs education is skipping over. And perhaps employers should avoid overemphasizing a top cs school for standard tech jobs?