IME junior code (that violates DRY and SOLID) is usually fairly easy to fix. It's the overengineered code that's an absolute pain.

The worst is code written by a freelancer/temp. Freelancers often come in at a bad time. It's like when you see a tree stump and there's this charred tree ring that says there was a forest fire at one point. We have a piece of code which is Kotlin converted to JavaScript then Java then back to Kotlin. The worst are the ones who use it as a test bed for experimental technology.

So work backwards. How badly are/were things rushed? Who built the code? Were they a bit too enthusiastic about new technologies or are they just happy with what works?

Messy code isn't always a bad thing: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-...

There's some chances to get an idea based on the interview. People who care about code quality will try to ask you questions around the same. If they ask you around how to structure the code for an interview questions in a maintainable question, or how you would write a unit-test for something - that's a plus because it also shows they care.

Pure leetcode like algorithm questions are unfortunately very bad to judge that (in the same way that they are imho bad to judge the knowledge of the interviewed person).

If you are interested about test coverage and practices, looking at the domain of the company might help. Some have to comply with regulations (medical, automatotive, etc) and do more on enforcing to get this right. Obviously code coverage != good code, so the latter might still be on the worse end.

You can also ask in interviews what their test coverage is, and how they feel about unit-tests vs integration-tests. If they have answer things will already be much better than if they have none.

I think 3) works to some extent, and I think there is a small correlation between tech stacks, code quality and code coverage. Most C code that I've seen is very low on test coverage - and I guess that is because a mix of "testing C code is hard" (no nice interfaces/traits, no nice test frameworks) and engineers writing that code having more of a hardware than software background. But despite generally low coverage, there's still a mixture of C code which has better or worse structure. Code in new languages where a lot of users come from a more academic background and are programming geeks (Rust, Scala, F#, etc) seems more likely to have high code quality - but can sometimes also be overengineered. With the more boring managed languages (Java, C#) I usually found things are somewhere in between.

Lastly I want to recommend on simply not expecting too much - things are usually very mixed. More important than the current state of things is also how much you would be empowered to influence and change the status quo. Teams where things might be lacking, but where all contributions to make it better are valued, can still be good.

Ask during the interview what is the worst bits of their code base, and if they'll show you. Having a discussion about what to change and how it might get changed is a great way to assess a candidate and for a candidate to assess an employer.

For hiring managers out there, it could even be something you've already refactored and you can pull up the older version of it.

It can be found to an extent during interviews -

1. How frequently they deploy it to prod? And, how?

2. How they design, develop and test their code.

3. What’s their tech debt? And, how they are addressing it.

Let’s talk about the worst case scenario here - if it’s horribly written code then - can you convince them to rewrite/refactor it? If yes, then it’s a bigger opportunity for you

You can’t.

Companies and candidates both have to come to terms with the fact that it’s impossible to know everything relevant about the other party before the hire is made.

Candidates: in your career, if you stick with it long enough, you will be hired at places with shitty code, shitty bosses, and shitty teams. You make the best of it and move on.

Employers: if you really want to start building it, you will hire people who aren’t in the top 10% of your candidate pool and you’ll even rely on them for business-critical functions. Damage control.

The recent tendency towards obsessive risk-aversion in hiring is not healthy.

i can't imagine the code at any company would really be bad.

i _know_ i've inherited shit codebases before, but it's been so long i canny remember. :-D

i could see certain pieces/modules being shit, but not most of it.

i got it - if the interviewers (who are coders) ask you stupid fucking questions, then they're probably stupid/incompetent/lazy/etc. - so i'd worry about their code quality, and the quality of everyone and everything at the company - products, processes, people, etc.

outside of that, you just have to get in there and convince them to start coding the _right_ way -- that is, _your_ way.

:-D

lastly, i have to question the premise a bit - as cliche as that may be.

take your hypothetical -- you've got three offers -- how far down the list of pluses/minuses is 'code quality'?

  * company brand (resume)
  * pay
  * location/remote/commute
  * industry
  * position
  * vacation
  * manager
  * advancement
  * potential pay/ipo/etc.
  * tech stack
  * etc. 
  * etc.
  * etc.
  * maybe codebase quality is here??

Go somewhere that has no code/is starting a brand new project ;) Otherwise its guaranteed to be spaghetti

I don't think a greenfield project alone isn't sufficient if the op wants to be happy here. E.g. what if others are contribution on the same project, but care less about quality? What if there is a "skip testing, we will just ship the project" policy in place? In those cases the greenfield project can become as bad as any legacy project in a rather short timeframe.

Not true. I inherited the best codebase I’ve ever seen about 3 years ago. I make small improvements here and there, but the thing is a beaut.

I think it’s difficult to know. You might speak to someone working on a micro service that is well written, but then you might get unlucky when you start and be asked to work on some other hideous component that nobody wants to go near.

I've asked companies both during and after interviews for a look at the codebase I'd be working in and they've been happy to show me. Worst case scenario is they say no.

I ask for the best and worst code, specifically. And if they say no ask them to describe the code: why is it good? Why is it bad?

Once they showed me the "best" code and it was a mess. Okay, that's not a show-stopper as there could be perfectly valid reasons for that. Then they showed me the "worst" code and it was actually a bit better, but the guy said "yeah, it's not good; we're missing public/private on a lot of classes".

I had trouble not laughing.

The code itself isn't all that important. It's what they say about it. Bad code? That's okay, I worked with a lot of bad code. But if you don't realize you have bad code and think that is the biggest issue ... yeah....

How much do they care about my code quality during the interview?

One reason I appreciate pair programming interviews is it lets me evaluate their attention to detail. I hear their feedback as I code and I can assess “is this someone that has great cares to their code?” It’s at least a signal someone on the team cares.

I focus more on how much time and autonomy you have to improve it. All software shops have their own unique warts. What really matters is whether they are getting better.

I've seen certain job applications ask you to pair for a few hours/day to judge your competency. How about you ask them if they are willing to pair you for a day?

Yes, this is a serious problem. In my opinion, it is better to use the third option: Asking about tech stack and especially change of tech stack.