Forced to settle for a nonideal job? Here’s how to make the most of it

Sounds a lot like a place I once totally noped out of.

Seemed good at first because it was fairly hands off. Turned out I got tricked because the part of their ecosystem I initially got a glimpse of really was just a small thing that wasn't really representative of anything else they were doing.

Most of the tech stack was pretty old and horribly maintained. Frameworks remained severely outdated and obvious antipatterns were used to keep them playing nicely with some things that were at least a bit more up to date. The codebase(s) was way too big and unwieldy for what the product was actually doing. Strings and configuration that were liable to frequent change that should have been served from an API were all hard-coded and required multiple things to be deployed simultaneously for even the smallest modification. The code was just dreadful, and there was an anti-documentation culture in the team. Lots of the other engineers were clueless, and I couldn't blame them because I was clueless as well. The smallest changes took forever to implement without causing significant breakages. The QA team did no automation and failed to catch a lot of things. Code review was an absolute joke. There were tons of dependencies, including ones that were totally nonsensical. The only real sort of coding style or preferred design pattern, if you could call it that, was to use OOP up the wazoo, with several layers of needless inheritance. It was hard to make sense of anything and I was forced to jump through tons of files to figure out how something worked. There were lots of things in the app that no one could explain, and nobody seemed to think any of these things were problems. I'm sure I could have remained there indefinitely, but in my opinion it's damaging to one's sanity to go through the motions and pretend like that's all fine. So I walked.

> A simple thing to keep in mind is that if someone thinks they know better than the veterans in the industry with dozens of textbooks on the subject, chances are they are morons.

That depends on what you are looking for, though. They're probably morons if they are looking to hire a junior developer. If they're hiring someone more senior, I don't think it's obvious that they might be morons.

Honestly, I find what a lot of veterans evangelize about to be bullshit intended to sell books. If I'm interviewing somewhere and I find out that they hate the overuse of OOP as much as I do, going against what a lot of veterans said for years, I'm more likely to be intrigued.

The heart of your first point is totally valid. If something doesn't smell right to you, just move on. You don't even need a reason. Almost every time my spidey senses tingled, they turned out to be right.

> Ask as many questions about the tech stack as possible

I wish I could see the code before I sign an offer. If I could see the code, that can tell me almost everything I need to know most of the time.

> I wish I could see the code before I sign an offer. If I could see the code, that can tell me almost everything I need to know most of the time.

This is why contract-to-hire, for all its downsides shows a strength. Being a contractor, you get the experience of the company without becoming enmired in all its bullshit.

To try to extract this information in the 10-15 minute “what questions do you have for me?” phase of most interviews is nearly impossible.

Many years ago I used svn at an old job. To be honest if I had to choose between mercurial and svn and death wasn't as option, I'd choose svn. Mercurial feels like the product of unsolicited help(which turned out to be the case when I read how it came about). And if you look at how it works underneath, it's practically the equivalent of trying to mass print books using Gutenberg's press in the 21st century.