8 ms·

I'd much rather my engineers have spent their time practicing their actual jobs and not brainteaser interviews. To wit, the interview questions I ask are usuall

I'd much rather my engineers have spent their time practicing their actual jobs and not brainteaser interviews. To wit, the interview questions I ask are usually in line with the role they're assuming.

qPM9l3XJrF 5y ago
The author wrote this post in the context of hiring at a "hard technology startup". I interpret that as a place where engineers are expected to be able to do cutting edge computer science research (it's not a "well-established [role] to do specialized tasks"). It's not clear to me what sort of questions you would ask "in line with the role they're assuming" for this scenario. One idea here is to give candidates an open problem in CS and ask them to solve it. Which is a nice idea, but one of the other things I learned through administering hundreds of interviews is that open-ended questions aren't great interview problems because they depend a lot on creativity/lateral thinking/insight, which highly benefits from being in a relaxed frame of mind. So these questions end up being a test of how relaxed the candidate is. Stress creates tunnel vision, which is terrible for generating interesting research ideas but it's OK for solving these kind of leetcode problems. So checking for a very high level of programming aptitude, as a proxy for CS research ability, is an approach which is a bit more fair to candidates who are stressed out by interviews. (I also think it is a pretty decent proxy, because doing great CS research requires you to quickly & fluidly generate & evaluate algorithms / data structures which might solve your problem, which is a big part of what a great leetcoder does.) If you're targeting a very high level of generic programming aptitude, it is arguably most fair to make use of a standard method of measuring it. Leetcode problems are the industry standard for measuring programming aptitude. People know to practice them a lot and they know what to expect. If you came up with your own unique way to measure programming aptitude, that would create an even greater burden on candidates to practice (they'd have to do a whole different sort of practice in order to succeed in your interview), and also create anxiety due to an unexpected interview format. I think a lot of readers are overreacting because they didn't pay enough attention to this bit: "It's applicable if you're building an extraordinary team at a hard technology startup." The vast majority of companies in SV are not doing hard technology and don't need an extraordinary team. People should not feel inadequate if they aren't capable of improving the state of the art in technical areas of CS such as databases. This is ordinarily the domain of PhDs, and filtering for demonstrated algorithmic aptitude (as opposed to academic credentials) is actually a pretty egalitarian approach.
- void_mint 5y ago
  So let's be clear. You're honing in on this block: > "It's applicable if you're building an extraordinary team at a hard technology startup." And you're accepting that a timed question about tic tac toe is enough to prove you're capable of being on an "extraordinary team" at a "hard technology startup"? Really?
  - qPM9l3XJrF 5y ago
    Yes, I think to a large degree being able to build hard technology is a matter of being extremely fluent with writing code and reasoning about data structures and algorithms, as I stated. Being able to solve this problem in 10 minutes seems like a hard-to-fake demonstration of such fluency. When I think about CS open problems and when I solve leetcode problems with algorithmic content to them like this one, it feels like I'm using the same part of my brain (or at least there is significant overlap). If you don't agree with me that the fluency I described is a significant asset to advancing the state of the art in CS, what do you think a significant asset is?
    - void_mint 5y ago
      > Yes, I think to a large degree being able to build hard technology is a matter of being extremely fluent with writing code and reasoning about data structures and algorithms Sure. Again. I don't really think an algorithm that shows up as an introduction to algorithm proves much more than a person read "Intro to Algorithms". So again, a timed introductory problem proves some elite technical skill? > If you don't agree with me that the fluency I described is a significant asset to advancing the state of the art in CS You're building a cute lil strawman. I think the question is totally out of line with the stated goal. If a college sophomore can answer a question, you're not really assessing much of anything. Also, working at a "hard startup" has nothing to do with "advancing the state of the art in CS". > what do you think a significant asset is? If I'm handling hiring for a "hard startup" and am in search of engineers fit for an "extraordinary team", I'm probably going to spend more time finding applicable skills than opening up to Chapter 1 in the closest algorithms book.

qPM9l3XJrF 5y ago

The author wrote this post in the context of hiring at a "hard technology startup". I interpret that as a place where engineers are expected to be able to do cutting edge computer science research (it's not a "well-established [role] to do specialized tasks"). It's not clear to me what sort of questions you would ask "in line with the role they're assuming" for this scenario. One idea here is to give candidates an open problem in CS and ask them to solve it. Which is a nice idea, but one of the other things I learned through administering hundreds of interviews is that open-ended questions aren't great interview problems because they depend a lot on creativity/lateral thinking/insight, which highly benefits from being in a relaxed frame of mind. So these questions end up being a test of how relaxed the candidate is. Stress creates tunnel vision, which is terrible for generating interesting research ideas but it's OK for solving these kind of leetcode problems. So checking for a very high level of programming aptitude, as a proxy for CS research ability, is an approach which is a bit more fair to candidates who are stressed out by interviews. (I also think it is a pretty decent proxy, because doing great CS research requires you to quickly & fluidly generate & evaluate algorithms / data structures which might solve your problem, which is a big part of what a great leetcoder does.) If you're targeting a very high level of generic programming aptitude, it is arguably most fair to make use of a standard method of measuring it. Leetcode problems are the industry standard for measuring programming aptitude. People know to practice them a lot and they know what to expect. If you came up with your own unique way to measure programming aptitude, that would create an even greater burden on candidates to practice (they'd have to do a whole different sort of practice in order to succeed in your interview), and also create anxiety due to an unexpected interview format. I think a lot of readers are overreacting because they didn't pay enough attention to this bit: "It's applicable if you're building an extraordinary team at a hard technology startup." The vast majority of companies in SV are not doing hard technology and don't need an extraordinary team. People should not feel inadequate if they aren't capable of improving the state of the art in technical areas of CS such as databases. This is ordinarily the domain of PhDs, and filtering for demonstrated algorithmic aptitude (as opposed to academic credentials) is actually a pretty egalitarian approach.

void_mint 5y ago
So let's be clear. You're honing in on this block: > "It's applicable if you're building an extraordinary team at a hard technology startup." And you're accepting that a timed question about tic tac toe is enough to prove you're capable of being on an "extraordinary team" at a "hard technology startup"? Really?
- qPM9l3XJrF 5y ago
  Yes, I think to a large degree being able to build hard technology is a matter of being extremely fluent with writing code and reasoning about data structures and algorithms, as I stated. Being able to solve this problem in 10 minutes seems like a hard-to-fake demonstration of such fluency. When I think about CS open problems and when I solve leetcode problems with algorithmic content to them like this one, it feels like I'm using the same part of my brain (or at least there is significant overlap). If you don't agree with me that the fluency I described is a significant asset to advancing the state of the art in CS, what do you think a significant asset is?
  - void_mint 5y ago
    > Yes, I think to a large degree being able to build hard technology is a matter of being extremely fluent with writing code and reasoning about data structures and algorithms Sure. Again. I don't really think an algorithm that shows up as an introduction to algorithm proves much more than a person read "Intro to Algorithms". So again, a timed introductory problem proves some elite technical skill? > If you don't agree with me that the fluency I described is a significant asset to advancing the state of the art in CS You're building a cute lil strawman. I think the question is totally out of line with the stated goal. If a college sophomore can answer a question, you're not really assessing much of anything. Also, working at a "hard startup" has nothing to do with "advancing the state of the art in CS". > what do you think a significant asset is? If I'm handling hiring for a "hard startup" and am in search of engineers fit for an "extraordinary team", I'm probably going to spend more time finding applicable skills than opening up to Chapter 1 in the closest algorithms book.