15 ms·

I used have a similar perspective as the author, that the leetcode style questions / data structure / algorithm stuff they ask in interviews but seems to have l

I used have a similar perspective as the author, that the leetcode style questions / data structure / algorithm stuff they ask in interviews but seems to have little to do with day-to-day corporate software development is all a big waste of everyone's time. I'm not sure I still do, though. It's true that this stuff rarely comes up and often doesn't matter for most real-world applications... but when it does, it matters a lot. The difference between O(n2), O(n) and O(log n) is huge for big values of n. Being about to go straight to a (nearly) optimal solution, instead of hacking together something, waiting for it to burst a the seams, and then having to fix it... or being able to spot someone else doing that, can save weeks or months of development at a time. It's a bit like saying it's silly for pilots to have to know what to do in the case of engine failure or stall from memory and regularly practice in a simulator, because that stuff rarely happens and most of the time they're just using autopilot. That's true, it usually doesn't matter, but when it does... it matters a lot.

YZF 5y ago
When it comes up do you need to code it up in 20 minutes or is looking the algorithm up in a textbook ok? If all you want to test that sort of knowledge just ask the knowledge question. I don't need to memorize Floyd-Warshal and be able to code it on demand to be able to recognize when it's needed and look it up. I'm sure I remembered it back in school, haven't used it since, but if the day comes I'll look it up...
- Hermitian909 5y ago
  I do think there's a real place for interview questions where you identify algorithmic opportunities in real world problem scenarios quickly, but you also may be missing some of the incentives for testing the way it's currently tested: Coding floyd-warshal importantly shows that you can code, and generally signals at least one of two things: 1. You studied hard for the interview, you're willing to do difficult and unpleasant intellectual work for rewards and do so in a structured enough manner to get results. 2. You have such a deep understanding of graphs and graph algorithms you were able to re-construct floyd-warshal in 45 minutes. This implies time will not be an issue if you see an opportunity for these problems, and you can probably handle much harder problems as well. Filtering for these two traits might work very well depending on the hiring needs of a particular company.
  - YZF 5y ago
    I would say: 1. You're fresh out of school or you have a lot of time on your hands. 2. You memorized some interview preparation book. I do agree that a candidate that has shown some effort preparing for an interview is a positive. Other than that this seems like a silly game. The flip side is the candidate that memorized the book, prepared like it's a test at school, and is useless on the job, can't operate at all outside that memorized domain, can't write the simplest bit of real world code.
    - Hermitian909 5y ago
      > The flip side is the candidate that memorized the book, prepared like it's a test at school, and is useless on the job, can't operate at all outside that memorized domain, can't write the simplest bit of real world code. I think this leaves out the possibility of high mastery. I think it is instructive think about algorithm skills as similar to those for algebra. If the most advanced algebra you ever solved was linear equations, remembering how to solve a linear equation may be difficult. However if you're skilled at solving advanced calculus problems by hand, your understanding of algebra is so deep that you could re-derive the process as necessary. Many of us with a lot of math experience will never forget how to solve linear or quadratic equations barring steep cognitive decline and this is also so true for certain classes of algorithms. Personally, I've studied graphs and graph algorithms beyond what you might find in just CLRS or other introductory algorithms textbooks and as a result I can re-derive many classic graph algorithms on the fly, no memorization necessary. I have done this interviews as have people I know.
    - XorNot 5y ago
      I mean it's also a pretty good filter by age: if you're middle aged, working and have children, then you're not going to really have the time to get through memorising a bunch of leetcode. Which is handy because Google et al don't really want employees who look at the in-office perks and wonder why they'd be appealing at all if you're just going to go home at the end of the day.
      - BurningFrog 5y ago
- tubby12345 5y ago
  - lazyasciiart 5y ago
    So, you roll your own crypto?
  - YZF 5y ago
    Sorry but this is completely wrong. Not needing to code Floyd–Warshall on the job is not equal to "high-level apis and glue code". You can totally recognize the opportunity for the correct data structure or algorithm despite not having them all in your head all the time. That's exactly what a good software engineer does. But if you think you can code up any algorithm in any domain on the fly I'm sure I can find some good interview question for you. I mean there's only like 5 algorithms in the world, right? I'm sure you have at least all the volumes of Knuth memorized... And if not, you must just be writing glue code ;)
    - tubby12345 5y ago
      - YZF 5y ago
        I can assure you, 100% without a doubt, that this is where the vast majority of developers are. Including people working on the most cutting edge software. The only reason the people you interview(?) can regurgitate this is because they just re-read their course book yesterday and they expect algorithmic problems. Or sure, some of us do competitive coding and such where these things do show up. There's absolutely no need to memorize this. But if you do more power to you. EDIT: I have made it through those interviews. That's not really the point. The way you make it through is by preparing, just like you'd prepare for the test in school. Doesn't show anything.
        tubby12345 5y ago
        >I can assure you, 100% without a doubt, that this is where the vast majority of developers are. cool? then that majority doesn't generate the same value as those that do and so they shouldn't get paid as such? i already asserted that? >Including people working on the most cutting edge software. ctrl+f to doubt that you know what people working on cutting edge software do. i, on the other hand, do have some experience on cutting edge compiler tech and it is absolutely what i've described. sorry not sorry. >can regurgitate this is because they just re-read their course book yesterday and they expect algorithmic problems. great. i'm glad. they're prepared for tasks being assigned to them that exercise those skills and by the end of the half they'll have a deep understanding rather than just a wrote understanding. either way i'll hire them over someone that thinks it's worthless being conversant in the algorithm.
- random314 5y ago
  I have worked with engineers who treated their work as glueing together various services to get the results required. They were absolutely shit engineers, whose approach to building services for massive scale were simply 1. Glue together whatever services are available and seem to make sense. 2. Throw increasing amounts of traffic at it and check what fails 3. Try to patch around failure point 4. blame the service provider for "not scaling" 5. Ask for more and more machines 6. Exclaim how great their design is on the basis of the cool class hierarchies and interfaces they wrote. Teach "junior devs" their "OOP design skills and patterns" 7. Go to step 2 They think of themselves as great engineers who scale things. The reality is they are absolute shit engineers who have no clue what they are building, frequently have crazy O(n^2) loops in their code, dont recognize a graph problem if its staring them in their face. Examples 1. They needed a way to rerun map reduce jobs to regenerate data for previous 30 days. It was a straight forward, graph topological sort problem. Instead they built a crazy solution using multiple instances of Airbnb airflow. One server ran out of memory for these airflow instances, so they allocated a whole damn cluster of machines to run 30 instances of airflow! The job of the cluster? Issuing map reduce jobs to the hadoop cluster. They needed a cluster of machines just to issue commands to hadoop. They gave an elaborate tech talk about "scaling to 30X capacity" to process 30 days of data. Meanwhile, my team was processing 3 years of data. We considered hamake for our data rebuild process. Eventually, I wrote a 70 line scala topological sort routine that would do the job for us, because it gave us more flexibility than hamake and linked to our code libraries. 2. Some guy wrote a data pipeline to summarize a days results that took 24 hours to run, thanks to 40 different joins. I rewrote it to use a single group by. The code ran in 10s of minutes. He didn't know how hadoop worked or external sorting, beyond writing arbitrary sql. So much for looking up algorithms when required. 3. Guys presents beautiful OOP code that has major race conditions in a distributed environment. I point out the race condition. Keeps proposing hacks to "solve the problem". Does not understand transaction processing or locking algorithms or what options are available to him. Hadn't heard if read write locks. What are the pros or cons. Doesn't understand the difference between local locks and distributed fault tolerant locks. I explain it to him. He eventually comes up with a solution using zookeeper that will need zookeeper to process 1000s of updates per second. I give up. "DSA, what DSA? They are for kids. I will look up an algorithm when I need it".
  - 5y ago
WalterBright 5y ago
Over and over, I see code written by star professionals that you've heard of, reinventing the bubble sort. I'm guilty of it myself. > It's a bit like saying it's silly for pilots to have to know what to do in the case of engine failure or stall from memory and regularly practice in a simulator, because that stuff rarely happens and most of the time they're just using autopilot. That's true, it usually doesn't matter, but when it does... it matters a lot. Well, we now know what happens when pilots forget the runaway stabilizer trim procedure (turn off the stab trim).
- XorNot 5y ago
  I mean this is also what happens when pilots aren't following their checklists though.
  - WalterBright 5y ago
    Checklists in an emergency are the same idea as Dealer's Strategy in blackjack. If you've got nothing better, or are under so much stress you can't think, or don't have time to think, do Dealer's Strategy. But sometimes, pilots are needed to recognize when the checklist isn't going to work, and can innovate on the job. That's why we still have pilots on airplanes, as a computer can follow a checklist.
- tubby12345 5y ago
  if i need a toposort in my proprietary task scheduling system, or fisher–yates shuffle in my proprietary ranking system, what do you recommend? this isn't hypothetical - i've had these things come up in the last half at work.
  - YZF 5y ago
    There ya go: https://www.boost.org/doc/libs/1_78_0/libs/graph/doc/topological_sort.html https://www.boost.org/doc/libs/1_78_0/libs/graph/doc/topolog...
    - tubby12345 5y ago
eropple 5y ago
> It's true that this stuff rarely comes up and often doesn't matter for most real-world applications... but when it does, it matters a lot. The difference between O(n2), O(n) and O(log n) is huge for big values of n. Being about to go straight to a (nearly) optimal solution, instead of hacking together something, waiting for it to burst a the seams, and then having to fix it... or being able to spot someone else doing that, can save weeks or months of development at a time. This is true, and absolutely matters. But I would suggest that developing the intuition to recognize a problem as being of a particular class, and even going further as to being able to look at the provided solution and intuit whether or not it is optimal (or optimal-enough), is a different thing than calling up that optimal algorithm from your limited brainspace. Like--if you understand the principles of what you're doing, Google isn't a much slower recall mechanism than you are, and it's less likely to have misremembered something.
capitalsigma 5y ago
Friendly reminder that O(2n) = O(n)
eternityforest 5y ago
Knowing that O(n2) is a problem and that an O(n) algorithm exists matters. But why do they have to know how to write that O(n) themselves? It's a quick easy test of understanding, but why not ask "How would you speed this up" and show them some O(n2) code?

YZF 5y ago

When it comes up do you need to code it up in 20 minutes or is looking the algorithm up in a textbook ok? If all you want to test that sort of knowledge just ask the knowledge question. I don't need to memorize Floyd-Warshal and be able to code it on demand to be able to recognize when it's needed and look it up. I'm sure I remembered it back in school, haven't used it since, but if the day comes I'll look it up...

Hermitian909 5y ago
I do think there's a real place for interview questions where you identify algorithmic opportunities in real world problem scenarios quickly, but you also may be missing some of the incentives for testing the way it's currently tested: Coding floyd-warshal importantly shows that you can code, and generally signals at least one of two things: 1. You studied hard for the interview, you're willing to do difficult and unpleasant intellectual work for rewards and do so in a structured enough manner to get results. 2. You have such a deep understanding of graphs and graph algorithms you were able to re-construct floyd-warshal in 45 minutes. This implies time will not be an issue if you see an opportunity for these problems, and you can probably handle much harder problems as well. Filtering for these two traits might work very well depending on the hiring needs of a particular company.
- YZF 5y ago
  I would say: 1. You're fresh out of school or you have a lot of time on your hands. 2. You memorized some interview preparation book. I do agree that a candidate that has shown some effort preparing for an interview is a positive. Other than that this seems like a silly game. The flip side is the candidate that memorized the book, prepared like it's a test at school, and is useless on the job, can't operate at all outside that memorized domain, can't write the simplest bit of real world code.
  - Hermitian909 5y ago
    > The flip side is the candidate that memorized the book, prepared like it's a test at school, and is useless on the job, can't operate at all outside that memorized domain, can't write the simplest bit of real world code. I think this leaves out the possibility of high mastery. I think it is instructive think about algorithm skills as similar to those for algebra. If the most advanced algebra you ever solved was linear equations, remembering how to solve a linear equation may be difficult. However if you're skilled at solving advanced calculus problems by hand, your understanding of algebra is so deep that you could re-derive the process as necessary. Many of us with a lot of math experience will never forget how to solve linear or quadratic equations barring steep cognitive decline and this is also so true for certain classes of algorithms. Personally, I've studied graphs and graph algorithms beyond what you might find in just CLRS or other introductory algorithms textbooks and as a result I can re-derive many classic graph algorithms on the fly, no memorization necessary. I have done this interviews as have people I know.
  - XorNot 5y ago
    I mean it's also a pretty good filter by age: if you're middle aged, working and have children, then you're not going to really have the time to get through memorising a bunch of leetcode. Which is handy because Google et al don't really want employees who look at the in-office perks and wonder why they'd be appealing at all if you're just going to go home at the end of the day.
    - BurningFrog 5y ago
tubby12345 5y ago
- lazyasciiart 5y ago
  So, you roll your own crypto?
- YZF 5y ago
  Sorry but this is completely wrong. Not needing to code Floyd–Warshall on the job is not equal to "high-level apis and glue code". You can totally recognize the opportunity for the correct data structure or algorithm despite not having them all in your head all the time. That's exactly what a good software engineer does. But if you think you can code up any algorithm in any domain on the fly I'm sure I can find some good interview question for you. I mean there's only like 5 algorithms in the world, right? I'm sure you have at least all the volumes of Knuth memorized... And if not, you must just be writing glue code ;)
  - tubby12345 5y ago
    - YZF 5y ago
      I can assure you, 100% without a doubt, that this is where the vast majority of developers are. Including people working on the most cutting edge software. The only reason the people you interview(?) can regurgitate this is because they just re-read their course book yesterday and they expect algorithmic problems. Or sure, some of us do competitive coding and such where these things do show up. There's absolutely no need to memorize this. But if you do more power to you. EDIT: I have made it through those interviews. That's not really the point. The way you make it through is by preparing, just like you'd prepare for the test in school. Doesn't show anything.
      - tubby12345 5y ago
        >I can assure you, 100% without a doubt, that this is where the vast majority of developers are. cool? then that majority doesn't generate the same value as those that do and so they shouldn't get paid as such? i already asserted that? >Including people working on the most cutting edge software. ctrl+f to doubt that you know what people working on cutting edge software do. i, on the other hand, do have some experience on cutting edge compiler tech and it is absolutely what i've described. sorry not sorry. >can regurgitate this is because they just re-read their course book yesterday and they expect algorithmic problems. great. i'm glad. they're prepared for tasks being assigned to them that exercise those skills and by the end of the half they'll have a deep understanding rather than just a wrote understanding. either way i'll hire them over someone that thinks it's worthless being conversant in the algorithm.
random314 5y ago
I have worked with engineers who treated their work as glueing together various services to get the results required. They were absolutely shit engineers, whose approach to building services for massive scale were simply 1. Glue together whatever services are available and seem to make sense. 2. Throw increasing amounts of traffic at it and check what fails 3. Try to patch around failure point 4. blame the service provider for "not scaling" 5. Ask for more and more machines 6. Exclaim how great their design is on the basis of the cool class hierarchies and interfaces they wrote. Teach "junior devs" their "OOP design skills and patterns" 7. Go to step 2 They think of themselves as great engineers who scale things. The reality is they are absolute shit engineers who have no clue what they are building, frequently have crazy O(n^2) loops in their code, dont recognize a graph problem if its staring them in their face. Examples 1. They needed a way to rerun map reduce jobs to regenerate data for previous 30 days. It was a straight forward, graph topological sort problem. Instead they built a crazy solution using multiple instances of Airbnb airflow. One server ran out of memory for these airflow instances, so they allocated a whole damn cluster of machines to run 30 instances of airflow! The job of the cluster? Issuing map reduce jobs to the hadoop cluster. They needed a cluster of machines just to issue commands to hadoop. They gave an elaborate tech talk about "scaling to 30X capacity" to process 30 days of data. Meanwhile, my team was processing 3 years of data. We considered hamake for our data rebuild process. Eventually, I wrote a 70 line scala topological sort routine that would do the job for us, because it gave us more flexibility than hamake and linked to our code libraries. 2. Some guy wrote a data pipeline to summarize a days results that took 24 hours to run, thanks to 40 different joins. I rewrote it to use a single group by. The code ran in 10s of minutes. He didn't know how hadoop worked or external sorting, beyond writing arbitrary sql. So much for looking up algorithms when required. 3. Guys presents beautiful OOP code that has major race conditions in a distributed environment. I point out the race condition. Keeps proposing hacks to "solve the problem". Does not understand transaction processing or locking algorithms or what options are available to him. Hadn't heard if read write locks. What are the pros or cons. Doesn't understand the difference between local locks and distributed fault tolerant locks. I explain it to him. He eventually comes up with a solution using zookeeper that will need zookeeper to process 1000s of updates per second. I give up. "DSA, what DSA? They are for kids. I will look up an algorithm when I need it".
- 5y ago

WalterBright 5y ago

Over and over, I see code written by star professionals that you've heard of, reinventing the bubble sort. I'm guilty of it myself. > It's a bit like saying it's silly for pilots to have to know what to do in the case of engine failure or stall from memory and regularly practice in a simulator, because that stuff rarely happens and most of the time they're just using autopilot. That's true, it usually doesn't matter, but when it does... it matters a lot. Well, we now know what happens when pilots forget the runaway stabilizer trim procedure (turn off the stab trim).

XorNot 5y ago
I mean this is also what happens when pilots aren't following their checklists though.
- WalterBright 5y ago
  Checklists in an emergency are the same idea as Dealer's Strategy in blackjack. If you've got nothing better, or are under so much stress you can't think, or don't have time to think, do Dealer's Strategy. But sometimes, pilots are needed to recognize when the checklist isn't going to work, and can innovate on the job. That's why we still have pilots on airplanes, as a computer can follow a checklist.
tubby12345 5y ago
if i need a toposort in my proprietary task scheduling system, or fisher–yates shuffle in my proprietary ranking system, what do you recommend? this isn't hypothetical - i've had these things come up in the last half at work.
- YZF 5y ago
  There ya go: https://www.boost.org/doc/libs/1_78_0/libs/graph/doc/topological_sort.html https://www.boost.org/doc/libs/1_78_0/libs/graph/doc/topolog...
  - tubby12345 5y ago

eropple 5y ago

> It's true that this stuff rarely comes up and often doesn't matter for most real-world applications... but when it does, it matters a lot. The difference between O(n2), O(n) and O(log n) is huge for big values of n. Being about to go straight to a (nearly) optimal solution, instead of hacking together something, waiting for it to burst a the seams, and then having to fix it... or being able to spot someone else doing that, can save weeks or months of development at a time. This is true, and absolutely matters. But I would suggest that developing the intuition to recognize a problem as being of a particular class, and even going further as to being able to look at the provided solution and intuit whether or not it is optimal (or optimal-enough), is a different thing than calling up that optimal algorithm from your limited brainspace. Like--if you understand the principles of what you're doing, Google isn't a much slower recall mechanism than you are, and it's less likely to have misremembered something.

capitalsigma 5y ago

Friendly reminder that O(2n) = O(n)

eternityforest 5y ago

Knowing that O(n2) is a problem and that an O(n) algorithm exists matters. But why do they have to know how to write that O(n) themselves? It's a quick easy test of understanding, but why not ask "How would you speed this up" and show them some O(n2) code?