Here’s a counterpoint: I don’t want to be forced to do OSS as part of my resume. I already write software over 40 hours a week for my job. And I won’t do a take home that takes longer than a regular interview unless the place has really good pay (I’ve never heard of a take home place paying top of industry).
Meanwhile I’m very good at competitive programming, I actually find it enjoyable because of the challenge, and I don’t need to practice it much even when interviewing.
Also to be perfectly blunt I think this just ties into people generally being uncomfortable with tests. All the examples you gave have the benefit of allowing unlimited time. What’s wrong with a test that challenges your knowledge of data structures and algorithms? I actually find that in general the very smart people I know are good at them and most of the people who “don’t test well” aren’t. And even then they can just practice them. They might even learn something. Sorry if that sounds mean, I don’t mean it to be, just blunt.
>What’s wrong with a test that challenges your knowledge of data structures and algorithms?
It's not a good signal for who will provide good business value through software engineering.
>I actually find that in general the very smart people I know are good at them and most of the people who “don’t test well” aren’t.
Is "smart" just directly 1:1 with "provides good business value" for you? I'm not so sure it's that simple...
>And even then they can just practice them. They might even learn something. Sorry if that sounds mean, I don’t mean it to be, just blunt.
It "sounds mean" because you are being selfish about your personal situation and then saying "it's not really that bad, come on," to people in different situations. It has nothing to do with you being "blunt."
>It's not a good signal for who will provide good business value through software engineering
Entirely depends on the org. I’ve done DS+A work professionally. I do think it tests fundamental understanding of programming considering DS+A underlies everything we do. If you’re hiring generalist software engineers (or general knowledge is a requirement) and not specialists in specific stacks it makes complete sense to me. I also think it’s harder to fake/game than almost any other programming related test.
>”smart”
Necessary but not sufficient. You can drive business value without knowing software engineering at all. Driving business value through software engineering requires being a good problem solver
Seeing someone unable to do a slight modification of breadth first search given 30-60m to sketch it out does, in my opinion, give me a general sense of their software engineering ability. I am bluntly saying I think it’s an accurate way to assess skill regardless of all the hacker news complaints of “why can’t I get a $300k/year job without knowing what a trie is”
> why can’t I get a $300k/year job without knowing what a trie is
You're grossly misrepresenting my complaint.
I've made contributions to several high-profile OSS projects (including some small HTTP core contributions to Golang), have published one book as a co-author (another as an editor; both with Apress), have several projects with 100+ stars on GitHub, and am in the top .9% of Stack Overflow contributors. This is in addition to having a few interviews out there given to legitimate outlets, like Vice and PCGamer, about past startups (all of which have involved hardware or software).
My pedigree is verifiable. And yet, if I want to switch jobs (which I will inevitably have to do), I will be subject to being asked about some algorithmic questions that I am willing to guarantee I couldn't answer without studying. For example, I genuinely don't remember how red-black tree or splay tree balancing works. But I'm small fries compared to people like Max Howell[1] (who wrote and manages brew) and yet couldn't get a job at Google because of some algorithmic question he flunked.
Fighting for better interviewing practices in software engineering is one of the few hills I'm willing to die on.
I agree that knowing the details of a red-black tree rebalancing is not fair game. I wouldn't bother implementing one unless I had access to a paper written by an expert like Sedgwick. Which leads into my gripe with programming interviews.
My biggest problem with this culture of interviewing is that most people don't seem to know/appreciate the complexity of the questions they are asking. There's been a number of times where my interviewer completely lacks any knowledge on the background theory/history on the question they asked me.
Afterwards I tend to find the question in Knuth or an Algo book.
That being said, I do think knowing that red-black trees, like AVL trees, fundamentally rely on Tree Rotations to maintain invariants about the tree which ensures its height balance IS fair game, IF you require formal algo knowledge from your candidates. With that knowledge, theoretically a well-read interviewer can guide someone to towards a partial implementation.
And from that knowledge, if someone would to introduce the concept of a splay tree, I could guess that since its a self-balancing binary search tree, it likely relies on tree rotations as well. You would need to bounce that off the interviewer obviously.
But if you're not familiar with the concept of tree rotations, and/or data structure invariants, you probably won't succeed no matter how much coaching your interviewer provides, due to pressure on your working memory.
The fact that you couldn't remember red/black trees or splay tree balencing works is a GOOD sign in a software engineer. It means that you're not going to try to re-engineer existing solutions.
I would be very surprised if you were asked about red-black trees or splay balancing at the two large tech companies I’ve worked for. That would be considered too niche/specific to be a good interview question unless you were applying for a position which needed that particular knowledge.
On the other hand asking to “invert” a binary tree is totally fair game. I attribute Max’s frustration partially to his interviewer not adequately explaining what “invert” means in that context though that would also partially give the answer since it’s IMO a very easy problem (though not a good one since it’s confusing).
> to be perfectly blunt [...] the very smart people I know are good at them
> and most of the people who “don’t test well” aren’t
It's frustrating to read this same response in every interviewing thread. If I may be equally blunt: it almost always comes from someone showing a distorted understanding of the process, or implying human beings are fleshy robots which are easily deterministically QA'd by automated tests.
For weeding out the worst performers, testing works for lots of people and it works at scale. That's why it's used. That doesn't mean there aren't false negatives, or even that there aren't a lot; it just delivers good enough results for cheap enough that other local maxima aren't worth exploring.
But the industry wants it both ways. They want to cry about a talent shortage where apparently there's no one in the output of this local maximum of process they've chosen, and also claim this choice of process is fine and maybe people should git gud or maybe they're dumb, and also actively refuse to reexamine their decision in spite of its obvious failure.
The very fact of their complaint is evidence the process isn't good enough. Unless they're simply lying, its results are costing them in growth or time-to-market or actual money. If they really feel this pain, they should be finding other options—but they just don't want to.
Where else would this behavior fly?
> ...do a slight modification of breadth first search given 30-60m to sketch it out...
> ...“why can’t I get a $300k/year job without knowing what a trie is”...
I've interviewed at FAANG and elsewhere, pass and fail, and this is simply not what happens. People who defend the process often try to frame it like this and it's just... at best, indifference to the truth. In my experience—and many others', and of everyone who gets on LeetCode with a sigh because they know this—you better not be tinkering with BFS at all. Your session might be scheduled for an hour, maybe closer to 45 minutes, and the interviewer will expect you to correctly solve at least two questions, probably three, and still have time for "any questions for me?" at the end.
Counting introductions and small talk, and allowing you 10 minutes at the end to get one question in about the company, that leaves you (optimistically) with 15 minutes per question—including them explaining it, your clarifying questions, writing code on the board, erasing mistakes, drawing awkward arrows where you oops-forgot a line, and all the rest.
Need a hint? Cool, sure, I guess. Another? Uhh. (You're dumb.)
You don't in any sense have even 30 minutes for your BFS if you expect to pass, and your sketches won't count. That easy trie thing or search-with-a-twist, in actual practice if not in design, is meant for you to solve as fast as you can write it on the board. Otherwise you won't have time for questions 2 and 3, the ones they're really counting. Get ready for a crapshoot of well-chosen problems, pointless memorize-the-answer gotchas, and random applications of DP or topics from computer science papers they "would never ask because that's silly" but really just did.
If you're ok with that, I understand. But please don't say it isn't this because you like it.
> Is "smart" just directly 1:1 with "provides good business value" for you?
Not necessarily... but I've seen a concerted effort in the past few decades to separate business value generation from software development anyway: the sort of people who are good at business value do business value stuff and they work with the software developers to get the computers to participate in it.
> Meanwhile I’m very good at competitive programming
Not to burst your bubble, but you aren't. You are very good when you get it right. You aren't when you don't get it right. But then you are leaving out that part because nobody likes to focus on the negatives. Consider this - at some point of your life, you didn't know competitive programming. Were you 100% un-hireable at that point ? Most likely, you would have done perfectly fine if you were hired without all this ceremony. That's what people are frustrated with.
People dismiss college credentials as elitist gatekeeping, When you create entire artificial domains out of whole cloth, like "competitive programming", that's gatekeeping on steroids. Because that whole domain is artificial, I can stuff anything into it. The surface area of that domain is practically infinite. Forsure there's some patch where you'd under-perform. And I reckon the area of that patch is quite large. You just haven't found it yet.
> Not to burst your bubble, but you aren't. You are very good when you get it right. You aren't when you don't get it right. But then you are leaving out that part because nobody likes to focus on the negatives
I'm sorry, what? "No one is right 100% of the time so there's no such thing as being good at anything"?
> People dismiss college credentials as elitist gatekeeping, When you create entire artificial domains out of whole cloth, like "competitive programming", that's gatekeeping on steroids.
No it isn't. Anyone can pick up a book or go to leetcode and learn to solve interview problems. I know multiple people who did it in their early teens.
Counter to your counterpoint. I don't do competitive programming. I already write software 40 hours a week for my job. I don't want to spend months learning how to hack interviews when I know I can do a good job and I have done so in the past based on my resume and references.
Yeah but there's got to be some give in the name of getting signal. Resumes are incredibly noisy signal. I think references are pretty noisy too... a bad reference is very bad, a better than average reference is really good, but I think the average reference, which most people give, is very low signal.
> Also to be perfectly blunt I think this just ties into people generally being uncomfortable with tests. All the examples you gave have the benefit of allowing unlimited time. What’s wrong with a test that challenges your knowledge of data structures and algorithms? I actually find that in general the very smart people I know are good at them and most of the people who “don’t test well” aren’t. And even then they can just practice them. They might even learn something. Sorry if that sounds mean, I don’t mean it to be, just blunt.
Not everyone sees these trivia games as a valuable use of our time. Some people have hobbies, some people have side projects that are of use.
The leetecode problems don't test you for experience. They just demonstrate your ability to minimally code up a trivia problem. They don't show good coding practices, doc, or testing.
The thing is, CP is not everyone's cup of tea, and also it is a separate discipline/subject with its own trivia knowledge & tricks. CP uses Computer Science same way as e.g. Physics or Biology use Math.
Meanwhile I’m very good at competitive programming, I actually find it enjoyable because of the challenge, and I don’t need to practice it much even when interviewing.
Also to be perfectly blunt I think this just ties into people generally being uncomfortable with tests. All the examples you gave have the benefit of allowing unlimited time. What’s wrong with a test that challenges your knowledge of data structures and algorithms? I actually find that in general the very smart people I know are good at them and most of the people who “don’t test well” aren’t. And even then they can just practice them. They might even learn something. Sorry if that sounds mean, I don’t mean it to be, just blunt.