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.

comments removed: Comments are intended to help improve a post or seek clarification. Please don't answer the questions in the comments. These can't be easily voted on as the best answers, and they may inadvertently prevent other users from providing real answers. Please see How should I post a useful non-answer if it shouldn't be a comment? for more guidance. — jmort253, Sep 26 '14 at 06:04
Comments are not for extended discussion; this conversation has been moved to chat. — jmort253, Oct 01 '14 at 04:16
@IanLewis, for discussions, you and others are welcome to use [chat]. However, comments have a very specific purpose on our site. Specifically, see the sections "When should I comment" and "When shouldn't I comment" for more details, or see What comments are not? Hope this helps clarify. With that said, I automatically moved these comments to their own chat room so the discussion circling this question can continue unabated. See the previous comment for the link. — jmort253, Oct 01 '14 at 04:20
Not an answer to your question, but keep an eye out for related short-term consulting projects, as well as opportunities to chat with developers who do or have worked with the company (e.g., hackathons). — Careerasaurus.com, Oct 02 '15 at 21:03

David K · Accepted Answer · 2020-11-18T15:32:08.060

149

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.

edited Nov 18 '20 at 15:32

answered Sep 24 '14 at 12:39

David K

30,066
21
108
140

4

+1 Makes perfect sense. I think I will start by asking the questions you have proposed and only ask for code if the reaction is evasive/startled/mumbling. – kostja Sep 24 '14 at 13:39
3

To add on to the list of questions to ask, I would ask about any static analysis tools or any tools that automate the process of enforcing a coding standard. I know Java has Checkstyle. – Shaz Sep 24 '14 at 16:35
15

Hmm, during an actual interview I have asked to see some code of non essential parts of the application and been shown it. I simply saw it as part of 'getting to know the company'. This was already at the point though that the company knew they wanted me, and I was likely to accept. – David Mulder Sep 25 '14 at 06:17
1

+1. A small sample of code won't tell you much out of context. Whether the codebase as a whole is good or not will be heavily influenced by whether the whole development process is conducive to producing good code. – Fiora the Ferret Sep 25 '14 at 08:31
6

Also to this list I'd add the question How long is your code freeze before a release? If the answer is none or a very short one, then it may be a shop that is practicing protoduction... and the ensuing hilarity of fixing bugs with the recently-released product. – SWalters Sep 25 '14 at 15:55
3

They could be doing all of those, and afterwards you can find a page full of gotos in the core of the C++ application. There's really no certain way to assess the team skills (or company's for smaller scenarios) without working on them. – Marco A. Sep 25 '14 at 23:04
3

On thing I asked when interviewing with potential employers was "what is your test framework"?
If I didn't hear about automated unit tests etc, it was not a good sign.

Another good generic question is ones that force the interviewer to say something negative about the company. Usually you'll find a pattern that tells you something useful. If code health is an issue, someone might mention it.
– m24p Sep 26 '14 at 20:56
I think you missed one key question: What are the steps in the build - test cycle and how long does it take? – kevin cline Sep 26 '14 at 22:00
1

"Do you have any automated processes, such as building and running tests?" Essentially, ask about continuous integration practices. – jpmc26 Sep 27 '14 at 03:28
2

I was at an interview once where they showed me the live code without even asking. Was no big deal. – TMOTTM Sep 27 '14 at 06:47
12

In addition to these questions, don't forget to ask at what point in development did they start implementing good coding practices. I've seen a lot of developers and companies mention coding practices, but when the code is a mess they answer, "Oh, that! That was written before blah blah blah". Of course, that consists of 90% of the code base. – dotancohen Sep 28 '14 at 17:57
"Also to this list I'd add the question How long is your code freeze before a release?". IMO the need to have a code freeze at all is a red flag. They're not necessary if your code is well tested and deployments are all fully automated – tddmonkey Dec 01 '20 at 13:23

Vietnhi Phuvan · Answer 2 · 2014-09-24T11:58:26.830

27

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

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.
Even if you were allowed to see some proprietary code, there is no guarantee that this code is not actually their best foot forward.
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?

edited Sep 24 '14 at 11:58

answered Sep 24 '14 at 10:44

Vietnhi Phuvan

72,342
8
133
268

3
Also, if they actually allow you to see a sample of their code there is no guarantee that the rest of the code has the same quality/structure.

trrrrrrm

Sep 24 '14 at 11:06

3

@Vietnhi Thank you for your answer, Vietnhi. I agree with your points 1 and 2. There are no guarantees, but this is not relevant to the question. I am not afraid of being rejected - the company expressed their interest quite clearly. I am asking for a way to assess whether I should be interested as well. Do you happen to have advice on that? – kostja Sep 24 '14 at 11:19

5

@kostja At the end of the day, accepting a job offer boils down to a crap shoot where you hope for the best. If you are specifically hired to work on new projects starting from scratch, then you will not be running into legacy code. At least at first. Junior programmers get hired to maintain legacy code so that the senior programmers get to jump in on the fun projects :) During the interview, you can ask if you are expected to be deployed on the new projects starting from scratch or the legacy ones. A new project that includes a lot of legacy code does not count as a new project :) – Vietnhi Phuvan Sep 24 '14 at 11:36

10

is pointless: if they want, they can show you. And showing a couple of file from a whole project won't undermine anything, it's not like you can make any use of them.

– o0'. Sep 24 '14 at 12:34

score 20 · Answer 3 · 2014-09-24T12:19:37.273

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.

That is, when the company is willing to and committed towards cleaning up. That may be the whole point of willing to peek at current code. — desseim, Sep 26 '14 at 16:57

Bryce · Answer 4 · 2016-01-20T05:08:21.553

19

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.

edited Jan 20 '16 at 05:08

answered Sep 25 '14 at 17:31

Bryce

307
1
5

2

+1 I would probably get significantly more insight than simply asking to show me the code. Great advice. – kostja Sep 25 '14 at 17:42

score 14 · Answer 5 · edited Sep 24 '14 at 22:27

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.

+1 good point. I view the situation rather as a potential partnership (while actually being employed). To start out with an assignment can benefit both parties. Thank you, mhoran. — kostja, Sep 24 '14 at 12:35

score 14 · Answer 6 · answered Sep 25 '14 at 09:53

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.

+1. At my company, several of the "future colleagues" are the interviewers, but that's not the case everywhere. — Brian S, Sep 25 '14 at 14:42

score 9 · Answer 7 · answered Sep 24 '14 at 21:19

9

Simply ask some questions taken from Joel Test:

Joel Test Example

answered Sep 24 '14 at 21:19

Marco Altran

199
2

7

I don't think this would help at all in the situation the OP is describing. He says "..I am often disappointed as it turns out that the commitment to code quality is rather a figure of speech." In my experience, many people would answer "yes" to Joel Test questions but when push comes to shove, they don't really live by that yes answer. – Carson63000 Sep 25 '14 at 00:24
1

@Carson63000: and part of the reason they get away with it, is that as with any concise criterion there are good reasons for hedging some of Joel's points anyway, and these get stretched into bad reasons. For a contrived example of a good reason, if "the best tool money can buy" frequently alternates between X's and Y's different packages to achieve the same thing, since each one out-does the other with each new release, then 50% of the time no, we don't use "the best tool money can buy", we stick with one to avoid the cost of constantly flip-flopping ;-) – Steve Jessop Sep 26 '14 at 09:23
1

... similarly, I don't buy a new CPU every time a faster one is released. So almost 100% of the time I don't use the best tool money can buy in that category either. I have one that meets my requirements, but if the disruption to me from getting a faster one was zero then I'd probably take it, so the one I have is not the "best". But either of my examples can turn into a company full of people using obsolete tools if you end up never seriously assessing alternatives to your current tools and whether you could improve what you have. They might believe they have the best through ignorance – Steve Jessop Sep 26 '14 at 09:28
1

I have to agree with all of you. However, I was thinking about taking a qualitative approach, rather then quantitative. Some questions are more subjective than other, so I would ask first: "Do you use source control?", and if yes, I ask what tool they use, how they use day in day out, etc. This way you show interest with your question, rather than suspicion. – Marco Altran Sep 26 '14 at 14:54
2

I can only concur ; I've started asking the questions of the test at interviews recently, and it always lead to good discussions with enough insights to get an idea of the general quality / legacy level of the code base. – desseim Sep 26 '14 at 17:09

score 7 · Answer 8 · answered Sep 25 '14 at 09:32

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.

score 3 · Answer 9 · answered Sep 25 '14 at 01:57

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.

score 2 · Answer 10 · answered Sep 24 '14 at 19:28

2

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.

answered Sep 24 '14 at 19:28

Andrew

101
3

1

I wouldn't be so quick to sign an NDA - that might not only prevent you from using their code, but also from doing anything similar on your own in the future. Giving up the right to think of that same bit of code yourself is a real cost. – Brilliand Sep 25 '14 at 17:04
1

Yes - the idea of signing NDA IS to prevent you from using their code ;-) More importantly, all developers ALREADY run a risk, but of copyright infringement, not NDA, every time they 'think of the same bit' of code. Signing an NDA is a non-issue for that very reason. – Andrew Sep 25 '14 at 17:55
1

And if the code was sufficiently obvious that you would have thought of it yourself if you encountered the same problem? If you do encounter the same problem in the future, you're prevented from solving it. That's not a problem if the code they show you really is unique and special, but you don't know whether it is when you show up for the interview. What I'm saying is that by seeing the code and agreeing not to use it, you give up something compared with never seeing it at all. – Brilliand Sep 25 '14 at 18:52
1

If you saw some code and didn't sign an NDA, then as Andrew says you can't use it anyway due to copyright. So the problem here, if there is one, is "looking at code", not "signing an NDA". The NDA might say anything, it might say "I will never use the programming language in which the code was written", in which case of course don't sign it. But an even vaguely reasonable NDA won't prevent you from ever using (say) Quicksort just because there's a Quicksort in the code you view under NDA. The Quicksort algorithm isn't what the NDA is protecting. Their specific implementation of it is. – Steve Jessop Sep 26 '14 at 09:12
1

... however, what the NDA does (and what the person whose code it is cares about) is forbid you from going around saying "company X uses Quicksort". Mere copyright of course doesn't stop you doing that, and that's the main reason you can get access to stuff under NDA that they wouldn't want to give outsiders under merely a restrictive license that prevents you adapting the code yourself on your future projects. – Steve Jessop Sep 26 '14 at 09:16

Justas · Answer 11 · 2020-11-30T21:10:09.310

1

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

edited Nov 30 '20 at 21:10

answered Nov 18 '20 at 00:17

Justas

1,688
1
12
20

score 0 · Answer 12 · answered Nov 18 '20 at 19:54

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

score -1 · Answer 13 · answered Sep 26 '14 at 20:12

-1

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.

answered Sep 26 '14 at 20:12

Ian

1,387
9
10

2

Awful advice. No-one wants people stalking them on Stack Overflow. And, believe it or not, many many excellent programmers don't ask questions on Stack Overflow. What would you do if they said "we don't have any representative programmers with an account? – GreenAsJade Sep 28 '14 at 08:39

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

13 Answers13

Linked

Related