When applying for a job, how can I detect whether companies have good development practices?

Question

I'm a senior CS major currently applying for software and web development jobs. As much as we talk about development best practices in the software community, I've heard plenty of horror stories about companies that don't really apply them. (For example, see this SO thread)

So, in a job interview (or in the research I conduct before applying), how can I test the company as much as they're testing me? I would like to be able to say something like, "How does your company balance business with developing quality software and code?"

I suspect that some companies would welcome that sort of question, but others may not.

What else should I be looking for? Do you think that a tech company would generally have better practices? What are symptoms of bad development practices?

Answer 1

"The Joel Test" isn't perfect, but it's simple. http://www.joelonsoftware.com/articles/fog0000000043.html

Answer 2

I suspect that some companies would welcome that sort of question, but others may not.

Well, just ask. If they're not open to it, then just go to the next company.

On the other hand, you could also ask to have a (neutral) talk with a (lead) developer about the development methods and if you could have a look at the existing code/projects. This is not uncommon, but this way you can afterwards judge yourself based on the gathered information. The other benefit is that it shows that you're really interested in the work they do and they (at least, the good companies) will appreciate it.

Answer 3

Normally start ups will have lesser practices than larger tech companies, although not always true. You can definitely ask the developers interviewing you the following questions without causing any discomfort

• What is the usual software release cycle?
• What process/methodologies do you follow like Agile? (They may or may not, but this gives a good starting point into starting a discussion about development practices)

Answer 4

All companies will play games with you during an interview to some degree. Unless you know someone on the inside well, you would never find out the whole truth. If you are good/lucky enough to make it to Google, MSFT, etc. then you will not have that problem. But, you can always quit, right?

I started my career as a sys admin some time ago because other jobs were unavailable to me right when the .com bubble popped.

I have come to appreciate the hard-earned dollars. Remember - work is pretty much the only money-making activity. You do not get paid to go to the beach or contribute to your favorite open source project. If you can combine work and hobby - great. Other than that - just deal with it!

In todays economy you might not have a job for some time at all.

Answer 5

Adam is right, "The Joel Test" is pretty good, but I think they only really work when you have the senior tech guy in the interview, most of the time when interviewing with small companies I have been with the owners.

For interviewing with a smaller company (not MS, Google, etc) I have some others questions to ask like:

1. How many clients do you have? This helps to understand if the company is stable enough to follow standards.
2. How many developers do you have? Quick check to know if they have a proper team.
3. Do you have a product manager / project manager?

Also try to understand if they are in panic mode continuously (no time to do things properly, just want a monkey to bang out code) or do they actually do research and development.

Hope that helps

Answer 6

You can never be sure! I would go for the best pay and financially stable company. You learn from both good and bad practices and can actually be a catalyst for introducing good practices. In this industry you should expect changing jobs several time during your career and not all of them will be perfect.

Answer 7

Almost by definition the symptoms of bad coding practises would be bad software. Just ask to see some of the software you would be working on and decide if you would be proud having your name on it.

Answer 8

For me, in terms of procedures, source control/release management and estimating/deadlines are important issues. There are many others as well, but I'd bet most of us have never worked somewhere that scores full marks on the Joel test (useful though it is).

I think it should be well accepted to ask about source control in an interview.

Estimating and deadlines however is a potential minefield. I think you have to make a judgment during the interview as to if and how to ask.

Some interviewers may be relaxed and open, others may seem worried and defensive. This obviously gives you an insight into a very important issue: the culture and "health" of the team. You can also ask to be shown around the programming area to get a vibe for this.

My feeling is that no amount of good practices can compensate if everyone is not working together as a team.

Answer 9

I personally believe that things worthy of The Daily WTF can be smelled from a mile away, especially if you take the interview passing through or at the developer's place.

It is wise to memorize the Joel Test (already mentioned on this thread), as while it is not the be-all of software development, is a neat guideline.

The Joel Test

• Do you use source control?
• Can you make a build in one step?
• Do you make daily builds?
• Do you have a bug database?
• Do you fix bugs before writing new code?
• Do you have an up-to-date schedule?
• Do you have a spec?
• Do programmers have quiet working conditions?
• Do you use the best tools money can buy?
• Do you have testers?
• Do new candidates write code during their interview?
• Do you do hallway usability testing?

You just have to wait until the tech interview, take the previous interviews as a way to try and learn how the company is in the "human resources" and "profitability" areas. It's a smart thing to do to try and see if you can learn who their clients are, how old the company is, how many people are working there, etc.

One great way of asking this questions without sounding like an arrogant bastard is to observe if the interviewer is passionate about development (when on the technical interview). Proud people will take for hours about implementations details and the processes and tools in place. Sometimes, just asking them How do you do X?, you'll get to know the code versioning system in place, the build process, the bug database in use (never seen a company that doesn't use one. Built in house is a red mark.), and if there are milestones.

When being interviewed you will be asked some questions to assess your knowledge. These questions can give you some idea of what the company will want you to be able to resolve, and how it works. If the questions are generic or abstract, out of some book, that for me is a black mark. If the questions are more of the form What tools do you like using or Have you ever used Trac or svn? or What are the relative advantages of git and svn?, then I'm inclined to think that the one on the other side of the table is not just going through some checklist.

Of course, when the interview is nearing its end, the interviewer will ask if you have any questions. Be ready to ask between one and three questions (you won't have time for more and you'll likely be deemed as too inquisitive, if there is such a thing) and ask about some things that weren't completely clear to you from the previous conversation.

I consider that interviewers are expecting questions, any question, as you'll be spending a lot of your time on the company, so you'd want to know what you'd be up against.

Some of the questions I've asked are What tools do the developers use? (If the answer is whatever they like, we don't have a standard, we let the developers use what they want sign then and there!), How many people work on a single project?, How many projects are you currently working on?, What source control system do you use? (If the answer is None. tear the previously signed contract and jump out the window to escape!), etc.

Never bring up the money part of the interview, especially on the tech interview.

One thing that I've seen is that I find more enjoyable, relaxing and fulfilling to work at young companies founded by knowledgeable developers, in contrast to more established companies founded by non-techies. The later tend to be more rigorous with some stupid things (developers don't have root to their machines for security reasons, you can only use Visual Studio 6.0, all apps are to run on IE6) and to not understand some part of development, specially why some really bad module should be refactored (- "It's working! what does it need fixing?" - "It's a .Net accounting app that has code from VB3 plagued with GOTO.").

Answer 10

Just as you are trying to put on your best face for an interview, so is your interviewer. So you won't get the full picture.

Still, you are interviewing the prospective employer as much as they are interviewing you. Do ask deep questions in an interview. It shows that you are truly interested in finding the right job, and that you think deeply about how you want to do your job. Any good interviewer will like that.

Ideally you'll ask a question that the interviewer doesn't have a prepared answer for. Getting to see them think on their feet tells you a lot about what it would be like to work for them. You want a smart boss, right?

If you run out of time during interviews, follow up with more questions over email. When I conducted interviews, I would always give candidates my business card.

The best way to find out where you want to work is to work there. As an employer, we liked interns because we got a really good look at candidates before hiring them. As an employee, being an intern gets you a good look at your employer, without the commitment.

Even though you're a senior, you could say that you're going to grad school, and look for a summer internship. If you like the place, let them hire you on full time, but be sure to ask for more money! Your intern salary shouldn't be your full-time salary.

Answer 11

I always as about the command structure of the company. If the top person in the development department reports to the top person of the administrative department, the company doesn't value development as much as a company who's development department reports directly to the CIO.