How to Spot Toxic Software Jobs from Their Descriptions

The first thing is - this is the industry we live in; especially for small companies, it should be expected to have to handle or at least support tangential roles; it should be expected to have more responsibility and lower bus factor; it should be expected that processes, code standards, etc are not matured since this kind of thing often takes time.

The second thing I'd say, is that there are different personality types. Sure, no one wants to be stressed out; but there are a good amount of people that prefer these smaller-company challenges over sitting in large architecture review meetings for months working in a waterfall format (the other extreme).

Some people like to work in a comfortable role, with a predictable schedule, and just color within their lines with the technologies they know, and go home. Others actually appreciate the challenge and difficulty, and see an "on fire" situation and attempting to level up and see if they can get everyone rowing in the same direction, put processes in place that will last, train discipline and standards, and make it a better place to work.

The third piece, is that what I've described thus far I would not use the word "Toxic" for. I would not consider "overworked" to be the same as "Toxic" personally, since it is each person's responsibility to make sure they are lookin out for their own health, and working to an acceptable and sustainable standard. Sure, employers are always going to want you to work more. That said, the line is crossed when the employer demands or forces workers to work beyond healthy or sustainable limits, especially when the worker has clearly communicated these (often, this second part is what is the failure of many devs) - if that limit is crossed, this is what i would describe as "Toxic", including any sort of employer speak which could be described as "abusive."

For example, he reads that a company expects a developer to "facilitate discussions with business partners to determine needs and appropriate solutions." He takes this to mean that he's expected to "be a product owner, a partner manager, and do business development on top of being a software developer". Somehow he misses the part that says "facilitate discussions with business partners" and gets a warped reading.

Then there are parts where the author has some nitpicks (and frankly an unusual perspective for someone who is trying to be a software developer for an established company): "'Possess the ability and desire to dive into an existing codebase and grasp the functionality, design, and refactoring opportunities in the code.' Who desires to refactor someone else’s bad code?" It's just one of many unnecessary and pessimistic quips.

Applicants should keep in mind is that HR departments typically write and edit all of a company's job postings. Many of them try to write in a way that's enticing, but also shows a range of responsibilities that may be expected or skills that are desired. If you're reading a job posting and it interests you, but it has some ambiguities or odd phrasing, it would be worthwhile to reach out to the company for more information, or even just apply anyways. The specifics of the job will be fleshed out much more clearly during the job interviews that follow. Dismissing an opening because the posting expects candidates to have things like "a great sense of humor" is only going to hinder success.