7 ms·

Asking candidates to come up with this kind of solution in an interview setting where they are under all kinds of pressure is honestly dehumanizing. There's a

Asking candidates to come up with this kind of solution in an interview setting where they are under all kinds of pressure is honestly dehumanizing. There's a lot of good insight in the article about the correct way to approach the problem, but asking anyone to come up with it on the spot is unrealistic. You have the benefit of having seen the problem before with time on your side to reflect on it. They haven't. When I do interviews like this, I prefer to talk them through the problem together, like we were actual teammates working on a problem together. That more closely relates to life on the job, which to me is the point of interviewing someone.

dnsco 3y ago
Many people (especially from big tech backgrounds), treat interviews as "the time for the candidate to prove that they are good enough to work at my company". I, like you, prefer to use the time for collaborative problem solving to try and get as much signal as possible about whether it would be fruitful for us to work together, while also trying to figure out if we would want to work together. The "is this person good enough for me" interview allows geniuses who are assholes through. I prefer to filter for good teammates.
bfung 3y ago
The question asked doesn’t involved any computer science algorithm knowledge at all, nowhere near leet code complexity. Only the basics that are close to everyday programming work: write a for-loop, know what a Map/dict is, and Google for “how to read a file”. If a candidate can’t do that, they can’t really program. ChatGPT can probably code this answer.
- sfn42 3y ago
  And now you know who the devs are who think LLMs will replace us. They're the ones who think this question is too much to ask.
corethree 3y ago
This one is pretty easy though.
cperciva 3y ago
If this is considered dehumanizing, I'm concerned for the future of our industry. Anyone with even a first undergraduate algorithms course should immediately spit out "sort by customer and page, then stream the output". I wouldn't expect everyone to immediately see the optimizations -- you can sort the days individually, you can drop all but a small number of pages per customer -- immediately, but I would be disappointed if someone couldn't be hinted there by the end of a 30 minute interview. Failing to even get the O(n log n) solution tells me that someone should never have graduated.
- thaumasiotes 3y ago
  > Failing to even get the O(n log n) solution tells me that someone should never have graduated. This is something I wonder about in my comment sidethread - to me, the natural solution is the O(n) one in O(n) space. I see that the O(n log n) solution requires O(1) space to run. But it requires O(n) space to return a result! Is that actually better than O(n) time and O(n) space?
  - cperciva 3y ago
    Either of those solutions is ok from a junior developer. From a senior developer, I would expect a discussion of in-core vs. out-of-core operations, and the fact that hash tables (even if they fit into RAM) aren't really O(1) time per operation since random access to large address spaces runs into e.g. TLB misses.
    - xoranth 3y ago
      Given that the depth of the page table tree is fixed at 3/4/5 depending on the architecture and kernel, I think most people would be confused if asked whether the average complexity of a hash table lookup is always really O(1). Even senior developers that understand the TLB would likely think of it as "O(1), but with a big constant factor". On a side note, one thing that the article doesn't mention is the possibility of using a Bloom filter. It trades an extra scan of a file for smaller hash tables/smaller set to sort with external sort.
aaomidi 3y ago
I would seriously expect anyone above mid level to not even consider the brute force solution.
- DoesntMatter22 3y ago
  Sadly I know plenty of Seniors with 15 or so years of experience. That would write brute force and it still wouldn't work right. Senior in a perfect world sure but the reality is that for decades ppl have been desperate for talent and so you don't have to do much to get by. I knew a popular principle engineer at a fortune 50 company who was loved by execs. He would check in 5 or 10 of the same file. Opposite of the dry principle.
mock-possum 3y ago
I don’t about that, I mean - if you’re going to be in a position where this level of craftsmanship is necessary, then why shouldn’t the interviewer require that you demonstrate your ability to do so? It’s not a trick question, it isn’t unrealistic or impractical, it just spotlights a particular programming focus, performance.
munksbeer 3y ago
Agree. Our interview technique is a trimmed down but somewhat realistic coding exercise. We do it as a pair programming exercise and we tell them up-front that this should be an interactive and positive experience, we're not trying to trick them or put them under pressure. It'll test the candidates ability to actually do the job they'll be doing if we hire them, which is to write code in an IDE. We do it with them, so they can ask questions on libraries they're not familiar with and so on. Obviously we're not going to solve the problems in exercise for them, but if they do get stuck, we'll help move them forward. The coding exercise will involve writing tests, deisgn of classes, working with floating point arithmetic, working across thread barriers, some fairly standard maths, and so on. I actually can't say we're hired a bad candidate yet and they all report that the interview is a positive experience. In my fairly long career I've been through about 10-15 interview processes. A few of them were quite toxic and those were the "just cram leetcode for months" type. I never want to inflict that on someone else.
- weaksauce 3y ago
  While I like your approach better than his by a considerable margin... I would say his approach has merits since he's a principle engineer at google(maybe hiring there) and was an engineer hiring at amazon. the problems they face would definitely have this applicability of a large volume of data needing to be worked on efficiently.
  - munksbeer 3y ago
    I actually think the question from the blog is a good one and I've used similar at previous roles. It may consist of one part of the interview process. I think in hindsight I was more responding to the overall ethos were some interviews are conducted in an unduly abrasive manner.
jemfinch 3y ago
> I prefer to talk them through the problem together, like we were actual teammates working on a problem together. If a colleague came to me to discuss a question this basic, I'd want them PIPed out. This is miles from the complexity of problems that require collaboration. It's a shell pipeline that I'd write with sort/uniq in less than five minutes. I just did it to make sure my estimate wasn't wrong: sort <(sort -u <(cut -d' ' -f1,2 /tmp/day1) <(cut -d' ' -f1,2 /tmp/day2) | cut -d' ' -f1 | uniq -d) <(sort <(cut -d' ' -f1 /tmp/day1 | sort | uniq) <(cut -d' ' -f1 /tmp/day2 | sort | uniq) | uniq -d) | uniq -d Maintainable? No. Done iteratively in less than five minutes? Yes. If your perspective is that it's unrealistic to ask anyone to come up with an answer to this question on the spot, you should take a long, hard look at yourself and the quality of your colleagues.
- AstralStorm 3y ago
  This thing runs for 2 days not total scan though. It does not scale to a total scan due to an O(n) memory requirements of storing every hit. You didn't ask the question you were supposed to ask. :)
- DoesntMatter22 3y ago
  As mentioned over and over. This isn't about the ability to do it. This is about making it less of a hazing ritual that generally only seeks to make the interviewer have a sense of importance.
- nsxwolf 3y ago
  If people knew that people like you existed, they’d be terrified of ever asking for help on anything.

dnsco 3y ago

Many people (especially from big tech backgrounds), treat interviews as "the time for the candidate to prove that they are good enough to work at my company". I, like you, prefer to use the time for collaborative problem solving to try and get as much signal as possible about whether it would be fruitful for us to work together, while also trying to figure out if we would want to work together. The "is this person good enough for me" interview allows geniuses who are assholes through. I prefer to filter for good teammates.

bfung 3y ago

The question asked doesn’t involved any computer science algorithm knowledge at all, nowhere near leet code complexity. Only the basics that are close to everyday programming work: write a for-loop, know what a Map/dict is, and Google for “how to read a file”. If a candidate can’t do that, they can’t really program. ChatGPT can probably code this answer.

sfn42 3y ago
And now you know who the devs are who think LLMs will replace us. They're the ones who think this question is too much to ask.

corethree 3y ago

This one is pretty easy though.

cperciva 3y ago

If this is considered dehumanizing, I'm concerned for the future of our industry. Anyone with even a first undergraduate algorithms course should immediately spit out "sort by customer and page, then stream the output". I wouldn't expect everyone to immediately see the optimizations -- you can sort the days individually, you can drop all but a small number of pages per customer -- immediately, but I would be disappointed if someone couldn't be hinted there by the end of a 30 minute interview. Failing to even get the O(n log n) solution tells me that someone should never have graduated.

thaumasiotes 3y ago
> Failing to even get the O(n log n) solution tells me that someone should never have graduated. This is something I wonder about in my comment sidethread - to me, the natural solution is the O(n) one in O(n) space. I see that the O(n log n) solution requires O(1) space to run. But it requires O(n) space to return a result! Is that actually better than O(n) time and O(n) space?
- cperciva 3y ago
  Either of those solutions is ok from a junior developer. From a senior developer, I would expect a discussion of in-core vs. out-of-core operations, and the fact that hash tables (even if they fit into RAM) aren't really O(1) time per operation since random access to large address spaces runs into e.g. TLB misses.
  - xoranth 3y ago
    Given that the depth of the page table tree is fixed at 3/4/5 depending on the architecture and kernel, I think most people would be confused if asked whether the average complexity of a hash table lookup is always really O(1). Even senior developers that understand the TLB would likely think of it as "O(1), but with a big constant factor". On a side note, one thing that the article doesn't mention is the possibility of using a Bloom filter. It trades an extra scan of a file for smaller hash tables/smaller set to sort with external sort.

aaomidi 3y ago

I would seriously expect anyone above mid level to not even consider the brute force solution.

DoesntMatter22 3y ago
Sadly I know plenty of Seniors with 15 or so years of experience. That would write brute force and it still wouldn't work right. Senior in a perfect world sure but the reality is that for decades ppl have been desperate for talent and so you don't have to do much to get by. I knew a popular principle engineer at a fortune 50 company who was loved by execs. He would check in 5 or 10 of the same file. Opposite of the dry principle.

mock-possum 3y ago

I don’t about that, I mean - if you’re going to be in a position where this level of craftsmanship is necessary, then why shouldn’t the interviewer require that you demonstrate your ability to do so? It’s not a trick question, it isn’t unrealistic or impractical, it just spotlights a particular programming focus, performance.

munksbeer 3y ago

Agree. Our interview technique is a trimmed down but somewhat realistic coding exercise. We do it as a pair programming exercise and we tell them up-front that this should be an interactive and positive experience, we're not trying to trick them or put them under pressure. It'll test the candidates ability to actually do the job they'll be doing if we hire them, which is to write code in an IDE. We do it with them, so they can ask questions on libraries they're not familiar with and so on. Obviously we're not going to solve the problems in exercise for them, but if they do get stuck, we'll help move them forward. The coding exercise will involve writing tests, deisgn of classes, working with floating point arithmetic, working across thread barriers, some fairly standard maths, and so on. I actually can't say we're hired a bad candidate yet and they all report that the interview is a positive experience. In my fairly long career I've been through about 10-15 interview processes. A few of them were quite toxic and those were the "just cram leetcode for months" type. I never want to inflict that on someone else.

weaksauce 3y ago
While I like your approach better than his by a considerable margin... I would say his approach has merits since he's a principle engineer at google(maybe hiring there) and was an engineer hiring at amazon. the problems they face would definitely have this applicability of a large volume of data needing to be worked on efficiently.
- munksbeer 3y ago
  I actually think the question from the blog is a good one and I've used similar at previous roles. It may consist of one part of the interview process. I think in hindsight I was more responding to the overall ethos were some interviews are conducted in an unduly abrasive manner.

jemfinch 3y ago

> I prefer to talk them through the problem together, like we were actual teammates working on a problem together. If a colleague came to me to discuss a question this basic, I'd want them PIPed out. This is miles from the complexity of problems that require collaboration. It's a shell pipeline that I'd write with sort/uniq in less than five minutes. I just did it to make sure my estimate wasn't wrong: sort <(sort -u <(cut -d' ' -f1,2 /tmp/day1) <(cut -d' ' -f1,2 /tmp/day2) | cut -d' ' -f1 | uniq -d) <(sort <(cut -d' ' -f1 /tmp/day1 | sort | uniq) <(cut -d' ' -f1 /tmp/day2 | sort | uniq) | uniq -d) | uniq -d Maintainable? No. Done iteratively in less than five minutes? Yes. If your perspective is that it's unrealistic to ask anyone to come up with an answer to this question on the spot, you should take a long, hard look at yourself and the quality of your colleagues.

AstralStorm 3y ago
This thing runs for 2 days not total scan though. It does not scale to a total scan due to an O(n) memory requirements of storing every hit. You didn't ask the question you were supposed to ask. :)
DoesntMatter22 3y ago
As mentioned over and over. This isn't about the ability to do it. This is about making it less of a hazing ritual that generally only seeks to make the interviewer have a sense of importance.
nsxwolf 3y ago
If people knew that people like you existed, they’d be terrified of ever asking for help on anything.