Hacker News Reader

Comment by remyp | Hacker News Reader

I’m always surprised when candidates ask for this. I can see why they would want to, but it presents problems for the company:

Employees always sign stuff to protect the IP. I’d have to go get paperwork from the company attorney to cover non-employees before I can show them anything.

Can they really learn anything about the codebase in the limited interview time we have? They’re not getting repo access.

Why is the candidate asking this question in the first place? It makes me wonder if they’re inflexible or unwilling to be pragmatic about imperfect code. If they have a track record of leaving companies because the code isn’t up to their puritanical standards then it’s a hard pass.

View on HN

It doesn't necessarily mean they have puritanical standards. But for me it would offer a glimpse into what its like to be a developer at a company. Like, does the company tell developers to just "make it work" in the quickest amount of time possible or does it let them come up with a proper, maintainable solution thats not going to cause headaches for future developers?

If I see a codebase that is blatantly vulnerable to something like SQL injection (i.e. GET parameters being referenced directly in SQL query strings) then this would probably be a deal breaker for me. I get that nothings perfect but something like that would indicate an extremely poor competency of the development team.

EDIT: That said there is another side of the coin - the kind of place where developers spend hours discussing things like how to name a class or a variable. That would also be a frustrating place to work in - its about getting the balance right. Also seeing the way the developers talk about their code would be interesting - are they dead-set and have an "emotional" attachment to their way of doing things - or are they open to new ideas and willing to discuss pros/cons of differing solutions and make compromises as a team.

> Why is the candidate asking this question in the first place?

Because every company says "we take quality very seriously" and standard crap like that, looking through the code and the most recent contributions is the only way to actually assess them.

> It makes me wonder if they’re inflexible or unwilling to be pragmatic about imperfect code.

Which is perfectly reasonable when the hiring companies try to avoid being pragmatic about imperfect people. They'll give stupid codes tests and look for rockstars, this is the employee equivalent. Rockstars are picky about their collaborations.

> Can they really learn anything about the codebase in the limited interview time we have? They’re not getting repo access.

Ideally I'd want to run some tooling over it and get some stats like cyclomatic complexity and collaboration graphs to see how many pointless layers they have. I'd also take a look at their unit testing to see if anyone in the company actually understands what a unit tests is.

Interviewing is meant to be a two-way street and code review is the only way to address the information asymmetry and make this true.

I absolutely agree that this is the employee equivalent of "jumping through hoops".

With that said, for the companies I've hired for in the past someone who sees the state of unit testing as a dealbreaker would likely be a bad fit. If they're hiring it might be because the company needs more hands to help make the tests better!

It really depends on how the rest of the interview process goes, if they said their tests were in horrible shape and were committed to making it better then it's not a dealbreaker, even less so if they can point to some commits where they've improved things. The two common types that you can sus out with a code review are the bullshit artists and the ones that really do think the code is great.

There are other factors too, I work somewhere with mountains of horrible code, but they compensate by not putting you under pressure and giving you time to work through the mess. If they had the same code and constant pressure then I'd be long gone, life is too short for that.

I'm really surprised by the opposition to the idea, we all seem to agree that good devs are in high demand but few on the hiring side seem willing to bend to that reality. We all seem to agree that hiring is expensive but the hiring side doesn't seem willing to let the candidate who will walk in a month eliminate themselves.

if this were actually true I'd be pretty on board. there is a mountain of half-assed code out there. cleaning it up and making sure its adequately tested can be pretty satisfying.

unfortunately those are things organizations like to make lip service about fixing. often times the state of the project is symptomatic of underlying structural issues in the organization that they aren't really willing to address.

> Why is the candidate asking this question in the first place?

Conway's Law. You can lie about your company during the interview. (You probably do, at least a little. In my experience, every company does.) But ultimately, if your company's product is software, you can't fake the quality of the source code. If your teams are dysfunctional, it'll show.

(It can also be apparent in the use of the product, but lots of companies don't make consumer products, so it's not reasonable to expect the applicant to have used your software.)

> Employees always sign stuff to protect the IP. I’d have to go get paperwork from the company attorney to cover non-employees before I can show them anything.

Why? There are very few companies in the world where the source code contains any 'secret sauce'. There's PageRank, and ... that's about the only one I can think of. What exactly are you afraid they'll see? Give me 5 or 10 minutes to look at the source code to Photoshop or Mathematica and I might learn something, but I'll be no closer to launching a competitor, or hurting your business.

What I'm hearing is: applicants are expected to trust you implicitly, while you display absolutely no trust in them. Interviews are already an inherently asymmetric relationship, and you're doubling down on emphasizing your power over the candidate.

Compared to my experience in other fields, this is not normal. It's paranoid and petty on the part of the company, and it's no wonder tech companies have trouble with hiring and retention when they start business relationships this way.

Personally I've always been as upfront as possible with candidates about the state of things. I've never had a new employee join and be surprised with what they found, and I've never showed a candidate code prior to hiring them.

Sure, there may be very few companies in the world where there is 'secret sauce', but the problem is that they all _think_ they have it. If my GC says I can't share IP without paperwork signed then I can't share it - the reason is not relevant unless I have the power or influence in the organization to change the policy. I'm not getting fired over it and (at least at previous companies) I'd get laughed out of the room for even asking.

I'm an engineer myself. This isn't some kind of game I'm playing to pull one over on poor hapless souls - we can argue what ought to be until the cows come home but the reality is that the vast majority of hiring managers have their hands tied by company policy.

The code base is a reflection of the values that are at play in the company's development process. It's a kick-the-tires defense against puffery, which is something a recruiter is perfectly allowed to use to get you to sign a contract.

Plus, it gives you an honest picture of something you will literally be looking at for thousands of hours. Would you buy curtains without knowing what they looked like?

Like I said, I see why people ask for it. If the benefit to you of getting that information is worth the risk of potentially making a bad impression then go for it.

If you want to see the code, just ask.

If someone like you has a bad impression of me even though you understand why I'm asking, then I guess it's a bullet dodged.

This feels a little hostile, but I don't consider this outcome a bad thing. Everyone wants to avoid a bad fit - my intention was simply to help people fully understand how they may be perceived.

Sorry, was not meant to be hostile.

I should say that I understand if a company cannot show me their codebase, it is just one thing to consider among many.

I think you are jumping to conclusions here. There are plenty of respectful reasons why a candidate would want to look at the code. After all, the code is what he/she is going to work with. So doing this is as logical as getting to know your future colleagues, workplace and corporate benefits. I see two main reasons that may prevent the company from sharing the code. First: their security is below standards: e.g. hard coded passwords to the production database in code. Second: their business is extremely sensitive to security(e.g. they are an anti-malware software company or a financial institution), so they must run a deep background check on candidates, which is time consuming, so they only do it right before offering the job and not earlier in the hiring process. In any other case, an simple NDA would be enough.

Hard agree. If an engineer asked me for this I’d assume they have no concept of how an actual business operates and likely be a hard pass on them

Can you elaborate on that please?

Reply on news.ycombinator.com