By now there is more than one story how some open source developer wasn't hired because their skills with the project they created was not sufficient for the job.
The "invert a binary tree" thing is a reference to a tweet by Max Howell [1] where he complains that he didn't get hired by Google even though he wrote Homebrew, which he estimates 90% of their engineers use.
Howell describes himself as a "dick" [2], hadn't been involved with the Homebrew project for years, and has since gone on to write the NFT-based package manager Tea [3] and pkgx [4], which is an "everything app"-style CLI tool with lots of fever-dream AI art and RCE as a feature.
It's possible that Google just didn't hire him because he wasn't a good candidate.
This wasn't the only story like that. I at least remember similar stories about some kind of database / library maintainer and yet another javascript framework.
Dont have enough time to find them now, but it's kind a obvious people would like to apply to places that already use their open source code. I would at least try, but no one use open source game-clone engines so no way on earth anyone will use what I worked on.
Conversely, a story from the opposite end of the extreme: Fresh out of college I got an interview at a company that made games. It was exactly what I wanted to do and I made it miraculously far given the fact that I had zero real world experience. I made it to round three but ultimately got rejected. Who did they hire instead? A friend who works at the company later told me that it was down to two candidates. It was me vs the guy who wrote the game engine they make all their games in.
I do think shipping a product that has real users (and everything it entails, like writing the docs) is 100x more important than having leetcode and common interview tactics fresh on your mind.
Without context, I suppose I can see the Homebrew guy's case possibly signaling a sort of hubris since it was just a fizzbuzzy-level question.
In his defense, I would find it ridiculous if we just had a technical convo about how I built Homebrew and then they gave me leetcode question.
At least an easy leetcode question is insulting in a bearable way, like inverting a binary tree. But a medium+ question risks me not even being able to solve like, like having to use dynamic programming. And that's just humiliating.
Never mind that a lot of the jobs that ask you to do this will mostly involve the conversion of database data to JSON or HTML with a few steps of business logic in between.
And the harder computational challenges you’d likely learn as you need it. In which case, simply knowing what a binary tree is means you’ll know it’s available to you, even if you can’t invert one from the top of your head.
And even then, start going for staff or principal and your leadership, communication and architecture skills should be more of a focus than algorithmic puzzle solving.
When you gain experience and responsibility as a software developer and take on broader roles, the main values you've accumulated are higher level skills, like the ability to bring a project to completion (and everything that entails).
There's always a place for algorithmic hacking. But it feels like the easiest thing to hire for when you need it because it's so concrete. That's prob why it's so dominant in hiring practices: it's the only easy thing to measure.
> I do think shipping a product that has real users (and everything it entails, like writing the docs) is 100x more important than having leetcode and common interview tactics fresh on your mind.
It depends on the job! At a small product company, absolutely. Shipping useful features to customers is what you're hired to do. Hardcore CS knowledge is less useful than understanding how to talk to customers and shipping. Interviews should reflect that.
But that isn't all jobs, or all software. For a lot of problems - particularly in systems software or places where performance matters, understanding data structures and algorithms is essential. For example, video game engines, operating systems, databases, LLM inference and training, etc.
I get it - most product engineers don't make use of "leetcode" skills. But absolutely relevant at a place like google. If you don't understand how to reverse a binary tree, I wouldn't hire you to work on Google Chrome or the Go compiler either.
> But a medium+ question risks me not even being able to solve like, like having to use dynamic programming. And that's just humiliating.
What an incredibly entitled thing to say. "Those horrible interviewers asked me to solve a problem that was too hard for me! How humiliating! I failed the interview and its all their fault!"
It would be interesting to get a perspective of how many developers are in these types of roles if you are closer to them than most? My experience definitely aligns with interviews with leet code questions being unrelated to the daily work. From this perspective, it seems that those dealing with these core projects like Go or Chrome have an outweighed impact on others. Eg, it only takes a few people solving those problems to help everyone. Where as from my perspective, loads of businesses need web apps, fairly simple backends, mobile apps etc for their very specific use case where they want to control the whole user experience.
The frustration of being asked a very specific question looking for a very specific solution under unusual time and pressure constraints I think is quite understandable. Not coming from a place of entitlement, but rather frustration that they know with high certainty that they could do well in the position, the question has nothing to do with daily work expected of them, yet its become this arbitrary pass/fail process due to people copying companies that are screening for positions working on Go or Chrome, when they just want a web app. I've been in several interviews, including on the employer side, where another technical interviewer asks these questions as a power trip. It's not helpful, and doesn't even get better candidates. Hence the frustration people are expressing.
> I've been in several interviews, including on the employer side, where another technical interviewer asks these questions as a power trip. It's not helpful, and doesn't even get better candidates. Hence the frustration people are expressing.
Oh I get it. Again, if those skills aren't relevant for the job, stop asking them. At best you're wasting everyone's time. And at worst, you're going to make bad hiring decisions. In one chapter of Thinking Fast And Slow he says people have a habit of taking a hard question - like "Is this person a good candidate?" Instead of answering the question, we subconsciously replace it with an easier question - "Did the person find the solution to my puzzle?". Then, when you've answered the easy question you think you've answered the hard question! But you haven't - they're different questions. Puzzle interviews are a clear example of this cognitive trap.
Generally, nobody is born knowing how to give a good technical interview. But most people are thrown in the deep end anyway, with no training or no guidance on how to do a good job of it. So, as you say, they just cargo cult bad questions that they themselves were asked or go on little power trips. Very stupid and frustrating!
Which is all to say, I hear you and I agree that this is a problem. There's a lot of bad interviewers out there doing lazy interviews.
But.
I also think there are a lot of jobs where deep computer science knowledge is relevant and important. If you don't have those skills, you will (obviously) spend your whole career kept away from those jobs. So you wouldn't even know about them! But they're absolutely out there. React. Chrome. Linux. Sqlite. ChatGPT. NodeJS. HTTP2. LLVM. All of this stuff is made by other engineers. Usually, by engineers who know how to reverse a binary tree. CS questions might be overused in product engineering interviews. But CS skills are still relevant in a lot of very important jobs. Just, maybe, jobs that a lot of people might not be qualified for.
If it's a failure to demonstrate a basic skill that are relevant to the job, then yes, that's entitled. However what was described is much closer to irrelevant trivia. I don't think it's entitled to resent such things being the deciding factor.
> We do not USE the thing we're building by and large.
Yes, thankyou, that's quite obvious judging by the quality of most software.
It really is amazing how bad most software made for non-developers is. Like, as software engineers, we understand how essential version control is. We made git and github for ourselves. But nobody has bothered building that functionality for people who edit word documents all day. Or people who edit video, or animators, or 3d modellers, or 100 different jobs. Word and google docs have track changes. But they don't let you bounce between branches or make pull requests. You usually can't time travel, or bisect, or git blame, or any of the other things we take for granted. My partner works in a CMS all day at work. Every change she makes is pushed directly to production. There's no review process. No staging. No testing. No change control or rollback. If anyone messes something up, they get blamed for "taking down the app". As a software engineer, I look on in horror.
I believe the more cognitive distance there is between 20-something silicon valley tech bros and your particular use case, the worse your software is going to be. If you're a manchild living in san francisco who can't be bothered driving, doing your laundry or shopping for groceries, you're in good hands. There is a startup that will solve your problem! But the further from that "ideal" you get, the worse. Here in Melbourne, I can't use my iphone to pay for public transit. Google maps couldn't really handle roundabouts (traffic circles) for a decade and change. (I guess they don't have those in California). Unicode support was only added recently because of Emoji. Until then, a huge amount of software butchered non-english text. I shudder to think how badly most software probably handles right to left languages. And the list goes on and on.
> My partner works in a CMS all day at work. Every change she makes is pushed directly to production. There's no review process. No staging. No testing. No change control or rollback. If anyone messes something up, they get blamed for "taking down the app". As a software engineer, I look on in horror.
Fwiw that just sounds like an immature CMS - I've seen review/approval workflows, branches, preview environments etc in more than one CMS. I take your overall point but maybe your partner doesn't have to live this way.
> I take your overall point but maybe your partner doesn't have to live this way.
I agree - but if a review system exists in the product, she's never seen it. They don't even have a staging system for testing changes. Its wild.
And for context, she works at a large organisation that's a household name here in Australia. This is a large organisation thats been around for well over 50 years. They have an engineering team and thousands of employees.
I don't know if the software is bad or if its misconfigured. But the status quo outside of our industry is jaw-droppingly terrible.
Yeah absolutely. I worked at a startup awhile ago with a really incredible designer. She insisted that everyone in the company sit in on one or two user interview sessions she had organised with our potential users. It was an incredibly eye-opening experience, and I can't recommend it highly enough.
I highly recommended doing the same if you can swing it. Its equal parts insightful and motivating. And the clients generally love it - since it shows your team really cares about their problems and use case.
Well my comment wasn’t really on usability or UX per se, just noting that the narrative of needing race car drivers is inaccurate. You don’t need to reverse B-trees to program normal software.
Also usability concerns have nothing to do with reversing B-trees.
