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?

10 Answers 10


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:

  1. Your coworkers will be lazy.
  2. Management doesn't give time to use proper process.
  3. Your coworkers aren't smart enough to understand unit tests.

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.

  • Could this be sublimed to something that is best described as a development manifesto? Is that what we should, essentially, be looking for? Commented Jan 31, 2011 at 0:52

You could give them the Joel Test:

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?
  • 5
    +1. I thought about it. The sad part is that most companies don't even have 3 out of 12. Commented Dec 30, 2010 at 23:05
  • 4
    @MainMa I think #11 is exactly what you seek. If no one asks you to write code, it's probably because they can't either. Commented Dec 31, 2010 at 4:37
  • 2
    The sad part is when you ask #1 and they answer no. I have actually got that response during an interview for an intership.
    – HoLyVieR
    Commented Dec 31, 2010 at 17:27
  • #10. The programmers are the testers, is a very common response. Then they will tell you, that the UAT is done by the business.
    – abhi
    Commented Jan 18, 2011 at 17:29

Keep your resume circulating for a month or so after you are hired, and if things aren't up to snuff don't be afraid to take another opportunity. Companies will often view your employment as probationary for a period of time because they want to make sure that you work as well as you interviewed. It's only fair that you do the same if things really are at a Daily WTF level.

  • I think this is a reasonable attitude to take. I would still be worried if the company found out I was still looking around, though. It might be best to take a short break unless things are horrible on the very first day. Commented Jan 2, 2011 at 0:16

I'm going to take the pessimistic and non-traditionally-engineer position on this.

You can't.

Every company, no exception, is a candidate for Daily WTF stories. This is because every person, no exception, no matter what their profession and no matter what their experience, can be a dunderhead in some aspect of their chosen professional life.

Yes. This includes you, the person reading this. (If you don't believe this applies to you, I think we've just found one of your areas of incompetence....)

  • +1 LOL, to quote the great Homer: It's funny because it's true.
    – Orbling
    Commented Dec 31, 2010 at 16:07

Remember that any interview is a two-way street. The employer is trying to determine whether you are a good candidate. Similarly, you should try to determine whether the company is worth working for. Ask a lot of questions. Figure out what's important for you and ask about it. Ask your interviewers what they like and dislike about the company.

Also, I second the other poster's recommendation to give them the Joel Test.


Maybe you could try to see things differently.

Being hired by a company being in the spotlights of The Daily WTF is an opportunity for you to show how you can solve problems. Huge problems.

You may see those difficulties as opportunities.

Instead of using the Joel Test to avoid companies, use it to improve them.

What could be more exiting than that?

If you come in the company with your white horse like Napoleon telling them they are all wrong, you will be kicked out very quickly.

The opportunity there is that you will be able to do constructive proposals, backed with facts and references. If done like described in the previous sentence, you will be proposed to take care of it most of the time (that's the opportunity). In very few cases, you will be ignored.

  • 6
    That very much depends on what you were hired to do and how open management is to having you decide your own duties. A manager that hired you to take care of a specific problem they're having may not take it so kindly if you start doing other work without their approval, especially since they've shown they don't consider that other work important (otherwise someone would already have taken care of it). Commented Dec 30, 2010 at 23:22
  • 12
    It is an opportunity, an opportunity to drive yourself crazy and destroy your soul. Commented Dec 30, 2010 at 23:46
  • 4
    @whatsisname: Between stimulus and response there is a space. In that space lies our freedom and power to choose our response. In those choices lie our growth and our happiness..
    – user2567
    Commented Dec 30, 2010 at 23:48
  • 7
    there are cases where you will not be able to do much of anything, because management will take it as a personal attack if you don't follow exactly what they want. Sadly, such people are far too common. Commented Dec 31, 2010 at 0:32
  • 4
    I largely agree, but there are times when it's better to just cut and run. Of course, you can't really make the decision to run without first giving it a red hot go. Commented Dec 31, 2010 at 0:47

Even a psychotic megalomaniac manager can run a team that passes the Joel Test. How do they react when deadlines are not being met? Does the CIO report to the CEO or CFO? This may give you an idea of how important IT is in a non software company.

Why is the position available? Do they have a lot of turnover?

Look for ways to see if programmers are over-worked. No one has had a vacation in several months to a year? You can't beat a company that gives out vacation time, but no one feels they can ever take it.

You can tweak bad testing practices and code control systems. Can't cure crazy.

  • Getting an idea of turnover strikes me as a very very good idea. You could ask "how big is your team?" followed by "how many people have left in the past year?". Commented Jan 2, 2011 at 0:31
  • @PeterAllenWeb - I like the way you've phrased your questions because you can also find out if the company is growing .
    – JeffO
    Commented Jan 2, 2011 at 3:06

Here is what I would do if I were you:

  • try to obtain the possibility to interview one or more programmers in the company, and ask them what's a typical day in their job. That may be difficult to ask if they don't provide it, but a company which does provide it is a huge plus in my book
  • ask them how is a new feature developed, typically, and how the work is shared between programmers.

Both questions end up being the same thing, asked differently to different people. Important points:

  • How are disagreements on technical issues solved in the team
  • How is the work shared among developers
  • How are bugs assigned to people
  • How do you make the decision to design in-house, outsource, off-the shelve ?
  • How do you judge project failure/success

This in complement to the Joel test. Note that there is no "right" answer: it depends on what you are looking for by yourself, what kind of company you are looking for, what kind of company that is (e.g. a startup will be less likely to be able to afford the best tools compared to a fortune 500 one). If the person cannot answer this question, that's almost definitely a bad sign: most likely they have not even thought about those issues.

  • Assuming we were pretty far along in the interview process, if I asked a company for an interview with one of their developers and they refused to grant it, I would be VERY worried. Commented Jan 2, 2011 at 0:27
  • But it is a very good suggestion. Commented Jan 2, 2011 at 0:28

There are a number of obvious, due-diligence sorts of things you can do, like ask them some questions about their process, or try to talk to, or even briefly work with, another developer there. As good as this is, it's also easily spoof-able - even the worst managers often know the right things to say about their methodology ( knowing what to say without understanding the "why" is what makes them bad managers in the first place, right?) and most programmers aren't going to want to bad-mouth the company to a prospective hire - why risk it getting back to someone for one of a million interviewees that goes through the system? (in an unhealthy company where criticism is .. frowned upon... that can be a real risk)

However, you can look at more subjective things - do the managers seem full of buzzwords or honest? Does it seem like a healthy environment?

What's the quality of questions and knowledgeability of your interviewers - this is the process everyone you work with has gone through, remember. Are they asking you stupid questions? HR-type question? Are the coding questions too easy?


As others have already said, interviews are a two-way street....

But there is a subtle psychological factor here which I think a lot of people don't do well: being intimidated into taking a crappy job. This is more of a problem for junior people, but we are all vulnerable to it.

I think a lot of people are of the mindset that you can't really change crappy corporate behaviour, so we take way too many bad feelings in our stride when deciding to accept a job offer. Part of the psychology here is also the power relationship between employer and employee - especially in a bad or competitive economy - one feels like they have to give lots of leeway, even in the face of some rather bad job smells - such as dismally failed Joel Tests, etc.

So effectively, what I'm saying is - a lot of us accept jobs KNOWING they will be DailyWTF jobs. The trick is to be more picky, drill the interviewers hard - and simply not accept crappy jobs unless you're absolutely desperate. There is a balance of course, but it really pays to examine your feelings when deciding if a job offer on the table is a WTF or not. It's easy to convince yourself that you're just being "too choosy and inflexible", when in reality you're ignoring a genuine bad job smell.

Not the answer you're looking for? Browse other questions tagged or ask your own question.