It feels like there are two separate questions here, I'll try to address both: 1. How to remember how code you wrote a long time ago works As you mention, doc

It feels like there are two separate questions here, I'll try to address both: 1. How to remember how code you wrote a long time ago works As you mention, documentation is key. It honestly doesn't have to be super proper docs where you end up with 5x more documentation than code. Even just a couple comments here and there, especially on code that was tricky to figure out, will be super helpful in the future. It also helps to have consistent naming and organization conventions - not just capitalization or underscores but the words you choose to name certain things and the pattern in which you modularize code. This is useful for avoiding accidental rewrites of code you wrote in the past and helps you navigate the codebase. It's always nice to think something like "hmm, I don't remember where the rest of this is but I probably would've called this ScreenManager" and then find out you really did have a ScreenManager file. Realistically, you're always going to be forgetting old code. The key is to structure your code in such a way that it's easy to "explore" if you ever need to dig up an implementation detail or add some new functionality. If you have more logically complex code, keep at least single-liner comments that lay out what's going on. Get used to IDE commands you have like "Go to definition" - even if you've forgotten, most of them time you'll be able to refresh yourself after seeing all the relevant code. 2. How to explain a codebase you haven't worked with in a while to an interviewer In my experience, you typically will not need to actually explain specific code to an interviewer. You don't need to say, "well I used a HashMap for this and then a LinkedList for that". What you do need to explain is concepts that you implemented, like "the clients established websocket connections to the servers to get real-time updates in the form of a byte stream". I find that large projects can generally be broken down into a set of interesting features. You can keep track of these features in a separate file and just list one or two things about how they were implemented, and refresh yourself before an interview. --- tl;dr (I know I tend to get rambly) - leave single-line comments as often as possible - hop around your codebase with go-to definition when you forget how things work - keep a list of features you implement for each project for interview prep