Ask HN: Is it rude to ask an employer for a walkthrough of their code base?

13 points by nullundefined ↗ HN
All too many times have I joined a company only to find a horrendous code base that makes me question the business and its employees.

Is it rude to get a walkthrough ahead of time to figure out if it's a code base I want to bother working in?

I figure employers look at my code, ask for samples of my work. Why not see theirs?

15 comments

[ 3.5 ms ] story [ 45.8 ms ] thread
I'm not sure that it's rude, per-se. But, it would be considered a disclosure of sensitive IP. (Obviously, most corporate codebases deserve to be gutted and rewritten from scratch, but there's some kind of internal valuation.)

For some perspective -- the company I work for was sold for a tidy sum, and part of the negotiation was that the buyers got statistics about the codebase (number of lines of code, which languages certain sections were in). They didn't get to see any of the code before the sale closed. And, a prospective buyer has a lot more to lose & a lot more influence than a prospective employee.

You can probably ask about processes and what languages etc. High level architecture of the system. That will give you some kind of idea. how they handle refactoring?
All too many times, you say? So you've repeated the same mistake over and over with the same results each time and many times at that?

My question to you: what is a good code base? What would be the features of such a thing? How would you characterize it and quantify it? What are some of the things you consider "horrendous"? What tolerance do you have for such features?

I think if you can answer the questions above, you can find the right questions to ask. Then you can start to ask the right questions. Can you see my code before I hire you? No.

not sure if these are great questions to ask, but some ideas:

* what's the economic cost to the company/organisation for shipping defects? what's the cost of correcting a defect that's been released?

* what level of automated test coverage is there? how long does it take to run all the automated test suites?

* how often do you deploy/ship releases? why?

* has the company ever hired someone for a dev role who turned out to be a poor developer? how did they identify this, and what happened afterwards?

"Can you see my code before I hire you? No."

I'm curious, but why?

Pros to letting him see the code base

- You just made an offer to this candidate, you obviously like him and think he is a good. Good candidates are expensive and time consuming to find. Recruiters will charge 40k to give you a candidate you have a 50%(this is being super generous) of hiring. Letting him see the code base probably saves you 5k-30k depending on how selective you are with candidates.

Cons

?He figures out your secret sauce based on looking at your code base for 10 minutes and builds your company from scratch and runs you out of business???

Honestly, if I get the sense a candidate is chasing the perfect code base, he or she probably would not get an offer. People like that leave unexpectedly once their itch is scratched (or not scratched).

Assuming that the candidate was extended an offer and asked to look at the codebase, I would require an NDA. I work in a niche market so you can't get the secret sauce in a sit down, but there are methods that can give you an advantage. For example, I worked at a place that did something they weren't supposed to be doing to gain a competitive advantage. To this day, 8 years later, despite working at several of their competitors, I still haven't seen anyone else do this thing. I haven't revealed this to anyone and I won't. We aren't doing anything like that, but we do have methods that I haven't seen till now.

Trying to think of a better way to get this info without code.

I like talking about how testing works. How code review works. How deployment works. I think those all tell me more than I would learn looking at the code.

Could they lie about test questions? Sure. But I am sure they could show you cherry picked code that lies also.

> I figure employers look at my code, ask for samples of my work. Why not see theirs?

Absolutely! I always ask to see the code, and have turned down jobs before because I can see the system is a total train wreck.

I dont expect perfection, and indeed perfection doesn't exist. I also believe that done is better than perfect.

But I have seen some royal clusterfks in my time, and I think it's perfectly reasonable to ask to see the code.

I imagine a good chunk of them will decline due to IP reasons and stuff.
Great question. Employers sure don't have any reservations about seeing your GitHub, watching you whiteboard random and obscure puzzles for 8 hours, requesting 50% of your yearly time-off on worthless interviews, etc.

Seems like what's good for the goose and all...

Having thought about it, I'd probably run as fast as I could if an employer with whom I was interviewing had a over-grown, out-of-contgrol spaghetti-code, all-javascript-SPA type code base - all business logic on the front-end, endless chains of promises and events being fired asynchronously from God-knows-which controllers, etc.

Add Mongo or another NoSQL solution as their main backend, and the interview would come to a hasty end. :)

And let's be honest, unless the potential employer is working on Top Secret defense software or is some Silicon Valley, PHD-heavy AI startup, their typical CRUD app does not warrant a NDA or anything else, at least for a cursory glance at the main code base, build system, etc., especially if you're not currently employed with their direct competitor(s).

I always do. Sometimes this involves tedious NDAs & sometimes it ends the conversation with the company.
Don't just ask for the codebase, ask for repository access!

You might care about how it looks, but you should care more about how its changing. Tell them your more than willing to do it in office on a company laptop for an hour or two, tell them you don't mind having someone sit with you to answer/field questions.

This is right up there with "can I see a cap table" for questions to ask before taking an offer.

I might be completely wrong but I think if you request from a position of strength, in that you have pleased all the interviewers and they are visibly eager to hire you ASAP, then it seems possible that they let you have a look, if not the core logic at least the less critical parts. Whether or not it is rude depends on how you make the request. :)

About horrendous code, I haven't changed many companies so I wonder how many real world products that are some years old have code bases that are not some sort of a hard to figure patchy clutter if not down right trainwreck.

As for employees looking at my code, it isn't as straight forward. The code I upload to public repos like github are meant to be seen, used, extended and/or appreciated by peers, so letting potential employers look at them isn't a problem. However, when I mention that I have some personal projects brewing, which to me are potential business ideas, I would not let them in on too much detail much less look at the source code. Even if then agree to sign an NDA I wouldn't let them as I don't trust big corporations.

definitely ask for it or at least try to get familiar with their workflow as much as possible
Some employers have a special knack for making you forget to even ask such probing and important questions. I have had the same thoughts and will remember to this the next time I have an offer.