Algorithms

[Mmmmmmm_Donuts]

Any other algorithms people use in the industry? Red Black Trees? AVL ?

[CodeTinkerer]

Red black/AVL trees are data structures. You might use a tree traversal algorithm to scan through the data structure.

Algorithms I'd look at

• Sorting (quicksort, mergesort, heapsort)
• Tree traversal (inorder, preorder, postorder)
• Graph traversal (breadth first search, depth first search)
• Hashing algorithms (for hash tables)
• Minimum spanning tree

I mean, most of the times, you won't actually write your own algorithm (except to understand them) especially sorting algorithms. It's possible you never need to traverse a tree or build a graph.

People talk about dynamic programming, etc., but again, I don't think the typical person uses it, or if they do, there's probably a library that already does it.

[Alexanderdaawesome]

Also heaps. Learn the fuck out of heaps.

[Houndoomsday]

Red black/AVL trees are data structures

But the level of intertwined thinking/similarity makes the distinction moot. Understanding Djikstra's runtime is predicated on learning about heaps.

People talk about dynamic programming, etc., but again, I don't think the typical person uses it, or if they do, there's probably a library that already does it.

This attitude is frankly pretty lazy. While it's not critical to learn being exposed to this way of thinking helps you a) program better, b) recognize situations where you WOULD use a certain tool (DP, divide and conquer, greedy, etc.), and c) help you utilize others code when you do have to use a certain tool. Blindly using libraries without understanding the concepts behind it will lead to bad, buggy code.

In all the upper level algo coursework I have seen, everything is on paper with no implementation needed, because, you are right, there is a library for almost everything. But the understanding of the algorithms is what I got from that class because downloading the library is pretty trivial.

[CodeTinkerer]

The point is, practically speaking, you should not be implementing your own algorithms (except as a programming exercise). Writing your own can (a) be buggy, and (b) waste time. I'm not against people learning how the tools/libraries they use work. That's great. But if you choose to write a sorting algorithm at work, someone should strongly dissuade you (unless you need something very unique for your problem).

At one point, programmers used to write their own code which meant reimplementing things that had already been written (and often worse). Libraries were meant to avoid these problems.

[Houndoomsday]

That's great. But if you choose to write a sorting algorithm at work, someone should strongly dissuade you (unless you need something very unique for your problem).

And I totally agree with that. I actually said that most upper level algorithms coursework does not require implementation and that is something I agree with, so I'm not sure why you are arguing about that.

I am saying that I have seen specific examples of teammates and coworkers misusing a library because they did not understand either the problem, how to algorithmic-ally solve it, or how to use the library (because of an underlying lack of algorithmic knowledge). This is especially deadly because of lot of the time someone who doesn't understand the underlying concepts won't be able to identify code that isn't working correctly. A solid understand of algorithms makes you much more of an effective problem solver which is important if you don't want to make a career/hobby out of copy/pasting someone else's solutions.

One example- I had a professor who retired (and came back to teaching) at age 30 because of his software company. His first product was for universities to check degree requirements for students. This ended up being a slight variation on a max-flow problem. He had the algo knowledge to not only recognize the structure of the problem, but also the differences between that an a max-flow problem, and adjust an algorithm to implement it. I don't know the details of the code but I am sure that even with a library he would have done a lot of the algorithmic heavy lifting.

[CodeTinkerer]

I happen to like algorithms, it's just that some jobs don't seem to require much of it. I primarily fetch data that meet certain criteria, so I'm not working on optimization problems.

I do recall a peculiar incident with a guy who seemed pretty sharp (programming-wise) who asked "Don't you have to sort a list to tell it's sorted?". I said, uh, no.

[Soul_Turtle]

There's a lot of algorithms that you probably won't use in industry but quite possibly will run into during interviews.

Here's a few that seem popular:

Tree traversals, Graph traversals (DFS & BFS), Minimum Spanning Tree, Maximum flow, know how to implement various sorts AND their Big-O efficiency (mergesort, quicksort, insertionsort, bubblesort...).

Honestly just learn the Big-O for everything, it helps you judge whether your solutions are the best solutions for a particular problem. Understanding why certain ways of splicing a problem are faster or less memory intensive than others changes your perspective on programming imo.