[dnackoul]

I like to think about this question in three parts: scope, depth, and originality.

The scope of the project is the size and ambiguity level. Ideally as you get more experience your scope grows. Whenever you're coming out of school, your answer to this question might be a tricky bug fix but after a few years it might be something like "we needed to build a system to flag and filter fraudulent users based on their site activity."

Depth is about how much detail you can talk about the project in. If you choose a project with a big scope, can you drill down and talk about the implementation details of each component? If you chose a bug fix, can you describe exactly what triggered the bug as opposed to just knowing what fixed it?

For originality, what about the problem made it non-trivial to solve with out of the box tools? For the fraud case above, maybe the data was stored in a format that was hard to analyze. Or maybe for people at the bigger companies there were scaling issues that requipped unique solutions. For bug fixing, maybe it was a bug that was really hard to reproduce and you had to do a lot of memory dumps and code analysis to pinpoint it.

When I finish something I like to think about it along those three axes for a little bit in case I need to recall details later.