> This is a weird take because the whole point of the last decade of leetcode was that people with special skills or that built something great can't even get hired.

No, it looks like you're missing the point. Leetcode is not for people with special skills. It's for people with NO SKILLS other than "can code". Well if the only thing you can do is write code, you better be really good at writing code.

Didn't the guy who made Homebrew fail his interview at Google because he couldn't invert a binary tree? That's a guy who has built a popular product in the wild and can clearly code but failed because of the leetcode barrier at all IC levels.

You sound like you're trying to make a point. Make a point.

I agree. Every hiring process will have false negatives. Pointing out every one doesn’t invalidate the effectiveness of the process

Effective for whom? And at doing what?

SV is full of mediocre engineers; so it fails at guaranteeing you got yourself a star. And I don't think anyone needs more anecdotes to think great candidates lose for arbitrary/subjective/misunderstanding/random reasons

--

I'm 15y into my career with a degree from CMU; I am treated like royalty everywhere I work ... and yet I still absolutely dread, hate and repeatedly have bad experiences interviewing for jobs.

I've considered switching careers numerous times because of the emotional distress I go through just interviewing. And that's before we even talk about the insane amount of time every prospective employer demands of you!

Who's forcing you to stay in SV?

If it's making you so stressed out as you claim, then the obvious step, to me, would be a change of scenery.

> insane amount of time every prospective employer demands of you

I have worked an average of 40-hour/week jobs for my entire 30-year career. What's this "demand" nonsense?

I believe parent is talking about time demands of the interview process, not the job.

ah!

If you can’t invert a binary tree, how can I trust you to change my website’s favicon?!

You would be surprised how hard it would be to invert a binary tree, or really just what the question is asking for, if you didn't at least study up on the concept in the last decade. It is conventional enough to sound mundane, but how often are we inverting binary trees in practice?

It came out that by inverting a binary tree just meant swapping the left and right children of all nodes of the tree. It's pretty much 'can you iterate through a tree?' which comes up a surprising amount.

Sure, but try coming up with that without even remembering what invert meant (it isn't a word that is commonly used in practice outside of CS education and l00tcode). Most of the problem in l00tcode question is just figuring out what is being asked for, not in doing the ask. That's why studying and understanding lots of l00tcode problems as prep is very effective (even if you haven't seen the problem, the problem is probably adjacent and you can understand it more quickly during the interview).

'Invert' is a pretty common word.

Yes, but the common slang it is used for isn't the meaning we are using for l00tcode questions.

There isn't one meaning in leetcode questions; it could mean a bunch of things. That's why you ask questions in an interview.

The common meaning isn’t slang. The (multiple!) math/CS senses of the word are jargon. Which is fine—nothing wrong with jargon—but their existence doesn’t make the ordinary sense slang.

Yes but is it Referring to the additive or multiplicative inverse?

Or maybe it’s making the tree upside down, so all leaves become roots, and the root becomes a leaf. But when we do that, do we just invert all the edges or transform the whole tree?

Maybe it’s referring to changing a red-black tree into a green-white tree? Or turning a splay tree into a merge tree?

It can mean a lot of things, so you ask questions.

Howell (the homebrew 'google didn't hire me because of inverting a binary tree' guy) confirmed that they meant swapping right and left children of all nodes.

you can always ask interviewer - define invert what does it mean - and interviewer in 100% cases will explain and even provide test cases.

in fact any candidate that doesnt ask clarifying questions and goes deep into coding right away - has a chance of going into wrong direction and is flagged as red flag.

As an interviewer I always lookout for candidates that dont ask questions, dont start with test cases, assume in their mind what is their understanding of ideal solution - and start coding. These are very inexperienced people who do that

To be fair, Homebrew is great product design, but actually pretty janky software engineering. Anyone who's had it wreck their PATH a couple of times isn't going to be an automatic yes vote on a technical screen.

Long ago, I switched to MacPorts because its path and directory story is better, and I didn't find myself having to run chown to fix things.

As if average FAANG quality in customer-facing software is better.

If that’s the hang-up on hiring him, they need to get the log out of their own eyes first, because shifting to the quality level of Homebrew would be a big improvement for a whole lot of their software.

Yes, we are aware companies hire privileged losers instead of skilled employees

But inverting a binary tree is trivial. It’s not like finding the shortest path in a graph, or something similar that requires recalling an algorithm on the spot. Go and look at the actual problem if you don’t believe me.

It's amusing the answers so far are mostly all "well this is an easy question and he should have gotten it." I actually agree with that, but even so, he got rejected by Google but did get a job at Apple, which is what this article is about, and that seems like a far more relevant fact to me.

I'm a Machine Learning Engineer with 5+ years of experience at FAANG. I have designed and built real time ML systems that support millions of QPS with < 10 ms latency. I also have a variety of other skills.

And yet I can't escape leetcode interviews. In fact I recently sent a spree of CVs and got automated rejection emails for most of them.

I don't buy your take.

This is privilege if you think 3 CVs is a lot. I applied for 100 yesterday.

I feel like 100/day is swinging the pendulum in the opposite direction. I apply like 3-5/week and I feel like that's a lot. Granted I don't live in a tech hub so my options are limited but 100/day feels like you're just spamming aimlessly and wasting your energy on quantity instead of quality.

OP said spree, not 3

At 100 resumes/day it's hard to believe that you're optimizing them for the position or for that matter, doing anything other than shotgunning.

You're far more likely to get 100 rejections doing this than if you research a handful of the positions and send targeted resumes to those.

I'm pretty sure I have some kind of skill having been in the industry for more than a decade, and jumped to higher paying jobs several times.

Even at the staff/senior staff/principal levels you will still have to face the same LC gauntlet they give to new grads.

The comment you're replying to is saying there's 2 processes, and it matters which one you're in.

System A optimizes for min(p(hire|bad_candidate)). System B optimizes for max(p(hire|good_candidate)).

System A has resume screens, long lead times, and Leetcode out the wazoo. System B has a few convos, short lead times, and review of actual previous work product.

Horror stories come from great candidates in system A. This article is describing how to get into system B.

Well, it describes what it's like to be in system B. All it says about how to get in is to build something (good? great? flashy?) and hope someone notices.

This clearly does work sometimes, but it's not necessarily the best advice for everyone.

Yea fair point, totally agree. Big selection bias.

Still, I think a lot of folks could benefit from thinking through "how do I get into system B?" - because those skills are tremendously helpful in System A, too.

Build good things and develop a good network of people who know what you can do.

A lot of hires, even in companies like this, happen more from conversations that resumes and job postings.

As a hiring lead, there are a small handful of people I know well that I would try to create a job for immediately if they emailed me they wanted to join. As an employee, many job's I've had started something like that.

Yep. Also learn like 5 data structures and 7 algorithms in case the relevant manager can't just unilaterally hire you.

there's an old joke about a company owner who would routinely throw half of every stack of resumes he received straight into the bin, because "who wants unlucky people working here?". i think a large part of why it's funny is because it really does take a considerable amount of luck to get hired at all, and especially through the system B process.

To be honest, building something on your own time is very different, in that, it's much easier.

You start from scratch, you can pick something you're interested in building and maybe also feel you can succeed at. You make up your own requirements, as you see please, so things aren't ambiguous or changing in requirements constantly.

There's no prior legacy constraints, there's no time constraints, it doesn't require finding ways to deliver faster by leveraging other developers.

You get to spend as much time as you need, go watch tutorials, take a hiatus, come back to it when refreshed, fail multiple times and try again, etc.

You can choose the programming language, framework, library ecosystem, that you're more familiar with and comfortable with.

And so on.

So having someone that can show some cool personal projects I've found isn't always a great way to know if they'll be good in a work environment and on a team.

How can you test all of that? through leetcode kinda questions you surely cannot. Maybe behavioral questions are close, but you would do those in both types of hiring processes, no?

Leetcode questions have their own set of issues. Just wanted to say, not sure a portfolio of personal projects is all that better either.

A candidate that has a good portfolio and can pass an algorithm and design interview, and described prior work experience on projects that seemed involved is your best bet of course.

But you can't do any of this and expect to get recognized.

No ones gonna hire you because you spent a decade and have a half finished game engine written Haskell.

All of that freedom is fake and some even in contradiction with each other.

You cannot take your time, or you pick a larger scope project, you will eventually run out of savings, or get questions from family members about why your job search is taking so long.

If you filter out everything but smaller scope projects then you have a far smaller subset of projects that aren't as unique because everyone else has done them. If you just graduated from University, you lack experience with project management and as the saying goes, write what you know, and so that'll limit yourself to video games or web and that one niche subject you took at Uni.

This advice feels like what you would get from a rock-star who was young and stupid and naive and very lucky telling a kid that if he just makes music and sticks it out he'll get scouted by a record label, When in reality he just was lucky enough to market pop-derivative music at gigs, while not realizing the kid likes to make music from sampled traffic noise and his favorite album is Music for Airports.

This is a high risk endeavour and you either need to make conscious decisions that mitigate risk heavily and are compatible with your personality, and the end goal of being financially secure.