3 ms·

The problem space for computer science algorithms is gigantic and many of these companies testing for this knowledge then immediately throw new engineers onto l

The problem space for computer science algorithms is gigantic and many of these companies testing for this knowledge then immediately throw new engineers onto line of business CRUD apps and bug fixes, which rarely have the engineer implementing any of these algorithms from scratch. A programmer worth his salt should retain enough 1st principles knowledge to not create a O(n^3) bottleneck in production or otherwise stay out of trouble. Unless you have a super targeted problem space that interviewing employees know about Often the specific skills are mentioned up front. It doesn't have to be that targeted, either. Most developers I know just brush on as many algorithms as they can remember when they are going to interview for a new job. Then they just go through interviews until they find a company that manages to pick an algorithm out of the ones they memorized. This speaks more to bad interviewing. It certainly does not mean that such knowledge being worthless and arbitrary. What you want in a candidate, generally speaking, is someone who can actually apply knowledge. What you are describing above is just regurgitation. http://v.cx/2010/04/feynman-brazil-education http://v.cx/2010/04/feynman-brazil-education

sidlls 8y ago
Yes, and regurgitation is what tech interviews these days optimize for in selecting candidates. Regurgitation is not simply repeating the technical components verbatim, by the way. It includes rote rehearsal of a believable way to present (i.e. fake) working it out from scratch.
- stcredzero 8y ago
  Hell, if an interviewee understands enough to be able to convincingly fake working things out, they're already way ahead of a lot of other candidates. I've seen people faking such things badly. In general, they can spout off about the "happy path," but they can't tell you how the implementation can go wrong and what to do about it. When I was a grad student TA, I told people not to cheat. If you don't know enough to answer the questions, you don't have enough knowledge to cheat. That turned out to be quite true.
  - sidlls 8y ago
    I think you might be underestimating how big the "interview prep" industry is or how it works. The people "faking" it in this way likely actually know much less than someone who honestly struggles to come up with a poorly performing brute force solution and they practice the soft skills necessary to prevent the interview from ever getting to the point where you're asking questions about where the implementation can go wrong that aren't also on their script.
    - stcredzero 8y ago
      The people "faking" it in this way likely actually know much less than someone who honestly struggles to come up with a poorly performing brute force solution My office scores the people with the brute force solution higher than the others, so long as they know the time/space complexity. they practice the soft skills necessary to prevent the interview from ever getting to the point where you're asking questions about where the implementation can go wrong that aren't also on their script Oh yeah. That sounds familiar. Not getting to the part where they can answer questions about where the implementation can go wrong counts against them.
watwut 8y ago
The task was not about probable n^3 bottleneck. It was about proving probability distribution.
- stcredzero 8y ago
  In that sentence, I was talking generally about people debugging CRUD apps, not about the specific example. You will note that the parent comment to mine is talking in general terms, not about the example.
lovich 8y ago
I agree it speaks to bad interviewing, because these whiteboard interviews are a bad interview practice. Yea knowing how to not acciddentally get an O(n^3) bottleneck is table stakes for development. What we get however is you interviewing for a job to make data entry apps and they ask you to implement a variety offlood fill algorithms with modifications that force edge cases unless you work around it. Or you'll be maintaining a legacy application and then they ask you to work out a Month Carlo simulation on the board. Then on top of this, despite what interviewers say out loud, they almost always start looking at edge cases and if the interviewee does not work there way around them they are dinged for points compared to an interviewee who does deal with the edge cases. The majority of development work does not have you working through every comp sci algorithm in existence on a frequent enough schedule that the average engineer, or even a great engineer, will remember them all. That is going to garuntees that interviews are a game of chance. The more algorithms and the trick question associated with them that you can memorize the greater your odds, but it's still down to luck of the draw for what questions you are asked. If you're looking for devs to show that they understand the ideas, you'd be better off telling them the problem space ahead of time so that they can prepare for it, and then deeply questioning their knowledge in that space
- stcredzero 8y ago
  Yea knowing how to not acciddentally get an O(n^3) bottleneck is table stakes for development. It seems to me that a lot of younger folks want to lower the bar below that. If you're looking for devs to show that they understand the ideas, you'd be better off telling them the problem space ahead of time so that they can prepare for it, and then deeply questioning their knowledge in that space Perhaps combine that with a related but novel question.
  - mixmastamyk 8y ago
    Creativity comes from solitude not with a gun to your head.
    - stcredzero 8y ago

sidlls 8y ago

Yes, and regurgitation is what tech interviews these days optimize for in selecting candidates. Regurgitation is not simply repeating the technical components verbatim, by the way. It includes rote rehearsal of a believable way to present (i.e. fake) working it out from scratch.

stcredzero 8y ago
Hell, if an interviewee understands enough to be able to convincingly fake working things out, they're already way ahead of a lot of other candidates. I've seen people faking such things badly. In general, they can spout off about the "happy path," but they can't tell you how the implementation can go wrong and what to do about it. When I was a grad student TA, I told people not to cheat. If you don't know enough to answer the questions, you don't have enough knowledge to cheat. That turned out to be quite true.
- sidlls 8y ago
  I think you might be underestimating how big the "interview prep" industry is or how it works. The people "faking" it in this way likely actually know much less than someone who honestly struggles to come up with a poorly performing brute force solution and they practice the soft skills necessary to prevent the interview from ever getting to the point where you're asking questions about where the implementation can go wrong that aren't also on their script.
  - stcredzero 8y ago
    The people "faking" it in this way likely actually know much less than someone who honestly struggles to come up with a poorly performing brute force solution My office scores the people with the brute force solution higher than the others, so long as they know the time/space complexity. they practice the soft skills necessary to prevent the interview from ever getting to the point where you're asking questions about where the implementation can go wrong that aren't also on their script Oh yeah. That sounds familiar. Not getting to the part where they can answer questions about where the implementation can go wrong counts against them.

watwut 8y ago

The task was not about probable n^3 bottleneck. It was about proving probability distribution.

stcredzero 8y ago
In that sentence, I was talking generally about people debugging CRUD apps, not about the specific example. You will note that the parent comment to mine is talking in general terms, not about the example.

lovich 8y ago

I agree it speaks to bad interviewing, because these whiteboard interviews are a bad interview practice. Yea knowing how to not acciddentally get an O(n^3) bottleneck is table stakes for development. What we get however is you interviewing for a job to make data entry apps and they ask you to implement a variety offlood fill algorithms with modifications that force edge cases unless you work around it. Or you'll be maintaining a legacy application and then they ask you to work out a Month Carlo simulation on the board. Then on top of this, despite what interviewers say out loud, they almost always start looking at edge cases and if the interviewee does not work there way around them they are dinged for points compared to an interviewee who does deal with the edge cases. The majority of development work does not have you working through every comp sci algorithm in existence on a frequent enough schedule that the average engineer, or even a great engineer, will remember them all. That is going to garuntees that interviews are a game of chance. The more algorithms and the trick question associated with them that you can memorize the greater your odds, but it's still down to luck of the draw for what questions you are asked. If you're looking for devs to show that they understand the ideas, you'd be better off telling them the problem space ahead of time so that they can prepare for it, and then deeply questioning their knowledge in that space

stcredzero 8y ago
Yea knowing how to not acciddentally get an O(n^3) bottleneck is table stakes for development. It seems to me that a lot of younger folks want to lower the bar below that. If you're looking for devs to show that they understand the ideas, you'd be better off telling them the problem space ahead of time so that they can prepare for it, and then deeply questioning their knowledge in that space Perhaps combine that with a related but novel question.
- mixmastamyk 8y ago
  Creativity comes from solitude not with a gun to your head.
  - stcredzero 8y ago