4 ms·

I never did a CS degree so much of the learning was decently useful but it also took me years

dekhn 4y ago
I only took 1 CS class in college- Cybernetics with Huffman. I failed! So clearly, that was a strong predictor for my future 12 year career at google (where I failed to do quicksort, or virtual ants problems). Nowadays I take a lot of extra time to come up with questions that aren't in leetcode, are easier than leetcode, and give far more signal than any leetcode would, for anything except for a 10X Staff Engineer.
- cadr 4y ago
  Can you share what kind of things these are that give far more signal?
  - dekhn 4y ago
    To be honest? every programmer needs to be able to pass FizzBuzz. Beyond that, I add some more basic work around byte representations of data (I have 4 symbols... how many bits do I need to encode a symbol?). I will typpically also include one major bug in a piece of code and ask the user to identify it (with hints). I once interviewed a guy- a CTO at a biotech- and he wouldn't answer the question "I have a million DNA sequences and want to count the number of occurrences of each sequence" (could be hash table, could be any number of other solutions; he just balked and exited the interview). Only if the person can get all that right would I even consider asking something more complicated.
    - cadr 4y ago
      I agree liking to ask simpler stuff first. But what about this more complicated stuff? My problem is that when we talk about stuff having more "signal" - how are we determining if those questions are giving us more signal?
      - dekhn 4y ago
        My question is fairly open and allows me to continue asking significantly more complicated questions. So far, nobody has (for example) asked enough clarifying questions to determine that a bloom counting filter could potentially solve the problem- most people just store ASCII string keys in a hash table, which wastes tons of memory and requires a lookup for every string. So usually I end up after 45 minutes finding that the candidate has more or less tapped themselves out at "make a hash table of string keys, use it to store counts" (OK for a very junior programmer) or "make a perfect minimal hash" (I help them get there if they don't know what those are) or "use a probabilistic counting filter". This is about all I need to make a determination.
        cadr 4y ago
        But have you had a chance to look back and see if those questions worked out? Like, are they a good predictor for how the person actually performed in the job?
        dekhn 4y ago
        I've only been directly involved in hiring five people and it worked out well for all of those
        cadr 4y ago
        cool. Thank you!
        visarga 4y ago
        Bloom filters have collisions. How would that work with counting sequences?
        dekhn 4y ago
        Because (and this is absolutely a clarifying question I would love to get), approximate counts are acceptable. https://bmcbioinformatics.biomedcentral.com/articles/10.1186/1471-2105-12-333 https://bmcbioinformatics.biomedcentral.com/articles/10.1186...
    - akhmatova 4y ago
      I once interviewed a guy- a CTO at a biotech- and he wouldn't answer the question "I have a million DNA sequences and want to count the number of occurrences of each sequence" (could be hash table, could be any number of other solutions; he just balked and exited the interview). Maybe he's just been around the block a sufficient number of times to have gotten tired of the standard SV "here's a hoop, jump through it, now do it again, and again and again" ritual that it likes to call "interviewing" for some reason. Seriously - your questions are fine for junior or mid-level roles, but beyond that, you should have more important thinks to talk about. And both of you should be able to tell if the other is a bullshitter and/or a lightweight within about 30 minutes at most (and often far quicker than that) of a normal, focused technical conversation -- without having to specifically grill the other person, or otherwise put on the pretension that you're one whose bona fides are established beyond question, and they're the one who needs to jump through a sequence of hoops to prove that they are worthy of your time and attention. Just cut the crap, get down to brass tacks, and talk what needs to be done as if they're a peer. That's all you have to do.

I only took 1 CS class in college- Cybernetics with Huffman. I failed! So clearly, that was a strong predictor for my future 12 year career at google (where I failed to do quicksort, or virtual ants problems). Nowadays I take a lot of extra time to come up with questions that aren't in leetcode, are easier than leetcode, and give far more signal than any leetcode would, for anything except for a 10X Staff Engineer.

cadr 4y ago
Can you share what kind of things these are that give far more signal?
- dekhn 4y ago
  To be honest? every programmer needs to be able to pass FizzBuzz. Beyond that, I add some more basic work around byte representations of data (I have 4 symbols... how many bits do I need to encode a symbol?). I will typpically also include one major bug in a piece of code and ask the user to identify it (with hints). I once interviewed a guy- a CTO at a biotech- and he wouldn't answer the question "I have a million DNA sequences and want to count the number of occurrences of each sequence" (could be hash table, could be any number of other solutions; he just balked and exited the interview). Only if the person can get all that right would I even consider asking something more complicated.
  - cadr 4y ago
    I agree liking to ask simpler stuff first. But what about this more complicated stuff? My problem is that when we talk about stuff having more "signal" - how are we determining if those questions are giving us more signal?
    - dekhn 4y ago
      My question is fairly open and allows me to continue asking significantly more complicated questions. So far, nobody has (for example) asked enough clarifying questions to determine that a bloom counting filter could potentially solve the problem- most people just store ASCII string keys in a hash table, which wastes tons of memory and requires a lookup for every string. So usually I end up after 45 minutes finding that the candidate has more or less tapped themselves out at "make a hash table of string keys, use it to store counts" (OK for a very junior programmer) or "make a perfect minimal hash" (I help them get there if they don't know what those are) or "use a probabilistic counting filter". This is about all I need to make a determination.
      - cadr 4y ago
        But have you had a chance to look back and see if those questions worked out? Like, are they a good predictor for how the person actually performed in the job?
        dekhn 4y ago
        I've only been directly involved in hiring five people and it worked out well for all of those
        cadr 4y ago
        cool. Thank you!
      - visarga 4y ago
        Bloom filters have collisions. How would that work with counting sequences?
        dekhn 4y ago
        Because (and this is absolutely a clarifying question I would love to get), approximate counts are acceptable. https://bmcbioinformatics.biomedcentral.com/articles/10.1186/1471-2105-12-333 https://bmcbioinformatics.biomedcentral.com/articles/10.1186...
  - akhmatova 4y ago
    I once interviewed a guy- a CTO at a biotech- and he wouldn't answer the question "I have a million DNA sequences and want to count the number of occurrences of each sequence" (could be hash table, could be any number of other solutions; he just balked and exited the interview). Maybe he's just been around the block a sufficient number of times to have gotten tired of the standard SV "here's a hoop, jump through it, now do it again, and again and again" ritual that it likes to call "interviewing" for some reason. Seriously - your questions are fine for junior or mid-level roles, but beyond that, you should have more important thinks to talk about. And both of you should be able to tell if the other is a bullshitter and/or a lightweight within about 30 minutes at most (and often far quicker than that) of a normal, focused technical conversation -- without having to specifically grill the other person, or otherwise put on the pretension that you're one whose bona fides are established beyond question, and they're the one who needs to jump through a sequence of hoops to prove that they are worthy of your time and attention. Just cut the crap, get down to brass tacks, and talk what needs to be done as if they're a peer. That's all you have to do.