Maybe instead you could probe at interview time whether they are happy with their microservices, how many do they have, do they feel happy that the service boundaries they finished up with are the best possible etc.

Not all microservice setups are shit shows.

Plenty of monoliths are.

There is no way anyone tells you in interview that the codebase is crappy or that they are unhappy with.

You’ll always be told « well, like everywhere, we have legacy, but we learnt for it and now every new project is in [put REST + shiny front tech here] and we are happy with it. We migrate step by step ».

And then you’ll realize that the codebase they called legacy is what makes the company’s money, it’s not that bad compared to new project and is a pain to maintain because nobody works on it anymore except for urgent bug solving.

So, they’ll probably tell you that « they are happy with their microservices » (or quite happy) because they already try to fool themselves about it.

Yeah they are. One service per team, the thing that Amazon was originally doing that was the inspiration for all this, works, but you wouldn't call that "microservices" these days; the thing that people call "microservices" is always a shit show.

I needed a place to store marketing and PR templates that were completely unrelated to the core of our product.

Of course the rule was "one service per team", so the CTO demanded that I store it together with our service, which is the part that performs customer authentication. Meaning, the part that is responsible for securing customer data and everything else. Whenever we had auditors checking it they're puzzled as to why there's marketing material storage inside the auth microservice.

This could have been the poster-child example of a good place do have a separate service, but no, the law was the law.

It's almost as if there's no such thing as a silver bullet.

I've found it incredibly hard or impossible to gauge the quality of a codebase during interviews. (Beyond immediate red flags like "oh, we don't write any tests or do code reviews" or whatever.) And to be honest, most codebases are bad, it's just a matter of degree. And I would almost always prefer working in a bad monolith than bad microservices.

Oh yeah. But I've seen this also happening in frontend libraries, and sometimes even inside monoliths.

I find that inexperienced developers tend to break up services/libraries/classes purely because they believe that "code should be neatly organized", not because there is a logical boundary between two parts of a system. Thus, we get lots of tight coupling, chatty microservices, and 20 lines of imports at the top of the file.

I find that A Philosophy of Software Design by John Ousterhout [1] has a good rule of thumb: classes (and services, libraries, repos, applications) should be "deep, not shallow". The "surface" (aka the part that touches external components) should be as small as possible, while the internals should be larger. Of course that doesn't sit well with people looking to "neatly organise code".

[1] https://www.goodreads.com/book/show/39996759-a-philosophy-of...

Splitting code as a way to visually organize code can lead to tight coupling, which tends to be worse than large classes.

If you split a class but there’s still multiple “points of contact” between both, it wasn’t a good split at all.

That sounds unwise. I only ever split because the class is getting too large, or because some functionality is better off being moved to its own class. And those other classes also should preferably only have one or two methods exposed to the outside, there's nothing worse than a large surface area unless it's a library class.

> there's nothing worse than a large surface area unless it's a library class

Yep, exactly. Even big classes are better than tightly-coupled classes with large surface area.