'Principal' developer at my last place spent 100 consecutive days grinding leetcode. Shortly after had an interview where they made him do a leetcode test live and he failed it.
The whole thing is broken.
The whole thing is broken.
They could cheat on the take-home but it isn't meant to be difficult and you hopefully figured out at the in-person that they're someone who wouldn't need to bother cheating.
I more understand the emphasis on leetcode problems for juniors but a timed session without an observer (perhaps with browser tracking) to solve those problems makes a lot more sense than bringing in the anxiety of the observer, as you’ve noted. It sucks having to spend mental energy wondering how your problem-solving looks to whoever’s watching and seems actively detrimental to assessing talent for an IC role.
I'm sure the manager was great, but we've all heard of some less-desirable aspects of working at Amazon, and I wouldn't want to go there without a sign that I'd be shielded a bit.
So, I've made the "corporate drone coding screen", and Leetcode interviews in general, my own metric. If a company does it, they fail the interview.
And if I'm having a moment of weakness, and considering submitting to some techbro frat hazing, I remind myself that, if I was willing to do that, I would've gone to Google already, which usually would've preferable to whatever opportunity this other company is dangling.
I had some interviews, not at the principal level, we had a couple of candidates who were very good during the informal interviews, they could hold a conversation about technology, but they couldn’t code the simplest of problems. I know folks don’t like it, but this could happen in my humble opinion at all levels.
What is key is letting the candidate decide the format they're best at.
Leetcode's signal is pretty bad compared to pair coding/PR reviews IMHO. And if the job genuinely involves writing algorithms, you can put algorithms in the code and have them go over that.
Take home is probably the most vulnerable to cheating, but if you have them code review it afterwards, it's detectable fairly easily.
But I've never seen anyone fail upwards as far as a Principal/Staff Engineer level. Last time I interviewed at that position, no one even asked anything about code. They were more concerned about my position on architectural choices, pros and cons of various approaches, knowledge of applicable standards and regulations (I'm in the medical device field), mentoring and team leadership issues and how to resolve them, etc.
If you've ever hired a plumber or electrician, you might have gotten a crew of younger apprentices, maybe a journeyman, and an older "master" plumber or electrician. Most of the master's time is spent with the critical mechanical tasks, solving problems that occur, and directing those other tradesmen. The principal is the 1 person who can do _any_ of the other's job if they are unavailable. They are also the 1 person (and ideally the only 1 person) who makes "the plan" for how the work will proceed, and also decides when a project is complete.
The crucial difference (well, one of many?) between a principal-level engineer, and any type of management...is that the principal-level engineer should be able to do every junior engineer's job in a pinch - expertly, and with confidence and adapability to problems.