I prefer to not conflate "computer science" with "software development." The majority of the problems with tech interviews in the Valley stem from an overabundance of CS grads who mistakenly believe that their academic trivia quiz questions have much value for developing software people use.
Very few programming jobs actually require the more mathy end of CS. If you want an analogy with physical science and engineering, the the algorithms-and-data-stuctures interview is like giving a candidate for a satellite engineering job an interview laden with mid to upper level undergrad physics questions. It's just nonsense.
> Very few programming jobs actually require the more mathy end of CS
I disagree. I'm a lowly web dev who is not in Silicon Valley, but I do know the practical benefits of applying the right data structures and algorithms, even though I don't apply this knowledge every single day.
Yes, nested for loops and a hash table will "solve" almost any problem and you can push the release out the door, but how much will that sloppiness cost the employer/customer in hardware and the maintainer and users in time?
> how much will that sloppiness cost the employer/customer in hardware and the maintainer and users in time?
Next to nothing in almost every case.
In fact that hash table is probably overkill most of the time. Unless you're dealing with keys that have a costly comparison, a large number of key value pairs, or a large number of lookups (for some context-specific value of "large") the most naive and "inelegant" of solutions you could imagine, an unsorted array of key value pairs, is sufficient most of the time. So in fact what you call a "sloppy" solution is probably, and quite by accident, far more powerful an algorithm than the problem truly calls for.
Understanding complexity analysis is useful when the domain has performance demands or constraints that make it necessary. "Lowly" web dev is almost never one of those domains.
A directed graph to represent arbitrary user-defined element-event relationships between fields that triggered changes in values depending on one or more events on other fields. Since the events could repeatedly cascade, skipping transient states drastically improved the performance.
I also avoid using exponential complexity all the time.
What you describe is far more often a CS guy looking for a way to apply his CS education instead of asking whether he's identified the correct problem, and frequently that's because, having only an academic CS background, it doesn't occur to him there might be a more serious underlying problem that has a better solution.
I don't know if it was your intention, but you're almost sounding like a CS education is a handicap to solving problems- this is at odds with my experience (I was an embedded developer before I earned my degree)
Very few programming jobs actually require the more mathy end of CS. If you want an analogy with physical science and engineering, the the algorithms-and-data-stuctures interview is like giving a candidate for a satellite engineering job an interview laden with mid to upper level undergrad physics questions. It's just nonsense.