There's two reasons I think. (I have ~25 years experience)

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.

I am one of these engineers, but I consider the "cowboy style" a weakness and bad habit and would never ever judge another engineer over using a debugger.

I am personally not a fan of debuggers but I would never ding someone over using them unless it was obvious they couldn't debug without them.

Strange. Whenever I use a debugger I always get a lot out of it. The code never quite executes exactly the way you envision, even with passing tests. In Java, there is a strange emphasis on classes but I've always felt objects are more fundamental, and the debugger is the way to see them and their interactions.

To add more context. The task included interfacing with a 3rd party API that was poorly documented. In order to even see what a response looked like would have been incredibly hard without a debugger. Dumping it to the console would have been many pages of nested JSON. So sitting there twiddling, trying to make sense of an API doc that didn't provide a clear description of the results rather than just run the thing and see what it did was the wrong way to go.

A debugger is as much "help" to an engineer as a hammer is to a carpenter. In my experience, engineers who don't use one are a detriment to the entire engineering organization wasting time and money.

Anyway, yeah I dodged a bullet on that but it's such a pain in the ass that I went though a two month interview process only to be vetoed at the end like that. During that time I spent about two weeks to learn an esoteric API that I'll never use again. Oh and it would have been highly unlikely that I would have even used that API in the job. It was just a requirement that I learned it for this particular interview. ...and no I'm not going to commit it to memory just so I can pass a coding interview and if that was the expectation then this whole situation is even more ridiculous.

Is this sarcasm or epic hubris? No-one writes bug-free code, and thinking otherwise sounds like an enormous red flag.

Not sure if you're trolling or just missed the "/s" tag.

A much worse mindset is to be arrogant enough to assume the code has no bugs.

As a matter of principle every code has bugs. Some bugs are found, some not.

It’s actually worse than that: using a debugger shows that you’ve written so much buggy code that you somehow learned that debuggers exist.

Steer well clear of these people!

What? Are you implying that you don't write bugs?

Yep, this is the kind of senior tech lead advice I'm willing to shell out 475k total comp for.