How to Practice?¶
TBD: Describe what the formal process is.
The real treasure is the practice we strengthen along the way¶
Many interview candidates aim to solve as many problems as they can before the interview. They aim to cover as many different topics as they can ranging from Big-O notation to AVL trees. This works for many candidates, especially formal CS graduates. Many of these candidates actually stregnthen their problem solving practice through the series of questions even if they don't realize so.
This course takes a different approach. This course is not a mad dash to the solve the most problems. Solving any given problem is not important. Problems are tiny tools to incrementlly improve your practice and mental processes. Each problem you solve using the formal process stengthens your practice and furthur etches in the "correct" mental processes to solve a problem. Each problem that you solve by sidestepping the formal process or skipping steps weakens your practice. Thus it is important to use the same formal process for both difficult or previously unseen questions as well as for the simple or previously solved questions. The time spent on solving the easy or previously solved questions via the forma process is the investment that will protect you from haphazard thinking when confronted with a difficult or previously unseen question.
Take your time¶
It is essential that you go through this course at your own pace. Don't rush it. Ideally, you should spend 6-12 months preparing for interviews. For every topic, spend time thinking about the problem yourself. Pose questions to yourself and answer them, even if the question seem crazy or irrelevant. It's the mental tussle that'll build your problem solving muscle.
Don't get help from anyone¶
If it takes you 2 days to even understand the basic premise of a question, let it take 2 days, even if it takes your friend only 5 minutes to understand the question. Everyone thinks differently and there are myriad of factors that affect your understanding. If you're a physical scientist/engineer, then it is likely that you've been trained to think about different topics of mathematics and your internal requirement for a mathematical proof is much higher (or lower) than a computer scientist. If you're unable to grasp a concept quickly now, then it is likely that you won't be able to grasp a concept during an actual interview quickly. If your mind struggles against ideas, let it struggle and let it anneal into understanding instead of forcing it.
Don't read-though the topics leisurely¶
Many candidates simply read through a topic without spending any mental energy on trying to solve it themselves. If you continue to read through any topic in this course, you will read through the solution as well which would deprive you of a possibly irreplacable opportunity. Now that you've read through the solution, you have at least one solution in your mind. Your mind may no longer be willing to look for another solution. Even if you forced yourself to think of an alternative solution, your mind may always converge to the solution that you've just read. There may indeed be no alternative solution, which may make you even more complacent.
Wrong solutions are good for you¶
Wrong solutions are good for you. Bad solutions are good for you. Ugly solutions are good for you. All solutions are good during the practice phase, especially if this is your first time practicing these topics using a formal process. If you arrive at a solution that you yourself can prove is incorrect, then retrace your steps to pinpoint the exact mental location where you made the error. Then correct your error and continue the solution. Do this until you are convinced that your solution is correct. Then check the correct answer. There is a chance that even though you were convinced that your solution was finally correct, it wasn't. Repeat. This search-and-destroy operation will provide tremendously more benefit that solving 10 other problems correctly at the first attempts.
Bad or ugly solutions are correct but not elegant. They are often complicated and messy and you may have a feeling that a cleaner solution must exist. That is okay. Unless you are an extemely talented genius1, you will write ugly solutions, especially for new or difficult problems. The quicker way to learn to write elegant solutions is to spend the mental energy to find the points of ugliness in your solution and confronting them. Often candidates avoid confronting the ugliness, not because they don't have the time, but because it's just uncomfortable to confront your ugly code. Many candidates would write ugly code and then instead of looking at or fixing the ugly code, they will simply discard it. They will then start writing another piece of code to solve the same problem with the hope that in their now latest attempt, they would somehow avoid all the ugliness of the previous attempt. It works, sometimes. Often, every successive attempt only improves code elegance incrementally, requiring multiple sequential attempts. To meta-use the big-O notation, the time complexity of arriving at an acceptably elegant solution may be \(O(n^2)\), where \(n\) is the average number of lines in the code2. A better solution would be to confront the ugliness, introspect why your brain did what it did, and then attempt to fix all the issues in the second attempt.