How to Spot a Toxic Software Company in an Interview and Survive the Nightmare

Background : The author, known as "军哥", shares a story about a former colleague, Xiao Li, who joined a software company that turned out to be a textbook example of a toxic workplace.

Interview Illusion : During the interview, the technical director boasted about cutting‑edge tech stacks, engineer autonomy, and generous salaries, convincing Xiao Li to accept the offer.

Code Swamp :

The first task involved a simple user‑info display, but the repository contained a monolithic 500,000‑line codebase with no modularization.

Business logic was littered with hard‑coded values.

A single CommonUtils.java utility class spanned 3,000 lines, offering 27 static methods ranging from date formatting to WeChat payment signatures, and was referenced in over 200 places.

Unit‑test coverage was a dismal 0.27%.

When Xiao Li raised technical‑debt concerns, the team lead dismissed them, saying, "Finish the requirements first, improve later."

Chaotic Development Process :

Product managers could change requirements on the fly, shouting "just a small feature".

No dedicated testing environment; debugging happened directly in production.

Releases were forced on Friday evenings, leading to all‑night work and emergency hot‑fixes.

When issues arose, rollback was considered impossible; the team patched on the spot.

Lack of documentation meant knowledge was passed only orally; when senior members left, their modules became isolated islands.

Absurd Technical Decisions :

The technical director, originally from sales, arbitrarily forced the entire stack to use Go after reading a single article, then reverted to the old stack three months later, wasting three months of effort.

Subsequent whims included sudden shifts to Serverless or Rust, with a group chat titled "What the director read today?".

Team Management Issues :

Performance was measured by lines of code and overtime hours, with promotions tied to overtime.

The so‑called "Agile" process reduced to daily stand‑ups and staying late as proof of effort.

Employees who left on time were reprimanded for "poor work attitude".

Root Causes Identified :

Business model driven by sales; technology is a cost center.

Management lacks technical background; they view software development as mere keyboard‑typing.

Absence of technical leadership; the director prioritises pleasing the boss over supporting the team.

Talent drain creates a vicious cycle of inexperienced or burnt‑out engineers.

How to Identify an Unreliable Software Company (questions to ask in interviews):

How does the company handle technical debt?

What does the development workflow look like?

Is there a structured technical sharing or growth program?

What is the office atmosphere like? Are engineers motivated or exhausted?

Do technical leaders advocate for the team or merely follow the boss?

Is the company technology‑driven or sales/operations‑driven?

Self‑Rescue Methods for Engineers Stuck in Such Environments :

Documentation rescue: read code while writing comments to build a personal knowledge base.

Technical gilding: introduce modern practices (containerization, automation scripts) into the legacy system.

Resume polishing: reframe firefighting incidents as high‑concurrency emergency experience.

Interview deflection: craft a diplomatic explanation for why you left when asked.

After eight months, Xiao Li left the company, citing delayed salaries and a dismissive response from the technical director who refused to invest in unseen value.