Download Cracking The Coding Interview Free
Linda Berens
Then there are also chapters at the end of the book which hopefully are going to be apparent. That they are on very specific topics. And a lot of these topics you don't really need to go in depth into, unless that's something that you are already an expert in. So for example if you were doing your interviews in Java you wouldn't need to study the chapter on C and C++. And that leads me to my sort of core set of chapters that you should focus on. So the core chapters of this book that you really need to know are chapters 1 through 5 and 7 through 10. And this is in the most recent edition.
So chapters 1 through 5 and 7 through 10 basically cover all of the fundamentals that you would need to know for your coding interview. And just to go through them quickly chapter 1 is stacks and or sorry chapter 1 is arrays and strings, chapter 2 is linked lists, we have stacks and queues, trees and graphs, bit manipulation which a lot of people think you can just skip over, but is a really valuable thing. You don't have to go super deep in it but it is a valuable thing. Object-oriented design, another thing that may or may not come up but is actually really valuable to have a good grasp on. Recursion and dynamic programming and with dynamic programming you can also check out my ebook on dynamic programming if you haven't already. System design and scalability which is going to be more relevant if you are further on in your career but it's still something that's worth covering. Sorting and searching and that's the first ten chapters, skipping the math and logic puzzles. And then other than that there are a couple other chapters that you could go into. You could go into a language specific chapter, if you're gonna do a lot of stuff with databases. Or if you do a lot of stuff with databases. Covering the database chapter would be helpful and there's also the medium and hard problems at the very end that are gonna be useful if those if you get through everything else. But focusing for the starters on those first ten chapters and skipping chapter six is a really good way to get started. The second thing I want to talk about is how you actually approach this book.
You start with the book at the beginning you start with chapter 1, and you've read the whole chapter. You study that material and then you do the practice problems. And once you feel really good about arrays and strings you move on to linked lists. And then you move on to stacks and queues and etc etc. So that's one way that you can approach the problem the book. But what that fails at is that it may be very difficult to portion out your time. Especially because some of the later chapters are harder. If you break up your time evenly for each chapter you may find yourself running out of time as you're getting closer and closer to your interview. So that's something to be very aware of if you're going to take this approach.
Basically the point is that you're just going to spend a little bit of time and then you're gonna move on to the next topic. And what you're gonna do is you're gonna continue rotating through topics day after day, until if there are topics that you feel really good about you can remove those from the rotation and focus more on the other topics. Or until you get to your interview. And the goal here is to make sure that you have a good breadth of knowledge of all of these topics. It's much more important that you have that breadth of knowledge than you are really strong on graphs, but you don't know anything about recursion or dynamic programming. Because if a question on that comes up then you're gonna have no idea what to do. It's better, especially if you have good interview skills, to have a moderate amount of knowledge on everything and then be able to apply those skills so that you can work through the problem in your interview, and not get totally stuck. Whereas if you didn't have any knowledge on that topic you might get totally stuck and not know what to do.
So I really like this breadth-first approach to Cracking the Coding Interview because I think that it makes sure that you are covering everything you need to cover for your interview, at least in a little bit of depth. And the final thing that I want to talk about with Cracking the Coding Interview, is just the fact that this book is meant for review. This book is not the full encyclopedia. It's not your computer science textbook. It is a textbook for interviewing but that means that you are going to have to go outside of Cracking the Coding Interview to get all of the knowledge you need. If you just study exactly what's in the book, you're not going to go deep enough. And yes looking at yes the book does include a pretty good list of topics, but it doesn't really cover those topics in great detail. So as you're studying I highly highly recommend that you go reach out beyond the book and use the book just as a guideline for what topics you need to study in more depth.
For example with dynamic programming, just go back to this example, you'll see that there are some stuff in the book. There's an example or two. And it shows you tells you a little bit about what dynamic programming is. But that's not gonna help you really get good at dynamic programming. If you really want to get that good at dynamic programming you should check out my ebook, or you should check out other resources that are going to be more helpful for you and go into more depth. So on the day that you were working on dynamic programming you might reach out beyond the book and go look at those other resources. And that's just a really important point because I think that some people view this book as being the entire sum of knowledge that they're gonna need for their interviews.
And unfortunately just because that's not plausible in a book. Like this book would be ten times as thick if that was true. And so it's just not possible to do that. And so that's a good way to make sure that you're getting all of the knowledge in there. So just to recap real quick. With Cracking the Coding Interview, I think it is the best book for prepping for interviews and I highly highly recommend that you get a copy if you haven't already. And it doesn't even matter you don't even need the most recent edition any edition will do. It's just a really good starting point.
When you're studying the first thing I recommend is do chapters one through five and seven through ten. Skip chapter six, skip the remaining chapters unless there is specific knowledge in there that you need for your interview. Secondly, decide if you're going to take a depth first or a breadth first approach. I like the breadth first approach where you cover all the topics and then continue to cycle through them until you get to your interview. Because that makes sure that you actually cover all the topics that you need to.
And third, make sure that you go outside of Cracking the Coding Interview and look at the other resources that are out there. Use it as a guideline for what topics might come up in your interview, but don't let it be the end-all, be-all in terms of the actual stuff you need to know.
So I hope those tips were helpful for you. If you haven't already please subscribe to this YouTube channel so that you can get notifications for all of these videos. And also if you haven't go over to DynamicProgrammingBook.com and you'll be able to download my free ebook on dynamic programming which will take you a lot deeper on that topic. And I other than that I look forward to seeing you guys again in the coming weeks.
Gayle has worked as an engineer for Google, Microsoft, and Apple. Most recently, at Google, she served on the hiring committee where she interviewed hundreds of candidates and evaluated thousands more. It was here that she discovered the disconnect between candidates, their skill set, and their interview performance.
To me, MyStack means I am creating an Object MyStack made of an other Object T, which does not make any sense. If a stack is made of Nodes, then my type T should be the type StackNode (???). But then, when I define Stacknode it would be like saying Stacknode. I think I making to much confusion with generic types, but the point is I do not understand why it is not sufficient doing like I did in my code: whatever sort of stack it is, it is made of nodes, which can then of course have a generic data, so I just said that the data of my Node is of type Object, can someone explain the main difference, or at least why in "Cracking the coding interview" it is done like this? What are the advantages? What am I understanding wrong?Thank you in advance!!
Hence I spent the last three months figuring out how to improve my coding interview skills and eventually received offers from big tech companies like Google, Facebook, Airbnb, Lyft, Dropbox and more.
Many of the algorithmic concepts tested in coding interviews are not what I usually use at work, where I am a Front End Engineer (web). Naturally, I have forgotten quite a bit about these algorithms and data structures, which I learned mostly during my freshmen and sophomore years of college.
I used to think that being able to think, code, and communicate simultaneously was an impossible feat, until I realized that most people are just not good at coding interviews when they first start out. Interviewing is a skill that you can get better at by studying, preparing, and practicing for it.
My recent job search has led me on a journey to improve my coding interview skills. Front End Engineers like to rant about how the current hiring process is broken because technical interviews can include skills not related to front-end development. For example, writing a maze solving algorithm and merging two sorted lists of numbers. As a Front End Engineer myself, I can empathize with them.
Front end is a specialized domain where engineers have to care about many issues related to browser compatibilities, the Document Object Model, JavaScript performance, CSS layouts, and so on. It is uncommon for front-end engineers to implement some of the complex algorithms tested in interviews.
aa06259810