We normally do minor fizz buzz code screens internally. But that's just a small test to see how much of the tech you know, like if you were switching from say Python Lambdas to Angular front-end. And it's mostly to see about how you approach the problem.
But some of the internal postions do it differently. My favorite was a mock code review on a PR that had intentional flaws. Then you'd call put what was wrong and how to fix it - not just pure code but also requirements, tests, commit messages, etc.
LeetCode is different though. The rating and stuff. Even the interface... I still don't know what it's doing behind the scenes to run the code and feed inputs and what those inputs are. Believe it or not, this LeetCode interview wasn't my worst internal code screen. I once had one that HR said to bring my laptop and use any language I wanted. When I got there, the manager handed me a Mac (which I've never used), told me to use Angular to create a page with a table (hadn't used Angular at that point), and told me to do it in Webstorm (most teams were still using Eclipse at that time, so no experience here either). I managed to Google my way to a working table, but cut the interview short when he wanted me to style it. It's and internal posting. I clearly know the basics and got something working, even in the worst possible interview scenario where I didn't know the tools at all. Surely I can learn the rest (this was a midlevel posting, not even senior).
I'd interpret that as they wanted actual usable work from the interview,
I've had a few of those "technical tests" that boiled down to "if we get enough applicants to add to this code we won't need to hire any of them"
You can be assured that the person who actually got the job worked on a Mac in Angular using Webstorm and that nobody wants to entertain ideas that their methods of interviewing are in any way tipping the scales.
On the opposite side, I usually skip teams for their repo so I can review them. Are there test cases built out? Do they have east to follow code design, or descriptive comments? Do they have a normal level of abstraction, or are there multiple layers of interfaces for not real reason? I recently declined a position because the team was building a UI, didn't have a CMS, didn't have any real rests, and the code looked like a bit of a mess. It didn't help that the languages (Go, React) were completely new to me, so I wouldn't be able to make an impact on improving these issues.
