4 ms·

>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 thr

>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."

opportune 6y ago
>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”
- dvt 6y ago
  > 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. [1] https://twitter.com/mxcl/status/608682016205344768?lang=en https://twitter.com/mxcl/status/608682016205344768?lang=en
  - monksy 6y ago
    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.
  - opportune 6y ago
    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).
  - dhanna 6y ago
    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.
- bulatb 6y ago
  > 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.
commandlinefan 6y ago
> 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.

opportune 6y ago

>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”

dvt 6y ago
> 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. [1] https://twitter.com/mxcl/status/608682016205344768?lang=en https://twitter.com/mxcl/status/608682016205344768?lang=en
- monksy 6y ago
  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.
- opportune 6y ago
  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).
- dhanna 6y ago
  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.
bulatb 6y ago
> 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.

commandlinefan 6y ago

> 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.