How can I ask a potential employer to show production code?

Question

In my experience, managers and even employees at a potential employer tend to emphasize the commitment to quality in their company or their team during interviews. I am also routinely asked about my proficiency with tools and processes to improve and maintain code quality. It is also customary to write some code during the interview or as an assignment.

Having experience with several maintenance projects, I had to learn the value of good code the hard way. It has become very important to me when writing my own code. And I do not want to be employed by a company that is not committed to writing good code, definitions of good code aside.

However, once the legacy code is on the table I am often disappointed as it turns out that the commitment to code quality is rather a figure of speech. It tends to be teeming with simple errors that have been introduced years ago, has no consistent formatting, no consistent idioms and sometimes exhibits a grotesque misunderstanding of basic coding techniques and principles. I am probably preaching to the choir here :)

Is it a good idea to ask a potential employer to show some source code first? Specifically, I would like to see some production code samples.

How can I ask for it so that a potential employer will understand my concerns and actually allow me to take a look.

Are they likely to refuse on grounds other than bad code quality (confidentiality etc.)?

If they should refuse, how can we reach an agreement that is satisfactory for both sides?

For the sake of the argument, let's assume that I will be able to determine the code quality from a fairly small sample - my question is really only about whether and how to ask for it. Warning me about low expected returns is nice, but off-topic.

I am not an applicant. I have been approached because of my qualifications and would like to evaluate whether I am actually interested. I am not afraid of being excluded from the race. My primary objective is to find out if the food is to my liking without having to eat up the whole plate.

Answer 1

It is highly unlikely that they are going to provide you with a sample of the code, so really what you need to figure out is how you can answer your questions without seeing the code. You're trying to make sure that they value good coding practices, so ask them about that.

Here are some example questions that should help you understand how much value the company puts on maintaining quality code over time. There are plenty of other things that you can ask specific to your situation and priorities.

• What sort of source control do you use?
• How does the team report bugs?
• Do you conduct peer reviews on code?
• How do you ensure that code written by one developer will be easy to read and understand by another?
• How do you maintain legacy code over time?
• How do you keep your team members up-to-date on the best coding practices and techniques?
• Do you use any static analysis tools, such as Checkstyle, to enforce coding standards? (@Ryan)
• How long is your code freeze before a release? (@Sandra Walters)
• What is your test framework? (@m24p)
• At what point in development did you start implementing good coding practices? (@dotancohen)

EDIT:

Some folks are pointing out that just because the interviewer tells you something, doesn't mean it's entirely true. Their standards for peer review may not match yours, or maybe the manager doesn't know as much about their team's coding practices as they think. This is true of everything you are told at an interview, across all topics, and you have to rely on trust at a certain point. If you really would feel more comfortable seeing some code, then by all means, ask! I just don't think you can presume the answer will be yes.

Answer 2

If you are maintaining code, you might as well assume that the code you are maintaining will be structurally deficient in some way.

1. Asking for code to review is no good because that code is considered confidential and proprietary unless it has been Open Sourced. You could take a look at the Open Sourced code but if it's well written and well structured, there is no guarantee that the legacy code is as well written and structured.

2. Even if you were allowed to see some proprietary code, there is no guarantee that this code is not actually their best foot forward.

3. If you were interviewing with me and you ask to see some of our proprietary code, I'll take the attitude that you don't know the meaning of the words "confidential" and "proprietary" and pass you over as a candidate. Why should I hire you anyway, if I have to worry about which legacy code you are willing to maintain?

Answer 3

Just ask. Don't give an ultimatum that if you don't see the code, you're going to walk out the door. There may be legitimate reasons they can't show it. If you feel this is a deal breaker, just decline the next interview.

Although they weren't selling commercial software, I have seen code during an interview and I didn't even have to ask. They wanted to know if I understood it.

Cleaning up code is always going to be part of the job. You may feel you hold very high standards for your current coding practices, but in a year or so, you may not be so pleased with it.

Don't be so harsh. A picture may contain a thousand words, but it only shows one side of the story.

Edit: I think a key here is are they going to put you into a position to write poor code. That could be the reason for a current code base that is low quality or it may be the previous programmers weren't as skilled. Cleanup isn't always fun, but it is tolerable if you know the company is going to put you into a position to successful and do quality work.

Answer 4

Don't ask for a copy of anything : that just sounds creepy and unwise. Don't ask management: the codebase might not match the aspirational aims of current management. Don't even ask about the Joel test, as they may claim things they don't really have.

But do ask to sit down with an existing developer for a tour of the codebase and toolchain and current challenges. It's a reasonable request, not exceptionally unusual. At that time you can ask about code maintenance issues. If the code base is bad, you'll know pretty fast. If it's good, you've started rapport with the team.

Answer 5

You say you don't consider yourself as a candidate, and you don't fear being rejected, but insist on using the term potential employer; you need to change your focus.

You want to function as a contractor. They aren't a potential employer; they are a potential customer.

No home improvement contractor will give an estimate without seeing the job site, the conditions, and understanding what risks are involved. You as a code improvement contractor need to do the same steps.

One approach is to take a one or two week assignment to investigate the situation and make an estimate of what they need and what it will cost. If you don't like the situation bid high, or refuse to take on the work.

You of course will sign any confidentiality agreements they require.

Note: even if I approached you to become an employee, I would drop you from consideration if you insisted having access to my code base. But if I was looking to hire you as a contractor to achieve a specific goal, I would expect you to do your due diligence.

Answer 6

I would try to speak to future colleagues. Preferably more than one.

Actual programmers are more likely than their managers to tell you the day to day truth, instead of a vision of where the company will hopefully be some time in the future. You can compare the views of multiple colleagues as well to further separate facts from wishful thinking.

Another benefit is that the people you work with are also very important to your job satisfaction, so you want to meet them anyway.

Answer 7

Simply ask some questions taken from Joel Test:

Answer 8

As others have said, you can benchmark them with some simple questions but I really do understand where you're coming from... From personal experience.

People say a whole load of stuff on the spot that they either don't know for sure or they answer not understanding the question. Something like the Joel Test is really great, but only if they understand the question and the technology (and if they're not lying scumbags).

An affirmative to "Do you use source control?" could actually be as awful as "we work from FTP and back that up in CVS at the end of the month". If this stuff is important to whether or not you're going to do work with these people, or (perhaps more importantly) how much you're going to charge them to offset their ineptitude, you need to find out by direct observation. People who aren't contracting software developers probably won't understand that.

But professional people understand risk assessment. That's all you're doing here. Explain it, say that you're happy to sign a [good, not ridiculous] NDA, and if they refuse, make them absorb the risk by quoting to the very worst case scenario (or factor thereof). That's how every other industry manages this.

---

I'm not saying you shouldn't also benchmark them with tests like the Joel Test. Just make sure you've seen what's important to you before you commit to anything.

Answer 9

In my experience, managers and even employees at a potential employer tend to emphasize the commitment to quality in their company or their team during interviews.

Every employer is supposedly committed to quality. Yet tons of crappy software is out there & tons of security breaches exist.

In general you are mixing up the puffery of business speak because saying “we are committed to quality” is ultimately a vague statement. Whose quality? What is the benchmark? It’s just bull crud made to make you feel great.

In general everything you will hear during an interview process will be—for lack of a better term—a “white lie” designed to make you feel that the potential employer is the best choice you have.

My advice? You will most likely never see production code until you are in the company itself. And if it does not meet your standards, just keep on looking for a new gig.

The harsh reality is pretty much tons of companies have crappy systems, crappy software & crappy practices. And that stems from the fact this type of computer work is “invisible” to most & most people can get away with it.

Answer 10

Quite simply: Offer to sign a non-disclosure agreement (NDA). This will legally (though, not technically) prevent you from using their code in your own projects.

Also, be sure your request sounds logical. Make a request only for the code snippets you need. This will help guide your discussions about the project and make your request sound sensible.

Answer 11

Ask about:

• Test coverage
• TDD - Test Driven Development
• How object-oriented analysis and design is done
• Do they use SOLID principles
• Usage of Sonar, Veracode or other code analysis tools
• CI/CD practices
• The biggest class in a project

Answer 12

I say ... "don't waste time on companies who somehow expect you to 'write code' extemporaneously. If they really don't believe that you can actually write source-code in {insert programming-language here}, why-the-hell did they invite you in for an interview?

Now – having just said that – I must also acknowledge that "there are pretenders out there." And, there are also reasons why companies have learned to perform superficial criminal background checks on every candidate ...! (I could tell you stories now, but I won't.)

So – it's up to you, I guess. "How badly do you want this job?"

Answer 13

You can’t as per the other answers.

However you are more likely to get them to agree to tell you the userIds of some of their programmers that have accounts on StackOverflow and Programmer.

Looking at the problems their staff have will give you some idea what their code is like.