How do you ascertain the quality of a potential employer's code before you take a position? [closed]

Question

In my experience before you start working for a company you have no opportunity to look at the code-base (I've asked and for reasons of confidentiality everyone has always said no, I think that is fair), so during the interview process what do you think are the most important questions to ask to find out what kind of state the code is in (after all, if it's a dog, then you are going to be on of the poor unfortunates who has to walk it every day)?

UPDATE:

A check-list: Ask;

• What they think of the codebase. And when you do, pay close attention to facial expressions and the time it takes for them to respond. [Anon]
• What is the company's CMM level [DPD] (and if you hear Level 5 run the other way [Doug T])
• What lifecycle they use [DPD] (And if you do hear "Agile", that's when you start asking some penetrating questions to try to figure out if by "Agile" they mean "Agile or "cowboy coding" [Carson63000])
• What tools they use to asses code quality? [DPD]
• What tools they use for development? [DPD] (Look for refactoring tools and continuous build servers)
• What source code (version control) system they use, and a good follow up is to ask why they use it. [Zachary K].
• What are their testing procedures like? [Karl Bielefeldt] (Look especially for teams that use mocking frameworks and place an emphasis on thorough automated unit testing through established frameworks like NUnit / JUnit; don't be put off by teams that don't use test driven development TDD, but be wary if they don't consider testing to be integral to and the cornerstone of solid software development. Look for teams with dedicated testers.)
• What kinds of assignments are given to new developers? To experienced developers? [Karl Bielefeldt]
• How many people work on a project? [Karl Bielefeldt]
• Is refactoring allowed? Encouraged? [Karl Bielefeldt]
• What quality-related process or architecture changes are under consideration or have been made recently? [Karl Bielefeldt]
• How much autonomy do individuals have over their modules? [Karl Bielefeldt]
• Will you be developing newer projects (greenfield development) or legacy projects (brownfield development)? (Greenfield development is generally more fun and has less problems as you aren't cleaning up with someone else's mistakes).
• Is the employee turnover rate is high in the organization or the team? (This often indicates lower quality of code) [M.Sameer]
• Some programming problems of your own; but avoid seeming like a jerk. [Sparky]
• How do the developers collaborate and how is knowledge shared amongst the team? (This should match your personality; I would say a mixture of solo and pair work is probably best, with the ratio matching your social needs)
• How close their database is to 3rd Normal Form (3NF), and if it deviates where and why? (If they say "3NF???", leave. If not, and there might be good reasons for it not, then find out what they are).

NOTE: I've accepted Anon's answer because after about a week the community thinks that it is the best one - I think this suggests that it is just something that you somehow need to develop a sixth-sense for. But, I think everyone has had something valuable to say.

Answer 1

Rather than ask to see their code, ask what they think of the codebase. And when you do, pay close attention to facial expressions and the time it takes for them to respond.

Then apply your knowledge of your culture's non-verbal gestures to interpret what they're really saying. For a North American company, the following should be accurate:

• A small shrug, and quick response of "it could be better": it's probably pretty good.
• A long pause, intake of breath, perhaps a small laugh: it's not pleasant, and the people that you're interviewing don't feel comfortable telling you that.
• Rolled eyes, quick response of "it sucks": might be good, might be bad, but there are political games happening. Unless you're ready to play that game or be a quiet nobody, stay away.
• Raised or contracted eyebrows: they don't understand the question, and the codebase is almost certainly putrid.

Of course, if you have trouble with inter-personal communication, this might not work for you.

Answer 2

I'm surprised that you have even asked. No company will ever show you the code before you have joined. Not even to consultants called in for the process, unless they have signed a confidentiality agreement.

Here's what you can ask to find out.

• What is the company's CMM level(ideally 5)
• What is the process that is followed in your prospective project(BTW, asking this is good because it shows you are interested in "this" job and not just any job)
• What lifecycle do they use (Don't be judgemental if you don't hear "Agile". They may have a valid reason for using the old school models)
• Ask if they use any tools and metrics to check for code quality. And if yes which one (if they use at least one tool for metrics and another for quality it is a good sign.)
• Also note what tools they use. If it is an expensive tool such as Resharper instead of some freeware tool then they are dead serious about quality.

Answer 3

1. Ask them if they use source control.
   • No source control? -> code most likely shitty
2. Ask them how often do code reviews.
   • No code review? -> code might be suspect (but not necessarily so, specially if it is a small team made up of decent developers.)
3. Ask them if how they test and deploy before going into production?
   • No test environment? Direct deployment into production? -> code most likely shitty.
4. Ask them if they do continuous integration (.ie. running builds with Hudson)
   • No continuous integration? -> code might be suspect, but not necessarily so.
5. (Related to #3), ask them if their test environment is separate from your development environment?
   • Test is dev? -> not a good sign, not unless they are really cash-strapped, but how expensive an extra box would be?
6. Ask them if they review an action list before deploying into production.
   • No review of actions before production deployment? -> Bad juju.
7. Ask them how many steps does it take for them to do a build.
   • More than 3? -> typically bad juju.
8. Do they take (or guesstimate) code metrics such as cyclomatic complexity or LCOM (a measure of class cohesion).
   • Yes? -> probably (but not certainly) a good sign regarding their code quality.
   • No, but they understand the concepts (at least cyclomatic complexity)? -> hard to say
   • They think cyclomatic complexity is an exotic dish or aphrodisiac from Timbuktu (in other words, they don't know what that is)? -> possible bad juju.
   • They think that's irrelevant shit (or some other demeanor of the sort)? -> run away.
9. Ask them how they keep track of bugs.
   • They track # of bugs against some metric (.ie. per project, number of changed modules, or number of requirement/change requests, something!)? -> good sign about their code (and their software process).
   • They do the one above and attempt to predict the number of possible bugs they might encounter in a future (or ongoing) project based on an expected metric (# of change requests, project size, etc)? -> very good sign.
   • They keep track of bugs only for bug resolution? -> hard to tell
   • No consistent tracking? -> run away.

That'd be from the top of my head. You'll notice that some of my questions pertain to software development process, and not just strictly on coding. The quality of the later is a direct function of the quality of the former.

With that said, when you ask these questions, proceed with caution. Study them and select a few at the time of an interview.

A couple of things you should keep in mind. A good development team will be glad to hear an interviewed person ask these questions... provided they are asked with tact. Do it wrong, and you'll give the interviewer an impression of arrogance and perfectionism. No matter how good a dev team is, no group is perfect and they all have problems to solve, compromises in quality and such. They want a team player with a penchant for quality, not a disruptive perfectionist. So be careful.

Also, there could be cases where you have a team of good people that by external circumstances must work in code that is of sub par quality (they might be junior developers, or they simply inherited a pile of crap they must now work on with limited resources devoted for improving quality.) You can work with shitty code and still have a good working experience if the people around you are also good people (both personally and professionally). Give them the wrong impression when you ask the questions, and they might just avoid hiring you altogether (robbing you the opportunity to work with good people on a very hard and challenging situation.)

• btw, I whole-heartily believe it is a must for a software developer to have worked at least once with some type of beyond-hope (or near beyond-hope) code. You survive that and get do to a good work, that's a valuable lesson.

You might also encounter a shitty development group with shitty people. Obviously then, their code will be shitty, and they'll flunk at any of these questions. They might despise you for asking them hard-ball questions (and thus might be doing you a favor), or they will hire you because they need you (even if they are/will be incapable of working with you.)

When that happens, then you have to ask yourself whether you need this job that bad. Sometimes you do, and you have to take a plunge in a pile of spaghetti shit. Sometimes you do not (meaning, you can afford not to.)

Those are the things you need to take into consideration when/if you chose to ask an interviewer about the quality of their code and software processes.

Answer 4

Instead of actual code quality, I would rather look for a company where the importance of code quality is well understood.

For example, say company A has managers who believe that "planning is wasted time" and "we can fix design problems later on (e.g. when hell freezes over. We'll have time then)". Even if that company happened to have a good code base now, they won't have it for long. And you'll be the one who will (be forced to) make it worse.

On the other hand, say company B has a bad code base, but management understands that the code quality is causing all those bugs and delays, they see the need for change, and they're willing to do something about it (e.g. large scale refactoring or even rewrite). That company will improve its code base, and you can help them make that happen.

I know where I would like to work.

Answer 5

There is a 99.9% chance that you will not be able to see code before you start. (Unless they put out free software product of course)

So what can you do, I would ask about process, in general good process will produce good code. I would start with the Joel test, and ask about development method. Also go beyond the basics. For example, I always ask what source code system they use, so a good follow up is to ask why they use it.

Answer 6

The place I worked with very high quality code basically didn't allow two thirds of the developers to touch the code. The others wrote automated black box test scripts instead. If you proved yourself worthy of changing the actual code, the requirements were so extremely overspecified that it was basically nothing more than a transcription into source code. The test scripts were actually more fun to write.

The places I've seen the lowest quality code were exactly the reverse: only relatively untrained or unmentored programmers ever touched the code, usually because it was a tool not directly related to the company's product, or deemed experimental.

The most pleasant places to work have a balance. New developers are given real assignments, but mentored. There is a good QA department and peer review process to catch your mistakes. You are not punished for making mistakes, but are expected to fix them and learn from them. Occasionally, a badly-written module falls through the cracks, but you are not criticized for spending time improving code quality when you come across those. The company as a whole is continuously striving to find new ways to make the code better.

Therefore, the questions I would ask to assess code quality are:

• What are your testing procedures like?
• What kinds of assignments are given to new developers? To experienced developers?
• How many people work on a project?
• Is refactoring allowed? Encouraged?
• What quality-related process or architecture changes are under consideration or have been made recently?
• How much autonomy do individuals have over their modules?

Answer 7

As @DPD and @Zachary said, process and SDLC are very important factors but I want to add some other factors that according to my experience have significant impact on the code quality:

• Ask if you are going to work in development in a relatively newer project or in maintaining legacy application. Legacy applications tend to be less clean than newer project.
• Try to know if the employee's turnover rate is high in the organization or the team. This will most likely to lower the quality of the code as well.

Note that a process does help much but it will not give total immunity against the above factors. When many developers pass on a project, every one comes with a different mindset. The architect and the developer will not follow the exact way their predecessors did which will lead to some inconsistencies.

Answer 8

My attitude is this, code is code, if it's bad, well it's a challenge to make it better. If it's good, well it's an even more difficult challenge to make it better!

Most important for me is whether I want to work for the company and the people that I have the opportunity to interact with. Code can be changed, people can't...

Answer 9

Slightly jokingly I say, interview with me.

I normally use an actual bug (already fixed) in our code-base as an interview test, so you see some actual code. Generally slightly complicated code, and it has a bug in it.

I encourage everyone to use this technique, as you already know the bug is real, the problem is real, and you know how long it took to find and fix.

The great thing is you can have a measurably difficult problem.

I have used a very difficult problem as a last interview question to separate the experts from the pretty good.

The relevance to the OP's question is that everyone who makes it to a physical interview gets to see some code. (Not anything with company confidential content)

If you couldn't use this technique, due to say, profanities in the code-base, then the test works, as prospective employees will ask "can I see the code" and the reply would be "oh, you can't it's full of profanities".

Of course, the standard "it's all a company secret" answer is total horse-puckey.
My proof: at my previous employer, a non-confidential part of a military product was the code sample for the interview question. [Luckily unclassified]

I leave the problem of determining the quality of classified designs before working there to someone smarter than me. I suggest it may be common that classified is synonymous with free of oversight.

Answer 10

It is doubtful that they will let you see their code, but you may be able to get an idea what it may be like if you give them a programming homework assignment. Many places give interviewees a take-home programming assignment that they can use to gauge you. Return the favour--expect one of them so that you may better gauge what you could be getting yourself into.

Answer 11

Ask what is required for code to make it into the production build. If you get 'uhh... the dev commits it...' then it's almost certainly garbage.

There are a number of things that have a tendency to increase the quality of the code (obviously, there's no guarantees).

• Static analysis (in .NET this is things like fxcop/stylecop)
• A subset (or full set) of the test suite - unit/integration/regression/manual etc.
• Buddy build (another dev on the team builds the changes to see if there are any machine/user dependent problems - sometimes running a quick sanity as well)
• Code review

These can help improve, not only the strength of the code, but the quality of the code.

Answer 12

Ask them about unit testing. If they take it seriously, then the interviewer will probably have some definite opinions on the subject, and will be glad to share them. If the answers are vague, that's a big warning sign.

If it's a Java shop, ask them what ORM library they're using. If they've rolled their own, then it could go either way - it could suck, or it could be fine. If they're not using any, run for the door right away.

This is a difficult task because there are so many different bad coding practices, that you'll never be able to predict all of them.

Answer 13

You can't, unfortunately. No company will let you see their code (but they'll ask to see YOUR code...), and chances are if you ask them questions about the environment you'll either be outright lied to ("Version control? Sure.. we use.. uhh.. thinking Sub.. Sub-something") or misled about the quality ("We're using the latest and greatest .NET 4" only to find out that while they're using .NET 4 they're writing it like .NET 1.1).

I've been burned by it many times in the past, and I have yet to find a good way to gauge the quality. Usually the best way is to use your own judgement and if it boils down to it, leave immediately if it's worse than you thought; you might end up a job hopper but you'll keep your sanity.