Is it reasonable to ask a potential employer for samples of their code and/or employee contact information, to determine if I want to work there?

Question

I'm currently looking for a new job as a developer. There are two things that companies usually require that bother me a lot: long programming assignments and reference checks. There are plenty of questions about both things in this site.

There are other things that bother me even more: after doing such a process, finding out that the code or system I'm going to be working with is a disaster, or the company itself is.

So I've started trying, with no success (and no surprise) at all, asking the companies in return:

1. Some code of their own. I'm aware it's confidential, but just any, any small piece of code they're usually working with.
2. Former and/or current employees contact information, so that I can ask "hey, did/do you enjoy working there?" Also confidential, but just the same as the contact information they require from my references. I can read reviews on Glassdoor, but I don't put much trust on that.

One of the companies said that what I'm asking (2-3 people's contact information, they'd asked for 6) is unreasonable. Is it? I acknowledge they have the right to do all they consider necessary to get the best people on board. Can't I do the same?

Answer 1

I have asked "could you walk me through some of your best and worst code for a few minutes?" the last two times I went job hunting, usually at the end where people ask "do you have any questions for us?" Thus far, this has universally been received as positive. Not all companies may be willing/able to do this – much depends on company culture, size, industry, etc.

The reason I ask for the best and worst code is so that I can get a vague idea of what they consider to be "good code", and also get a vague idea of what they consider to problems in their code base. Note that this is not a code review, but rather an opening to start a discussion about the state of their code, future plans to improve the code base, and most importantly, their general approach to software development. Even if they're not able/willing to actually show you code, this can still be a good conversation starter; for example they can verbally describe why they consider their good code to be good, or their bad code to be bad.

Some organisations have surprisingly funny ideas about this. To give an example one organisation showed me what was clearly a huge spaghetti mess, and the biggest problems they pointed out with it were "public and private keywords often not being added" and "variable names not always being descriptive". While these are legitimate concerns, those were far from the most pressing concerns with that code. They clearly didn't know what they were doing. I did end up working there as a friend of mine worked there and I trusted her, but this turned out to be a big mistake and vexing experience for both parties.

Addendum: OP came back and posted the following in the comments:

Although I found this a good idea, and I tried it several times, results were pretty bad: big companies can't do that, as they'd need a process that they have not implemented, but that's ok because big companies usually don't give you home assignments. Other companies, including the ones that do give you home assignments, refuse with better or worse excuses, promise to do it and then never send it, or don't understand why/what you want. A couple of them sent me their whole repositories with several thousand lines of code, which at least was honest in that I would know what to expect. – antonro

So it looks like your mileage may vary; I can only speak from my own limited personal experience. I've almost exclusively interviewed at smaller "non-enterprise-y" companies, and perhaps it also depends a bit on your locality (I'm in Europe). It's important to stress that I've never asked anyone to send me anything, but rather to just walk through the code a bit with them during the interview for a few minutes. Just sending code seems pretty useless to me because there's no conversation: the value is mostly in the conversation not necessarily the code as such, which is mostly of a MacGuffin in this context.

---

As for asking employee's contact information, this seems rather strange to me. I understand where you're coming from, but aside from the privacy concerns it can also put regular employees in a rather tough spot.

Use sites like glassdoor instead, where current and past employees can leave reviews, if they choose to. For medium to large companies this should give you a reasonable indication, although I would strongly recommend to read some of the reviews rather than blindingly trust the 4.4 rating (or whatever).

Answer 2

I am an employer of several developers.

Screening Tests: We ask candidates to answer a 20-30 minute multiple choice test which attempts to screen candidates who would never succeed in a coding interview. This is in the interest of the candiate as well as the employer, as it reduces the amount of time wasted by all parties.

If your prospective employer asks you to do several hours of coding before even having a conversation with you, they are NOT efficient and do not respect your time, and that's a big warning sign. However, the right response is to politely decline and walk away (if you're in a position to do so), not ask the employer to spend a large amount of time on you before they even know if you're competent.

---

Coding Interviews: What you have to understand is that hiring is not a fun process for the employer either. You have to wade through a plethora of candidates who have applied for a job they are incapable of doing. That's why coding interviews are so useful.

I ask prospective employees to code in their interviews to see:

1. What their thought process is, and if they are able to identify an algorithm for solving a problem
2. The quality of their code
3. Their ability to debug
4. Their ability to adapt to criticism

Is it fair to ask to see some of our codebase? Yes, and I'd entertain this question if I was already confident in the prospective employee's ability to code, and if the prospective employee had enough experience to understand what they were looking at.

---

Reverse Reference Checks: I do not do reference checks in general. I think it's pointless as personally I have given positive reference checks to ex-employees that I would not hire again. Why? Because I can find truthful positive things to say about all my employees, and I have no skin in the game. There is only one ex-employee who I would not do this for, and for that person, I would say that it is against company policy to give reference checks.

However, if I were asked in the interview to give the contact details of several ex employees, I would respond - "Thanks for your time. Unfortunately, you're clearly not the right candidate for this role."

If on the other hand, I was already in negotiations to hire an employee who I really really wanted, yes I would ask former employees if they'd be willing to give us a reference check.

Answer 3

There are some already good answers here, but to add my own thought. Has it occurred to you that their assessment of you is your opportunity to assess them?

Let me give you two different examples all based off real experiences I've had:

1. I spent 15+ hours working at home on a programming assignment for a company, their response came back via a recruiter but basically fell into the category "you didn't have to use X for that" and "you didn't need to do that". No discussion, no phone call.
2. A second company brought me in for an interview and gave me a list of instructions on a piece of paper and a laptop. It was a very simply TDD programming challenge. The two interviewers sat in the room with me an chatted as I completed the challenge, we discussed the pros and cons of NUnit over MSTest and how you can overcome the disadvantage of poor test naming by using the NUnit Name property on the attribute.

Guess which company I wanted to work for?

While you're in an interview it's VERY important to impress the interviewers, but look for clues. Listen to their feedback on these challenges, if it's collaborative and you have a friendly chat then that's how they company operates. If it's a "not good enough" then you probably don't fit into their mold.

They WANT you to be the candidate (believe me, they've already seen enough bad ones). But company's often forget that you want them to be the company. Look for clues about what the company is like from the interview process itself!

Answer 4

For the code sample side, if they ask you to do a programming assignment, ask to see their coding standards so you know what they would expect the code to look like, and also give an indication of what they see as good coding practices.

This doesn't mean their code will all be like this. Some places may manage legacy applications or versions, which have awful code bases. Anywhere which doesn't have coding standards (or can't point to general ones such as PSR-2) is somewhere which is likely to have code quality issues.

A small piece of code may not be the best indication, as they could write a small application which is extremely neat, but doesn't represent their main code platform.

As for the employee questioning, ask the people in the interview the best and worst parts of working there. They are able to discuss it, and it's something which puts a lot of people on the spot, so isn't always rehearsed.

Answer 5

I understand your frustration. You want to have enough data to make an informed decision. But you are taking a big risk.

Unless you are far above the other candidates in terms of requirements and the company has switched from interview mode to trying to convince you to accept their offer, your requests will probably make them decide that it isn't worth making an offer to you.

Faced with a candidate that wants me to find expose code, and wants to interview current and former employees; compared to 9 others that aren't asking for these things - I would focus on the 9.

No matter where in the process your application is, I believe the risk is that your application will not make the cut to the next step. As long as the company has more qualified candidates than open positions they can decide to be quick to eliminate applications.

As an employee I am not sure that I would want to be interviewed by a candidate, unless it was part of the process for all candidates. And as part of that process I would be evaluating candidates..

Answer 6

Please forgive one more answer in a long series of answers, but my suggestion explicitly states some things that other answers imply:

When being interviewed, the company will ask you about the things that they care about, and this can tell you a lot if you pay attention. Code reviews, unit/integration testing, coding standards: these are the tools that help companies write good code. Companies that care about good code use these tools, and as a result they will ask you about your familiarity with them. If the interview process itself doesn't make it extremely whether or not they are following best practices, these are the sorts of questions I would ask as an interviewee to try to figure it out:

1. How does your code review process work?
2. What is your code style guide? Do you follow a particular standard for your technology? (PEP8, PSR2, etc...)
3. What tools do you use to manage your continuous integration and deployment?
4. What tools do you use for managing writing/running unit and integration tests?

These things can tell you a lot about a company without needing anything else. You can also word them so they don't sound like an interrogation and gets the interviewer engaged: "In the past I've worked on teams that use bitbucket to manage code reviews. What tools do you guys use for to help manage them?" or "In the 'tabs vs spaces' debate our team chose X. It's crazy how much controversy that created! Where do you guys land in that debate, and as a team how do you decide what standards to follow?".

Questions like this accomplish a few things:

1. They make it clear that you care about good code, and aren't new to these concepts. If the place you are applying to cares about good code they will absolutely pick up on the fact that you ask these things, and view it positively.
2. You don't sound like you are interrogating them and can start a conversation with them about an aspect of their code management process
3. You find out about their standards!

If you ask them about "tabs vs spaces" and their answer is something like "I dunno, whatever people want I guess" then you are obviously interviewing with a company that is not taking things seriously. If you start a friendly conversation about continuous integration and they don't know what you are talking about, then obviously you are in the wrong place.

In essence, companies that write good code do so because the developers care about good coding practices. As a result, you should be able to have a coherent conversation with whoever is interviewing you during a technical interview about best coding practices. Granted, when you get in you may find some areas where their standards are not practiced as well as they claimed during the interview - no one is perfect after all. However, if the employees care about standards, then in all likelihood you don't have much to worry about in this area.

Answer 7

As you've seen already, this isn't a great interview technique. If it was, it would be commonplace.

In asking to see code samples of your prospective employer, you're turning the interview into a coding review where you're the judge. It's also intellectual property, and there's the potential of exposing security sensitive material to a third party (you, the candidate).

This isn't going to happen.

You're also asking for confidential contact details of previous employees. This also isn't going to happen (for obvious reasons).

You can best assess the suitability of the company by doing your research and asking questions, this is what everyone else does.

For example, it's perfectly OK for you to ask what challenges they've had in roll-outs or projects, and ask about their current development processes. But keep in mind that asking these kinds of questions can result in a negative reaction (no one really likes to admit they (or their company) is at fault).

Answer 8

Well, I feel the need to put my 2 cents in.

I won't sign a contract until I:

1. Meet my future teamates
2. Discuss some code with those teammates.
3. Meet my boss.
4. Spend at least a couple of hours in the office while things are operating normally.

The best way to accomplish this is by going and doing some pair-programming with your future colleagues for a couple hours.

I usually let my prospective employers know about this requirement early on in the interviewing process, generally when they ask me if I have any questions. It's at that point that I say something along the lines of "Well, that sounds great, and I'm interested in going forward with the hiring process. I should let you know that I want to (fill in your process summary here) before I actually sign a contract, but I'm willing to wait until you're sure you want to hire me.

I usually mention something like "I think it's in both of our best interests if we make sure we really are a good fit for each other". Most companies agree.

When I'm on the hiring side of the fence, I would find that reasonable. My experience has been that my interviewers tend to appreciate it. The ones that don't are probably working in an environment I want to avoid. Spending a few hours letting a candidate you want to hire make sure she integrates well into your company before hiring is high return on investment, and I don't like working for companies that won't invest such a small amount in creating a good team.

Answer 9

I do not think the employes the company could allow you to contact would be of great value. Since they wont give you every single employe contact, they will have chosen a panel of happy - friendly employes who will give you the exact same feedback you got from the recruiters. You better trust the recruiter on this one, since it's too easy to "game" this question.

Asking for the process and some non critical samples of code produced or maintained by the company on the other hand is quite a reasonnable request, as long as you do not ask that they forward it to you, or ask to leave with it. I can see this question be raised at the end of the interview when the recruiter ask if you have any question.

Answer 10

I have always wanted to look at the code before i started. But in place you can ask specifically what will you be working on, how the development environment is setup and what immediate module will you be working on and what dependencies, technologies, and where in the SDLC the current project is, as well as if what the n-tier architecture is, which modules , ask what you do NOT have access to, where the documentation is etc.

As for references at the employment, i have done that for free using linked in, you can find people that work somewhere else but used to work for the company in question. Imn my experience my feedback on linked in , people said they wish they did (ask former employers on linked in) and gave me allot of information that i would not get on glassdoor or indeed

Answer 11

I believe in every job interview it is apparent who is initiating the potential transaction. Are you the scarce commodity, or are you being aspirational? The ability to write commercial code is very scarce, as it requires a level of concentration many game-addled younger folks do not have. Hence the company should in most instances be selling themselves to you. I would modify your request, to having probing questions of the interviewer to assess his or her abilities to code, rather than ask to see some of the company's code. If you ask to see snippets, this suggests you might be seeking a guide for your own answers, whereas asking the interviewer to code for you suggests you don't want to work for fools, a proper attitude.

Answer 12

Companies that specialize in producing open source software are usually more open to this.

• First of all, a large portion of their source code is available on GitHub or for download.
• Many of them also make much more things open, for instance their issues, their unit tests, their experiments, their roadmap. How issues are handled reveals a lot. While a few open source companies only push code to the public after internal review, most work from the start in the open, with all developer work directly in branches visible to all on GitHub, making it easy to get a true idea of what a coding day looks like.

Such open source-centric companies have offered me to have a call with members of the team to discuss what they think about the job. This is my limited experience, but it seems that being open is a culture, and it usually means that the company is not scared of their employees talking frankly about the workplace.

Answer 13

As someone who has (over koff-koff... several decades ...) "interviewed a'plenty of 'coders,'" let me now very-plainly tell you this:

"I don't give a damn *about 'your source-code!'"

If you actually made it to my interview, then I already presume that "you are technically competent." (Therefore, I expect you to somehow "land four-paws down.") Therefore, what do I want? One thing:

"When presented with a technical requirement (that, of course, caused your purist-mind to puke ...) what did you do?"

I'm very much focused on social things. Will you integrate well within any of my existing teams, or will you simply cause problems? Will you "dig down into the trenches and help us," without complaining (much ...), or will you just "cut and run?"

"Yes, I have a business need to hire you!" But – "are you the individual that I want to hire?" 🤷‍♂️