I frequently hear this basic point: &quot;Software interviews test algorithms and data structures that are so <i>clearly</i> not relevant to the work being done and soooo theoretical I don&#x27;t understand why interviewing isn&#x27;t better???&quot;<p>I used to believe this myself, mostly because I didn&#x27;t have a strong CS background and was still successful at carrying out  software projects at a relatively high level.<p>The truth is, as I learned more CS I learned that these things are actually pretty crucial.  Not necessarily for executing one single project, but for building a large system that scales reasonably?  Absolutely.  I spent years reinventing the wheel of basic data structures and algos simply because I did not know them or how to use them.<p>Bottom line: I would not want to work with the me of 5 years ago because I wrote shitty code while proudly proclaiming that CS was theoretical bullshit that didn&#x27;t matter in web development, and I think many people who make these types of claims really just don&#x27;t understand how applicable a good CS foundation is.<p>I&#x27;d agree that ideally you want some kind of work sample as well.  Either an OS contribution, github or even small project written specifically for the interview.  You can&#x27;t ask someone to write enough code on an interview that you really see what happens when they have to structure a real project (ie: thousands of lines) or work within a real system (ie: millions of lines).  This is where CS foundations in interviews have their relevancy.