What I consider a good backend
A correct backend is boring: it does what it says, fails predictably, and can be changed without fear six months later. It is not the one using the newest architecture, it is the one the next person can understand.
In practice that means separated layers, explicit dependencies, errors that carry enough context to diagnose, and logging where things can go wrong.
It also means not adding complexity before it is needed. An application serving thirty internal users does not need microservices; it needs to be well written.