Cracking the Coding Interview
This week has been without a doubt one where I have learned a lot since I’ve started reading the book “Cracking the Coding Interview” book by the amazing Gayle Laakmann McDowell.
This book is designed to give you everything you need to present yourself for an interview in the world of technology however, I think it has taught me things that can be applied to the outer world, in particular, I’m thinking about empathy since it exists a section in the book that talks about the interviewers and at least I’ve never thought about this side, I didn’t realize that the work of these people is more complicated than what one believes at first glance since this implies being able to ask questions that really measure the interviewee’s ability to solve problems. It’s in this search that some interviewers fall into asking difficult questions that will only test the memory capacities of the person interested in filling a position and in the end, this quality (not insignificant at all) will not be able to cover the needs of the position when it’s desired that the collaborator develop an innovative strategy to attack an unfavorable situation.
In the same way, this book contains useful resources such as a table that helps you to improve your way to talk about the projects in which you’ve participated. It has happened to me more than once that I end up talking more about the context than what I achieved in a certain project. Giving context is not bad, it’s just that the focus of talking about a project is giving the interviewer more information about your experience and your contributions to a given project.
Another interesting resource is the section dedicated to talking about the weaknesses of the interviewer, although it is true that we all have these and in general, it is not bad to recognize them in order to work on them, at least I’d never thought about the positive side of having something commonly perceived as bad. For example, in my case, I’ve always been aware of my short time attention, but thanks to this book I can see that being like this helps me make relationships that are not always so obvious and that when I’m stuck solving a problem it’s usually beneficial since it is easy for me to find relationships between concepts that seem alien to each other.
The book has a part where emphases is placed on the “Big O notation” and how to correctly design algorithms based on this notation, although I already knew the concept of Big O Notation, I’d never delved into this subject as before, I find it very satisfying to be able to understand why go through a linked list turns out to have a complexity of O(n) or why Log(n) is the most desirable complexity, even more than linear since Log(n) gets easier as the algorithm progresses in time.
Finally, I want to talk about one of the most important things I learned this week and that is to give concise and clear answers, whether you know the answer to a question or not. And it’s that usually, I tend to go around in my replies when I don’t know the answer, now I understand that it’s better to accept things as they are and if I don’t know something it doesn’t mean that I’ll obtain fewer points or something similar in my interview, but rather the interviewer will understand that I don’t know something about this topic and therefore she/he will have to adapt the following questions to the level of knowledge I have, which is not something inherently bad.
At the end of this week, I think I am a much better person and I am taking with my knowledge that will undoubtedly be with me all my life.
