Update README.md

Author: Joseph Luce

README.md

@@ -62,6 +62,13 @@ If the average interview expects you to finish a question in 45 mins, finish it
 ### Mock Interviews
 If I were to say which part was the more important step from this entire post. I would pick this one here. Mock interviews are EXTREMELY IMPORTANT! Did you hear me? EXTREMELY IMPORTANT! I highly recommend you find another person who is in a similar situation like you, both in skill level and dedication. This step requires some dedication and sticking to a schedule. Both of you should agree to meet up a few times a week to practice interviews. For example, I found mine on pramp, both us would try to solve a question then when we would meet up using google hangouts and google docs, we would ask each other the question we just solved. As you do this a couple times, you understand the areas of each other weakness and provide feedback. You can sometimes learn some new way of approaching problems from each other. Its a great and important learning step to have instant feedback on your performance. We use to do marathon mock interviews to over prepare. Like give each other 5 questions in a row and try to solve them as quickly as possible. Our sessions would usually last around 3 hours. So again, this step really only works if you can find someone willing to put in the time and effort just like you would. So use websites like pramp to start mock interviews and as you go ask if they are willing to do this type of preparation.
 
+### Communication
+Understand that the interviewer is trying to find signals during the interview. If he cannot 100% assess whether you know your stuff, then you will not get the role. What that means is, DO NOT go through your interview/question without explaining your thought process. You can fail the interview even if you get the question 100% correct when you speak nothing. The only thing it shows is that you may have been given a question you have seen before and memorized the solution. It is better if you can solve the question in buckets, break down the question piece by piece and question the pros and cons of your approach and your other approaches. 
+
+I've had situations where I did not get the code 100% working, but because I questioned by code, found errors in my approach, fixed them, tried some test cases, refactored, and broken down my code into easily testable chunks, I passed the interview. The interviewer can easily understand my approach to programming in the real environment.
+
+You will need to learn to talk while you code, even if its not what you normally do. If you are stuck, say so and on what, that way the interview can possibility help you out or question something. If you don't say a word, the interview does not know if you are just thinking or really stuck.
+
 ### Apply wishful programming
 The idea of wishful programming is to assume you already have a given method, value, something that can help you solve a subset of your given problem. The issue with a lot of people when they think about problems, is that, they think of too many details. If given a very complex problem with multiple requirements, its hard to figure out where to start. I love to apply wishful programming into my thought process and my solution. It can help break down a problem and identify subproblems, while keeping you code clean and bug free. You will also noticed that your code will become more testable as well as more maintainable and malleable since this thinking forces you to think in a dependecy injection like way. You can see plenty of examples of wishful programming taking place in this repo, so look around. 
 
@@ -79,14 +86,6 @@ Make sure your focus is to create a skeleton working layout of your solution usi
 - https://www.pramp.com/
 - https://interviewing.io/
 
-# Bottom-Up and Top-Down Approaches
-Usually solutions will take either one of these approaches. Depending on the question, either or will be easier than the other. In interviews however, both approaches are fine. I rarely get asked to implement a specific approach, instead this is more or less the interviewee's choice of preference. I advise exploring and getting a 'feel' with the pros and cons of either approach. There isn't a very good way of explaining when to use one over the other. You just sort of 'know' based on how familiar you are to the implementation.
-
-# Tackling Recursion
-
-# Tackling Dynamic Programming
-Dynamic programming is using previously calculated information to calculate the next solution. To do this, one must allocate extra space to save sub-answers. This extra space is usually in two forms, either a one-dimensional array or a two-dimensional array, for interviewing purposes, it shouldn't need to go any further. Now the last portion you need to figure out is, what makes a sub-answer? Then you have to ask, what is the sub-problem? Then you have to think in terms of divide and conquer, what is the smallest problem set I could use, that when combining other small problem sets create another 'summation' of other problem sets. This will require a 'feel' of how solutions with dynamic programming work. There isn't a very good way to explain this other than the way I just described, so just dive in.
-
 # Recommended Event Timeline
 Assuming you are starting from ground zero, no idea about Algos and Data Structures. First read CTCI's chapters, for each chapter, you can attempt to do a few questions until you hit a wall. Don't try to understand every chapter fully, you should figure out the scope and breath of knowledge you need to know by reading each chapter. After reading each chapter, tackle a chapter you "think" you can accomplish in a week. Use that entire week to purely focus on a specific category. For example, I suck at heaps, so I do a bunch of questions on heaps for a week. Then switch to recursion for a week, then graphs then back to heaps again. Every other week you revisit a topic to test whether or not you truely understand that topic or not. Over time it will get easier.