We hear much about code smells, test smells, and even project smells, but I have heard no discussion about employer "smells" outside of the Joel Test. After much frustration working for employers with a bouquet of unpleasant corporate-culture odors, I believe it's time for me to actively seek a more mature development environment.

I've started assembling a list of questions to help vet employers by identifying issues during a job interview, and am looking for additional ideas. I suppose this list could easily be modified by an employer to vet an employee as well, but please answer from the interviewee's perspective.

I think it would be important to ask many of these questions of multiple people to find out if consistent answers are given. For the most part, I tried to put the questions in each section in the order they could be asked. An undesired answer to an early question will often make follow-ups moot.


  • What constitutes "well-written" software?
  • What attributes does a good developer have? Same question for manager. Who are your most valued employees/managers, and why?


  • Do you have a development process?
  • How rigorously do you follow it?
  • How do you decide how much process to apply to each project?
  • Describe a typical project lifecycle. Ask the following if they don't come up otherwise:

    • Waterfall/iterative: How much time is spent in upfront requirements gathering? upfront design?


  • Who develops tests (developers or separate test engineers?)
  • When are they developed?
  • When are the tests executed?
  • How long do they take to execute?
  • What makes a good test?
  • How do you know you've tested enough?
  • What percentage of code is tested?


  • What is the review process like?
  • What percentage of code is reviewed? Design?
  • How frequently can I expect to participate as code/design reviewer/reviewee?
  • What are the criteria applied to review and where do the criteria come from?


  • What new tools and techniques have you evaluated or deployed in the past year?
  • What training courses have your employees been given in the past year? What will I be doing for the first six months in your company (hinting at what kind of organized mentorship/training has been thought through, if any)
  • What changes to your development process have been made in the past year?
  • How do you improve and learn from your mistakes as an organization? What was your organizations biggest mistake in the past year, and how was it addressed?
  • What feedback have you given to management lately? Was it implemented? If not, why?
  • How does your company use "best practices?" How do you seek them out from the outside or within, and how do you share them with each other?


  • Tell me about an ethical problem you or your employees experienced recently and how was it resolved?
  • Do you use open-source software? What open-source contributions have you made?


I liked what @jim-leonardo said on this Stack Overflow question:

Really a thing to ask yourself: "Does this person seem like they are trying to recruit me and make me interested?" I think this is one of the most important bits. If they seem to be taking the attitude that the only one being interviewed is you, then they probably will treat you poorly. Good interviewers understand they have to sell the position as much as the candidate needs to sell themselves.

@SethP added:

Glassdoor.com is a good web site for researching potential employers. It contains information about how specific companies conduct interviews...

  • 6
    from the title, the answer that leaps to mind is "like a dog"; please rephrase the question to be less...gross ;-) May 30, 2011 at 18:10
  • 4
    @Steven A. Lowe: Agreed. There's no way to thoroughly smell a prospective employee that won't make the interview seem thoroughly creepy. May 30, 2011 at 18:13
  • 1
    @Steven, the set of questions is likely specific to programmers. May 30, 2011 at 20:50
  • 2
    Do you really want to be asking questions about Ethics in an interview?Also how thoroughly you vet your prospective employer is a sure shot indicator of how much he might not hire you. Do you want to risk appearing as all bark and no bite? IMHO only few and good questions ( most appropriate at that time and situation ) must be asked.
    – Aditya P
    May 31, 2011 at 5:24
  • 1
    @Aditya, I'm afraid I don't understand your questions. glenviewjeff made it clear that he cares more about these things that just getting any job, so I don't see why he wouldn't ask. Otherwise he could just stay in his current job.
    – Benjol
    May 31, 2011 at 8:08

17 Answers 17


Look closely at the product you'll create. I work for a good ethical boss but I really dislike the industry that we are in. I wish I would have thought about that before accepting the position. I am now trying to transition away from it but most companies don't understand the niche enough to evaluate my work.

  • 6
    +1 "dislike the industry we are in". Boy, there are enough of those! Lotteries, mass advertising, some finance areas, etc. I once worked for a guy who invented a popular database package. Know who one of the best customers was? The Polish secret police. It's not easy to do well and do good. May 30, 2011 at 17:27
  • 2
    "Most do not understand the niche enough..." what niche is this? Now I am curious.
    – Chris
    May 30, 2011 at 17:35
  • +1: Also "dislike the industry we are in". I once wrote software that enabled people to do derivatives trading.
    – Bob Murphy
    May 30, 2011 at 18:18
  • @Mike Dunlavey, development of a mass-killing robot vehicles automatically attracts a sort of people, who will really like such a thing (not sure about lotteries though)
    – kagali-san
    May 30, 2011 at 18:57
  • 1
    @mhambra: I once worked for a defense lab. I didn't, but the lab did, build computers and guidance systems for nuclear missiles. We got picketed regularly. The people doing the work were just like you and me. May 30, 2011 at 22:36

Don't settle for one word answers

It's ridiculous to try and make an informed decision based on the employer using "Agile" or "SVN".

  • Ask questions that are your minimum criteria for working at a place, but get them involved in a discussion about it.
  • Ask to hang out with/work with/pair with a programmer for an hour.
  • Ask for a walk through of a typical day.
  • Ask what their standard release to production involves.
  • How often they work weekends, Holidays, late nights, etc.
  • Ask what process problems they are working on fixing


  • One word answers and a change in topic
  • Many late nights and weekends spent working
  • Antagonistic relationship with Ops or QA
  • Day-to-day involvement of the manager for task assignments and changes

Find out about the people who work there.

Processes are nice and all, but processes are implemented by, and followed by (or ignored by), people. If you have the right people, you can adjust the processes as needed.

For each of your questions, I would add meta-questions, e.g.:

  • Who decides what constitutes 'well-written' software?
  • What if there is disagreement?
  • How do we evaluate whether our definition is helpful?
  • How do we update our definition as state of the art or company priorities change?
  • What are the processes for creating 'well-written' software?
  • How do we evaluate those?

and so forth.

  • 1
    I like your questions very much, but I'm not sure what answers I would want to them, and even if I knew, I'm not sure they would be as important as a clearly defined and documented idea of what constitutes well-written software. The answer I'm looking for is the list of "-ilities," understable, maintainable, extendable, etc. How that's implemented will change over time, but the "ilities" should not. If the company values these, and a particular employee doesn't like it, I suppose the answer I'd like to hear is that they would patiently try to convince the employee. May 31, 2011 at 16:44
  • 1
    +1. I was lied in an interview about my potential role. It is difficult to lie to someone who does the same work as you. Jun 28, 2011 at 13:26

I'll add a caveat to this after several bad experiences: Many companies will lie or mislead you about their answers, especially in situations where you can't easily verify it without looking at their code (which they will never let you do).

For instance, if you ask about Version Control they may say they use Subversion, so you think okay good they use SVN. Except they don't have repositories set up properly, or everybody has their own repository, or they don't understand branching/merging at all. You can't verify that kind of thing.

Same goes for actual coding practices. If you ask them about coding standards they might tell you they follow, let's say, the "normal Java conventions". Upon taking the job you find they use Hungarian notation (I hate to pick on poor Hungarian notation as much as I do, but it's the first thing that pops in my mind all the time), refuse to touch any open source packages outside of Java itself, and basically write code very poorly compared to the "standard" of writing Java. Again, you cannot verify that without actually saying "Show me your code" which they will refuse.

Sure, you can find out if they're lying about testing by asking what unit test software they use ("The Visual Studio Debugger" is not a unit testing application...) or if they don't use version control at all, but you won't know if the code is bad.

On the non-coding side of things, again it's very hard to actually tell what is embellished. They might tell you one thing (everyone always makes their company appear amazing in interviews) and taking the job it turns out completely different or obvious lies. I hate to say it but many companies are founded on a "smoke and mirrors" approach and that stench permeates every corner of the place. As always there are exceptions, but I have yet to find a good, solid way of gauging the worth of an employer until I actually take the job and, if necessary, leave immediately upon finding out it's no good.

  • 1
    I have worked for many companies where the rosy picture painted during the interview is laughable once reality hits. I wouldn't look at it as if the interviewers were outright lying, and give them the benefit of the doubt that they may actually think they were being completely honest with you, but didn't think about things the same way. I think that's probably why it's best to make sure the questions are answered with enough detail that unless they do explicitly lie, you will have a better idea what you might be "in for." I.e., ask them to explain their branching strategy. May 31, 2011 at 15:52
  • @glenviewjeff Agreed 100% there. Often being more in depth than usual results in being able to figure out when you are being fed the "company line" and the environment isn't really good. Another thing I'd add to the list of what to ask is about their coding standards (variable naming, and the like): A good "best practice" style is good, no style at all or very strange styles are often bad. May 31, 2011 at 18:13
  • I havn't had a problem getting to look at code once I signed the NDA.
    – snakehiss
    Jun 1, 2011 at 5:23

One thing i ALWAYS do is ask to be shown around the companies working / office areas (as opposed to nice corporate boardrooms where you get interviewed). This gives you an idea of the working conditions, equipment used, demographics of your colleagues and general vibe of the place.

... And yes I learnt this lesson the hard way :(


  • Very good idea as well. Too many companies have shitty working conditions (tiny cubes, open spaces) and "hide" the poorer members of the team so people don't notice them and run away screaming while only showing the posh areas of the building (executive offices, meeting rooms, etc.). I make it a point now to always ask to see the developer's area. Jun 28, 2011 at 12:16
  • +1 Also make sure you see the locations that matters to you. ie the place where you team hangs out, the kitchenette, the cafe, your teams' desks, meeting rooms etc.
    – tehnyit
    Jun 28, 2011 at 12:46

Another thing I thought of: If you ask the interviewer what they like/dislike about the job, keep this caveat in mind:

The "good" answer is one that mentions the good and bad parts of the job

If the interviewer is all giddy and telling you how amazing the company is and how great the job is, be careful as it could mean the interviewer is a "Smithers" and is just a corporate yes-man and ass-kisser - many people, especially those complacent in their job (read: got promoted due to tenure without skill so wouldn't be able to find work outside of this company) tend to "buy into the company line" and wouldn't ever be able to see any problems even if there are problems. This is not always the case, but if you get an answer that smells like somebody drunk on corporate kool-aid you should investigate further to make sure.

On the flip side if the interviewer starts to rip into the company, it's a huge red flag because, obviously, they aren't happy with their job and more importantly they can't bring these concerns to anyone in the company since they have to vent to somebody that won't snitch on them for not being happy; again from experience I have seen places where if the executives think you aren't happy (for legitimate reasons or otherwise) they will fire you immediately, so everyone just pretends to be happy all the time because they can't tell anyone they don't like X about the job or they'll be shown the door.


I'd move code reviews either into their own section, or as it's own point under improvement (not testing). I'd also ask what kinds of reviews they do: Do they encourage pair programming (an immediate NOT A CHANCE IN HELL from me usually ;))? Do they do reviews prior to every commit? Do they do quarterly group reviews (this could also fall under mentoring)?

For me, when evaluating a company, I do ask a few specific questions, mostly related to the Joel test, but rather than concentrate on those (especially with a smaller company), I'd rather concentrate on the person I'm talking to and their passion and drive. Even at large companies, more times than not, you'll find similar personal and professional characteristics throughout the employee base. So, chances are that if the person who is interviewing you isn't driven and passionate about what they're doing, other will not be either. For me, passion is much easier to determine how I will enjoy working for a company than going through a list of questions, even over the phone (I recently spoke with a CEO from a startup whos passion and excitement was absolutely infectious, so I know it's possible :)).

Passion determines a solid company far more than a list of black and white questions. You can encourage and help steer change in a passionate company with a broken development process (you'll find that if they love what they do, they're always willing to change for the better). However, a company (or leadership) with a lack of passion but the best process in the world will always be a drag to work for..

  • +1 for the "smaller company" part and the passion argument. Formal code review and team evaluations are less important when you're working in a small team full of passionate, skilled programmers.
    – tdammers
    May 31, 2011 at 9:11
  • To me it's less about the specific implementations and more about the culture and how open-minded the organization is and how truly interested they are in continuous improvement of the company as well as the individuals. May 31, 2011 at 15:47

Glassdoor.com is a good web site for researching potential employers. It contains information about how specific companies conduct interviews and what salary you can expect for certain positions.

All of their information comes from community members, so it may be a small sample size.

Despite that, it seems like a great place for people to discuss their interview experiences.


You haven't mentioned any quality of life questions. Especially frequent issues in software development companies are problems with scheduling and hours, so I'd ask about how often people come in each week and how long they are there. Although I'd try to find a subtler way to say it, so as not to imply that I don't want to come to work.

  • good point, although I can't imagine that if the other questions were well answered, that the same company would fail to recognize that "quality of life" is important to employee satisfaction resulting in higher quality of work. I suppose it couldn't hurt to ask the employees what kinds of hours they work, including how often there is "overtime" or weekend time, and how often they telecommute. Jun 5, 2011 at 16:26
  • 1
    If it wasn't that so many companies are clueless to the benefits, I would always ask how much flex time is available; developers do not like to work rigid hours like factory workers - I'd love an environment that understands this and lets you come in later but eat lunch at your desk or leave a little later, and not this "You must be in ze office at 8am sharp or you von't be comink in anymore" garbage that you find so often. Jun 28, 2011 at 12:18

Ask to meet with someone familiar with the automated software deployment process. If they say, sure, you can meet with Joe or Mike, then fine. If they are vague, then you have your answer.


Apart from the technical questions, I would also throw in some business related questions. Such as...

1) How is your business going to support my employment?

2) What is the business model that your company is using?



Depending on how the interview is going, and how much rapport you have built up with your interviewer, i think it ok to ask 'Why shouldn't I work here?' after all people dont usually leave due to the selling points of the company, they leave because of the bad points, but if you know in advance what they are, then you can assess whether you can deal with them beforehand.


Some has touched on this but not specifically: ask for things you hate as if you liked them. For example, if you dislike the idea of paired programming (to take an example from Demian Brecht) do ask about it.

Finally. always ask: "What is the most frustrating thing about your job?"


Try to find some of the employees' Twitter accounts. If you see them mentioning overtime or long work hours a lot, it might be wise to investigate a bit more or even avoid the company.


I would always recommend trying to find out what a company is like before deciding whether to work there. There are places where you can find it – websites like http://www.whataretheyreallylike.com – where employees review their own employers. They can’t tell you everything, but they’re worth a shot, eh?

  • As long as it's taken with a grain of salt (see earlier comment regarding Glassdoor), agreed 100%. Seeing what employees think of the company can often help if you can weed through the "dreg who couldn't work anywhere else so makes the company their life and thinks it can do no wrong" and "disgruntled person wanting to ruin the company due to some perceived sleight" type of reviews. Oct 19, 2011 at 13:46

Companies often hire those recommended by their employees. If you network in your own geographic area by attending code camps and other dev related meetings, you can find out from employees of other companies what their conditions are like in what is far more likely to be an honest fashion than in an interview. Then you know who to apply to. And you also have people who work there who will recommend you.


Make sure you are associating yourself with quality people who are under managment that recognizes they are quality people. I know that's subjective and so is your preference for where you want to work. You'll have to determine what you think is important. You can have a long list of questions, but you'll probably be able to figure out the people on your own. We tend to be able to smell our own kind.

They may not be implementing the best practices, but are capable of doing it and are in the process of improving. Are you going to pick a company that wins on the Joel Test by a couple of points only to find out they are all set in their ways and have not desire to improve? I personally would have a problem with that. Even a perfect score won't last forever if they can't continue to attract quality people.

  • I may be in the minority here, but I really don't think the Joel test is by any means sufficient to determine the quality of a workplace. My former employer would have scored pretty well on the Joel test, but was terribly dysfunctional, closed minded, and inefficient. Oct 19, 2011 at 16:33

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