A book club for developers.
BookBytes is a fortnightly (or biweekly) book club for developers. Each episode the hosts discuss part of a book they've been reading. And they also chat with authors about their books. The books are about development, design, ethics, history, and soft skills. Sometimes there are tangents (also known as footnotes).
(Intro music: Electro swing)
Hello, and welcome to BookBytes, a book club podcast for developers. We’re talking about Cracking the Coding Interview, 189 programming questions and solutions by Gayle McDowell. I’m Adam Garrett-Harris.
I’m Safia Abdalla.
I’m Jason Staten.
So, I read this book about two years ago when I was interviewing as well as about a year ago when I was interviewing and I always recommend it to anybody who’s interviewing or thinking about interviewing, especially if they’re interviewing at one of these big tech companies. And, you know, actually, I never thought I could get a job at one of these big tech companies but it’s actually a lot more attainable than I first thought.
You know, because they’re not recruiting out of these small colleges that I went to. So if you’re from one of these smaller colleges or self taught, you really just have to go and study and apply yourself.
So, anyway. This book is massive. It’s about 700 pages long, but most of it’s just solutions and so the overall structure is that there are eight chapters at the beginning which are about 80 pages and they cover some basics about the interview process. Then there’s the actual questions that are about 100 pages, but that’s kind of split into different chapters based on topic. So it will talk about arrays and strings to give you some hints and then it will have some questions about it, and then the questions, they have different hints that you can go and look up and then you can go and look at the actual solutions. And then after that there’s the solutions which is about 400 pages and then there’s some advanced topics, a code library because there’s certain types of things that come up over and over again and so that that code is just sort of in one spot at the back, and then there’s the hints.
How did you use the book when you were studying? Did you, like, just go straight to the problems and do those? Did you read, like the intro chapters at the beginning? Did you use the things at all? What was your process then?
Yeah, I had enough time that I went and read all of the eight chapters at the beginning, then I went through and started reading each section. I’d read a chapter before the problems and then I wouldn’t answer all the problems, you know, I would read about strings and then answer a couple of questions and then move onto the next section.
And there were certain chapters that I didn’t really feel applied to me, or I wasn’t as interested in. Like, I didn’t think I would get asked about object oriented design as much, or there’s a chapter on C and C++ and one on Java, so I, kind of, skipped some of those.
Got it. So you were, kind of, selective about the content.
Yeah. And then when I was being really good about this I would get an actual white board and then write out the code on the whiteboard. And then after it’s written out go to the computer and type it in and see if it works.
Oh, wow. So you actually went in and coded, like, a compiler, or /interpreter approved code?
So that’s what it recommends. It recommends that you read the question, you try to solve it on paper or a whiteboard without looking at the hints or the solution, just try to do it on your own, and then test it on paper, and then go to the computer and type it in exactly as it is on paper and see if it works.
I see. That’s interesting.
Not the process I’ve used for things. So that’s interesting that it recommends that.
When you went through the problems, Adam, did you also try and talk through it aloud? Because I know that’s probably the most important thing of any whiteboard interview is letting people know and like, the interviewer knowing rather actually coding it 100%, or at least that’s always been my take on it.
I think I did that a little bit because I also watched a video from Google about how to interview at Google and so they talked about how to write it out, how to ask questions before you even start to make sure you understand the question fully because when they ask the question they’ll give you little hints, like, little, they’ll include, or not include certain information that’s relevant to solving it and so making sure you answer it really well. And then it talks about describing the naive or brute force approach. Maybe, not actually writing it on the board, just describe that to let them know that, yes, you can do a naive approach and then talk through maybe a better solution and then starting working on it.
Yeah, I agree with that approach. That’s the strategy that I always use whenever I’m interviewing is I, like, I ask questions, throw out a brute force answer and then spend the rest of the time optimizing.
Yeah, and if all you can think of is the brute force, then go ahead and put that on the board and then they’ll probably ask you how you could optimize it.
Or ask you what the Big-O is.
I’ve definitely been in that situation before of only being able to think of the brute force option, especially when coming up with it on the fly during an interview. And so, just getting it up on the board and having it as a point that you can discuss with the interviewer makes a lot more of a statement than sitting there quietly trying to churn out a linear, line, answer if you just don’t know.
Yeah. So chapter one kind of talks about the interview process in general and one of the things it says, especially with these big companies, is that they want to make sure they get really good people and so they are okay with there being false negatives Meaning, they’re okay with turning away really good people, what they don’t want is false positives where they let someone not so great into the company.
Hmm, interesting. Yeah, I guess that makes sense.
Yeah, even if you get rejected that’s not necessarily anything against you, it could just be you had a certain interviewer that was looking for a certain set of skills and if you’d gotten someone else then you would have gotten in. And the other thing is you’re not necessarily supposed to finish all of the questions. So you can’t tell how well you did because they’re comparing you with every other candidate and you don’t know how well the other candidates did.
So it, you know, it definitely said basic data structure and algorithm knowledge is useful. I went to this one interview one time where the job description said, “Hey, you don’t need to know any data structure algorithm stuff or weird logic puzzles.” And then I went in for the interview and that’s exactly the kind of questions they asked.
yeah, I think at smaller companies sometimes you don’t get these data structure questions but super useful to know and the big companies will definitely ask those.
And then Chapter Two talked about behind the scenes at Microsoft, Google, Apple, Facebook, and Planter? And just how their interview process is different from each other. You know, some of them you’re applying for the whole company in general and then after you get hired you pick what team you’re on. I think at Microsoftwaret you’re applying, usually, for two teams and then you talk to a hiring manager on an as needed, on an as needed basis. And so if you end up talking with a hiring manager that’s a really good sign. And like, I don’t know how up-to-date these company profiles are, but…
I can to Microsoft a little bit.
Yeah, so I think, and I checked I can publicly share this, there’s actually a couple of blog posts and news articles out about it, and the “it” here is Microsoft’s new job interview format for software engineers and other roles, as well. As a caveat, I actually did not interview under the new format. I interviewed under the old format. The new format is unlike traditional software engineering interviews. It’s designed to be a little more focused on project-based problems. So, for example, like in the old interview format, similar to other tech companies, you would end up doing stuff similar to what is, like, in the Cracking the Coding Interview book where it’s like you’re solving different exercises and they’re all kind of, like, disconnected from each other and they test different things and there’s not really a cohesive story behind each of the questions.
With this new format, it's more like you get one kind of general theme or thing that you're going to be working through in each of your interviews and then there's also experimenting with different things. Should, I think one of them is you get some information about what you're going to be asked about before you come to the interview. So you like, have time to research-
And, like, prep and stuff like that. So yeah, this is the new format. I think I'm supposed to do a training on it at some point so I can learn how to do this interview format but I know a lot of people talk about how there's, kind of, problems with these traditional Tech interview formats and so this is, like, an example of a big tech company realizing that and starting to change the way that they do interview. You know, I interviewed with Microsoft in December of 2018 and I was doing it under the old format so I'm not sure what the timeline is for rolling it out for people-
But I can speak to the old format because I think that's probably the one that's, like, most similar to how Google and Apple and all those big fancy companies do things.
And my interview process was in two phases which I think isn't the case for most people. There is a phone interview phase and then there was an in-person interview phase and on the phone interview I was speaking with two different engineers solving a technical problem and it was, like, on, like, an online code pad and I was required to produce code that would compile and run.
Yeah. So this is saying, when we were like on the coder pad like the virtual online code editor where you can, like, collaborate with each other.
Yeah, that's interesting because I've heard that Google uses Google Documents.
Type it in there and it's not going to compile if you're writing in a Google Documents.
So, yeah. I guess that is something that can depend. I know in other companies that I've interviewed at that were also, like, bigger-type companies it was like a portion where I was on an online code editor and it did have to compile and run. And then-
Once I got past the phone interview, it was the on-site which was like 6? 5? 4? I blurred this all out of my memory because it was a terrifying experience.
Yeah I think the book says 4 to 5.
Yeah, it was 4 to 5 and it's basically like, back-to-back the whole day. So, like, you start at 9:00 and you end at, like, 4:00 and it's about an hour per interviewer and it's a whiteboard-style interview questions. So you get, like, they ask you the interview question and then you work through it on the whiteboard.
I mentioned earlier the principles I follow which were like, you know, ask questions to set the scenario. I usually like to do this by kind of making it a little bit test-driven. So what I'll do is they'll give me the problem statement like “write a function that prints out the number of letters in a word. And so what I'll do is I'll, like, write a couple of test cases for it so I’ll like, you know write the word cat and say my function is going to return three and then I'll start to, like-
Explore edge cases. I'll be like should my function handle nulls? Should my function handle empty strings? What if the word is so long that it's got like, you know, whatever the maximum integer is on your machine and like-
Like establishing those test cases and then I write the brute force.
And are you asking them what it should do in the case of null and empty string?
Yeah. I’ll, like, ask like, “Should I-”, I’ll be like, “Should I care about these kinds of edge cases just so it shows I'm thinking about it and then usually that'll, like, get into more scenarios. I remember distinctly the things that I got caught up on with my interview was when I didn't consider edge cases until I was, like, well into having written a solution and then I realized I forgot an edge case and I had to, like, keep rewriting.
Yeah and and speaking about rewriting. How do you manage your space on the whiteboard?
So I will, I think the way I did it was, like, I split up the far left of the whiteboard for my test cases and then I, kind of like, planned ahead of time what kind of functions I would need. So I started by creating, like, my main function, like, immediately next to my test cases and I then left room for, like, helper functions and things I needed to add on to the right of the white board.
And to be honest, it definitely got a little bit messy. Like, I was like, you know drawing arrows and like, “Add this here because I forgot it” and all that kind of stuff.
But yeah, I think it ended up looking fairly clean. I did do a lot of, like, erasing and rewriting and stuff like that and I I got the job. So I ob-,that obviously wasn't a bad thing that I was like erasing and rewriting my solution as I was going along
One good tip that the book gives is to bring your own whiteboard markers and bring the fine tip whiteboard markers.
markers. Oh, that's a good tip.
A good tip.
Yeah, because a lot of times they don't have good markers that have ink in them. Like, they can actually write on the whiteboard and if they do they're the fat ones and so it's hard to write a lot of code.
That is a really good tip.
I've done that before and they were, you know, I definitely needed them. It's good to have the fine tip and then they were impressed that I thought of that.
Anything that can make you stand out a bit, right? Like, stand out in a good way.
Yeah, it shows you're prepared.
Also, your example of walking through the edge cases is definitely one of those side qualities that you get is, or that I would think interviewers are looking for in you is not can you solve the problem immediately, but are you thinking through the problem case in general? Because I mean, that's what we do as developers. Like, every program that we work within has some sort of bounds associated with it and so knowing those constraints is really important to the decisions we make in the software we write.
Yeah, definitely. Anything you can do that, for example, like Adam was talking about that, like, bringing your own whiteboard markers or exploring edge cases that shows you’re, like, thoughtful, is really good.
On the topic of thoughtfulness, one thing that I think is really important, and I have not done this but I have shadowed interview sessions where I've seen other people do this, and it's, like, being kind of, like, rude or snipey when you get corrected or when someone points out something that you didn't consider. So, like, for me, I was talking about how, you know, there were, like, edge cases I didn't consider. When the interviewer pointed that out to me I was like, “Oh, thank you for letting me know that. Here's how I think I can rework it.”
And I was in a situation or I was a shadowing an interview once where someone, like, the main interviewer had pointed out that they had, like, missed something and the person was just like, I don't, maybe I'm reading into it but they were just like, “Oh, yeah, of course. Whatever.” You know? They were like a little dismissive of it.
And I thought that was kind of, you know, not the best quality for someone to howcase when they're interviewing. so, you know, like, be courteous and respectable to the interviewer, which is a basic thing, maybe but...
Yeah, ‘cause they're looking for a culture fit as well.
And you want to look at you want to look at what the company values.
Yeah, that is a great point.
And align to that.
So I do have a flip story on that note of a personal interview that I got in and it was with a company that I had gotten through a phone interview with them and they actually flew me out to them to go and do an in-person and while I was there I was put on a machine to code a specific problem for an hour to debug, like, why some Windows application wasn't working; and it turned out to be the reason it wasn't working was related to threading and after writing it and figuring out a solution, was interviewed by a person who reviewed my code and there was a case where, like, I chose not to use a lock when dealing with a specific spot in it in it and this interviewer questioned me as to, like, why I didn't use it and I explained to them that it, in that particular case, it didn't matter. That it was okay to alter that structure and that case and he pushed back on me to say no and we wound up, kind of, getting in a pretty heated debate about it like near argument.
And at that point I had had the thought that I tanked this interview and not too long after I had one interview between but somebody came in and they were like,” I don't know what you said to this guy but he loves you like he thinks you're great.”
And so I was, kind of, uh, kind of surprised at that point and maybe it's because I stood my ground a bit and he was just of that type but that was actually one case where I was pretty stern back with him and it worked out because they did wind up making an offer. So yeah.
Yeah, that is interesting. I guess you definitely kind of have to, like, suss out the situation and play it by ear. I think, definitely, if you do feel like the interviewer is, you know, bringing up a point that isn't completely valid I agree that you should definitely bring it up in, of course, in a way that's, like, courteous and, you know, it's a good way to show that you, like, have your own opinions and you're not just gonna like go with what the person in power is going to say if that makes any sense. So yeah, that's a good story to
Definitely, that that makes sense having been an interviewer of other people, too. That's that's one thing I will look for in somebody is for them to take an opinion on something. I mean,whether or not it's right, I mean, there are so many things in development that append but if you say you are really good at something or that, you know something well then, like, you should have some form of opinion on it, like, whether it's good or bad or something is better and not just being loose about about everything that's discussed.
Yeah, that's a good point.
So one of my favorite parts of this book is in Chapter Four talking about before the interview. It talks about getting the right experience, writing a resume, and then has a preparation map which is this two-page flowchart about how to prepare for an interview starting out a year or more in advance all the way up to the day of the interview and after the interview, and I say it's a flowchart but really it it's completely linear. And you don't have to start at the beginning.Yo u just start it, however far out the interview is, you start at that point.
It stresses me out that it's like a year before. (laughs)
What do you do a year before?
I mean, one plus years before, build projects outside of school and work.
Learn multiple programming language, languages. Expand your network. Build a website, portfolio, take internships. Things like that.
You were nailing all those things, Safia.
What? I've done all those things?
Yeah, like between doing outside work, having public-facing stuff on a blog, like-
Starting your own startup.
Unknowingly, you were you were following the flow chart.
Yeah. I, well, although I guess not intentionally, but yeah, I can see how that is, like, I guess you're just, like, I guess in life in general and your career, you're just always pretend that you're going to be going for a big job interview and act like it. Like, now even though I have this job at Microsoft, not that that's like a big deal or whatever, but I mean, I guess it is a big deal. I shouldn't, like, downplay that achievement.
But I guess what I'm trying to say is even though I have the role, I'm still trying to, you know, keep blogging, keep still contributing to open source, still doing all of the stuff that I love and care about and then I also think it's, like, important that, like, the stuff that shows that I'm growing and developing as an engineer isn't just, like, within the walls of Microsoft, and that there is, like, evidence of my skill set and my abilities that is out in open source and blog posts, now in GitHub all over the place so that, you know, I have proof that I know what I'm doing for any other future opportunities I might have.
Even for your current company at Microsoft, I mean, I'm sure one of the influences on them making the hiring decision of you is the work that you had done in the past. And so I would assume that they wouldn't want that to stop because not only does it look good for you but it also does reflect well on them saying these are the types of brilliant people that were hiring here at
Yeah for sure.
Okay. Yeah, and one of the things that it says to do about four weeks out is to create an interview prep grid. So in Chapter Four it talks about the interview prep grid. Chapter Four is about behavioral questions rather than the technical questions. And so the prep grid is common question and then you… on the columns are three different projects you've worked on. So for each of those projects answer these questions: challenges you had, mistakes and failures, what you enjoyed, some sort of leadership, conflicts and what you would do differently.
That's a good list.
So yeah, I've done that. It's really good to have that in your back pocket. I mean not literally have a cheat sheet in your back pocket-
But to have those things in your mind and you can review that before you go in for your interview because they're going to ask you, “What's an example of a time you showed leadership?” Or, “What's an example of a time you overcame a challenge?” And you'll be able to answer those things.
Especially things you as an individual did as well and not just, “My team did this”, but thinking-
About your specific role.
Yeah, it does say to watch out for saying “we” too much because they want to know what you've done.
Huh. Interesting. Yeah. This is… yeah, this is kind of a tangent or footnote, but that's something-
That I definitely struggle with, just in general because I have a tendency to, like, maybe more so than others give credit to the support and, like, the, like, other people involved in something even if I did, like, a majority of the work, I'll still be all like, “We, the team, did this.” And I think that's, like, a good quality in many cases but sometimes I definitely do wonder if, you know, I'm interviewing or in situations where I have to showcase my particular skill set achievements if by like being too team-focused I'm kind of hurting myself-
By not, you know, being a little selfish about it in a good way.
Yeah, and then it kind of talks about how to answer these kinds of questions, like, a structured way to answer it. So first you give a little nugget and you say I'll tell you about a time where this happened. It was a little a little tldr and then you give the situation and then you give the action steps you took and then you give the result.
I like that roadmap.
Yeah, I think a lot of people tend to, kind of, their answers, kind of, meandering and you're trying to understand what the point of it, the story, is.
That is one thing that I've heard about storytelling in general is to start somewhere in the middle of it that, kind of, pull somebody in you put it in a situation that people can put themselves in, whether it's something they've experienced themselves, but it's not the whole ramp up of it but rather jump into the middle. Like, I was sitting in my car and it was really cold outside and as I walked up to the front door, you know, I go in and everybody looks at me, like, giving that without giving the other bit of it like pulls you in a little bit more than-
Like, giving, I don't know about the whole lead in and that maybe wasn't right [inaudible].
Yeah, that's a really boring story but I still want to know what happened.
Right. Like, what is going on because why did everybody look at me? Right?
Yeah. It gives the same advice for the question. So tell me about yourself.
Oh, I hate that question so much
Yeah, it says to start off with your current role, just a headline, and then briefly college and then post-college what your jobs were and then you get back to your current role again, and you can get some more details. And then you can talk about stuff outside of work if you want to. And then I think people miss this part, what you're planning to do now, what you're looking for now.
Mmm. That's a good way to pull in their company as a thing too, saying how you fit this role or this role fits what you're looking for.
And another thing too is not giving too many details but, like, not overwhelming them with too many details. If they ask you a question that's very, you know the answer is going to be very hard to explain and very detailed you can give them a high-level overview and then say, “I can go into more detail if you'd like.”
After that, it just talks about Big-O and that's a really long chapter and then it talks about how to answer technical questions and it's got a flowchart for walking through a problem and how to solve it. There's an acronym called BUD, uh, BUD optimization, which means when you're trying to optimize a problem, B is for bottlenecks, U is unnecessary work and D is duplicated work. So you can think through that.
Oh, I like that?
Where are the bottlenecks? Okay, where am I doing unnecessary work? Is there anything I'm doing twice, or multiple times, that I don't have to? Yeah.
I like that
And then finally it says “Don't give up and show excitement for solving hard problems.”
That's definitely a great thing to do, too. Like, I always try and say when I get the problem like, “Oh that's a really interesting problem.” Or, “Oh, I'm looking forward to solving this.” Just to, like, show that you're not someone who's necessarily like jaded or afraid to take on big problem. So I like that that tip is in there.
Yeah. Yeah, and this reminds me a lot of a technique I heard about overcoming anxiety and, ‘cause interviewing is be very anxiety-driven and a lot of people, when they're anxious, they try to calm down but that's very, like, low-energy and anxiety’s, like, high energy and so it's very hard to do that and instead you can just say, “I'm excited!” And so excitement is positive. It's not a negative one like anxiety. It's positive, but it's also high energy. So it's easier to move from anxiety to excitement.
I like that perspective, too.
And I think that's a TED talk. I'll try to find a link to that and then Chapter Eight talks about the offer and beyond. It says to negotiate and ask for, like, a specific number instead of just more.
Yep. That's definitely a solid tip on negotiation.
And then if you can't get more salary, there's other things you can negotiate for, more stock options or different things. More time off, it really depends. And it also says keep interviewing at least once a year to keep your skills sharp.
Mmm. I had not considered that I guess that is a good thing, a good thing to do.
Yeah, if you wait several years until you're really burnt out and you're desperate to get a new job. You may not be in the best position as you would be if you kept interviewing.
This episode of BookBytes is sponsored by Pluralsight. Pluralsight is the technology skills platform. You can see where your skills stand, master the latest technologies, and show off your expertise.
They’re currently hiring in Salt Lake City and Boston.
I work at Pluralsight and the engineering culture is amazing. We work in small cross-functional autonomous teams; each team has four to six engineers, a product manager, a ux designer, and a dev-ops engineer that all sit and work together on the same part of the product. And each team is autonomous so they own the discovery, design, development, delivery, and production support of their part of the overall system. We encourage test-driven development and pair programming so that at least two people who have looked at every piece of code that gets committed.
We have a culture of continuous learning. We have book clubs, discussion groups, and Pluralsight was just named the #9 Best Workplace and one of the Best Workplaces for Women by Great Place to Work.
If you want to work here visit Pluralsight.com/Careers/Engineering to learn. That's Pluralsight.com/Careers/Engineering.
And for those of you who would be interested in checking out the product you can direct message @Pluralsight on Twitter and they'll send you a free trial code so you can check it out for yourself.
And thanks to Pluralsight for sponsoring the show.
Okay, and then there's the problems. So Jason and I have done some problems that we can talk about.
Jason, and I know you’ve done several so why don't you start with one?
Okay, I will start with one because I guess you sent me a number of them that were on the start of Chapter Seventeen and so I went ahead and did 17-1, 17-2, and 17-3 and I will talk about the first one. Gave me an excuse to go and write some more Rust. I've been slacking on that a little bit, so…
It's nice to bust it out and try out the Rust documentation, which is, like, the documentation generator is so nice.