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.
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.
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.
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!
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.
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.
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.
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.
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?
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.
I should say that I understand if a company cannot show me their codebase, it is just one thing to consider among many.