Software Engineering ≠ Computer Science (2009)
Software engineers need to know to recognize and classify problems in CS. You need to know what algorithms and data structures exist, what their properties are, and what they are called. The areas that come up will come from Math and Computer science (which are closely related). A solid computer scientist person knows how to derive some Dijksttra algorithm from first principles. A good software engineer <i>recognizes</i> the problem at hand, and recalls the algorithm to pick when presented with the problem.<p>What is that problem in front of you? Gradient descent? Tree traversal? Multiple dispatch? Path finding? 
What structure represents the data or algorithm? Ring buffer? Blocking queue? Bloom filter?<p>You rarely need to remember a pathfinding algorithm or trie implementation by heart. What&#x27;s important is that you a) recognized the problem at hand as &quot;path finding&quot;, &quot;bin packing&quot; or whatever. Terminology is <i>important</i> here. The good software engineer needs to know the proper names for a LOT of things. Recognizing and labeling problems means you can basically look up the solution in no time.<p>So CS is definitely very relevant for software engineering - but you need a broad understanding instead of a deep one.<p>There is always the argument that a lot of devs basically to monotone work with SQL and some web thing in node and rarely even reach for a structure beyond a list or map. That&#x27;s true - but sooner or later even they bounce into a performance or reliability issue that&#x27;s basically <i>always</i> due to incorrect choice of data structure or algorithm. I&#x27;m only half joking when I suggest that most of todays &quot;scaling&quot; is compensating for CS mistakes in software.