1. In your code should know what the edge cases, loop condition issues, etc.
I think this is fair. If you don't know the edge case failures when you write your code, you could end up with something like the Microsoft Xune that shutdown for an entire day over a leap year failure.
https://www.seattletimes.com/business/microsoft/original-mic...
Keep in mind that code review will probably not catch all bugs, it's up to the original coder to write it. This is particularly true if you're the best person on your team, say. Or you're working at a startup where no one can really review your code other than you.
On the other hand well coded unit tests should help you here.
2. It's toxic brogrammer culture there -- where leetcode scores are all that matter. In which case it's probably best you were passed over.
Perhaps, but:
> It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.
* https://quoteinvestigator.com/2018/11/18/know-trouble/
Sometimes you want to go to 'first principles' and reassess your assumptions. As a sysadmin I sometimes I resort to making sure the thing is actually physically plugged in (OSI Layer 1), the move up the stack with regards to how the bits flow.