If an obviously junior developer is given an obviously 'fun, interesting' task, they should pair with a developer or have frequent reviews so any problems are caught before pull request stage. You need to catch these sorts of things before you get so late in the stage.
Additionally, you need a structure and culture that is able to hold back pull requests if the code is bad - that's the whole point of code review!
And I'm a guy with 15 years experience, 10 years frontend.
Hence much frustration often.
I mean, anyone senior around here should know that it's precisely making something production ready, as opposed to just 'work in theory', is one of the hardest parts of software: Who hasn't seen some code that mostly works, but is operationally unusable? Something that works with 1 server, but when you put it in 20, it all blows up? It's not about the nice presentation, or the talk where you explain how you turned MongoDB into a queue, but about making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable.
The sad part is, the world is so full of powerpoint architects and projects that don't provide any real value that many people have never seen a system work right. And that's why we see tons of SV companies that are built around tire fires: Nobody in charge of anything has ever seen a system that we shouldn't be embarrassed of.
This is exactly where senior architects make all their money.
The worst is when they say "This is your code man. I'm just helping you out a bit."
No. Finish the fucking feature so I can focus on my fucking feature without having to tripple check all your damn work.