3 ms·

I do quite a few interview each week, and one of our problems highlight the differences in these two approaches quite clearly. Inevitably, those candidates tha

I do quite a few interview each week, and one of our problems highlight the differences in these two approaches quite clearly. Inevitably, those candidates that layout their types, and think about the structure before they start coding come up with convoluted interfaces, leave unused class/struct/type member variables, duplicate data, or are simply unable to complete the problem because they've coded themselves into a rabbit hole. The best candidates decide what the public interface will look like, create the method signatures that they need and then start coding the logic. They add parameters/member variables only when they discover they're needed. In the end they arrive at a minimal and feature complete solution, rarely getting stuck on the way there. I've changed my own style of thinking about a problem as a result of this. Now I code outside-in, instead of inside-out.

zarzavat 5y ago
You should start with the most difficult (non-obvious) part first. If the most difficult part of the problem is the algorithm, then start with that and figure out the types along the way. If the most difficult part are the types / data representation then start with that and worry about the algorithms later. If both are difficult, then they need to be considered together and come up with a holistic solution. These are the kinds of problems that often take a two or more rewrites before you come up with something you're happy with.
lewantmontreal 5y ago
Some people call it the top down method. Start with the end result of what you want the program to be, in this case the public api methods.
Tainnor 5y ago
That's a straw-man. You can code type-first without going down the overabstraction rabbit-hole.
Beltalowda 5y ago
I think the problem isn't so much "where you start", but rather if you stop and backtrack along the way. What I mean is that if you have "convoluted interfaces, unused class/struct/type member variables, duplicate data" etc. then you started with some approach but never stopped for a minute along the way to redesign things using the knowledge you've learned from the first implementation pass. I sometimes end up with a messy and crappy solution on my first try, but it does work (sort-of) and then I just start from scratch again, liberally copying stuff over but also deleting/changing a lot of stuff, as needed.

zarzavat 5y ago

You should start with the most difficult (non-obvious) part first. If the most difficult part of the problem is the algorithm, then start with that and figure out the types along the way. If the most difficult part are the types / data representation then start with that and worry about the algorithms later. If both are difficult, then they need to be considered together and come up with a holistic solution. These are the kinds of problems that often take a two or more rewrites before you come up with something you're happy with.

lewantmontreal 5y ago

Some people call it the top down method. Start with the end result of what you want the program to be, in this case the public api methods.

Tainnor 5y ago

That's a straw-man. You can code type-first without going down the overabstraction rabbit-hole.

Beltalowda 5y ago

I think the problem isn't so much "where you start", but rather if you stop and backtrack along the way. What I mean is that if you have "convoluted interfaces, unused class/struct/type member variables, duplicate data" etc. then you started with some approach but never stopped for a minute along the way to redesign things using the knowledge you've learned from the first implementation pass. I sometimes end up with a messy and crappy solution on my first try, but it does work (sort-of) and then I just start from scratch again, liberally copying stuff over but also deleting/changing a lot of stuff, as needed.