Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Possible Duplicate:
What questions do you ask about a company before deciding to work there?

I'm already familiar with the Joel Test, but it's been my experience that some of the questions there have the answers "massaged" to make the company seem better than it is. I've had several jobs in the past that, for instance, claimed they had a QA process and did unit testing, and what they really meant is "The programmers test the app, and test with the debugger and via trial-and-error."; they said they used SVN but they just lumped everything into one giant repository and had no concept of branching/merging or anything more complicated than updating and committing; said they can build in one step and what they really mean is it's "one step" to copy dozens of files by hand from the programmer's PC to the live server.

How do you go about properly gauging a company's environment to make sure that it's a well-evolved company and not stuck on doing things a certain way because they've done it for years and they're ignorant of change? You can almost never ask to see their source code, so you're stuck trying to figure out if the interviewer's answer is accurate or BS to make the company seem good.

Besides the Joel Test what are some other good questions to get the proper feel for a company, and more importantly what are some good and bad answers that could indicate a good or bad company? I mean something like (take at face value, please, it's all I could think of at short notice):

Question: How does the software team apply the SOLID principles and Inversion of Control to their code?

Good Answer: We adhere to SOLID wherever possible; we use TDD so it kind of forces us to write abstract, testable code. We use Ninject for our IoC container because it's fairly easy to configure - it was that or StructureMap but I find Ninject a bit more intuitive, and who doesn't like ninjas? You're not a pirate, are you?

Bad Answer: Our code is pretty secure, yeah. And what's this Inversion of Control thing? I've never heard of it before.

You see what I did there. The "good" answer uses facts to back it up and has a bit of "in crowd" humor; the bad answer shows complete ignorance of the question - not necessarily a bad thing if you are interviewing for a manger/director position, but a terrible answer and a huge red flag if you're interviewing as a developer and talking to a senior developer or manager! My biggest problem at the moment is being able to take a generic response and gauge whether it's the good or bad answer; more often than not it's the bad kind and I find myself frustrated almost from day one at the new job.

I suppose I could name drop if I ask about specific things (e.g. "Do you write unit tests?" and if the answer is yes, ask if they use NUnit, MbUnit or something else; if they mention data access ask if they use a clean ORM like NHibernate or something more coupled like EF or Linq) but is there another way short of being resolute to actually call the interview on things (which will almost certainly result in not getting the job, but if they are skirting the question it's probably not a job I want).

share|improve this question

marked as duplicate by Karl Bielefeldt, Thomas Owens, Ryan Hayes, Walter, Anna Lear Jun 21 '11 at 3:03

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Never judge anyone based on whether they know acronyms and jargon. –  Satanicpuppy Jun 20 '11 at 18:30
Maybe, but in my experience not judging people on their knowledge of jargon leads to bad jobs that make me miserable because I understand acronyms and jargon, and I don't function in an environment where I'm the only person who knows that stuff. –  Wayne M Jun 20 '11 at 18:36
Don't ask whether they use NUnit or MbUnit, ask what framework they use. In general: always ask open questions that start with "what", "which", "where", "how", etc. It's what every interviewer should do and thus what you should do when interviewing the company / employees of the company to find out whether you want to work there. It makes for generally much more interesting answers! Closed question will just give you "yes" or "no" without any additional information that you can use to assess the other side. –  Marjan Venema Jun 20 '11 at 19:23

3 Answers 3

up vote 3 down vote accepted

What do you like most about your job?

What do you least like about your job?

(you can replace "your job" with "working for company X" if you want, although that sounds a bit more canned)

Ask it of every person in the room, in order and organized. Go down the line or lead with this question, especially if there are management and technical people in the same room with you. What you're looking for is honest and open answers. If the technical people (peons, like the job everyone is applying for :) ) are evasive or overly careful in how they treat the second question, then you have an indicator of a negative work environment. In other words, if the workers can't be honest and open about what they don't like about their job in front of their manager and peers, then that can be an indication of a very bad thing. None of the interviewers should be surprised by how their peers reply to this question (the manager shouldn't be learning anything here, if s/he is, that's a bad thing). Don't get hung up if they have complaints, the worst possible answer is "nothing, everything is great!" which translates to "I'm terrified of my boss" or "I'm terrified of my real answer's impact on office politics." The first question is more to break the ice for the second question than anything else, but you might learn something new from it (but that's not why it's there).

If things are going well, ask them a similar question to one they might ask you: "Tell me about a time when two developers had major technical differences of opinion. How was that resolved?" Oddly enough, some of the same questions they'll ask you are also appropriate to ask them (in altered form).

To recap, you don't care what they say on the second one, just that they can say it openly.

And another...

How long have most of the people been in this group?

(in other words: what is the average time-in-group)

This can be tough to interpret without some side data, but a short time-in-group can mean that there's a lot of overwork burnout, or an ineffective recognition/reward system. It could also mean that it is a new project, or even that a bunch of people took maternity leave at the same time. A long time-in-group can frequently mean everything is pretty entrenched, so if you're a "change the world" type that may not be a good fit for you.

share|improve this answer

A question I normally ask is, "take me through a typical day at work at your company". If they decline to answer or answer with something very genericd like "well, you show up, you program for a while, you have lunch, program more and leave", it's probably a very free-flowing structure with a lot of "lone wolves". Answers with a lot of specifics about time and procedure indicate a very regimented work environment. Listen for buzzwords that might indicate Agile practices like "daily stand-up", or of XP tactics like "pair programming". The environment that will work best for you depends on who "you" are; IME, lone wolves and Agile/XP don't mix. Regimented structure may be good at the entry-level, but seniors generally like flexibility of schedule and of decision making.

Also ask them to talk about the last project that was initiated and brought to completion. They won't be able to give specifics of course, but if they can talk in a general fashion about what happened to conceptualize, develop, then implement the product, and how involved other people at your position were in the whole process, you'll get a good sense of your overall duties and the corporate culture.

share|improve this answer

I've asked to walk around the development team area. I told them I wanted to get a sense of the team atmosphere to see if I thought it'd be a fit. In reality I was looking for artifacts of healthy development (e.g. burndown charts, CI build break lights, white board discussions). You can get a strong sense of a development team by walking amongst them for a few minutes.

As a side, the healthy organizations seemed to relish at the opportunity to show themselves off to me. The bad ones usually gave a line about "security concerns" of me walking through the halls.

share|improve this answer
There are places where you can't see the development environment, however. I've actually interviewed at organizations where I had to interview off-site because I couldn't get through the front gate. But even if you can't visit the development environment, you should ask about it. –  Thomas Owens Jun 20 '11 at 19:17
That's a very good point. Thinking back, the times I could see the development environment or meet some developers turned out be alright companies (although I didn't always get the job) and the ones that were very hush hush or seemed annoyed that I was asking them questions were the absolute shitholes. –  Wayne M Jun 20 '11 at 19:30
never heard of a build break light –  Woot4Moo Jun 21 '11 at 0:29
@Woot4Moo I worked at a place one that had it (I don't know how they set it up). It was a lava lamp that was green if the build compiled/tests ran, I think blue when compiling and red if something failed. It was pretty neat, actually. Of course that was the one and only job I ever had (it was a contract) where they even HAD a CI setup or even knew what CI was. –  Wayne M Jun 21 '11 at 2:28
@Woot4Moo My favorite build light was an old traffic light (side note: those things are huge!) that the team had wired to a basic RS232 controller connected to their CI server. When things were fine: green light. Broken build: red light. Build running, but over 30 minutes: yellow light. Everyone knew how they were doing at all times and there was real pressure within the team to keep working until it was green. –  Christopher Bibbs Jun 21 '11 at 11:57

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