6 ms·

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 a

by 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
      If you're a good middle aged engineer, you should have enough former coworkers happy to hire you that you don't need get on the leetcode treadmill.
    - joshuamorton 5y ago
      This is such a funny thing to read, because I see new L6 and 7 tech managers hired (above me) all the time. They're often middle aged people with kids. They don't bemoan this stuff (and yes, while they have fewer of them, they still need to solve a whiteboard problem or two to get hired)
      - disgruntledphd2 5y ago
        But you're seeing the outcome of a selection process. You might feel differently if you saw the top of the funnel.
        joshuamorton 5y ago
        In what way? If you mean that there might be management wizards who are just fantastic but we skip, perhaps. But that isn't the point I was making, just that despite what people think, these interviews don't actually filter out experienced people with families and kids. Those kinds of people get hired regularly.
        disgruntledphd2 5y ago
        Well you don't actually know that, because you don't know what the top of the funnel looks like. Consider a world where every L6+ manager candidate has a family and kids. However, only 5% of these can make time to do the LC stuff (revising most likely if they've been managing for a while). So your company will end up filtering out 95% of candidates immediately, but people in the company will say that there's no problem as all of the successful candidates have a family and kids, so it can't be biased. Don't get me wrong, I'm a fan of technical screening for managers, but I'm making the point that you can't look at the output of a funnel and conclude that everything's fine, you need to look at the complete funnel to understand this.
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

by YZF 5y ago

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
    If you're a good middle aged engineer, you should have enough former coworkers happy to hire you that you don't need get on the leetcode treadmill.
  - joshuamorton 5y ago
    This is such a funny thing to read, because I see new L6 and 7 tech managers hired (above me) all the time. They're often middle aged people with kids. They don't bemoan this stuff (and yes, while they have fewer of them, they still need to solve a whiteboard problem or two to get hired)
    - disgruntledphd2 5y ago
      But you're seeing the outcome of a selection process. You might feel differently if you saw the top of the funnel.
      - joshuamorton 5y ago
        In what way? If you mean that there might be management wizards who are just fantastic but we skip, perhaps. But that isn't the point I was making, just that despite what people think, these interviews don't actually filter out experienced people with families and kids. Those kinds of people get hired regularly.
        disgruntledphd2 5y ago
        Well you don't actually know that, because you don't know what the top of the funnel looks like. Consider a world where every L6+ manager candidate has a family and kids. However, only 5% of these can make time to do the LC stuff (revising most likely if they've been managing for a while). So your company will end up filtering out 95% of candidates immediately, but people in the company will say that there's no problem as all of the successful candidates have a family and kids, so it can't be biased. Don't get me wrong, I'm a fan of technical screening for managers, but I'm making the point that you can't look at the output of a funnel and conclude that everything's fine, you need to look at the complete funnel to understand this.

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