I know this question will raise eyebrows and I kind of enjoy it.

I passed the interview with a company making software, and got an offer. May I ask for a sample of their codebase? The reason is that the company is founded and run by a number of highly talented PhDs in Mathematics and Physics, and this often implies the quality of the source code is pure junk (to quote a classic: https://academia.stackexchange.com/questions/17781/why-do-many-talented-scientists-write-horrible-software). Every "pure" software engineer knows that: behind a brilliant researcher an awful programmer is hidden, and I don't want to be the janitor cleaning after him/her.

Is that an acceptable request? If so, how can I motivate it without sounding rude?

  • 2
    I'm not sure how helpful the internet is going to be here. The only way you're going to find out is by asking them. It doesn't sound unreasonable to me. If I were the company, I would probably ask you to come in to the office instead of sending you anything.
    – Bowen
    Mar 20, 2015 at 20:19
  • 2
    And one sample tells you nothing about how their other people code. Besides the question of whether they want to show you anything significant without a signed NDA, though that might be manageable. Basically, I think the answer is going to be that cleaning up others mistakes is always an implied part of the job, and making too much stink about that is a good way to get invited to apply elsewhere. Tl;dr: you can always ask, but you may not like their answer or their reaction.
    – keshlam
    Mar 20, 2015 at 20:41
  • 6
    THAAAT's the attitude companies want new hires to show up with </sarcasm>. Did you consider that maybe the reason they want to hire a "pure" software engineer is to bring good practices to their company? Besides, this is a question you should have asked in the interview. Mar 20, 2015 at 20:57
  • 3
    @NathanCooper - "Good Enough" isn't the issue. As an engineer (whatever discipline), you are being hired to solve problems. No one said "Drop to your knees," but if you're such a prima-donna that you aren't willing to tackle a funky codebase, I'd be careful about calling yourself an "Engineer." The question of whether or not the position will have the authority to correct the funkiness is entirely appropriate, however. Mar 20, 2015 at 21:18
  • 1
    I suspect keshlam is right. It's unfortunate that this wasn't part of the interview. But I'm sure you could reach out to them and get some time to look at the code, the problem's they're solving and get a sense of your colleagues. I'm sure this company has no interest in hiring someone who doesn't want to work on the codebase.
    – Nathan
    Mar 20, 2015 at 21:18

2 Answers 2


It may be difficult to ask this question without appearing to be rude or arrogant. You run the risk of poisoning the well if you ask the founders of the company to prove their competence at the very start of the relationship.

Let's say you're the hiring manager in a similar organization. What would you think of this request? If you consider what it implies about your day-to-day interactions with the employee for years into the future, would you want to have the person who made it on your team? Think carefully about these things when wording your question (or deciding whether to ask it).

If you decide to go forward with asking your question, you should phrase it as wanting to make sure your skills are a good fit for the existing code base, and not that you're worried about having to clean up someone's mess.

  • I can't help thinking of this the other way round "Think about what the candidate would think about their day to day interactions with this employer for years to come; questioning the abilities you've stated you have, even asking for proof!". The interview process isn't really anything like day to day interactions. You may well be right, but you shouldn't be Mar 24, 2015 at 12:40

If you had warranted suspicions about the codebase being "pure junk", the time to probe that is during the interview process. It is perfectly fine to ask to sit down with someone and get a "code tour" and you could then ask pointed questions and see where things stand. I've actually done this myself more than once (although I consider myself to be on the domain side rather than dev side). The thing I learned from it, however, is that the codebase is FAR LESS important than the people you would be working with.

I would much rather have a crappy codebase and really mindful/creative team that is open to new ideas than a tight codebase with 'holes running the show.

Waiting until the offer comes and then having cold feet means that you haven't thought this through. It is OK to get second thoughts, but be up front about them to yourself rather than try to ascribe it all to "the codebase" just so that you can hold something in your hands that you can use to confirm your feelings.

Not the answer you're looking for? Browse other questions tagged .