Iyfjky

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. — Sep 26 '14 at 6:04
Comments are not for extended discussion; this conversation has been moved to chat. — Oct 1 '14 at 4:16
@IanLewis, for discussions, you and others are welcome to use The Workplace 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. — Oct 1 '14 at 4: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). — Oct 2 '15 at 21:03

score 131 · Accepted Answer · 2014-09-29 13:11:09Z

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 situtation 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 his team's coding practices as he thinks. 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.

+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. — Sep 24 '14 at 13:39
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. — Sep 24 '14 at 16:35
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. — Sep 25 '14 at 6:17
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. — Sep 25 '14 at 15:55
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. — Sep 28 '14 at 17:57

score 26 · Answer 2 · 2014-09-24 11:58:26Z

up vote
26
down vote

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

68.9k7118254

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

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

5

Adding to what @Lohoris wrote: let alone in a few minutes of looking at it, which is likely what it would be about if you asked about it on-site. If you ask to have it sent to you, that obviously changes things somewhat, but not by that much; the company can certainly pick some portion of the code which is less critical and/or doesn't do anything important. I could pull some code out of a larger system that is trivial in many aspects, but still gets the overall style of the code in that system across to the reader. I assume that's what the OP is looking for.
â€“Â Michael KjÃ¶rling
Sep 24 '14 at 13:27

12

That is a very illustrative answer. This kind of reaction to a good question is a clear show stopper for me. I think I would quit the interview right after the 3rd point and leave you alone with your shitcode.
â€“Â Slava
Sep 25 '14 at 11:06

5

"Why should I hire you anyway, if I have to worry about which legacy code you are willing to maintain?" Well, isn't that the point? If you're only willing to hire somebody who is happy to maintain crappy legacy code, then that presumably means that maintaining crappy legacy code is part of the job description which means that kostja doesn't want to work for you. That's the whole point of asking!
â€“Â Ben Aaronson
Sep 25 '14 at 15:43

Â |Â
show 11 more comments

score 19 · Answer 3 · 2014-09-24 12:19:37Z

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. — Sep 26 '14 at 16:57

score 15 · Answer 4 · 2016-01-20 05:08:21Z

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.

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

Aaron Hall 4,16312033 · Answer 5 · 2014-09-24 22:27:06Z

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. — Sep 24 '14 at 12:35

RemcoGerlich 3,4521018 · Answer 6 · 2014-09-25 09:53:20Z

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. — Sep 25 '14 at 14:42

Marco Altran 1892 · Answer 7 · 2014-09-24 21:19:01Z

up vote
8
down vote

Simply ask some questions taken from Joel Test:

Joel Test Example

answered Sep 24 '14 at 21:19

Marco Altran

1892

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 0: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 9: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 9: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

suggest improvementsÂ |Â

Oli 851412 · Answer 8 · 2014-09-25 09:32:58Z

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.

JakeGould 6,5821739 · Answer 9 · 2014-09-25 01:57:37Z

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 · 2014-09-24 19:28:22Z

up vote
2
down vote

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

community wiki

Andrew

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 9: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 9:16

suggest improvementsÂ |Â

Ian 1,19569 · Answer 11 · 2014-09-26 20:12:33Z

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.

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? — Sep 28 '14 at 8:39

score 131 · Accepted Answer · 2014-09-29 13:11:09Z

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 situtation 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 his team's coding practices as he thinks. 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.

+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. — Sep 24 '14 at 13:39
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. — Sep 24 '14 at 16:35
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. — Sep 25 '14 at 6:17
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. — Sep 25 '14 at 15:55
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. — Sep 28 '14 at 17:57

score 26 · Answer 13 · 2014-09-24 11:58:26Z

up vote
26
down vote

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

68.9k7118254

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

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

5

Adding to what @Lohoris wrote: let alone in a few minutes of looking at it, which is likely what it would be about if you asked about it on-site. If you ask to have it sent to you, that obviously changes things somewhat, but not by that much; the company can certainly pick some portion of the code which is less critical and/or doesn't do anything important. I could pull some code out of a larger system that is trivial in many aspects, but still gets the overall style of the code in that system across to the reader. I assume that's what the OP is looking for.
â€“Â Michael KjÃ¶rling
Sep 24 '14 at 13:27

12

That is a very illustrative answer. This kind of reaction to a good question is a clear show stopper for me. I think I would quit the interview right after the 3rd point and leave you alone with your shitcode.
â€“Â Slava
Sep 25 '14 at 11:06

5

"Why should I hire you anyway, if I have to worry about which legacy code you are willing to maintain?" Well, isn't that the point? If you're only willing to hire somebody who is happy to maintain crappy legacy code, then that presumably means that maintaining crappy legacy code is part of the job description which means that kostja doesn't want to work for you. That's the whole point of asking!
â€“Â Ben Aaronson
Sep 25 '14 at 15:43

Â |Â
show 11 more comments

score 19 · Answer 14 · 2014-09-24 12:19:37Z

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. — Sep 26 '14 at 16:57

score 15 · Answer 15 · 2016-01-20 05:08:21Z

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.

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

Aaron Hall 4,16312033 · Answer 16 · 2014-09-24 22:27:06Z

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. — Sep 24 '14 at 12:35

RemcoGerlich 3,4521018 · Answer 17 · 2014-09-25 09:53:20Z

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. — Sep 25 '14 at 14:42

Marco Altran 1892 · Answer 18 · 2014-09-24 21:19:01Z

up vote
8
down vote

Simply ask some questions taken from Joel Test:

Joel Test Example

answered Sep 24 '14 at 21:19

Marco Altran

1892

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 0: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 9: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 9: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

suggest improvementsÂ |Â

Oli 851412 · Answer 19 · 2014-09-25 09:32:58Z

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.

JakeGould 6,5821739 · Answer 20 · 2014-09-25 01:57:37Z

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 21 · 2014-09-24 19:28:22Z

up vote
2
down vote

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

community wiki

Andrew

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 9: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 9:16

suggest improvementsÂ |Â

Ian 1,19569 · Answer 22 · 2014-09-26 20:12:33Z

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.

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? — Sep 28 '14 at 8:39

Search This Blog

Iyfjky

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

11 Answers
11

protected by Communityâ™¦ Sep 25 '14 at 17:31

11 Answers
11

11 Answers
11

protected by Communityâ™¦ Sep 25 '14 at 17:31

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

Category

Random preview

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

11 Answers 11

protected by Communityâ™¦ Sep 25 '14 at 17:31

11 Answers 11

11 Answers 11

protected by Communityâ™¦ Sep 25 '14 at 17:31

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

11 Answers
11

11 Answers
11

11 Answers
11