This is how I looked at jail. It gave me time to fix my diet and exercise. It gave me time to read. I read over 800 books while I was locked up. I guess there is a positive side to a lot of things that appear totally negative.
Two very important lessons:
1. Never EVER ignore red flags. Ask about tech stack, procedures, code-reviews, opinions on basic programming principles and everything you can think of. Generally the interviewers should be asking these questions but it's equally important to see how they see the world. 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. If you see something odd, ask more questions. For instance why use mercurial over git: If you get an answer such as "well we evaluated the two options and there really wasn't any benefit to git and only made things more complicated" - run for your life. In the case described here, it turned out that the head of engineering didn't know how to use git and was confused by it.
2. Ask as many questions about the tech stack as possible - there are 3 possible options: One is the company uses what it uses because it was inherited from someone else and they stuck with it. Two, they picked some technology because they wanted to use it and not because they had to. Three is they picked what seemed the most appropriate but are willing to explore alternatives. Ideally you should be looking for the third option.
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.
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.
I think you misunderstood me. I'm talking about the sheer basics from people like Kernighan or Robert Cecil Martin. If someone at a small and largely irrelevant startup had the pretention to know better than them, them they are the definition of morons.