That's interesting because I often think I do some programming in a trance like state. I don't write out giant steps, I sit there with headphones (to block out

That's interesting because I often think I do some programming in a trance like state. I don't write out giant steps, I sit there with headphones (to block out my stupid open office noise) and just keep working on something. I think the answer to your problem is not that complicated. First, add comments. Describe what you are trying to accomplish, and then the algorithm, and put a few notes throughout your code. You should be developing big projects in components and test the boundaries. For interviewing, you have to go back and study what you did. For your case, I suggest spending half an hour writing up a bullet point list of what you did after you finish a big project. You shouldn't write about any proprietary or internal algorithms about your company, but you can write a short list of the problem you solved (merging a large number of sorted runs with limited memory and xyz...), problems you faced (memory leak, or speed wasn't fast enough so you ...). Study a few of these as you move around jobs.