I'm reading The Daily WTF archives and especially those stories about IT-related companies which have a completely wrong approach of software development, the job of a developer, etc.
Some stories are totally horrible: a company don't have a local network for security reasons, another one has a source control server which can only be accessed by the manager, etc. Add to it all those stories about managers who don't know anything about their work and make stupid decisions without listening to anybody.
The thing is that I don't see how to know if you will be employed by such company during an interview. Of course, sometimes, an interviewer tells weird things which gives you an idea that something goes very wrong with the company (in my case, the last manager said I should work 100% of my time through Remote Desktop, connected to on an old and slooooow machine, because "it avoids several people to modify the same source code"; maybe I should explain him what SVN is).
But in most cases, you will be unable to get enough information during the interview to get the exact image of a company.
So how to avoid being employed by this sort of companies?
I thought about asking to see some documents like documentation guide or code style guidelines. The problem is that I live in France, and here, most of the companies don't have those documents at all, and in the rare cases where those documents exist, they are outdated, poorly written, never used, or do force you to make things that don't make any sense.
I also thought about asking to see how programmers actually work. But seeing that they have dual screens or "late-modern-artsy-fartsy furnishings" doesn't mean that they don't have people making weird decisions, making it impossible to work there.
Have you been in such situations? What have you tried? Have it worked?
Remember that interviews are a two-way street. Ask them open-ended questions that let you know they know what they're doing. And learn to "read between the lines" when evaluating their answers. For instance:
How do you guys make sure the software you're writing doesn't suck? (rephrased to something more "appropriate" if you're boring)
Good answer: "We use unit tests, have a QA department, and code reviews."
It doesn't have to be this. Nor does the person you're interviewing need to have the same answer to this as I gave. You're mostly just looking to make sure that the company values the code it writes to some degree and isn't just going to push it out the door with reckless abandon.
Bad answer: "Well, we've been meaning to make more of those 'unit test' things. We just haven't gotten around to it"
Again, the focus is less on unit tests and more about the attitude the interviewer takes to the issue. Generally, "We know we need it, we just haven't done it" is a red flag. That means one of several possibilities:
None of these are good (but some are worse than others).
Describe the process your company uses to add a feature (from deciding that the feature is needed to shipping it to the customer).
Good Answer: "Business people decide that a feature is a good idea and consult the programmers to see how easily-implemented it is. The programmers and technical staff decide on an architecture and implement it. A release team then pushes it out into the wild."
Bad Answer: "Business people tell the programmers what to do and they do it."
As with the above, the answer itself isn't as important as the attitude. The good answer indicates that the business side and technical side work together to bring a product about. The bad answer indicates that management views programmers as overpaid typists.
In summary, remember to ask the right questions during the interview. And remember that particular answers aren't as important as the attitude behind those answers. Lastly, don't hold back. Asking tough questions indicates that you're really interested in the job, and that you think you're good enough to be a bit picky about who will employ you.
External links referenced by this document: