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?
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.
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???
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.
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.
* 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?
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.
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).
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.
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.
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.