6 ms·

I genuinely want to know where people use these algorithms in their code. I'm a non CS dev to begin with so may be I don't know where to use them since I didn't

I genuinely want to know where people use these algorithms in their code. I'm a non CS dev to begin with so may be I don't know where to use them since I didn't get formal CS education. This way of interviewing is not what I prefer. I have been told I write better code than my CS grad peers but I have no clue about these algorithms and data structures. What do you guys think about this form of interview?

anomk5050 10y ago
Do you really find you can ignore data structures and algorithms in your work (and if so, what sort of work do you do)?
- hibikir 10y ago
  Let's look at it in a different way: I have a CS education, and have worked professionally since the 90s. In my resume there's things like: - A code generator that took as input sources - High performance RMI libraries for a phone company - A entire retail system, from POS, to warehousing, reporting and PCI-DSS compliant key exchange systems - Distributed systems that coordinate work between thousands of nodes - A machine learning project that was recently mention in HN. - Migrated most computing in a fortune 50 company to the cloud There are far more storied careers than mine in HN, but this is not a career of someone that spent their days writing CRUD apps in visual basic: I worked on fun things. Some of that worked involved algorithms: many of them very complicated. However, since I left school, other than in interviews, I never had to touch a high percentage of the algorithms in that page. Let me go a section at a time: - I have used graphs plenty of times, but I can't recall using any of those algorithms directly. Yes, not even BFS. - I had to do linked list-like operations when I was writing in C at the beginning of my career. Not a single time since. - Zero dynamic programming. Nada. - Not a single manual sort algorithm, not a single manual search algorithm. - There's been plenty of trees, but none of the operations covered there. They were either provided by the libraries underneath, or never came up. - Number theory? Nothing from that list. I have implemented HyperLogLog though. Just don't ask me to do it from memory. -Early in my career I had to deal with some bit manipulation. I've not had to touch it in years. -Not a single one of those string/array manipulation ops So my answer to the grandparent is that you can have a long, fun, not CRUD app career doing fun things without having to implement those algorithms once, because they are done for you. The algorithms those jobs need in practice are often harder, but you don't have to have them memorized: Some you go look for papers that solve your problems, others you develop yourself (and be afraid of that one, as I have seen a mathematician come up with a 5 page proof for an algorithm that only did what we needed in a parallel universe where latency is zero) What almost every professional programmer has to understand what an array, a list, a set, a tree and a map are, and to go check the performance problems of specific implementations if it matters at the time. Almost every other interesting thing I have done was only relevant a small percentage of the time, and I could look up. Interviews ask the questions they do because they match what is taught in a small subset of CS classes. We could teach other algorithms in those: Some of the ones I had to use would fit in said classes, instead of the ones we have. They can be implemented in under an hour too. However, nobody asks for them in interviews, because the people that come up with interview questions haven't solved them before. So my point is not that you can ignore data structures and algorithms: You'll use some no matter what. But there is no subset of algorithms harder than a loop that every programmer uses in a regular basis, or data structures that we manually implement. We just ask for things that come from those same CS classes because we have no idea of how to assess if someone is any good, and the algorithm classes were some of the harder ones in college, so we assume that if you have them memorized, you must be pretty good. And we assume wrong.
  - emodendroket 10y ago
    I feel like recursively descending some object isn't some obscure thing and there is DFS for you.
- andrewvijay 10y ago
  Im a frontend dev by day. Golang/rust by night where Im in the need of learning DS/Algo anyway.
- alkonaut 10y ago
  It's enough to know the existence and properties (benefits, drawbacks, running time, memory use) and to be able to recognize when to use a specific algorithm or data structure. I have no use for a candidate that can implement every sort algorithm on a whiteboard. What I want is a candidate that can identify problems and identify the required algorithms. So I want someone who says "this is analogous a dynamic convex hull problem" or "this can be solved greedily by branch and bound" etc. That knowledge has to be learned it can't be Googled. Mergesort or an A* implementation is googleable once you know you need them (which was the important bit).
jupiter90000 10y ago
All other things being equal, someone who understands these algorithms/data structures and how/when to use them would be preferred over someone who hasn't put time in to get familiarized with them. I think in many positions it probably isn't necessary to have knowledge of how to implement from scratch -- yet again, if the company could find someone that gets it, they may produce overall more efficient solutions. Whether that matters to the company or not is another story -- but things like finishing some scheduled task in 10secs instead of 2hrs can be really useful. I used to have a mindset like "these algorithm quizzes are BS!" Yet when I have learned more about them, it is amazing to see how inefficient things can be produced, without the foundational knowledge to process/store things efficiently EDIT: All that being said, I think the usual software engineer interview format is terrible. It's like an intellectual hazing gauntlet or something..
- ubernostrum 10y ago
  All other things being equal, someone who understands these algorithms/data structures and how/when to use them would be preferred over someone who hasn't put time in to get familiarized with them. Correction: all other things being equal, the person who does better on an algorithms/data structures pop quiz is more likely to be a recent college graduate who you can pay less and treat worse than an established developer who's forgotten most of this stuff and just looks it up when/as needed.
  - jupiter90000 10y ago
    In terms of simply getting hired/passed the interview, yes, either a recent grad or someone having studied the algorithms prior to the interviews will probably do best. I won't argue it's annoying to study for an interview. I still think someone who understands these and has studied them will be in better shape to understand when/how to use such things in situations on the job (even if they can't be reproduced in a pop quiz scenario by the person). Maybe those situations will matter to the company, and maybe they won't.
    - ubernostrum 10y ago
leonroy 10y ago
I've been a team lead and head geek for a small software company for a good number of years. I'd say that these questions matter a lot more than you'd think. Using the wrong data structure or a data structure in the wrong scenario can make the difference between an application which can serve 1000 users per node or 100. That impacts the number of servers we recommend deploying in our cluster and in turn the hardware and maintenance costs for a customer buying a license for our software. An understanding of Big-O and algos is very important and any good software eng or team lead should refresh themselves on the topics regularly since these really can make the difference between a performant app and one which brings the host device to its knees.
- abstractbeliefs 10y ago
  So really you're saying that actually you don't need to be able to implement these off-the-cuff, but you should understand big-O and based on the sort of data you have, pick the best algorithm from a table like this one: http://bigocheatsheet.com/ http://bigocheatsheet.com/ ?
  - burntsushi 10y ago
    Eh. I wouldn't put it that way. I'd say you need enough experience to know what you don't know. Which is hard and will vary based on the problem you're trying to solve. A simple cheat sheet won't be enough.
- amorphid 10y ago
  Do you really use Big-O at work? I don't know if I've ever heard it brought up outside of an interview. In my experience, when something is slow, people notice and start complaining about it. "Why does it take 30 seconds to complete this seemingly simple request? Oh, it's making a database call for every element in the list, vs. efficiently sending a single request. I fixed it, and pull request submitted." "What is this script taking so long? Oh, exec is being called on every command, so let's just pull that out and put it in a wrapper script." "What performance tweak can we use to make this Rails app hellza faster, since we've maxed out low hanging fruit caching options? Rewriting this part in Elixir takes advantage of concurrency in a way that Ruby can't do all that well." I guess real world discussions don't seem to incorporate Big O lingo.
crdoconnor 10y ago
You typically don't. This form of interviewing is cargo culting Google's interview process.
psyc 10y ago
As a working developer for 20 years, the majority spent at Microsoft, I'd say that I have to understand data structures and algorithms in general, but I certainly do not need to know how to implement the ones that have names.
Swizec 10y ago
Sometimes just moving a .find into a precomputed hashmap can be the difference between O(n^3) and O(n). The difference is important with n as low as 100. It's that intuition which is valuable, not the implementing of algorithms by name.
mavelikara 10y ago
> I have been told I write better code than my CS grad peers but I have no clue about these algorithms and data structures. For a programer in the industry, the ability to write simple "legible" code is very important. An ideal interview process should spend some time evaluating those skills of a candidate - but this is very very hard to measure. But good familiarity with the basics of CS is also important to be able to perform many of these jobs. Here is a good blog post about this form of interview and the rationale behind it: http://www.goodmath.org/blog/2015/11/19/technical-interviews-more-than-a-brain-teaser/ http://www.goodmath.org/blog/2015/11/19/technical-interviews...
UncleMeat 10y ago
Engineer at one of the big four here. These specific algorithms don't necessarily come up all the time but my work would be impossible without strong algorithmic background. Is it better to use BDDs or Radix Trees to store abstract program state? What is the most efficient iteration strategy for computing fixed points? If I can't give a good answer to these questions then in all likelihood my system will never terminate.

anomk5050 10y ago

Do you really find you can ignore data structures and algorithms in your work (and if so, what sort of work do you do)?

hibikir 10y ago
Let's look at it in a different way: I have a CS education, and have worked professionally since the 90s. In my resume there's things like: - A code generator that took as input sources - High performance RMI libraries for a phone company - A entire retail system, from POS, to warehousing, reporting and PCI-DSS compliant key exchange systems - Distributed systems that coordinate work between thousands of nodes - A machine learning project that was recently mention in HN. - Migrated most computing in a fortune 50 company to the cloud There are far more storied careers than mine in HN, but this is not a career of someone that spent their days writing CRUD apps in visual basic: I worked on fun things. Some of that worked involved algorithms: many of them very complicated. However, since I left school, other than in interviews, I never had to touch a high percentage of the algorithms in that page. Let me go a section at a time: - I have used graphs plenty of times, but I can't recall using any of those algorithms directly. Yes, not even BFS. - I had to do linked list-like operations when I was writing in C at the beginning of my career. Not a single time since. - Zero dynamic programming. Nada. - Not a single manual sort algorithm, not a single manual search algorithm. - There's been plenty of trees, but none of the operations covered there. They were either provided by the libraries underneath, or never came up. - Number theory? Nothing from that list. I have implemented HyperLogLog though. Just don't ask me to do it from memory. -Early in my career I had to deal with some bit manipulation. I've not had to touch it in years. -Not a single one of those string/array manipulation ops So my answer to the grandparent is that you can have a long, fun, not CRUD app career doing fun things without having to implement those algorithms once, because they are done for you. The algorithms those jobs need in practice are often harder, but you don't have to have them memorized: Some you go look for papers that solve your problems, others you develop yourself (and be afraid of that one, as I have seen a mathematician come up with a 5 page proof for an algorithm that only did what we needed in a parallel universe where latency is zero) What almost every professional programmer has to understand what an array, a list, a set, a tree and a map are, and to go check the performance problems of specific implementations if it matters at the time. Almost every other interesting thing I have done was only relevant a small percentage of the time, and I could look up. Interviews ask the questions they do because they match what is taught in a small subset of CS classes. We could teach other algorithms in those: Some of the ones I had to use would fit in said classes, instead of the ones we have. They can be implemented in under an hour too. However, nobody asks for them in interviews, because the people that come up with interview questions haven't solved them before. So my point is not that you can ignore data structures and algorithms: You'll use some no matter what. But there is no subset of algorithms harder than a loop that every programmer uses in a regular basis, or data structures that we manually implement. We just ask for things that come from those same CS classes because we have no idea of how to assess if someone is any good, and the algorithm classes were some of the harder ones in college, so we assume that if you have them memorized, you must be pretty good. And we assume wrong.
- emodendroket 10y ago
  I feel like recursively descending some object isn't some obscure thing and there is DFS for you.
andrewvijay 10y ago
Im a frontend dev by day. Golang/rust by night where Im in the need of learning DS/Algo anyway.
alkonaut 10y ago
It's enough to know the existence and properties (benefits, drawbacks, running time, memory use) and to be able to recognize when to use a specific algorithm or data structure. I have no use for a candidate that can implement every sort algorithm on a whiteboard. What I want is a candidate that can identify problems and identify the required algorithms. So I want someone who says "this is analogous a dynamic convex hull problem" or "this can be solved greedily by branch and bound" etc. That knowledge has to be learned it can't be Googled. Mergesort or an A* implementation is googleable once you know you need them (which was the important bit).

jupiter90000 10y ago

All other things being equal, someone who understands these algorithms/data structures and how/when to use them would be preferred over someone who hasn't put time in to get familiarized with them. I think in many positions it probably isn't necessary to have knowledge of how to implement from scratch -- yet again, if the company could find someone that gets it, they may produce overall more efficient solutions. Whether that matters to the company or not is another story -- but things like finishing some scheduled task in 10secs instead of 2hrs can be really useful. I used to have a mindset like "these algorithm quizzes are BS!" Yet when I have learned more about them, it is amazing to see how inefficient things can be produced, without the foundational knowledge to process/store things efficiently EDIT: All that being said, I think the usual software engineer interview format is terrible. It's like an intellectual hazing gauntlet or something..

ubernostrum 10y ago
All other things being equal, someone who understands these algorithms/data structures and how/when to use them would be preferred over someone who hasn't put time in to get familiarized with them. Correction: all other things being equal, the person who does better on an algorithms/data structures pop quiz is more likely to be a recent college graduate who you can pay less and treat worse than an established developer who's forgotten most of this stuff and just looks it up when/as needed.
- jupiter90000 10y ago
  In terms of simply getting hired/passed the interview, yes, either a recent grad or someone having studied the algorithms prior to the interviews will probably do best. I won't argue it's annoying to study for an interview. I still think someone who understands these and has studied them will be in better shape to understand when/how to use such things in situations on the job (even if they can't be reproduced in a pop quiz scenario by the person). Maybe those situations will matter to the company, and maybe they won't.
  - ubernostrum 10y ago

leonroy 10y ago

I've been a team lead and head geek for a small software company for a good number of years. I'd say that these questions matter a lot more than you'd think. Using the wrong data structure or a data structure in the wrong scenario can make the difference between an application which can serve 1000 users per node or 100. That impacts the number of servers we recommend deploying in our cluster and in turn the hardware and maintenance costs for a customer buying a license for our software. An understanding of Big-O and algos is very important and any good software eng or team lead should refresh themselves on the topics regularly since these really can make the difference between a performant app and one which brings the host device to its knees.

abstractbeliefs 10y ago
So really you're saying that actually you don't need to be able to implement these off-the-cuff, but you should understand big-O and based on the sort of data you have, pick the best algorithm from a table like this one: http://bigocheatsheet.com/ http://bigocheatsheet.com/ ?
- burntsushi 10y ago
  Eh. I wouldn't put it that way. I'd say you need enough experience to know what you don't know. Which is hard and will vary based on the problem you're trying to solve. A simple cheat sheet won't be enough.
amorphid 10y ago
Do you really use Big-O at work? I don't know if I've ever heard it brought up outside of an interview. In my experience, when something is slow, people notice and start complaining about it. "Why does it take 30 seconds to complete this seemingly simple request? Oh, it's making a database call for every element in the list, vs. efficiently sending a single request. I fixed it, and pull request submitted." "What is this script taking so long? Oh, exec is being called on every command, so let's just pull that out and put it in a wrapper script." "What performance tweak can we use to make this Rails app hellza faster, since we've maxed out low hanging fruit caching options? Rewriting this part in Elixir takes advantage of concurrency in a way that Ruby can't do all that well." I guess real world discussions don't seem to incorporate Big O lingo.

crdoconnor 10y ago

You typically don't. This form of interviewing is cargo culting Google's interview process.

psyc 10y ago

As a working developer for 20 years, the majority spent at Microsoft, I'd say that I have to understand data structures and algorithms in general, but I certainly do not need to know how to implement the ones that have names.

Swizec 10y ago

Sometimes just moving a .find into a precomputed hashmap can be the difference between O(n^3) and O(n). The difference is important with n as low as 100. It's that intuition which is valuable, not the implementing of algorithms by name.

mavelikara 10y ago

> I have been told I write better code than my CS grad peers but I have no clue about these algorithms and data structures. For a programer in the industry, the ability to write simple "legible" code is very important. An ideal interview process should spend some time evaluating those skills of a candidate - but this is very very hard to measure. But good familiarity with the basics of CS is also important to be able to perform many of these jobs. Here is a good blog post about this form of interview and the rationale behind it: http://www.goodmath.org/blog/2015/11/19/technical-interviews-more-than-a-brain-teaser/ http://www.goodmath.org/blog/2015/11/19/technical-interviews...

UncleMeat 10y ago

Engineer at one of the big four here. These specific algorithms don't necessarily come up all the time but my work would be impossible without strong algorithmic background. Is it better to use BDDs or Radix Trees to store abstract program state? What is the most efficient iteration strategy for computing fixed points? If I can't give a good answer to these questions then in all likelihood my system will never terminate.