4 ms·

Tech hiring practices is also a fantastic example. There was a time when companies like Google were looking for very talented CS people because they actually n

Tech hiring practices is also a fantastic example. There was a time when companies like Google were looking for very talented CS people because they actually needed people with broad skills because in the case of G they were building a search engine and there's almost no area of computer science that isn't involved in such a project. They actually needed people with strong CS skills. Twenty years later we have positions where hires are selected for their ability to reverse a red-black tree on a whiteboard, where the position will mostly be about gluing together CRUD apps with YAML.

shaan7 3y ago
On a lighter note, people who can write YAML are very skilled, in my eyes. I'm yet to encounter a situation where I edited YAML and it worked on the first go -_-
- marginalia_nu 3y ago
  Sure it's a skill, but it's a different skill. It's like hiring a chef on their ability to sharpen a cooking knife.
josephg 3y ago
> Twenty years later we have positions where hires are selected for their ability to reverse a red-black tree on a whiteboard, where the position will mostly be about gluing together CRUD apps with YAML. A few years ago I worked as an interviewer for a large software engineering recruiting company. We did quantitative scoring on a lot of parts of our standardized interview. We had sections in our interview on CS knowledge, programming, debugging and whiteboard style problems. Based on the data, we asked: Could we eliminate any part of the assessment? Could we throw out the CS knowledge part without losing accuracy about the overall hireability of the candidate? Based on the data, the answer was no. The scores were all positively correlated - so CS knowledge implied you were better at programming and vice versa. But we still got extra signal by assessing candidates on their CS knowledge. Turns out even if you aren't amazing at programming, having excellent CS knowledge will still make you desirable to a lot of companies. (The weakness of this study is we didn't follow up with people. We only knew if our candidates got hired, not how well they did after they were in the door, as employees. So we might have just been mirroring the same biases the companies themselves have in their hiring processes.)
- marginalia_nu 3y ago
  > (The weakness of this study is we didn't follow up with people. We only knew if our candidates got hired, not how well they did after they were in the door, as employees. So we might have just been mirroring the same biases the companies themselves have in their hiring processes.) This is some weakness. Surely this is the outcome that's interesting. I also suspect there's likely a correlation between how hard someone is trying to get hired and the freshness of their CS skills. Chances are a motivated candidate will have been brushing up on CS because it's such a trope to be grilled on those types of questions; that same candidate likely prepared for other interview questions as well and I would indeed expect that to increase the odds of getting hired. Since nobody walks around with perfect recall of the types of algorithms that crop up in the classic tech interview, it's fairly safe to assume the CS part of the interview is a direct measure of how much preparation the interviewee has done.
  - josephg 3y ago
    > Since nobody walks around with perfect recall of the types of algorithms that crop up in the classic tech interview, it's fairly safe to assume ... I'd love to have data on that. I know its really common for engineers to never touch this stuff in their day to day work. Most product teams don't need any of this knowledge at all. So asking about it in an interview is a massive waste of time. But personally, I've used a lot of these algorithms while working on collaborative editing for the last few years. For diamond-types, I ended up writing my own b-tree and skip list implementations, and I make heavy use of binary search, BFS, DFS and priority queues. I've used priority queues in plenty of projects - like, years ago I made a library to mock out timers in nodejs for our test suite so we didn't have to wait for real timeouts to trigger in our test suite. But I've got no idea what percentage of working engineers use any of this. 5%? 1%? 0.01%? On the surface, it seems nowhere near useful enough to justify how often these questions show up in interviews.
    - marginalia_nu 3y ago
      Well part of the reason I'm skeptical of how who would actually be able to pass these interviews without cramming for them based on the fact that I too have used a fair number of the algorithms (because as mentioned, internet search is a fractal of challenging CS problems) and would almost definitely not pass such an interview. Just because I've implemented a binary search a few times, and a b-tree, and a skip list, and various sorting and intersection algorithms doesn't mean I can reconstruct them on a whiteboard from memory. What it amounts to is that I have an upper quartile understanding of the underlying idea and the general quirks (among practicing programmers), but not much more than that.
bonoboTP 3y ago
Those "reverse this linked list" interviews are essentially disgused IQ tests, which wouldn't otherwise be allowed in the US, not without a lot of legal risk at least. Their point isn't to test a specific practical skill.

shaan7 3y ago

On a lighter note, people who can write YAML are very skilled, in my eyes. I'm yet to encounter a situation where I edited YAML and it worked on the first go -_-

marginalia_nu 3y ago
Sure it's a skill, but it's a different skill. It's like hiring a chef on their ability to sharpen a cooking knife.

josephg 3y ago

> Twenty years later we have positions where hires are selected for their ability to reverse a red-black tree on a whiteboard, where the position will mostly be about gluing together CRUD apps with YAML. A few years ago I worked as an interviewer for a large software engineering recruiting company. We did quantitative scoring on a lot of parts of our standardized interview. We had sections in our interview on CS knowledge, programming, debugging and whiteboard style problems. Based on the data, we asked: Could we eliminate any part of the assessment? Could we throw out the CS knowledge part without losing accuracy about the overall hireability of the candidate? Based on the data, the answer was no. The scores were all positively correlated - so CS knowledge implied you were better at programming and vice versa. But we still got extra signal by assessing candidates on their CS knowledge. Turns out even if you aren't amazing at programming, having excellent CS knowledge will still make you desirable to a lot of companies. (The weakness of this study is we didn't follow up with people. We only knew if our candidates got hired, not how well they did after they were in the door, as employees. So we might have just been mirroring the same biases the companies themselves have in their hiring processes.)

marginalia_nu 3y ago
> (The weakness of this study is we didn't follow up with people. We only knew if our candidates got hired, not how well they did after they were in the door, as employees. So we might have just been mirroring the same biases the companies themselves have in their hiring processes.) This is some weakness. Surely this is the outcome that's interesting. I also suspect there's likely a correlation between how hard someone is trying to get hired and the freshness of their CS skills. Chances are a motivated candidate will have been brushing up on CS because it's such a trope to be grilled on those types of questions; that same candidate likely prepared for other interview questions as well and I would indeed expect that to increase the odds of getting hired. Since nobody walks around with perfect recall of the types of algorithms that crop up in the classic tech interview, it's fairly safe to assume the CS part of the interview is a direct measure of how much preparation the interviewee has done.
- josephg 3y ago
  > Since nobody walks around with perfect recall of the types of algorithms that crop up in the classic tech interview, it's fairly safe to assume ... I'd love to have data on that. I know its really common for engineers to never touch this stuff in their day to day work. Most product teams don't need any of this knowledge at all. So asking about it in an interview is a massive waste of time. But personally, I've used a lot of these algorithms while working on collaborative editing for the last few years. For diamond-types, I ended up writing my own b-tree and skip list implementations, and I make heavy use of binary search, BFS, DFS and priority queues. I've used priority queues in plenty of projects - like, years ago I made a library to mock out timers in nodejs for our test suite so we didn't have to wait for real timeouts to trigger in our test suite. But I've got no idea what percentage of working engineers use any of this. 5%? 1%? 0.01%? On the surface, it seems nowhere near useful enough to justify how often these questions show up in interviews.
  - marginalia_nu 3y ago
    Well part of the reason I'm skeptical of how who would actually be able to pass these interviews without cramming for them based on the fact that I too have used a fair number of the algorithms (because as mentioned, internet search is a fractal of challenging CS problems) and would almost definitely not pass such an interview. Just because I've implemented a binary search a few times, and a b-tree, and a skip list, and various sorting and intersection algorithms doesn't mean I can reconstruct them on a whiteboard from memory. What it amounts to is that I have an upper quartile understanding of the underlying idea and the general quirks (among practicing programmers), but not much more than that.

bonoboTP 3y ago

Those "reverse this linked list" interviews are essentially disgused IQ tests, which wouldn't otherwise be allowed in the US, not without a lot of legal risk at least. Their point isn't to test a specific practical skill.