'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.
'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.
It's a whole separate skill to be able to code with an audience, let alone an audience who is judging you. I could forgive a non-technical interviewer not knowing this but surely someone who is a dev themselves understands the very real performance anxiety. It's bonkers why we do this to people— the best I've seen is the in person talks about their experience, architecture, problems they've encountered and how they solved them and then either code samples from their public code if they have some or a short take-home assignment if they don't.
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 can't code with somebody looking over my shoulder. I need to relax and think about the task. They expect me to code while being judged by one or more strangers, against the clock, with high stakes involved. If that was the actual job I would not apply for it.
A good analogy I’ve been told is the NFL combine. Vertical jump, straight-line speed, and bench press performances are probably moderately correlated with on-field performance, but the best test of playing the game is playing the game.
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.
It's almost impossible for me to do any serious work or problem solving in an interview situation due to anxiety and stress-my mind simple does not work the same way as it does when relaxed and in flow.
Principal Engineer level shouldn't even be tested on leetcode. There are far more important things to know about that candidate.
I interviewed at Amazon for a principle engineering position - got the interview as my resume has some pretty high profile accomplishments. But they just asked me leetcode questiins all day. I don't practice leetcoding so needless to say I didn't do well. Everyone there looked tired and worn out, probably dodged a bullet.
I was approached for Principal at AWS by the team's hiring manager, and I liked them, and was interested in the team's work. But when they couldn't exempt me from the company-standard initial coding screen, I withdrew my application.
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.
It’s because they’re not interested in engineers, they’re looking for visa workers from cultures that optimize for grinding those types of questions
depends on how much you're willing to suffer for the stock
I don’t get why people act like terms like “Principal Engineer” have an agreed-upon specific meaning that can be used in cross-company discussions. At most places I’ve worked the titles were a duct taped hierarchy born of “we needed to give so-and-so another raise but had run out of non-manager titles, so here’s Senior Software Engineer II”
FWIW, the "principal" part implies a few things no matter which org... they should be able to manage a project from start to finish, mentor juniors, and make confident correct architectural decisions.
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.
Some basic level of leetcoding should be fine to verify that the candidate can at least code and is not only a bullshit artist who jumps from one position to the next, failing upwards.
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.
I don't doubt you in the least: I've also seen BS artists who got through interviews without being able to so much as write a for() loop.
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.
Lots of reasons you can fail an interview, doesn't mean they're a bullshit artist. If we want to be intellectually honest about this process (letting a candidate prove themselves), the least we could do is offer different formats for people to pick from: leetcode live coding, take-home, pair coding, PR review, etc.
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.
if only he had spent 101 days...
Or the interview was about more than just leetcode and they just weren’t that good.