3 ms·

If you don’t know Dan or haven’t read enough of his work to get this, > I can't pass algorithms interviews! When I say that, people often think I mean that I f

If you don’t know Dan or haven’t read enough of his work to get this, > I can't pass algorithms interviews! When I say that, people often think I mean that I fail half my interviews or something. It's more than half. is insane. Dan’s day job is (or was, on the occasions that I’ve worked with him) to identify and solve the weirdest, gnarliest scaling and performance bugs in extremely large systems. If Dan isn’t passing your algorithms interview, it’s not testing what you think it is.

BeetleB 2y ago
> If Dan isn’t passing your algorithms interview, it’s not testing what you think it is. I think it's also much easier to see/solve problems in practice than on a theoretical whiteboard. I've rarely had to use Leetcode level algorithms at work. But when I did, it was much easier to solve than if I'd been given the exact same problem without the context of the experience I'd accumulated working on the project. Example: I wrote a C++ program that stored a large number of 32 bit numbers[1] in a map (both key and value were 32 bits). When I ran the program, it ran out of memory (something like 80GB of RAM). I quickly realized that the map had a high overhead - all those pointers in a red-black tree consume more RAM than my data! As I was storing only once and doing lookups many times, it was simpler to simply sort all the keys, and then store the values. When I needed to do a lookup, I'd do a binary search and find it. Algorithmically same complexity as a map. If someone gave me this problem as a whiteboard, I'd implement the map based solution, and would really struggle if I started getting questions about memory performance, and it would be silly to ding me for not choosing a binary search. In reality, my screwup was extremely simple to solve - given that I had a good understanding of the problem domain - something lacking in a whiteboard interview. So in general, people who do poorly in those whiteboard interviews may well solve the exact same problem with ease in an actual work situation. Another example: I wrote a DAG and needed to check if two (arbitrary) nodes were connected. I chose a fairly inefficient algorithm - recursive backtracking with no memoization. If I've already computed that B is connected to C, and I know A is connected to B, I don't need to run the whole algorithm to know that A is connected to C. I wrote the simple, inefficient version, knowing it was a poor algorithm. But my reasoning was that I wanted to write all my tests with corner cases working before I fixed the performance. Once I had all the tests written, I returned to optimize the algorithm. Then I said "Heck, let's see how bad it is with real world data." The algorithm was fast. Even when I significantly increased N. How come? Oh, it's because due to real world limitations in the problem I was solving, the maximum distance between any 2 nodes I was comparing was 7. Yes, in the abstract, it seemed very inefficient, but when you apply real world limitations, you realize there is nothing to gain by making it more efficient. Leetcode biased folks would have made the code more complex for little gain. [1] Maybe it was 64 bit - I forget.
- chipdart 2y ago
  > I quickly realized that the map had a high overhead - all those pointers in a red-black tree consume more RAM than my data! That is true if you use std::map , which should only be used if you have a strong requirement in having sorted keys. If you do not have a requirement to keep sorted keys, you should use std::unordered_map which internally implements a dictionary as a hash table, exactly as std::unordered_set. > As I was storing only once and doing lookups many times, it was simpler to simply sort all the keys, and then store the values. When I needed to do a lookup, I'd do a binary search and find it. Algorithmically same complexity as a map. If you used std::unordered_map instead, you would be doing the same thing with a constant-time computational complexity instead of logarithmic, while retaining linear space complexity.
TrackerFF 2y ago
In my experience, algorithmic interviews work great for people that A) Are deeply interested in the topic. If you dabble in competitive programming, then these interviews should be a breeze. B) Young people out of college, with a fresh memory of data structures and algorithms classes. C) High IQ individuals. This one might be controversial, but I've met plenty of people that were just intellectually sharp enough to deduce the solutions, without having touched the material in 10 year, nor have been "grinding" LeetCode. But even these folks might not get through, if they haven't practiced - as you also have to solve the problems quick enough. D) Those that are willing to grind LeetCode for months and months, and dedicate all their time to such prep. One common trait has also been the ability to work under pressure / stress. If you're a good test-taker, you have an advantage. If tests make you anxious, that could be enough to derail your performance. I don't remember which company that did the internal study, but they found that women fared worse at whiteboard interviews due to higher rates of anxiety and lower self-confidence, compared to guys - even though they were equals as far as technical knowledge and work performance goes.
- P_I_Staker 2y ago
  You forgot first and foremost that a percentage of people just show up with the right answer. This has always bothered me about "brain teasers". Just testing for "have I seen this before".
  - roughly 2y ago
    I once had an interview for an internal transfer where the problem they gave me was one that we’d spent 6 years worth of senior staff engineers solving. Not sure I got to the same answer they did in my allotted 30min.

BeetleB 2y ago

> If Dan isn’t passing your algorithms interview, it’s not testing what you think it is. I think it's also much easier to see/solve problems in practice than on a theoretical whiteboard. I've rarely had to use Leetcode level algorithms at work. But when I did, it was much easier to solve than if I'd been given the exact same problem without the context of the experience I'd accumulated working on the project. Example: I wrote a C++ program that stored a large number of 32 bit numbers[1] in a map (both key and value were 32 bits). When I ran the program, it ran out of memory (something like 80GB of RAM). I quickly realized that the map had a high overhead - all those pointers in a red-black tree consume more RAM than my data! As I was storing only once and doing lookups many times, it was simpler to simply sort all the keys, and then store the values. When I needed to do a lookup, I'd do a binary search and find it. Algorithmically same complexity as a map. If someone gave me this problem as a whiteboard, I'd implement the map based solution, and would really struggle if I started getting questions about memory performance, and it would be silly to ding me for not choosing a binary search. In reality, my screwup was extremely simple to solve - given that I had a good understanding of the problem domain - something lacking in a whiteboard interview. So in general, people who do poorly in those whiteboard interviews may well solve the exact same problem with ease in an actual work situation. Another example: I wrote a DAG and needed to check if two (arbitrary) nodes were connected. I chose a fairly inefficient algorithm - recursive backtracking with no memoization. If I've already computed that B is connected to C, and I know A is connected to B, I don't need to run the whole algorithm to know that A is connected to C. I wrote the simple, inefficient version, knowing it was a poor algorithm. But my reasoning was that I wanted to write all my tests with corner cases working before I fixed the performance. Once I had all the tests written, I returned to optimize the algorithm. Then I said "Heck, let's see how bad it is with real world data." The algorithm was fast. Even when I significantly increased N. How come? Oh, it's because due to real world limitations in the problem I was solving, the maximum distance between any 2 nodes I was comparing was 7. Yes, in the abstract, it seemed very inefficient, but when you apply real world limitations, you realize there is nothing to gain by making it more efficient. Leetcode biased folks would have made the code more complex for little gain. [1] Maybe it was 64 bit - I forget.

chipdart 2y ago
> I quickly realized that the map had a high overhead - all those pointers in a red-black tree consume more RAM than my data! That is true if you use std::map , which should only be used if you have a strong requirement in having sorted keys. If you do not have a requirement to keep sorted keys, you should use std::unordered_map which internally implements a dictionary as a hash table, exactly as std::unordered_set. > As I was storing only once and doing lookups many times, it was simpler to simply sort all the keys, and then store the values. When I needed to do a lookup, I'd do a binary search and find it. Algorithmically same complexity as a map. If you used std::unordered_map instead, you would be doing the same thing with a constant-time computational complexity instead of logarithmic, while retaining linear space complexity.

TrackerFF 2y ago

In my experience, algorithmic interviews work great for people that A) Are deeply interested in the topic. If you dabble in competitive programming, then these interviews should be a breeze. B) Young people out of college, with a fresh memory of data structures and algorithms classes. C) High IQ individuals. This one might be controversial, but I've met plenty of people that were just intellectually sharp enough to deduce the solutions, without having touched the material in 10 year, nor have been "grinding" LeetCode. But even these folks might not get through, if they haven't practiced - as you also have to solve the problems quick enough. D) Those that are willing to grind LeetCode for months and months, and dedicate all their time to such prep. One common trait has also been the ability to work under pressure / stress. If you're a good test-taker, you have an advantage. If tests make you anxious, that could be enough to derail your performance. I don't remember which company that did the internal study, but they found that women fared worse at whiteboard interviews due to higher rates of anxiety and lower self-confidence, compared to guys - even though they were equals as far as technical knowledge and work performance goes.

P_I_Staker 2y ago
You forgot first and foremost that a percentage of people just show up with the right answer. This has always bothered me about "brain teasers". Just testing for "have I seen this before".
- roughly 2y ago
  I once had an interview for an internal transfer where the problem they gave me was one that we’d spent 6 years worth of senior staff engineers solving. Not sure I got to the same answer they did in my allotted 30min.