How to advocate for prospective employers to show us their codebases?

While this makes sense to some degree, it sounds like an easy way to filter candidates based on how difficult it may be to work with them in the future. It really depends on how this is approached. Someone that drops an ultimatum during the interview process would be a hard pass for me. Now, if it were phrased as a request, maybe. It also depends on how they handle no. Either way, not hiring the candidate if there is disagreement on this sounds like a win for both sides. They likely are seeking a different work culture than the company has.

NDAs tend to be pretty invasive (they can sue at your expense whenever, you're presumed guilty if any of your IP looks like theirs no matter how novel it actually is, ...). Those clauses might not be used often, but if not then why include them in the contract?

With such a high potential cost, you'd want to buy something important. I don't think code quality matters that much. It's probably crap, it's probably fixable, and you'll probably get accolades for tracking down thorny issues and for sweeping changes that make it better. If you accidentally hit upon a company not using version control and not willing to change then in such rare cases you can grab another job in a couple weeks.

Unless some extraordinary scenario applies where you need each prospective job to have as high of a chance of success as possible (H1B quasi-slavery and whatnot), I don't think I'd bother even asking about code health.

I understand what you are saying, but a request/demand like that would be a hard pass for me as a manager. I’ve worked at companies that require a high level of security clearance and we wouldn’t be able to show you anything before you are cleared. No NDA will fix that. What I’ve done before is to show cases or examples of fake code/work tasks that looks like production examples but are very different. This is for the candidate to get a feel of what they will work with.

I can understand motivation to read some code samples from prospective employers, but not for the examples that the OP mentioned.

There are some terrible software patterns that someone might not want to work with, but such things can be found in every team of every company. My experience is that good engineers will gradually come to own whatever legacy they have inherited and either clean those up or rewrite them until they are satisfied. So for the purpose of not wanting to work with tech debt, asking to see the codebase seems futile.

But a codebase is also a reflection of culture, and it's reasonable to want to understand what culture you will be getting into. For example, if every other code comment contains a juvenile joke and that's the sort of thing that will offend you, that might not be a place you want to work. Cleaning up code is much easier than cleaning up culture.

>Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious. -- Fred Brooks.

>I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. -- Linus Torvalds

So really, why ask for just the code? Why not ask for a copy of their database as well? That's even more important. It has all the relations and structure, the customer data, the data points they use to judge success, etc.

I think you can imagine plenty of reasons why they'd say no to that. And the reasons regarding proprietary code, while not as strong, are not all that different.

Of course, it would be nice if they had something to show. A lot of companies do some work on open source modules that they use, so they should at least be able to show that.

But that's not necessarily indicative of their entire legacy codebase, nevermind their data structures. And many companies have some nice new code that they're working on, but still have to support lots of old legacy code as well. So you really need to be able to deal with that anyway.

I already have multi-year NDAs long enough to still cover me after I've switched jobs twice. The last thing I need in my life is to be under 2 previous employer NDAs, a 3rd NDA for current employer and rack up a 2..4..10 more NDAs while interviewing. Rinse&repeat when I look for a job again in 3-8 years.

You can do this at smaller companies if you’re a strong candidate. Startups understand that they need to offer something that Google/Meta/whoever can’t, and they often will be very flexible during the interview/courtship process.

I interviewed with the CTO at a series A, and he was enthusiastically talking about how good their CI and developer productivity was. I asked him to show me, and he happily solved an actual UI bug in front of me to show off the system. Left a very positive impression.

Hiring managers at big companies probably wouldn’t risk doing this, because they don’t know whether it’s allowed. Although maybe they would if it’s something they’re proud of and they have a bit of an anti-establishment streak.

do you necessarily need to see whole codebase? or like ancillary tools: run this linter for me, show me your API footprint across the dependencies you use, give me a sense of your cloud stack. test coverage. total lines or at least ratios between programming languages.

show me a random file that exists in every codebase but isn't sensitive, like the entrypoint

show me your jenkins / CI, how long do they take, how often do tests flap

screenshot of datadog / sentry

all that said, in the case of ML, I'm guessing even the dependency graph is giving away some hard-earned information like 'this implementation of this algorithm works best for our domain'

I think you might be in the minority on the NDA thing. I don't want to get sued by some dumb dog walking service because I copied their website color scheme and signed an NDA with them.

I do wonder if the real purpose of the 'ridiculous and demeaning puzzles' is more psychological assessment than skill testing in many or most cases.

Granted, there is the problem of academic cheating in CS so for people coming right out of college into the job market, so it's likely an acceptable filter for screening out people who haven't ever really written their own code from scratch, but otherwise. for people with proven track records in the industry?

Maybe the thinking is: "We've got this mess of a codebase, it's poorly documented, if it ever got out how bad it is we'd be very embarrassed, and we want compliant team players who won't shake up the boat or demand we overhaul the whole thing, as we care a lot more about revenue than code quality, and this thing does work, sort of, most of the time, and we sure don't want anyone writing memos about massive security holes to upper management... now, will you jump through these degrading hoops like a good little poodle or not?"

I don't know how much you'd be able to get just from looking at a code base. Most codebases suck in some way, and it's easy to read code and judge - but what is more important is how it's dealt with. eg How good is the CI? What is the team attitude to technical debt? You won't get that from reading the code base.

How about this instead? Ask to briefly shadow some of the team as they do their normal work. You will hopefully get a much more real impression of what working there is like.

I once had an interview last several hours, and in the middle they sat me down with one of the existing workers for a 45 mins chat. The guy talked about watching movies on shift - it was an honest chat.

ps. I work for an employer where almost all our code is open source, so we would find this an easy question :-)

I don't really need to see the code but there are some proxy questions.

Two of Joel questions cover example downsides (slow builds, bad tooling), post is from year 2000 - so in theory asking about source control might be silly but if company is not using GIT in 2022 I would slowly (not to make any sudden moves) try to find my way out of the interview room because there is seriously something wrong there.

https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

> And, it occurred to me that there's a big double standard in hiring around this. It seems like the software development process, generally speaking, is built on what is essentially a lack of trust in engineers - we can come in with over 10 years of verifiable experience, talk eloquently about that and our abilities, and still be met with these ridiculous and demeaning puzzles.

This is called a "power imbalance". So long as it's possible to recruit developers despite all these things, they will continue. Unless you manage to cartelize people into refusing to work under those conditions.

The truth is, most codebases are terrible. In any company that's been around for more than a year, you're likely to find most (or all) of the following:

* Legacy code that was written by people who left long ago and nobody wants to touch

* Code written in "uncool" languages, frameworks, and libraries that nobody wants to touch

* Code that was written by various offshore contractors

* Non-deterministic test suites that randomly fail and that engineers learn to skip/ignore rather than address

* Long build times

* Weird, bespoke code that was written for "fun" rather than using an established library or framework

* Microservice hell - impossible to tell what the codebase actually does since the true business logic is distributed across so many different services, and only an old-timer will be able to tell you how they all connect together * Severe lack of internal documentation

Given the above, when trying to select an employer, I think it's more important to carefully evaluate the people you'll be working with:

* Are they pragmatic or idealistic?

* Are they chasing fad technologies or are they comfortable using established frameworks that get the job done?

* What do they value more highly, delivering useful software or developing byzantine processes for everything?

* What percentage of the workforce is full-time vs contractors?

* What's the average years of experience of the engineers? Are there any adults in the room?

* Do people know the vision of the product? Do they what they're building and why they're building it?

Getting access to source code (as part of the interviewing process) will probably be very difficult as noted in many comments here. Also - what code would you be given access to? (some parts? a file? a whole repo? all of which could be cherry picked to show the company in a positive light.)

That code would also have to be vetted in case there's anything sensitive in it security-wise..? Also, source code in itself wouldn't tell you about the processes that are in place or not (how easy it is to deploy code, what's the review process like, etc.)

On the other hand, you should ask questions to learn as much as you can about the development practices. Getting answers to the Pragmatic Engineer Test [0] (based on the classic Joel Test [1], which is useful as well) will probably tell you a lot. Learning that code isn't tested (and that there are no plans to add that, or worse, testing is not considered valuable in general), and/or that code isn't versioned, would be obviously informative.

Finally, from personal experience, I'll add that as a freelancer, you typically get more leeway re: asking to see code. Specifically, if a client comes to you to help them with a project, it's much easier to ask to see the existing code to understand what the current state of it is, and to give an accurate assessment of how much work will be required.

[0] https://blog.pragmaticengineer.com/pragmatic-engineer-test/

[1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

It's a reasonable question, but frequently it's quite a complex answer. Given you are likely just one of many applicants I think it may just accelerate most employers turning you down.

If seeing the codebase is an important part of your decision (ie not just knowing what stack/libraries are in use) you may wish to apply for an open source oriented company.

As a hiring manager I show the source code of our product (some easy modules that show the general architecture) to every candidate.

It helps candidates to know where they’d be getting into and also serves as a starting point to very interesting conversations with them.

It helps that I work for an open source company so our code is public anyway.

I love this. It's very simple and fair. "Show me you can code. Yes, if you show me."

That's what we effectively sometimes. We were asked by a company to work on their codebase, add some additional features. In order to give a good effort estimation, we asked to looked at this Qt C++ codebase. I went to their office and look through carefully. The code was good and we could make a good offer.

In other cases we saw bad codebases, and asked for 10x more. Which they paid. And it really was 10x more the effort, as it turned out.

"We" is not a single employee, but a contracting company. So our leverage is better, compared to a lone wolf.

As part of my phone interview at Google in 2015, I was given a piece of real code to read, with all the comments removed, and asked to figure out what it did. Was actually a fun little exercise.

If I had done this at a previous company, it would've been a hard pass. The stack would've been considered modern 10 years ago. And was still using many of the same tooling and versioning from that era.

Some of the code was the worst I've ever seen. 50 classes in a single file, 10,000 lines long, almost impossible to navigate, due to needless OO "lasagna" layers.

(They sure had lots of unit tests though!)

Debugging or improving a snippet of production code is probably a fine interview challenge, at least for small software companies. Maybe a hiring manager would give a challenge like this (in place of "demeaning puzzle") if you asked at an early step of the interview process.

If there was any collective bargaining in software development then YES, it’s an easy ask.

If you’re considering a tiny startup desperate for developers then YES, it’s an easy ask.

It will not work in any other environments because of the power imbalance.

> still be met with these ridiculous and demeaning puzzles

That's to weed out people who did a 'bootcamp' or watched one youtube video and decided to quit flipping burgers and call themselves a 'senior engineer'.

You can always ask, and, when the prospective employer says no, you can walk.

Just work for companies that default to open-sourcing everything. Easier said than done, but that's the best guarantee.

Funny you should ask. With my current employer, after the interview, I asked to see the code. My future manager took me upstairs to the location where the team was usually sitting. Surprised to see me, team leader was happy to oblige. I pulled up a chair, sat next to him and (while manager was standing by, watching), asked him to click through the codebase where I should be working if they hired me. I spent at least 20 minutes. When I was happy, I shook his hand and thanked him for showing me the code. I was happy with what I saw, accepted the offer and currently work there.

Tldr: ask to see the code. Interview them, its a two-way street.

allowing interview candidates to look at the code is never gonna happen. Your best bet would be to try to meet some of the current employees socially, and ask them about their tools and processes to get a sense of what the workflow is like. most people would be pretty willing to talk about that if you bought them a beer or something.

How about simply asking questions like "how long does it take to compile the codebase locally?"

Never gonna happen.

I wouldn't screen for code quality, but for attitude. Every codebase is some level of crap. The older, the larger it is, usually the crappier. This is fixable, however, if they let you. The problem usually arises when the focus isn't on maintainability, the team doesn't want to improve their workflows, or the feature pressure is just too high.

Observe your interviewers: is the interview a questions-answers style process, or are you having a conversation? Do they come over as enthusiastic or rather as close to burnout? Those are tell tale signs of how it will be to work with them.

Just look for open source