Ask HN: How to advocate for prospective employers to show us their codebases?
The truth is, most codebases are terrible. In any company that&#x27;s been around for more than a year, you&#x27;re likely to find most (or all) of the following:<p>* Legacy code that was written by people who left long ago and nobody wants to touch<p>* Code written in &quot;uncool&quot; languages, frameworks, and libraries that nobody wants to touch<p>* Code that was written by various offshore contractors<p>* Non-deterministic test suites that randomly fail and that engineers learn to skip&#x2F;ignore rather than address<p>* Long build times<p>* Weird, bespoke code that was written for &quot;fun&quot; rather than using an established library or framework<p>* Microservice hell - impossible to tell what the codebase actually does since the true business logic is distributed 
across so many different services, and only an old-timer will be able to tell you how they all connect together
* Severe lack of internal documentation<p>Given the above, when trying to select an employer, I think it&#x27;s more important to carefully evaluate the <i>people</i> you&#x27;ll be working with:<p>* Are they pragmatic or idealistic?<p>* Are they chasing fad technologies or are they comfortable using established frameworks that get the job done?<p>* What do they value more highly, delivering useful software or developing byzantine processes for everything?<p>* What percentage of the workforce is full-time vs contractors?<p>* What&#x27;s the average years of experience of the engineers? Are there any adults in the room?<p>* Do people know the vision of the product? Do they what they&#x27;re building and why they&#x27;re building it?