Many of the people who say this kind of stuff never really mastered the theory, and because they never mastered it they can't really use it, and because they can't really use it they find work that doesn't strictly require it, and then conclude it's useless... It's like when otherwise successful people tell you all that calculus they learned in high school is useless, it's not useless, they just found success in a career that didn't need it.
I resort to my textbooks and academic nonsense all the time. There are often two ways to solve a problem, the first is just code-until-it-works, the second often involves modeling it in some kind of formal structure, and defining the operations over that structure and their properties. Usually, in doing this, the resulting implementation is far less code and far more resilient. But those who are not comfortable with the foundational theory stuff just don't see it and don't even think to approach the problem in that way.
You say caymanjim's comment "reflects a common meme" that real world work "doesn't involve the academic nonsense you learn in school" Why? It seems like you swapped out his argument with something different, by claiming one "reflects" the other. Sounds like "We got trouble, with a capital T, and that rhymes with P, and that stands for Pool". Stating that most software engineering work doesn't require CS theory doesn't commit anyone to claiming that it never relates to real world work. Furthermore, I think you can claim that theory isn't used in the vast majority of real world work without dismissing that theory as "nonsense" - a word you supplied here that wasn't part of the OPs comment.
Now - I will agree with you that many people say this stuff, and you may very well have diagnosed why. But you refuted something you recall other people saying, not what caymanjim said.
So for some very specific cases, in my career (and i suspect for many business application developers) set theory has been the most useful thing i learned in CompSci. How much of a real world day do i spend using that knowledge? 0.0something% on average.
In fairness, It has sometimes helped me get a product finished sooner but this is tenuous at best because i can point to far greater influences from learning how to use specific tools that have helped me get to "done" sooner.
The difference between real world developer and CompSci isn't necessarily in more effective use of CompSci.
- State machines. I run into a lot of state machines, especially incompletely specified ones. Not that everybody gets these wrong if they haven't studied state machines in a textbook and worked the exercises at the end of the chapter, but recognizing "oh, this is a state machine" gives me a mental framework, a notation, a vocabulary that other developers understand, and a better ability to understand when a problem is underspecified or inconsistent.
- Queueing theory and algorithmic complexity. These two usually come in handy from the perspective of spotting and avoiding stupid mistakes. It's true that people can do a pretty decent job from a handful of rules of thumb, but not everybody has that minimum knowledge, and sometimes a problem has a twist that an imprecise rule of thumb doesn't account for.
- Distributed systems. Just understanding the solution of a few problems in depth, and knowing from that how hard simple things really are, is incredibly valuable. Without that background, people can naively tackle extremely complex problems, bash their heads against them for years, and still underestimate the difficulty of the problems they've created for themselves by orders of magnitude.
In general, the rigor of doing theoretical problems, the discipline of actually proving things, creates habits that uncover lots of non-happy path possibilities.
- State machines: completely agree. I use them especially in the context of user facing stuff, like GUIs, animations and so on. In fact I would even argue that they are _inherent_: Even if you don't recognize and specifically structure your code around them, they are still _there_ just smeared all over your logic.
- A&D I find ubiquitous are: sets, graphs, trees. Sets especially are underused and graphs are the most expressive data structures if you need them and can help you model complex, long lasting models.
- Relational algebra is likely one of the most important concepts. It is fundamental to the Swiss army knife of databases: SQL.
- Algorithmic complexity: I rarely use this formally, but it really helps to get a decent intuition for performance.
Seriously? Currently working through my second databases course, I still can't help translating all of the relational algebra nonsense into proto-SQL in order to make sense of it. I was already working on large-ish business applications and databases for a few years before the first course and I didn't even know RA existed. Now it just gets in the way.
Not to mention relational expressions or whatever that thing is called where you use the "exists" and "for every" operators, which I still haven't been able to apply in practice.
I think the interesting Aha moment was the realization that SQL is syntax on top of a mathematical concept. Before I was distracted by the practice of reading and writing stuff to disk with it, if that makes sense.
Probably one of the most powerful tool out here. You can catch a lot of things simply by identifying which state transitions should be possible and which shouldn't exist
I have struggled - and failed - to find a use case relevant to daily SWE work, since (a) the probability distribution for most customers waiting in a queue is not known and must be "guessed" or predicted ahead of time using historical data and (b) nearly all queue requirements are simple (i.e. minimize total waiting time) and the solutions just as simple (scale up your queue consumers!)
A particular example I remember was a poorly architected system that was essentially two systems connected like queues in sequence. The first one was fast and lightweight, basically a gateway/hydrator for the second one, and could handle a very large backup with no ill effects. The second one was very slow and fell over quickly if too many items accumulated in the queue during a load spike. An easy short-term fix to make the system stable in production was to introduce artificial slowness in the first queue to buffer load spikes and prevent backups in the second queue. Little's Law points straight to this solution, but people who didn't have queueing theory in their mental toolkit had not considered fixing the system by slowing part of it down. It looked like a big leap of imagination for them, even if they found it intuitive to understand after it was pointed out.
There are interesting compiler roles but the vast majority who learn how to build a compiler never use it day to day work. Would you recommend spending more time building compilers to better compete for those few roles or would you recommend a different approach?
I may not be writing compilers professionally, but on the surface, understanding parsing has gotten me out of more than a few tight corners. More abstractly, there are lessens to be learned in designing large applications; and appreciating the difference between a finite state machine and a deterministic turing machine, including the types of problems they can solve and how much of a pain in the ass one is to write compared to the other.
CS still comes in handy though, especially computer engineering to understand some of the workings of the hardware
Occasionally I'll use real CS knowledge when I'm building tools for work or working on games in my free time.
Full disclosure, I didn't actually study CS in school though.. I studied EE and then went and learned CS via Wikipedia when I needed it to find a better-paying coding job.
... until I took a job in X-ray imaging. We were working on a surgical X-ray (C arm) that could pinch-hit as a CT machine. And suddenly everything was 3D coordinate transforms and fourier transforms, plus X-ray physics, up to my eyeballs.
The theory stuff isn't useful... until it is. And when it is, it helps to have it.
I've personally revamped core parts of a product at previous companies to be over 1,000x more efficient just by applying some CS principles. This translates to $100K/mo+ in savings for a company that is at scale.
For example something that has stuck with me since high school was hearing that H20 expanding when it freezes into a solid is what makes ice skating possible. Pressure exerted by the skate blade forces the surface of the ice into a liquid state which makes it slippery.
Where educational curriculum tend to lose people is by overemphasizing the canon/trivia. Ironically that seems to be a result of needing to develop additional, obscure, test questions to deter students memorizing rote information or last years final exams.
In regards to computer science I think there is more to gain for students by learning the history and development of particular CS solutions and discoveries as they are more likely to encounter those situations in their careers than a particular need for a CS technique.
38 year old studying astrodynamics for work. Can attest to the difficulty of this. No kids yet, that helps, but the wife and I are planning on starting a family soon so it'll get even harder with increased demands on my time.
My comment was that most (I would say the vast majority) of software engineer roles don't require a computer science background (emphasis on the science), and wouldn't leverage it even if you had it. If you do have a strong CS background, it opens a lot of doors, and in particular opens doors to--in my opinion--more interesting and challenging work. There's nothing bad about getting a CS degree. It's just not required for a software engineering job. I'm not being dismissive of the education. I'm skeptical of the idea that it's important for most roles.
Or don't realize how often they actually do use the skills they learned in calculus class to solve problems that don't necessarily involve derivatives or integrals but do require a methodical, structured approach to solve that isn't something you're born being able to do but must instead be honed through practice on "toy" problems.
this is quite the assertion. do you have any evidence supporting this statement?
"I don't think any of that is true" is a strong statement. Nobody is saying that a toy renderer in school resembles a AAA rendering engine, but the point is that the thought process needed is the same, and I'm still going to expect a certain degree of rigor from any candidate. Also, the parent post is speaking more about the theory and fundamentals in general, not the direct contents of any particular coursework. FWIW, I am not formally trained in graphics or CS (my training was math).
Most of my graphics works was better served by an understanding of hardware(pipelining, SRAM vs DRAM caches and latency penalties including random vs linear reads). Most of the embedded work was done with a rigor towards memory management and not any "traditional CS". In fact we avoided traditional CS structures(lists, trees, etc) since they had negative performance penalties. The only thing that we came close to leveraging was radix sort along the view axis, and that was through a gnarly hack that let us use it for floating point values.
I've also yet to run into anyone in gamedev or the graphics world who could derive quaternions from first principals. They're damn useful but I think you you know their operations understanding the theory doesn't take you much further.
I think you have a point on rigor, but that has more to do with how to tackle problems broadly rather than any sort of academic or theoretical background.
As for quaternions, I can derive them (no really, I've written a ton of code in this space, although I prefer the GA formulation), but I want to know, does the candidate understand why they're mathematically advantageous (blending properties, linearity, etc). Can they productively read a paper that uses it and apply the technique, etc.
It's not that CS knowledge is useless, in fact it's great to know the theory. It's just not the top priority in terms of doing everyday work. Recommending an aspiring engineer prioritize CS (outside of what you need to pass interviews) is like recommending an aspiring pianist to master music theory. Nice to have, sure, but not an efficient use of time.
Also when people defend the importance of knowledge of CS theory in this industry, their seems to be this implication that CS theory somehow can't be learned on the job. As if it's super complicated and only "real" engineers have the intelligence to pick it up. A load of crap. For example, I once had to use graph algorithms on the job (probably the only time I've ever had to use CS on the job), and I didn't remember any of that stuff from school, so I took a day or two to read up on graph data structures & algorithms, and was able to get the job done.
What's more important in this industry, or any field really (unless maybe you're doing something super special like nuclear physics), is knowing how to learn - especially at the junior level. That is way more important than any knowledge. Of course you need to have some base knowledge, but any junior engineer working their first job is going to have a hell of a lot to learn anyways, so for an entry level role I'd rather pick the smarter person who's dabbled in his own projects and is eager to learn than the CS major who's expecting to be tackling interesting CS problems all day at work - unless of course the job actually requires this which until now has never been the case for any of my software jobs.
Here we completely agree.
> so for an entry level role I'd rather pick the smarter person who's dabbled in his own projects and is eager to learn than the CS major who's expecting to be tackling interesting CS problems all day at work - unless of course the job actually requires this which until now has never been the case for any of my software jobs.
I disagree.
Using CS problems has two advantages. The first is that it establishes a common vocabulary. The second is that it's stack agnostic.
Personal projects are great, but sometimes it's hard to tell how much help they got from the internet...
Being able to learn CS fundamentals is, to me, a bigger predictor of later performance when they'll be tasked to learn Enterprise X Custom Stack that's not really covered online instead of Well Documented Framework With 1000 Examples.
But isn't this statement too specific to apply to the generalization that you're disagreeing with? "Most 'real world' work doesn't require CompSci" is a generally true statement, because most "real world work" is incredibly mundane and repetitive.
So, isn't your take kind of the inverse of what you're talking about? "I enjoyed ____, so I sought out industries that required ____". Almost as though computer science is a specialization within "real world" work?
I guess I think that most industries are not the industries that you're seeking out. Most software developers are employed to combine already-solved problems with new inputs for money.
What do you think?
- Boolean algebra has helped me greatly simplify hard to understand nested conditionals.
- Understanding data structures lets me pick the right ones for the problem.
- Algorithm analysis has let me take program runtimes from minutes or hours on modest data sets down to seconds or minutes.
- Discrete math topics helped me prove a problem that a coworker had spent a few weeks on was technically impossible.
- Again for parsing, understanding the ideas of parsing let me make a number of parsers over the years using a variety of mechanisms. The critical part, though, was understanding what was being parsed and how to parse so the code was clear. I replaced convoluted code with hardcoded values and assumptions about what would be in each part (line, or binary blob) with something more flexible and less hacky.
- Knowing how C stores data (stack versus heap) let me fix a lot of code from some engineer colleagues that would work, sometimes, but not reliably because they didn't understand how memory works.
In other industries...
I started my Software Development journey with C, then moved into Game Development in C++ as my first job. Game Development DEFINITELY requires a lot of CompSci info (that I lacked). Hash Maps, Pathfinding, Matrix math, physics calculations, Linked Lists; all the works. We were also using a proprietary Game Engine so maybe with other Engines CompSci isn't as needed, I haven't worked in different engines.
In many of these cases, the team I joined had a code base in place that "kind of" did the solution, but was not grounded in any conceptual model - despite phenomenal code quality, peer reviews, etc. Recasting it as an implementation of a well-studied formal model generally yielded a codebase that was one-tenth the size of the original, and with far fewer defects. As I said in the parent comment, if you aren't familiar with this kind of stuff, you don't know about it, so you don't use it, so you find other (suboptimal) ways to do it.
An understanding of time/space complexity (Big O Notation) is also relevant to evaluating approaches. A senior level developer will use this to make high level choices.
I also use compiler theory when writing parsers and simple DSL languages.
Honestly, never really had to deal much with red-black trees or linked list algorithms.
2. AWS was cutting edge distributed systems theory and gave birth to cloud computing.
3. Renaissance Technology was cutting edge algorithms theory and gave birth to quantitative hedge funds.
Some people innovate for a living.
Can you point me to any aspects of Unix that were theoretically new?
One can say the philosophy behind Unix was new. I'm sure that's why modular and micro kernel designs caught on.
Right now am working on a physically distributed, synchornized system. It has some signal processing code: cross-correlation, FFT. The process planner builds spanning trees out of the layout graph to execute the tasks.
Sometimes it's trivial, replacing a for-each loop with something that's log(n) or O(1). Sometimes a little more complicated, like refactoring some code and realizing the original implementer was trying to do BFS but.. wrote something else. And the rarer cases are having to really dive in and trace some odd contention issues. All of these touch on what I learned in college at some level. Sometimes knowing something exists is helpful for looking up later and can save lots of time.
I do wonder if it's less about "requiring" the education and more about someone seeking out the kind of work that uses the education. I know many people in my company are the opposite of me, and definitely do not care to go much deeper than implementing things until they work.
That's just one example, pulled from people I've worked with. An understanding of fundamentals is required to do a real evaluation for yourself.
Imagine an electrical distribution network where there are 3 phases (A/B/C) and an overhead line can contain any combination of those phases. These networks can be modeled as a graph with nodes connected by links. The links do not have a direction, but they do have a phase. If you want to know what the phasing is at any point in the network, the way to figure that out is to use graph algorithms.
Or maybe all that "foundational theory" is oblivious to cache hierarchies(hello Big O notation) and generates worse performance on constrained devices. Or perhaps there's enough unknown, unknowns that throwing something at the wall is a legit way to get data if it's not a one-way decision.
However the attitude on display above is a problem because you've just alienated those people who may have come from a different background or do know the theory but are approaching a problem in a different way.
And at least once a year I draw on my CS education to:
- Model something using state machine semantics
- Use heap-based priority queues, binary search, b-trees or skip lists. And of course I use hash tables and hash sets weekly.
- Read and implement something that CS researchers invented (PAXOS, interval tree clocks, CRDT work like RGA & YATA, etc).
A lot of self taught programmers also don't seem to have fluency with all the degrees of freedom you have as a software engineer. Off the top of my head: Do you know where the bottlenecks are in this program? Are there better algorithms you could use? Are there different dataflow architectures which would help? Can you trade off CPU for memory with caching or memoization? What are the memory allocation patterns? What do you expect the upper bound on performance to be for this process? What are the fundamental invariants your program / data model should always maintain? Can we use a fuzzer to ensure those variants are always maintained? If those invariants aren't being maintained, would we know about it? What are the single points of failure? (And how could we add redundancy?) How would reliability and performance change if we use a different database, or added or removed indexes or caches? If you wanted to steal our user data, what are all the ways you could you do it?
A junior engineer (or an engineer at a feature factory) might never need to ask these questions. But becoming a good senior requires a deeper expertise in seeing a program. And that requires an integrated knowledge of fundamentals, program analysis, tooling, experience and creativity. People learn all that without a degree, but personally? There's no way I would have learned all that stuff as well on my own.
Yet I run into good developers with good CS backgrounds all the time who were never exposed to cache hierarchies in their traditional CS education but had Big-O pounded into their head like it was the gospel on high. Sometimes it seems like revealing how cache misses or prefetchers work is some sort of magic trick that academia skips over.
I've also seen where software engineers will stop at the boundaries of "CS" when it comes to problem solving(ex: not consider the hardware because it's a "hardware" problem rather than rolling up their sleeves and digging in). With the pace of development in software you need to continue to learn outside of a school setting and cultivate that curiosity that helps you come at problems from new and interesting ways.
This is true of just about everyone in computing. This isn't an industry for people who expect to cruise on the knowledge they were given a decade ago. (Plenty of people do, but thats another rant.)
Regarding big-O, one habit / intuition I think its really important to develop is an intuition about how well something will actually perform in practice. Like, you should be able to guess within an order of magnitude or two:
- How many simple reads per second and writes per second your database can perform
- How many lookups / inserts per second to expect out of some standard data structures. (And how those numbers change as the collection grows)
- How many allocations your program does, and how much time is spent in the allocator
- About how large the steady state working memory size should be for your program
I'm not talking about theoretical O(n) numbers. I mean, right now, if I write a tight loop in nodejs on my laptop writing random numbers to a JS Map(), how fast will it go? How does that compare to C/Rust? How many SET calls per second can a redis instance on my laptop handle? How about SELECT queries to postgres, or find({id:...}) calls to mongodb? Will the database be faster or slower than the nodejs program on my laptop thats issuing those queries? How many HTTP requests per second should I expect out of my express server? How many milliseconds should it take to statically render my web app to HTML? Etc.
And arguably more importantly, it shouldn't take you more than ~20 minutes to go and find out the answer to any of those questions. Benchmarking is a delicate art, but if you can't measure, you programming blind.
I wrote a fuzzer the other day which did about 100 iterations / second. And I know something was wrong because the number was orders of magnitude lower than I intuitively expected. Some tweaking later its now running about 1000 iterations/second - still too slow. Profiling shows its now spending 99% of the time in a single function. I'm hoping for another 10x when I rewrite that function. Without my intuition whispering in my ear, my program could have ended up 100x slower than it should be for no good reason.
Aside: This might make a great interview question for a mid. "I have this simple piece of code. How fast do you think it will run on your laptop? Ok, share your screen and write a program to measure it. Talk to me about your answer!"
But isn't that generally true for most education and most jobs? For example, what percentage of Real World work that requires a high school degree, actually involves high school geography academic knowledge?
Contortions I can do easily mind you, but other than recursive functions and linked lists any more complex data structures are too fragile to survive the harsh world of constantly changing business requirements.
As a younger developer I wrote a beautiful algebra that described the company hierarchy for giving permission levels to people from active directory. Within a week I needed to scrap that and redo it from scratch because people needed permissions in the specific app that had nothing to do with their job position.
Groundbreaking software engineering projects that advance the state-of-the-art, like Google's Map-Reduce-based scaling architecture back in the day, or ones that provide some non-trivial edge or advantage, like the tight integration of hardware and software in iPhones (and the resulting responsiveness and battery life), or ones that provide high-assurance and provable correctness (Rust, Haskell, etc) actually do require CS knowledge.
Whenever someone makes a comment like this, I just assume their work thus far has consisted of linking together pre-existing building blocks to make web or mobile apps, rather than anything completely original or state-of-the-art.
And it's good that the industry has gotten to a point that such a job opportunity exists for so many people. But keep in mind it was only possible by decades of development of layers upon layers of abstracting away most of the CS into easily composable libraries, APIs, and other components. You many not need to know algorithms and datastructures yourself, but you're definitely using them by building on them and with libs that encapsulate them.
I work on a project management application. Its pretty much entirely custom code with little external libraries but it also requires very little computer science theory. The problems I face are less "Find the fastest way to search this datastructure" and more "This code was designed for a legacy model of the system, how can we replace it with something modern without spending months on it"
...otherwise known as the vast, vast majority of work in "most software engineering roles", as the parent commenter mentioned.
They didn't say CS knowledge was unimportant. They said it wasn't directly used in most SWE work. That's entirely accurate. They did not comment on whether the products of computer science are involved in most software engineering (of course they are, but I don't need to remember A* to use a graph database). They did not comment on (rare) roles in which that knowledge is required to make groundbreaking advancements.
I will say that I've seen some companies improve their interview questions to be less about having CS insight or algorithmic "tricks" and more about writing good code.
But I've also been asked to essentially come up with quickselect in a 45 minute screener, the asymptotic analysis of which took me more than 45 minutes to understand.
Isn't that similar to people saying "I've never used trig in 30 years"? Isn't the point to train your brain to think in a certain way, more so than actually needing sines and cosines?
For computer science specifically, the goal is to teach you to think in terms of loops, conditionals, recursion and so on. It's to train the muscle more so than memorize specific algorithms or data structures.
You might get that through other methods besides trig, meaning trig isn't strictly necessary -- it's just one option among potentially many. The hard part is proving efficacy and efficiency of each option.
CompSci interview questions go way beyond loops, conditionals and recursion though, such that if you don't already know some secret sauces, it's unlikely to get the best case solution that the interviewer wants.
The other thing throwing this off is interviews are looking for different grades of solutions or maybe just looking at your problem solving/communication skills, e.g. you can fail to find the best known solution but still get a job because of your reasoning.
So in this way, the algorithms & data structures interviews can sometimes be used to test knowledge, or test problem solving ability, or both.
The interview stopped being a test of "if you can do this job" and instead seeks to find a correlation backed up by some research that says "people that prepare, study, and do well at this interview also do well at this company". Similar research meant that they needed to stop asking brain teaser questions because it wasn't a good indicator of success.
Perhaps the knowledge of data structures and algorithms can be useful for people who need to design whole architectures and systems, but I think the folks who are fixing bugs, tweaking the UI, or adding small features would benefit more from Code Complete than an Algorithms book.
Sometimes its good to accept that the uncertain things are uncertain.
If i were them, i would find and train good "screeners", people with talent to spot talent and just let them do the job. Sometimes they will only have a hunch, giving their observations of things that escape most people of a particular candidate, and even without much to show of, they might be right.
Later the top screener's would help the new ones to be better at their job, teaching their tricks.
This is very subjective and personalized, and even if there might be some objective ways to train the screener's better, i think its just nuts trying to use objective tests to define a good hire.
I bet with you that there are a lot of "human gold" out there that would only be detectable only when its too late for the company.
There seems to be more emphasis on "the candidate knew to use bubble sort" or something stupid like that instead of "I observed this candidate reason through the problem and I don't really care that they didn't know a canned algorithm".
It's a bad proxy, but better than no proxy in my opinion.
You often need strange problems to really get to see people's problem solving, which is why they're often not things you see in real life, but again, the goal isn't to see if people know how to do the strange thing, it's to see how they approach a novel problem from scratch. Aka problem solving skills.
Explaining your abstract, critical thinking process seems much more valuable. HR screens someone for having the degree, assume they are familiar with all the facts (they can use Stack Overflow when they get in). Just learn how they think and how they communicate.
(In past tense because this "Microsoft interview" style quiz was dropped by Microsoft themselves long ago)
Yes, because at Google & Co. you actually NEED this stuff. I am not sure there is a day going by where being strong in math and computer science isn't immensely helpful for my job.
The problem is: All other companies immitate Google, not only through interviews, but also by copying their "scalability" which is completely crazy. For instance relational databases are perfectly fine for like 99% of companies. Single servers would probably work well for another 90% of companies. Monoliths instead of micro services would work well for 90% of companies... It's crazy.
What Google & Co.'s engineers do is gatekeep. Sometimes it's out of ignorance, sometimes out of inappropriate generalization of their roles to others, and sometimes out of a deep angst caused by working in roles that effectively make almost all their CS-specific trivia next to useless in practice.
This list is, "a software engineering study plan to become a software engineer".
This is good. I took the E&M course for electrical engineers at my university, a very well-regarded engineering school. I ha no idea what I was doing. After every exam, I thought I'd have to drop the course. One of my scores was a solid B, another was the third highest. I got a B because I didn't know how to do the homework. Literally the only thing I could do was get the sign and units right in the multiple choice answer.
I think that a lot of the math subjects that they focus on in colleges can be of questionable utility (Much as I wish this were the case, I don't think I've touched calculus at all since I've started working, outside of the occasional personal projects doing game physics or something), but I do think that having a decent understanding of set theory and discrete mathematics has made me a better engineer, if for no other reason than it made it easier for me to pick up TLA+, which is incredibly helpful when used correctly, at least when designing/building distributed systems.
That being said, I sadly feel like that basically any math is only useful earlier in your career. If you start working for one of the big FAANG-esque corporations, you end up doing substantially less compsci and spend a lot more of your time writing emails or sitting in meetings.
Most technical challenges in my experience end up being reduced to word problems.
All of the stuff you mentioned is probably 10% of it. You can be bad at the 10% if you're great at the 90%.
I think you're misunderstanding the premise here.
Work is always about people. If it's not about people, it's probably research, which is different from work.
That doesn't mean I don't respect a CS education, but I don't think this kind of testing is a good measure of potential.
Everything you've listed - communication, organization, and self-management - are qualities of a strong student. These are skills from college that last. I don't know a single successful student who got by on his own or did so without being extremely disciplined. Outside of the homework/exam grind, college was far more social than work life ever was.
My point being, you need people with a myriad of skill sets, and some of them don't even have to do with expert knowledge needed in some areas.
Also you might have an expert in storage for instance that do poorly in certain tests giving he never needed to work with those kind of algorithms.
So in the end the company ends with the same type, the same kind of person, and how can you make a great team that needs people with different skills doing distinct stuff, if you optimized your hiring to filter for one particular type?
That said, and admittedly I have gravitated to niches that might be more computer science-y niches at points in their hype cycles where lots of research was being applied, but I have occasionally wished I perhaps also had a stronger academic basis in computer science. In distributed systems, people are still writing new schedulers, and I wish I had taken that operating systems class when you had to write one. I don't always understand what my colleagues are talking about with some of the newer functional programming features popping up in languages. Stuff like that.
I do agree there's a disconnect between what universities deliver and what people expect of them (paths into academic research vs. career preparation) and I think a Bachelor's degree is overhyped for that. But I do think you're understating the role of CS theory and fundamentals in high-level software engineering. Just because you don't use many of the lessons does not mean they haven't improved your ability to think, and the general base of knowledge on which you're able to build.
Sure, you can become a "senior" engineer even at a big tech company if you take a more product-focused track, but even there your lack of mastery of fundamentals will eventually limit and stunt your career growth, because those around you at the same level will have that deep understanding and knowledge to pull from when they actually need it for their job.
Notice I didn't say this requires a COLLEGE education, I've met plenty of amazing, very senior engineers in my career with no formal degree or college education, but they sure as hell understood all the underlying fundamentals and theory of their field better than most.
At this level, nobody cares about fundamentals in 99% of companies. Also nobody cared about my lack of mastery of fundamentals during my career. If anything, people were bringing me into companies due to me having "out of box" vision and ability to see the big picture and not getting stuck in details.
Here's one way to look at it: I wear my seatbelt every time I ride in a car, but I haven't been in a serious accident in over twenty years. Does that mean I shouldn't have bothered?
Knowing things allows you to take an opportunity when it presents itself. It's really hard to know what opportunities are going to show up or which doors will be the doors that you want to walk through. But having more of those doors open is generally a good thing.
Of course, there is an opportunity cost to the time spent learning CS versus other stuff you could be learning. But, personally, I've found the CS stuff I've learned to be both personally rewarding and often helpful to my career in unexpected ways.
I'm not challenging your experience, but I am replying to say that mine is the opposite. I certainly have used quite a bit of theory (over a little more than 30 years), not so much explicitly as to think about the problem I'm working on before starting to code, or in the process of discussion about some code with coworkers. Also has helped me look stuff up or learn new things.
Perhaps you've used it more than you think, but merely subconsciously?
And, there is always pride of workmanship. There is a lot of beauty and elegance in computer science, appreciation of these things can have positive effects on morale, implementation quality, maintenance, and performance, and teamwork.
If all someone knows is plumbing API and rote memorized glue code, don't expect much. If someone went through CS, expect to see a different caliber of work for the same task.
Believe me, it's night and day and a lot of orgs have no clue what real engineering talent looks like: they never had any to begin with!
I disagree. See: hordes of new CS graduates that feel they are completely unprepared for an entry-level software engineering job, or their interviewers.
The employer really expects devs to be productive on day one and not have any training to do. Often they whine that a CS education isn't more like a bootcamp. But that's not how it works.
But that being said... there are many different types of engineering jobs. If your company deals with low level stuff, requiring low level knowledge is acceptable.
Like, it doesn't until it does, and when it does, it really does.
I went through school and did just okay in CS. 12 years later, I’m much more interested in topics within CS that felt like chores for my degree.
In the context of getting a majority of job, yeah, it’s not great. In the context of being a better programmer, I think it’s worthwhile to understand the “pillars” on which you are building your “house.”
HN has an interesting dichotomy of love for all things CS and hate for anything that involves interviewing.
So you don't see the sine in the sky from sunrise to sunset?