[sbov]

Different people are going to have a different answer to your question, but here's how I approach things:

You should commit things to memory the things your memory naturally keeps. If it doesn't it means you aren't using it often enough to bother remembering it. There's so much information I used to keep re-learning and forgetting because I never used it. I finally realized that it was a waste of time.

I guess the problem is when the job you're interviewing for will need vastly (or slightly) different things committed to memory than what your current job does.

I also like something between google and memory: cheatsheets. I have a dev notebook full of checklists and cheatsheets for various technologies I've used and tasks I've done.

[UniZero]

As a self-taught developer, I have reached the same conclusion regarding memorization. I find your concept of 'cheatsheets' inspiring, and would love to know more about how you organize that kind of information.

[sbov]

I used to just use text files. Now I stick everything in Evernote. Text files are good enough though.

Organization is pretty simple. Just need a decently named file with the relevant information. E.g. I would have an sql.txt file containing sql database operations that I don't use often enough to remember, but use often enough to be annoyed by having to search the web on how to do them.

Another example might be a centos5.txt file, giving me a quick rundown of the various setup options I've wanted in the past, and the location of various configuration files.

For programming languages, there's many that I use maybe once every 3 or 4 months. So ruby.txt might contain a quick rundown of how to do basic things: how to define a function, a class, perform loops, instantiate an object, access command line arguments, etc. I find it much better than having to hunt down a tutorial which will also be more wordy than needed.

I also have some for more computer science related things, such as tables of graph and search algorithms, along with their tradeoffs.

Checklists are another good thing. I have checklists for processes I've messed up.

E.g. committing new code. If I don't use my checklist, I always seem forget to forget to update a sample file. Or add a file.

Another big checklist is for giving estimates. For example, one of our legacy products is translated into 5 languages. This checklist reminds me to think of translations, because they have been a huge bottleneck in the past.

Hope that helps some.

[girvo]

Everything you've said is exactly what I do, and it works brilliantly for me, despite being self-taught :)