Forced to settle for a nonideal job? Here’s how to make the most of it
I was in a job I absolutely hated up until not that long ago. Initially I was very happy with it - as a developer, I loved the fact that there were no calls lasting hours filled with made-up acronyms and the usual &quot;we should&quot;, &quot;we must&quot; and all that. But to be honest there were other red flags from the very beginning which I completely ignored(and I shouldn&#x27;t have). The tech stack was horrible: infrastructure was 2010-ish at best, the deployments were absolute rat shit(45 minutes to deploy a new version on single digit number of servers, just deploy, which included no tests and no builds), the code was equally horrible - linters were a no-go(the so-called head of engineering had his own understanding of how code should be formatted), open a random file and you will see every anti-pattern known to man. Dependency tree was 500 lines long. Every common problem had a custom solution instead of the freely available industry standard ones. And speaking of the code, it felt like seeing the large perl codebases with 30k+ line files from the mid 2000&#x27;s: mixing paradigms in a way which only makes sense to the person who came up with them and no one else. Needless to say that a few months into it I hated every single bit of it. Worst of all is that for one reason or another, the developers were not only fine with all this, they had picked up every single last bad habit - mixing functional and object oriented programming, the wretched formatting, everything invented past 2010-11 was considered witchcraft and so on. I admit, I tend to swear when I don&#x27;t like something I work with. But here I was swearing all day, every day from the depths of my throat. I can&#x27;t describe how awesome it felt to do a $find -iname {company_name} | xargs rm -rf after my last day.<p>Two very important lessons:<p>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&#x27;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 &quot;well we evaluated the two options and there really wasn&#x27;t any benefit to git and only made things more complicated&quot; - run for your life. In the case described here, it turned out that the head of engineering didn&#x27;t know how to use git and was confused by it.<p>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.