5 ms·

This is nice list and ability to implement these algorithms certainly won't hurt. But I have to say that knowing these algorithms alone won't help you much dur

This is nice list and ability to implement these algorithms certainly won't hurt. But I have to say that knowing these algorithms alone won't help you much during job interview with smart employer like Google. The reason is simple but often overlooked by many people: the most important thing is not these algorithms themselves but ability to recognize them in problems. You may learn pretty quickly how these algorithms work and implemented but it may take years of practice to earn ability to recognize them. Google won't ask you directly to implement Dijkstra algorithm. They may give you a problem which on surface have nothing to do with graphs. It may take a while before you actually have a light-bulb/aha moment when you realize it's a graph problem. In practical non-interview problems, ability to recognize algorithms is much more important than knowing their implementation. You can always find their implementation on the Internet after all. This is why I'm trying hard to improve my problem solving skills by solving competitive programming problems almost everyday.

cle 10y ago
And then when you get the job, you will likely never use this skill again. 50% of your time will be spent on plumbing and wiring, 40% on meetings and politics and "agile processes", 9% on learning new ways to plumb and wire, and maybe 1% of your time will utilize these sorts of skills that can otherwise be identified from afar and solved by looking up in a book. Once you get your foot in the door, this sort of trivia becomes vastly less important than your ability to impress the right people and politically maneuver yourself into winning situations. This is the reality of life in a mega tech corp.
- snovv_crash 10y ago
  That, of course, depends where you work. My daily work is math intensive and performance critical. I constantly need to think about cache sizes, big-O scaling and that ever-important constant factor. I've seen commits failed by QA because they inadvertently added a shared_ptr copy in a tight loop, which affected performance of the entire pipeline by 20%. So yeah, I regularly have to think about dynamic programming, switching away from a linear low-constant algorithm once the problem is no longer small, how something could be restructured to be massively parrellizable, even alignment of arrays so that we get reasonable SIMD performance. Yes, these jobs exist, and yes, they do require a strong algorithms background, as well as a good understanding of memory heirarchy, branching delays and what can be offloaded to GPU or at least parallized.
  - hal9000xp 10y ago
    Your job sounds exciting! Do you work in gamedev? In which company you are working?
    - snovv_crash 10y ago
      Computer vision late-stage startup, 80+ people now I think, of which 50 are devs. Of course not everyone does what I do, we still need people to work on the UI and packaging/licences etc. But at least 50% of the devs here do very research-oriented work.
  - Silhouette 10y ago
    My daily work is math intensive and performance critical. I constantly need to think about cache sizes, big-O scaling and that ever-important constant factor. Me too, at least for some of the projects I'm working on, but it's probably fair to say that I've never used most of the "textbook algorithms" I've come across over the years in a production system. The interesting and challenging problems are mostly the ones that aren't just a direct application of such an algorithm. Consequently, I think the more valuable ability is recognising when a part of such a problem probably does have a standard solution, so you can spend a few minutes looking up the current state of the art. Obviously you still need enough familiarity with the theory in the areas you're working in for that recognition to work, and then to understand the current state of the art when you need it.
  - majormajor 10y ago
    > That, of course, depends where you work. Small correction: it depends on what problems you work on. There are people at top companies making big money working on complex problems, there are also people at those companies who passed through a super-algorithm-heavy interview and work on much less mathematically demanding code. And there are people at small companies you've never heard of working on much more intense problems than them. But the people doing boring work at big companies are often making $$$ compared to the people working at small companies working on interesting stuff. (I've been both of those people...)
  - threatofrain 10y ago
- a_imho 10y ago
  Software in a nutshell. The 'can you invert a binary tree' coming of age ritual one studies so hard for. You know it will happen before you step into the interview room and there's no escaping it, but you go in nevertheless.
- alkonaut 10y ago
  Avoid programming with databases and web servers and the plumbing and repetitive crud work can be minimized. Pick a math intensive and performance sensitive domain and interesting algorithmic problems like these pop up all the time.
- 1_2__3 10y ago
  Google doesn't use agile. Specifically to avoid the kind of nonsense you cite.
- ausjke 10y ago
  but you still need write them for interview purposes, it is the first step to filter out candidates, no matter how senior you are I think.
throwaway43 10y ago
I'm currently prepping for an interview at one of the Big 4. I can tell you that this site is quite useful. They have tons of problems to help you with the recognition part as well. You don't have to be a genius to be able to do these problems. It just comes down to pattern matching. That said I don't think this is the ideal way to interview people. However no one has as yet proposed a better alternative. I turned down an interview assignment recently because they wanted me to implement an app with : - Syncing to a database - UI Tests (with a mock API) - Unit tests - Functional reactive programming - A really complex architectural design pattern All this just to get a shot at the interview. I was too tired to do it at the time so I turned it down. So I would criticise programming interviews but I don't have a better alternative. Sane assignments are a reasonable middle ground (Perhaps they could have knocked off a few from the above list). So if you want to work at a top employer and not be forever stuck doing CRUD then your only option is to learn algorithms and practice interviewing. I know it sucks but that is how the game is played. The reason some people can do them is not because they're geniuses but they come from employers,schools where there is a culture of doing interview problems. They've been doing this for atleast a year if not more. So try doing them for a year and then tell me whether you still find them impossible. I realised this when I took the help of a champion competitive coder for preparation. It was hard to find a question typically asked in these interviews which he hadn't heard of in some shape or form. I have some tips I'm compiling which I might turn into a blogpost or book. For recognition you need to practice abstract thinking . Thinking of something in terms of code should be completely avoided. Suppose I ask you to find the common ancestor of two divs. In this case the DOM is a tree whose nodes have parent pointers. Turn every question into a mathematical abstract form. Find a k such that , Find two numbers x & y such that and so on. The next step is massive repetition. It feels like you're grinding with no understanding , but something happens when you repeat something 20+ times. Depending on how smart you are it happens sooner. Eventually it will become intuitive. Always learn multiple solutions. Never settle for just one answer. Learn all possible answers and how it might be possible to go from a brute force to the optimal one. Use Geeks4Geeks and Elements of Programming Interviews to build your pattern recognition. Next read books and PDFs by Udi Manber on algorithm design. http://akira.ruc.dk/~keld/teaching/CSS_e10/Manber88.pdf http://akira.ruc.dk/~keld/teaching/CSS_e10/Manber88.pdf This is a lot of effort. But that's just how it is. You don't HAVE to work at Google. You can work at other places and do quite well too. But if you want the top jobs then this the road you must take.
w1ntermute 10y ago
> You may learn pretty quickly how these algorithms work and implemented but it may take years of practice to earn ability to recognize them. This is false. Just as you can learn pretty quickly how the algorithms work, you can also pretty quickly learn how to recognize which one to use for a given problem - it's basic pattern recognition. The problem for most people isn't that they can't develop this pattern recognition skill, it's that they don't realize they need to (and instead focus on just learning how the algorithms work). A lot of the time when people say that you can't just "memorize" your way to passing a given test, they're just referring to situations where developing pattern recognition skills instead (or as well) will be more than sufficient. You can get pretty far in life by combining rapid memorization skills with the ability to rapidly develop pattern recognition for a new training set. The more types of inputs/outputs you can map between (muscular, visual, aural, etc.), the better.
soneca 10y ago
Is there any resource out there that links these algorithms to real world solutions?
ceronman 10y ago
> This is why I'm trying hard to improve my problem solving skills by solving competitive programming problems almost everyday. Here is another simple tip to improve your ability to recognize algorithms: Just look at the software you use every day and ask yourself how does it work. When you make a click on your web browser, how does the browser know what element you clicked? When you tell you StarCraft unit to move to a given point, how does the game engine know what path it should follow. Are you using a Redis cache with an LRU eviction policy, how does that work? Why it's so fast? (hint: it's not only because it's written in C) You know that adding indexes to your database columns makes them faster. Why? How does that work? What are the tradeoffs of the the different kinds of indexes. When you type `ls -R` in the console, what's happening? How is it that Google can give us the results of searching on trillions of webpages in just a fraction of a second? It's sad to see a general sentiment here on HN against algorithms and data structures. In reality, most of the tools we use everyday use all those algorithms and data structures. If you feel that you don't need to know about algorithms and data structures, you probably do very mechanic and simple things like CRUD software. The moment you do something slightly more difficult or at a bigger scale, you are going to need this knowledge. You simply can't be a good developer without understanding these concepts (I'm not saying that it's the only thing you need).

cle 10y ago

And then when you get the job, you will likely never use this skill again. 50% of your time will be spent on plumbing and wiring, 40% on meetings and politics and "agile processes", 9% on learning new ways to plumb and wire, and maybe 1% of your time will utilize these sorts of skills that can otherwise be identified from afar and solved by looking up in a book. Once you get your foot in the door, this sort of trivia becomes vastly less important than your ability to impress the right people and politically maneuver yourself into winning situations. This is the reality of life in a mega tech corp.

snovv_crash 10y ago
That, of course, depends where you work. My daily work is math intensive and performance critical. I constantly need to think about cache sizes, big-O scaling and that ever-important constant factor. I've seen commits failed by QA because they inadvertently added a shared_ptr copy in a tight loop, which affected performance of the entire pipeline by 20%. So yeah, I regularly have to think about dynamic programming, switching away from a linear low-constant algorithm once the problem is no longer small, how something could be restructured to be massively parrellizable, even alignment of arrays so that we get reasonable SIMD performance. Yes, these jobs exist, and yes, they do require a strong algorithms background, as well as a good understanding of memory heirarchy, branching delays and what can be offloaded to GPU or at least parallized.
- hal9000xp 10y ago
  Your job sounds exciting! Do you work in gamedev? In which company you are working?
  - snovv_crash 10y ago
    Computer vision late-stage startup, 80+ people now I think, of which 50 are devs. Of course not everyone does what I do, we still need people to work on the UI and packaging/licences etc. But at least 50% of the devs here do very research-oriented work.
- Silhouette 10y ago
  My daily work is math intensive and performance critical. I constantly need to think about cache sizes, big-O scaling and that ever-important constant factor. Me too, at least for some of the projects I'm working on, but it's probably fair to say that I've never used most of the "textbook algorithms" I've come across over the years in a production system. The interesting and challenging problems are mostly the ones that aren't just a direct application of such an algorithm. Consequently, I think the more valuable ability is recognising when a part of such a problem probably does have a standard solution, so you can spend a few minutes looking up the current state of the art. Obviously you still need enough familiarity with the theory in the areas you're working in for that recognition to work, and then to understand the current state of the art when you need it.
- majormajor 10y ago
  > That, of course, depends where you work. Small correction: it depends on what problems you work on. There are people at top companies making big money working on complex problems, there are also people at those companies who passed through a super-algorithm-heavy interview and work on much less mathematically demanding code. And there are people at small companies you've never heard of working on much more intense problems than them. But the people doing boring work at big companies are often making $$$ compared to the people working at small companies working on interesting stuff. (I've been both of those people...)
- threatofrain 10y ago
a_imho 10y ago
Software in a nutshell. The 'can you invert a binary tree' coming of age ritual one studies so hard for. You know it will happen before you step into the interview room and there's no escaping it, but you go in nevertheless.
alkonaut 10y ago
Avoid programming with databases and web servers and the plumbing and repetitive crud work can be minimized. Pick a math intensive and performance sensitive domain and interesting algorithmic problems like these pop up all the time.
1_2__3 10y ago
Google doesn't use agile. Specifically to avoid the kind of nonsense you cite.
ausjke 10y ago
but you still need write them for interview purposes, it is the first step to filter out candidates, no matter how senior you are I think.

throwaway43 10y ago

I'm currently prepping for an interview at one of the Big 4. I can tell you that this site is quite useful. They have tons of problems to help you with the recognition part as well. You don't have to be a genius to be able to do these problems. It just comes down to pattern matching. That said I don't think this is the ideal way to interview people. However no one has as yet proposed a better alternative. I turned down an interview assignment recently because they wanted me to implement an app with : - Syncing to a database - UI Tests (with a mock API) - Unit tests - Functional reactive programming - A really complex architectural design pattern All this just to get a shot at the interview. I was too tired to do it at the time so I turned it down. So I would criticise programming interviews but I don't have a better alternative. Sane assignments are a reasonable middle ground (Perhaps they could have knocked off a few from the above list). So if you want to work at a top employer and not be forever stuck doing CRUD then your only option is to learn algorithms and practice interviewing. I know it sucks but that is how the game is played. The reason some people can do them is not because they're geniuses but they come from employers,schools where there is a culture of doing interview problems. They've been doing this for atleast a year if not more. So try doing them for a year and then tell me whether you still find them impossible. I realised this when I took the help of a champion competitive coder for preparation. It was hard to find a question typically asked in these interviews which he hadn't heard of in some shape or form. I have some tips I'm compiling which I might turn into a blogpost or book. For recognition you need to practice abstract thinking . Thinking of something in terms of code should be completely avoided. Suppose I ask you to find the common ancestor of two divs. In this case the DOM is a tree whose nodes have parent pointers. Turn every question into a mathematical abstract form. Find a k such that , Find two numbers x & y such that and so on. The next step is massive repetition. It feels like you're grinding with no understanding , but something happens when you repeat something 20+ times. Depending on how smart you are it happens sooner. Eventually it will become intuitive. Always learn multiple solutions. Never settle for just one answer. Learn all possible answers and how it might be possible to go from a brute force to the optimal one. Use Geeks4Geeks and Elements of Programming Interviews to build your pattern recognition. Next read books and PDFs by Udi Manber on algorithm design. http://akira.ruc.dk/~keld/teaching/CSS_e10/Manber88.pdf http://akira.ruc.dk/~keld/teaching/CSS_e10/Manber88.pdf This is a lot of effort. But that's just how it is. You don't HAVE to work at Google. You can work at other places and do quite well too. But if you want the top jobs then this the road you must take.

w1ntermute 10y ago

> You may learn pretty quickly how these algorithms work and implemented but it may take years of practice to earn ability to recognize them. This is false. Just as you can learn pretty quickly how the algorithms work, you can also pretty quickly learn how to recognize which one to use for a given problem - it's basic pattern recognition. The problem for most people isn't that they can't develop this pattern recognition skill, it's that they don't realize they need to (and instead focus on just learning how the algorithms work). A lot of the time when people say that you can't just "memorize" your way to passing a given test, they're just referring to situations where developing pattern recognition skills instead (or as well) will be more than sufficient. You can get pretty far in life by combining rapid memorization skills with the ability to rapidly develop pattern recognition for a new training set. The more types of inputs/outputs you can map between (muscular, visual, aural, etc.), the better.

soneca 10y ago

Is there any resource out there that links these algorithms to real world solutions?

ceronman 10y ago

> This is why I'm trying hard to improve my problem solving skills by solving competitive programming problems almost everyday. Here is another simple tip to improve your ability to recognize algorithms: Just look at the software you use every day and ask yourself how does it work. When you make a click on your web browser, how does the browser know what element you clicked? When you tell you StarCraft unit to move to a given point, how does the game engine know what path it should follow. Are you using a Redis cache with an LRU eviction policy, how does that work? Why it's so fast? (hint: it's not only because it's written in C) You know that adding indexes to your database columns makes them faster. Why? How does that work? What are the tradeoffs of the the different kinds of indexes. When you type `ls -R` in the console, what's happening? How is it that Google can give us the results of searching on trillions of webpages in just a fraction of a second? It's sad to see a general sentiment here on HN against algorithms and data structures. In reality, most of the tools we use everyday use all those algorithms and data structures. If you feel that you don't need to know about algorithms and data structures, you probably do very mechanic and simple things like CRUD software. The moment you do something slightly more difficult or at a bigger scale, you are going to need this knowledge. You simply can't be a good developer without understanding these concepts (I'm not saying that it's the only thing you need).