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)?


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.

  • Bay their product, disassemble it, and read some.
    – Job
    Commented Apr 17, 2011 at 14:16
  • 4
    @Job - even if there is a public program to purchase, disassembled code isnt likely to resemble the non-compiled code. Commented Apr 17, 2011 at 15:55
  • Ask who owns the code, who is responsible for quality. If the answer is "everyone does, collective ownership, shared responsibility" it is likely to be a mess. If certain parts are assigned to specific individuals whose job it is to maintain and guard their design, it is likely to be better. Commented Jun 2, 2016 at 5:58

13 Answers 13


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.

  • 1
    – user23157
    Commented Apr 17, 2011 at 16:49
  • 6
    This doesn't tell you the state of the code, it tells you what the managers interviewing you think the state of the code is. Doesn't help if they have been mislead or are actively deluding themselves about it.
    – James
    Commented Apr 17, 2011 at 18:52
  • 5
    I would expect to be interviewed by someone who was actively developing the software; even if they were solely an architect I would have expected them to read the code that got written.
    – user23157
    Commented Apr 17, 2011 at 19:49
  • 1
    @B Tyler: What's "solely an architect"? Where I work, the architect is intimately familiar with the code because he wrote or helped write a substantial percentage of it. Commented Apr 17, 2011 at 20:23
  • 1
    @James - if you don't get a chance to be interviewed by your potential peers, that tells you something, doesn't it? It would certainly tell me something.
    – Anon
    Commented Apr 17, 2011 at 20:54

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.
  • 4
    An architect can walk around a prospective employer's building and see the quality of the work they do. An engineer can physically see the internals of the product produced; but a piece of software is a black box. Why not ask to see the code?
    – user23157
    Commented Apr 17, 2011 at 11:52
  • 8
    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". Commented Apr 17, 2011 at 12:11
  • 26
    Ugh, if I heard CMM level 5, I'd be running the other way.
    – Doug T.
    Commented Apr 17, 2011 at 12:19
  • 2
    @Carson63000 '"Agile" or "cowboy coding"' (I thought they were pretty much the same thing!)
    – user23157
    Commented Apr 17, 2011 at 16:51
  • 3
    @B Tyler: zing! But seriously, I've known a number of interviewers who thought the definition of "Agile" was "not a waterfall"; they didn't realize that after throwing away the waterfall model you did actually need to replace it with another process. Commented Apr 17, 2011 at 21:19
  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.


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.

  • This hit the nail on the head. Commented Aug 16, 2011 at 18:22

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.

  • ... or unless they supply source code with their proprietary product. In my line of business (NLP), LingPipe is delivered that way, and there must be other products shipped with sources.
    – Fred Foo
    Commented Apr 17, 2011 at 12:46

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?
  • Important fact here: What matters (to you) is not the quality of the code base, but how enjoyable the workplace is overall (and how likely it is that the company will stay around at least as long as you want to stay).
    – gnasher729
    Commented Jun 19, 2017 at 11:42

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.

  • 1
    I think the high turnover rate response is a very good indicator... Coming in behind a failed project usually isn't good for anyone's health...
    – webdad3
    Commented Apr 22, 2011 at 15:15
  • 1
    @webdad3: When the cause of the turnover is not related to the project like underpayment for example, the project is a victim of turnover. This will continue till the turnover causes significant problems to the project and the code becomes really bad. At this point the increase in salaries does not solve the problem and the turnover continues and as the project state becomes unbearable to developers as you pointed out, the less customers are satisfied and the less comes the profits which causes underpayment again and raises the turnover. It's like snowball effect.
    – M.Sameer
    Commented Apr 22, 2011 at 17:14

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...

  • 4
    The produce didn't just come into existence, the people and the company made it. If the code is bad, there is little reason to believe it will ever be better. Commented Apr 17, 2011 at 18:37
  • @Chris, that's defeatist! ;) There are many reasons for bad code, but if the attitude of the folks there is one that strives for change, why not??
    – Nim
    Commented Apr 17, 2011 at 18:51
  • because if they are aiming for good code, yet their code is bad, there is still a reason for it. Very often these are political reasons that you can struggle against all you want. There are enough places looking for programmers that you do not have to take a sub-optimal job unless that is what you are looking for. Commented Apr 17, 2011 at 19:10
  • Even if there are good people developing a piece of software that has become bad for perhaps historical reasons, who admit it is bad and who want to change it, changing it is still very hard. Even with a management that understands what technical debt is, and the problems it causes, developing a strategy for long term architectural change and getting the management to prioritise that over short term feature requests is very tough.
    – user23157
    Commented Apr 17, 2011 at 19:47
  • 1
    Can't agree. Good developers know bad code and ruthlessly stamp it out; if the code is bad there's a reason for it (either poor developers, clueless management, insane deadlines, or any combination thereof) and that reason will force the code to be bad forever because otherwise the code wouldn't be bad in the first place. Commented Aug 16, 2011 at 18:23

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.


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.

  • I think an assignment might be pushing it, although it's a great idea, but I have definitely thought about asking a few programming questions: whether that was acceptable was going to be my next question.
    – user23157
    Commented Apr 17, 2011 at 17:19
  • I agree it may be pushing it, but I also wonder if there are circumstances where the prospective employer may be willing--say after they have extended an offer perhaps? Just trying to think outside the proverbial box (gah, I hate that expression).
    – Sparky
    Commented Apr 17, 2011 at 19:03
  • +1 As I like the idea, but unless they really like you, most interviewers would tell you to take a running jump.
    – Orbling
    Commented Apr 17, 2011 at 21:40

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.


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.


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.