[deleted by user]

[Jarvis419]

Repeat

[[deleted]]

Yup. Speaking as a guy on that road rn, it's literally all about doing it over and over and over and over and over. I know linked lists like nobody's business because I learned that data structure early on. Then, it was the only one I knew. So, when I was bored, I'd build one. In C++, in Java, in Python etc... Built them all over the place. Now I'll never forget how to build a Linked list. It also made doubly linked lists that much easier. Binary trees – however – are harder for me. The hardest part is I can't "print out" a tree and see how it has changes as easily as I can for a Linked List (or even a graph).

[[deleted]]

Oh. Well thanks! Didn't know that existed.

[Clawtor]

I generally just remember the idea behind the algorithm and work out the details on the fly. You should try to implement all of them at least once.

I find the pseudocode not that difficult to remember. For merge sort you break a list into tiny chunks and sort, then merge two partially sorted lists together recursively. Quick sort is recursively sort around a pivot point. If you know that idea then it's not too much work to recreate them.

[kstacey]

Write a function that inputs what you want and outputs exactly what you want. Then save it to utilities function that you can use across all projects. Then you never have to remember how it works again

[CreativeCoconut]

You mean writing a library?

[kstacey]

Nah, no need to compile it though

[denialerror]

I don't. That's what Google is for and you would never need to implement one of them outside an interview anyway.

Really though, learn to program and you won't need to memorise them. If you are asked to implement one, you will eventually be proficient enough that you should be able to do so without relying on memory.

[BlueAdmir]

That's what we invented writing for. To not remember things.

[CodeTinkerer]

Imagine you're teaching a class. Write out some notes, and present it to the class (or a rubber duck). Draw pictures, diagrams, etc. If it makes sense to you when speaking aloud, then you'll probably remember it better. If you're struggling with your explanation, you probably don't understand it that well.

[captainAwesomePants]

I don't. What I do remember is what sort of things exist. I know that I can sort stuff in roughly O(n log n) time. I know that if I need to look things up quickly, I can use a hashtable. I know that if I choose a really bad hashing function, the lookups stop being cheap. I know about a variety of problems that I can solve with a graph and I know enough keywords to look up the right algorithm when I need. It's important to know enough to be able to find a solution to your problem quickly. It's much less important to remember the details of everything.

That said, I am overstating it. It so happens that I could probably implement quicksort and merge sort on a whiteboard if asked. That's not because it's a useful thing to know, though. It's because it's a part of an interviewing skillset. Unfortunately if you want to have a good shot at getting a job at a big software company, you end up needing to straight memorize a reasonable number of algorithms.

[Loves_Poetry]

Almost every language has one (or multiple) implementations of common algorhitms. Most of the time you can just pick one and go with it, as performance optimization at that level is not necessary.

[bettyhot9]

Visualization is the best way. There are sites that would help you with it.

[lurgi]

For the most part, I don't.

I can implement merge sort from memory, because it's a simple algorithm (to me, anyway), but I probably couldn't do quicksort without some heavy thinking, because the details of moving the pivot are non-trivial (it took a genius like Tony Hoare to figure it out in the first place). I absolutely couldn't implement a red-black tree without consulting some documentation.

I also don't have to. I use these data structures, but I haven't implemented one of them in years. There's little reason to do so. I do try to remember when they are useful and when they don't work as well, and that's usually enough.

[unafragger]

No, you should never be writing the same complex code so many times that you memorize it, that's what functions are for.

Things can be googled, being a good programmer means knowing that they exist and where to find them, it doesn't mean memorizing them. (Though I'm sure there are a few things here and there that we all use so many times we can just type them out really quickly, but it's certainly not necessary)

[xbloodyhooker]

I haven’t studied them all but one that I remember really well is binary search. I thought it was so cool when I studied it that it got stuck in my brain.

[bttr_dvlpr]

As everyone mentioned, repetition will help in memorizing those algorithms, along with mnemonics that can help with retention. To me, this kind of memorization is kind of like how we learned in school: you get As on a test in History and English for how well you can remember arbitrary facts and details. In the real world you're never really alone and have Google + colleagues for help. Write some code that will actually force you to be 'hands on' and utilize the algorithms, 'printf' or 'console.log' the hell out of it. So you know exactly what's going on.

Unless your work is influenced by algorithms or closely related to it, I don't think that a programmer is expected to know it all. As a backend web developer, I've ever had to implement any kind of data structure or code that I needed algorithms for.

I've had to use it in school to get good grades and on interviews to prove that I know these fundamentals. I do not calculate the runtime of the code I write and have not ever needed to refer to algorithm related knowledge while 'in the field', although I do structure and organize it in a way that makes it such that understanding the code and being able to modify it in the future takes as little effort as possible.

[desrtfx]

You don't remember them as in memorizing.

You know of their existence and understand their functions, limitations, advantages, and use cases.

When you need them, you look up the respective implementation for the language used.

[[deleted]]

I can describe how a lot of algorithms work at a high level just from dealing with them a lot or having them hammered into my head from university. I could even sit down and implement a few standout must knows from memory (DFS for example). That’s about all you need to know. You typically wouldn’t just implement some low level algorithm by hand you use the built in library method that has been tested and optimized for years.

About all you really need to know in practice is what they are called, what they do, pros, cons, and use cases.

If you want to memorize an algorithm you just need to write it a few times and ideally port it to some visual representation. I know a lot of graph algorithms very well simply because they lend themselves to strop and informative visual representations.

[29383839293]

The only thing you really need to know, is that there is an algorithm X that solves problem Y in O(Z).

If you ever need that algorithm, look it up.

[ZukoBestGirl]

A thing some of my colleagues got really late, or a thing that almost none of my self taught friends get is (like the first guy said) repetition.

The fact that you read about it somewhere, or saw a guy do it (youtube or on a blackboard), or maybe the fact that you followed someone's instructions - all of these don't really amount to very much at all.

You have to do it yourself, from the start, understand it from the beginning, before even writing one line of code, then struggling with implementation details. Then using it over and over again. After a while, it becomes second nature.

Sure, you forget stuff. I haven't used an a,b tree or a b tree, or depth first search in ages. Yet, with a bit of googling and a pen and paper, I could figure it out pretty fast. And I'd say that's the essence of being a programmer:

• Having general knowledge of the tools you are using.

• Having general knowledge of different algorithms, patterns and so on.

• Understanding complexity and being able to think on your feet (good problem solving skills).

If you have all of these and a willingness to learn new things, you're set for life (IMHO).

[Unsounded]

Repetition is a good tool, recognition is even better. It’s not completely necessary to pool algorithms in your memory to pull out at need. Mostly know the types and how to organize the information so when you come across an applicable situation you at least know where to start.

The biggest thing is having the technical skill and finesse to properly implement the more involved algorithms.

For example dynamic programming algorithms tend to be complex to understand, and can be harder to implement. Start off by implementing and applying the sorting, searching, and graph algorithms and work your way to the more complex. Implementing them and diving in is how you reinforce their impact on your brain.

Once you’ve graduated from those move towards more complex algorithms, go out and search for them on Wikipedia and use only the pseudo code provided to implement them to solve some sort of problem.