I've been compiling a mental list of things I want to know about a potential team. The code itself is not one of them - too sensitive to get access to, too large and context-dependent to evaluate from an outside perspective. But I do have a bunch:

- How is the physical space, crowding, noise level, workstation quality? How many hours a week do you spend in meetings? How to decision makers think about focus vs. collaboration?

- What is the process by which a proposed code change gets to production, and how long does it take? Code review? Linters? Unit tests? Integration tests? Human QA? CI/CD?

- What is oncall like? How many alerts per shift? Signal to noise ratio? How do you manage incidents? What are postmortems like? Are they about accountability, system hardening, or trying to balance both?

- What are some of the debugging/observability/operational tools you've developed for your product? What are the stories behind them?

- How do decision makers think about tech debt vs. feature velocity? What if any official support is there for getting tech debt items worked on?

- Can I fix & try things on my own initiative in addition to meeting assigned tasks, or must every work hour be dictated by the process/PM? Is an architect telling me exactly how my code has to be structured or am I making my own decisions?

- Where do deadlines come from? How real are they? What happens when a project is looking like it won't meet its deadline?

- What would happen to the business if your team disappeared? What are your current projects and why do they matter?

I also like to ask what tool does the team use that the interviewer personally doesn't like, a different way around, whats the worst part of your job.

No, because the quality of the existing code isn't what affects my interest in the job. The vast majority of software out there has mediocre structure at best. Your responsibility is to improve it gradually, leaving each function or module you touch a little bit better than you found it.

The jobs I've enjoyed the most and learned the most from were incidentally the ones with the worst codebases.

That said, it's probable that there's a certain degree of awful that it's simply impossible to work productively with. As a hiring manager, I wouldn't consider it unusual or a red flag for a developer to ask to see the codebase; and every project has at least some code that isn't too sensitive to share (well, there are probably some exceptions in regulated industries).

If a developer doesn't have the maturity to be willing to work with a codebase that's six years old, where the earliest layers were quick-and-dirty proofs of concept developed without automated testing just to get a startup off the ground, and the latest are better but still flawed, then they're a poor fit here anyway. We need developers who understand that the code exists to serve the business and not for its own sake.

> We need developers who understand that the code exists to serve the business and not for its own sake.

You're absolutely right about that - there is always a balance to be achieved between delivering a feature/product on time and writing maintainable / "good" code.

What would be a red flag for me as an interviewee would be to see a codebase with poor standards, and then see pull requests open with code that wasn't any better. If the quality of the code is only getting worse that makes my life as a developer pretty miserable.

Nothing is perfect but in my experience the difference between working with a well thought-out and architected codebase and something that has been hacked together as proof-of-concept is immense. Fewer bugs, fewer security vulnerabilities, the ability to deliver features faster etc. I don't think that code quality is just something for developers to pat themselves on the back for - it genuinely effects business outcomes.

> What would be a red flag for me as an interviewee would be to see a codebase with poor standards, and then see pull requests open with code that wasn't any better. If the quality of the code is only getting worse that makes my life as a developer pretty miserable.

Bingo. Bad code bases are fine as long as people agree that it needs to be better. I’ve worked on bad code bases that people just do the bare minimum, quick and dirty bull shit they’ve always done, and it’s absolute misery.

> I’ve worked on bad code bases that people just do the bare minimum, quick and dirty bull shit they’ve always done, and it’s absolute misery.

Those people do not realize anything is even wrong. :(

> leaving each function or module you touch a little bit better than you found it.

This is some of the best advice you can give a developer I think it's known as; The Boy Scouts rule: “Always leave the campground cleaner than you found it”.

Some people I've worked with seem to miss the importance of this...

The problem is that someone's definition of "cleaner" can be wildly different from yours. Sometimes even justifiably so.

That's the reason that all companies should have in-house coding standards. There are many different legitimate variations on "clean code", so the important thing is that one variation is chosen and used consistently by all devs. Which variation is chosen is less important.

Yes people can disagree on what "cleaner" code means.

But generally people can agree on badly designed code eg; bad naming, deeply nested logic, bad structure, tight coupling, no separation of concerns...

Sometimes this has been really hard when the campground was already spotless.

At my previous company, I asked to have a look at the code base before joining. The reason was that this was a system that has been in development for the past 13 years and I wanted to get an idea of how well they handle tech-debt on such an old code base.

The application was developed in C# and ASP.NET and I ended up being quite impressed with how the team handled this. When developing a new feature they made a point to clean up the code they touched to make use of newer language and frameworks features. Also, from time-to-time, there were bigger efforts to clean up specific areas of the code.

This was a 13-year old code base that was in many parts in better condition than many greenfield projects I have seen.

It definitely made my choice to join the team easier.

Thanks for your explanation. I think the real question here is to what do you pay attention when you inspect codebase of your potential employer and what conclusions can you make from it. Your comment answers that. I also think the fact that you were able to make those conclusions gives you additional credit in the eyes of the potential employer.

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.

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?

The easiest way to accomplish this, practically, is to do contract-to-hire. Do a couple of pull requests and take the temperature of what it's like to work there, and you'll figure out pretty quickly whether it's for you or not. Of course, many companies are averse to this for a variety of reasons -- at the end of the day, there can be agency problems if there isn't a base level of good faith commitment from both parties.

I never have, and I probably never will. I'd be surprised if a potential employer would agree to doing so (why would they? It's additional risk and expense for no gain.)

I have worked at places with terrible existing codebases (including where I work now). I just make it my mission to do what is needed to improve the situation. That in itself can be fun and rewarding.

Also, the vast majority of commercial codebases out there are pretty awful, regardless of language or the size or apparent competency of the company. If you have a low tolerance for working with substandard code, you're going to have very limited options for employment.

I think it's surprising that people are saying the code is too sensitive to view. We live in a world in which an increasingly large portion of code is open-source. Is it really that big of a deal if a prospective hire gets a glance at your CRUD web app code?

People don't have photographic memories. They aren't going to go home and write this stuff out.

Granted, there are areas where code is perhaps too sensitive for even a quick look. But I think those are the exception.

Messy codebase is one thing, but messed up build/configuration system is much worse.

I don't ask to see it, but I've found it effective to ask a simple question: "So, How's your build system?". The engineers at an effective company where everything is in order, will just have this puzzled look on their face and say "it's fine", not really understand just how terrible things could be.

However, for those companies that have huge problems with their stack, the kind of places where builds and configurations break on a regular basis, the kinds of places where you spend half your work hours fighting against configurations and setups, well those interviewers start having steam come out of their ears. After asking this, One interviewer admitted their build system was a hot mess.

I work at a place where the culture is definitely "everybody should tidy this up" and it never changes, or it changes very slowly. What I'm finding though is that there's no real defense against this kind of culture other than to be really tight about hiring. So, to your point, if you came to my company asking to look at source, it'd be a good thing -- particularly since so few people actually do it.

If the responsibility lies with everybody, nobody will do it[1]. There must be some rule or process whereby the job of tidying up something becomes a specific person's job - be it if they are committing changes to the same file, or whatever.

[1]: https://en.wikipedia.org/wiki/Tragedy_of_the_commons

I believe in the code dictator model also. However, the code dictator takes a lot of heat over style opinions. What I see is that, when the dictator emerges, he still has to build coalitions out of people with different skills and different backgrounds. If there's a pool of mediocre or average developers, that is very hard to work around. Only the new people being added can really come pre-loaded with the right code-culture attributes. With non-new people, everyone has to be convinced about the code dictator's approach. This is just not a frictionless process.

not necessarily. if we're all working on a code base and reviewing each others work, and we all value cleanliness, things can reach an ok steady state.

you have to establish a cultural habit of tidying up a little when you're in there. often accompanied by a 'wow thats much better, thanks for doing that'.

more importantly you have to foster a sense of ownership. a common issue with the worst organizations I've worked with is fear and lack of understanding. the code isn't something we're shaping together - its just some large and awful monstrosity that bites you every time you get near it. every time you start pulling at a thread the whole thing unravels.

so you restrict your scope to as narrow a window as possible, and make the smallest changes you can to fix the bug or add the feature.

its the difference between living in a pleasant little village or a squalid favela.

You expressed what I was trying to get at so perfectly and so much better than I ever did.

This is what I'm talking about. Not just "Hey can I see your codebase? Oh, you don't have 100% test coverage and I've seen some variable names that don't make sense, no thanks bye", which I feel is how some people have interpreted my post but I probably could have made that more clear.

In my experience, for most companies and projects, you'd have a hard time earning the trust to have much in-depth review of existing codebases, before getting hired.

Aside from legal reasons, much of this in my opinion is the traditional power dynamic between employer/employee, where the hiring side typically does a lot of due diligence and research into people being hired, and has the upper hand in the negotiation, much more than the other direction.

At least conceptually, I believe developers need to stand on equal ground, to judge and weigh their candidates (employers and clients) in the same way, including, like you say, assessing their code quality before making any commitment, to see if it's up to your standards.

There's always a "discovery phase" before hiring/being hired, where the two sides are exploring what the other has to offer, to determine whether they can be trusted with the work. You can usually poke around enough to discover, for example, what stacks their main product is using, the general level of skills and standards in UX, performance, security, etc.

Some, maybe at increasingly more places, they'd have public or open-source repositories that give a fair insight into the engineering culture. This could be similar to how developers have (or are expected to have) GitHub profiles. I'd take that as a healthy sign of developer-led best practices and transparency in the company.

---

I'd also like to add that the majority of codebases in the wild are bloated, complex spaghetti monoliths of questionable quality. It's just a reflection of limited time, budget, average skill sets, and the real world being practically chaotic. Knowing how to consistently improve the situation is part of being a valuable developer/team.

Yes - I want to see exactly what you're talking about. So far, there were 2 places where I interviewed at (out of roughly 50) that could provide this information.

London based, dealing with Laravel / Vue, fullstack.

If there's no github public code / no code can be provided I ask following things:

- are you following standards (PSR2 for PHP, anything for JS); do you apply linting that makes the standard mandatory

- do you have naming standards

- do you have CI pipeline

- how much of the codebase is unit / feature tested

- how much time within sprint do you spend on fixing existing code

- how much of the job would be working on existing code vs new code

In the end people lie and I picked up a job where some of the things ended diverging from what I was told at the interview

I've done this once ever, I was being asked to build an extremely technically difficult proof of concept so I asked for access and it was granted. I had already worked for the client previously so there was some trust, and they were thinking of open sourcing the project once it was farther along anyway. I wouldn't expect to have it happen again.

I feel like most of these problems can probably be sussed out in other ways. Ask the developers about things that typically lead to a better codebase: do they do code review, testing, QA, etc.

No. In general I’m less worried about bad code (more often than not I’m contracted to fix said bad code) as I am a shit working arrangement.

I can usually convince people why and how to resolve technical debt. Convincing a shitbag to pay a fucking invoice is much harder.