List all kinds of shoes. List all available shoe color. Give statistics for the number of each available combination that X number of women has.
1. Consider the options. Laying down all the cards can waste time at first glance, but it can surely save much more time in the end.
Option A: Is the number of kinds of shoes more than the number of women involved? Are there more shoes and shoe colors than the number of women involved?
Option B: Will it be easier to just get the list of kinds of shoes followed by the available colors?
2. Consider the variability and flexibility. If you fix your solution to your current scenario, it might blow up and become out of hand.
Option C: Are the number of kinds of shoes fixed over a period of time? How about the colors?
Option D: Is your subject group (the number of women) going to be fixed for the study?
3. Consider the beauty and simplicity. If you are to design a program or a script, make sure its always minimal. To achieve this, always try to refactor.
Option E: Would you use a loop?
Option F: Or statically deliver the statistics?
4. Consider the resources. If you plan to scale it bigger, then use the minimal resources but with greater flexibility and power.
Option G: Would you rather use a text based database?
Option H: Or an object relational one?
5. Consider maintenance. If you thought this wouldn't be in the list, then you can't call yourself a programmer. Everybody needs to cleanup their mess before leaving the room, and this is it.
Option I: Do you plan to give your client full responsibility afterwards?
Option J: Or you'd rather take part til the end?
Hmmm… but this is just the beginning. This is how you should think before delivering verdict to your code. And note, this is only a 15minute exercise. How about you? Do you think well?