[Coding Test] How to Solve Coding Problems

A problem Solving Flow Chart

 

1. Listen
   • Pay very close attention to any information in the problem description. You probably need it all for an optimal algorithm.
2. Example
   • Most examples are too small or are special cases. Debug your example. Is there any way it's a special case? Is it big enough?
3. Brute Force
   • get a brute-force solution as soon as possible. Don't worry about developing an efficient algorithm yet. State a naive algorithm and its runtime, then optimize from there. Don't code yet though!
4. Optimize (BUD)
   • Walk through your brute force with BUD optimization or try some of these ideas:
     • Look for any unused info. You usually need all the info in a problem.
     • Solve it manually on an example, then reverse engineer your thought process. How did you solve it?
     • Solve it "incorrectly" and then think about why algorithm fails. Can you fix those issues?
     • Make a time vs. space tradeoff. Hash tables are especially useful.
   • BUD
     • Bottlenecks
     • Unnecessary Work
     • Duplicated Work
5. Walk Through
   • Now that you have an optimal solution, walk throgh your approach in detail. Make sure you understand each detail before you start coding.
6. Implement
   • Your goal is to write beautiful code. Modularize your code from the beginning and refactor to clean up anything that isn't beautiful.
     • Modularized code.
       • This shows good coding style. It also makes this easier for ou. If yhour algorithm uses a matrix initialized to 
         {{1, 2, 3}, {4, 5, 6}...}
         don't waste your time writing this initialization code. Just pretend you have a function initIncrementalMatrix(int size). Fill in the details later if you need to.
     • Error Checks
       • Some interviewers care a lot about this, while others don't. A good compromise here is to add a todo and then just explain out loud what you'd like to test.
     • Use other classes/structs where appropriate. 
       • If you need to return a list of start and end points from a function, you could do this as a two-dimensional array. It's better though to do this as a list of StartEndPair (or possibly Range) objects. You don't necessarily have to fill the details for the class. Just pretend it exists and deal with the details later if you have time.
     • Good variable names.
       • Code that uses single-letter variables everywhere is difficult to read. That's not to say that ther's anything wrong with using i and j, where apporpriate (such as in a basic for-loop iterating hrough an array). However, be careful about where you do this. If you write something like int i = startOfChild(array), there might be a better name for this variable, such as startChild.
       • Long variable name can also be slow to write though.
         • startChild >> tell interviewer that you'll use abbreviate this as sc.
7. Test
   1. Conceptual test. Walk through your code like you would for a detailed code review.
   2. Unusual or non-standard code..
   3. Hot spots, like arithmetic and null nodes
   4. small test cases. It's much faster than a big test case and just as effective.
   5. Special cases and edge cases.
   6. And when you find bugs, fix them carefully.