42. How to Prepare for Coding Interviews

Julián: Yeah, those are topics that if you don't have a computer science background, those might sound a little bit intimidating. Personally, I'm a telecommunications engineer so I don't have any background around the computer science. I recently joined Heroku and was interviewing for other companies and the technical interview process is something that, especially for me that I don't have the computer science background, gives me a lot of anxiety, makes me feel insecure. It made me feel that maybe I don't know what I'm doing, I don't know if I'm going to be performing, because you sometimes get these stories that these type of whiteboard interview questions are super hard. And companies like Facebook, Google, they have a pretty strict process to get into these companies and bypassing the interview process. So how do you prepare people or how do you help them to become more confident to go through the whole interview process?

Parker: Yeah. Well you're not alone. I mean the coding interview is something that really strikes fear in the majority of engineers. And a lot of people who don't have computer science degrees obviously have that fear. But those folks are also often surprised to learn that even people coming out of a computer science program at MIT are afraid of the coding interview. I mean it's a very specific game and it's one that very few of us are just good at for free. The vast majority of us just need to do some practice to get comfortable with doing this stuff. So my recommendation for preparing, I mean the biggest thing is to practice. I mean that's by far the most important thing, because there's a lot of sort of awkwardness around the structure.

Parker: For people who haven't done a coding interview before, if it's an onsite interview, you'll be standing in front of a whiteboard writing code on a whiteboard, which is something that most of us are not used to. You'll be thinking out loud and designing an algorithm in front of a person. So it's almost like giving a tech talk where you don't really know where you're going yet. It sounds very scary. Definitely it is the first couple of times. And if it's a phone interview, it'll be a similar kind of structure, but you'll be talking into your laptop. So some ways it's even trickier because you don't have... the person on the other end might be nodding at you, but you can't see that so you just kind of feel like you're monologuing into the void. All this stuff is very awkward at first, but it actually gets more comfortable with more practice. So its my first tip is to just practice so that you're less uncomfortable with the structure of the interview.

Parker: And then the second tip is to brush up on data structures and algorithms. And that's where Interview Cake comes in. Our contention is that you could run dozens of practice problems and slowly get better. But the thing that we do kind of uniquely, we figured out that what's happening in your head when you're doing that is you're learning a small set of algorithmic patterns that come up again and again in these tricky data structures and algorithms problems, and those underlying patterns are what allow you to have that eureka moment of like, "Oh yeah, Oh, if I reverse the list in place, then I can do this." And little tricks like that. So what we do is we teach those patterns directly and that gets people more comfortable with solving tricky algorithms problems more quickly.

Julián: Well, that's very interesting. So besides teaching the technical part, you are also teaching how to communicate and explain these algorithms and exercises during the interview because this is also like one of the hardest part. I might be super good at solving the technical challenges and by writing code, but might have problems communicating what I have in mind while explaining the algorithm. How do you approach these communication part of the interview, how do you prepare the people to be able to communicate properly.

Parker: Yeah. It's a great question. It's something that we don't focus on a whole lot today. I would love to do a little bit more. That's something that really is pretty person specific and so there's some other companies in our space that do something that's a little bit more one-on-one with practice interviews or like in-person tutorials or in-person practice or lessons. What we do do is offer a little bit of advice on what I like to call the soft stuff, right? The general strategy for this stuff. Outside of the communication part, we do offer a lot of advice around how to get unstuck. For example, like when you have that deer in the headlights moment where you've heard the problem and you have no idea how to get started, we give you a very clear roadmap for how to start poking out the problem to try to crack it.

Parker: We also give a lot of tips for how to navigate various parts of the interview that people get wrong. So for example, there's a common scenario in a coding interview is that you're working on a problem and you're going down a path and you actually think that you're onto something. You haven't seen all the way to the end yet, but, but you think you're getting close and you're going down this path explaining this algorithm. Maybe you're starting to code it up and your interviewer interrupts you and says, "Oh, but what if we did it this way?" This is a lot easier to explain visually, which is what we do on our website. A lot of people get that moment wrong because they think that the interviewer is giving them a hint and they think that they lose points if they get a hint.

Parker: So they talk past their interviewer to signal like, "Oh no, I'm not stuck yet. I don't need a hint." Right? But what's actually going on under the hood often in that scenario is that you're on a path that leads to a dead end and your interviewer knows that and they know that you don't that yet, and they're not faulting you for that, but they do want to give you a chance to get all the way to the end before time runs out. So they're rushing you through that process of hitting that dead end. And then backpedaling. There's a lot of kind of little nuance stuff around like common misconceptions about what interviewers are looking for and this fear of receiving hints and stuff, so we talk a lot about that.

Julián: And it's also hard to properly ask questions because the interviewers are also expecting you to be asking about the problem and the quantity of the question you are doing at that moment because that shows that first you are understanding the problem you are working on and it gives you a way to test out certain approaches before going to the whiteboard.

Julián: One of the things I learned before going through the whole interview process was to communicate what I was trying to do before jumping directly into the whiteboard, trying to analyze the problem, to check all the different input and output, what the problem was asking before jumping directly straight to code.

Parker: Yeah, and that's something that interviewers are often looking for. And again, it's not our first intuition, right? We're not used to thinking out loud, but from your interviewer's perspective, they want to believe that you have an organized thought process. So it takes a little bit to get used to that process of like, "Okay, I'm not going to write code, I'm just going to figure out exactly what I'm going to do first and then I'm going to explain that very clearly to my interviewer. Then once we agree, then I'm going to start writing code, and then I'm not going to start debugging that code until I finish writing it and then I'm going to go back and try it with a sample input."

Parker: That this very procedural approach is not often how we're used to writing code cause we're not used to having someone looking over our shoulder but it's an important thing to practice and be able to show in the coding interview.

Julián: Interesting. I have a question. What's the motivation behind Interview Cake? Why Parker Phinney decided to create this initiative, this code?

Parker: Well, so the story is I was working at a startup in San Francisco. I was an engineer and then a product manager there. And I had a good friend who kind of fell on hard times. She lost her job and she lost her apartment and she needed to make a career change. And so she did one of these coding bootcamp type of schools, one of these 12 week coding programs and she was kind of crashing on various friends' couches in including mine. So when she finished the program and she was going out to interview, I ran a couple of practice problems with her because my company was hiring so aggressively that I was talking with as many as two candidates a day. Right? It's like 10 candidates a week. Right?

Parker: So I was on the other side of so many of these interviews and I could see the mistakes that other people were making. We sat down and I gave this friend a couple of practice problems and she struggled, but we took a long weekend to fill in the gaps in her knowledge and teach her some of the strategy on this stuff.

Parker: One thing that was interesting with this friend is that if she didn't have a computer science degree, so she was a little bit weaker on the more academic data structures and algorithms, Big O notation kind of stuff. But we were surprised to find that it didn't take that long for her to pick this stuff up because she didn't need to be able to prove theorems and solve algorithms, problem sets. She just needed to know this stuff she needed to know for the coding interview, which is a very specific, very learnable set of things. So we filled in the gaps there, ran a bunch of practice problems. It only took a long weekend to get her really good at this stuff and then she went out and interviewed and she ended up getting a job at Facebook and suddenly she was making more than I was. So that was a big sea change for her. And it was a big learning experience for me. Yeah. Really inspired me to go out there and help more people do the same.

Julián: That was the best validation of the idea. If she was able to land that Facebook, which is one of those companies that are known for having a strict interview process.

Parker: Yeah.

Julián: That's very interesting. So that's where you started to create the first content. It was after that?

Parker: Yeah, well that was what got me starting to think about this stuff. One thing I did in the early days that I think helped a lot was I got in touch with all the coding schools in San Francisco and I got them to... I don't remember if they paid me or not in the early days, but they would bring me in for a one day workshop on coding interviews with the students and that was really how I developed the curriculum.

Parker: I was starting to build the website simultaneously, but it was really helpful to be actually teaching in person, noticing which things were confusing for people, which things didn't need a lot of explanation and that was really how I molded the curriculum in the early days. I knew at a certain point when those workshops were on autopilot and I really knew how I wanted to explain each thing and stuff like that, that the curriculum was good. So then it was just a matter of writing that up on the website basically.

Julián: What is the type of content do you have in your website right now? What can I find if I go to Interview Cake and I want to get prepared for a code interview? What should I expect?

Parker: So the bread and butter is a bunch of interactive practice questions. The setup is a little bit unique so you'll see a question and you'll have a code editor over in to the right hand side that you can open up so you can type up your answer and we have some test cases, you can test it when you're done. But what's unique about Interview Cake is... and this came from doing a bunch of user testing in the early days, these coding interview questions are usually designed to take upwards of like 45 minutes. So each question tends to be pretty long and has some twists and turns and the best questions actually have three different answers that are all correct.

Parker: There is a bad answer, a good answer and a great answer. And the difference between the three is their efficiency. And so what you're doing in those 45 minutes is coming up with some insights, stitching some stuff together until you get to the bad answer. And then seeing if you can tweak the knobs and improve some stuff and then get to the good answer and then see if you can improve the efficiency even further to get to the great answer.

Parker: So with that in mind, the very first prototype of Interview Cake used what I call a flashcard model where you have a question and then you press a button to basically turn the flashcard over and you would see the answer, right? The problem is if you, I saw this in user testing, if you have the bad answer and then you flip over to see the final solution, you lose the rest of the exercise. You didn't get to do that process of trying to improve from the bad answer to the good answer to the great answer.

Parker: And also a lot of people might get stuck even before getting to the bad answer. And some people would get stuck at the good answer but not get a chance to try to improve through to the great answer. Right. So the flashcard thing really wasn't working and I noticed that when I sat, and the friend I was talking about earlier when we were doing practice problems, it wasn't just question and answer, it was this dialogue and there were a lot of little nudges and hints that I would give along the way. All this is to say Interview Cake mimics that dialogue of having a tutor there or honestly a real interviewer there with you. So you have the question and then when you get stuck you can say, "Tell me more." And you'll get a little nudge that's the next logical step that you need to make that's helpful enough for you to just take it and run with it.

Parker: If you get stuck again, you can say, "Tell me more." And so for most questions, we have like dozens of these little nudges that come up. And then we have something that's a little unique. It's, we call them gotchas. So if you have the good answer and you think it's the best answer, you can say, "I have an answer." On Interview Cake you can press a button and before showing you the final answer, we give you what we call a gotcha. So it's just enough information to compare your answer. Often it's the Big O efficiency. So maybe we'll say something like, "You can do this in O of n time." And you can look at your good answer and say, "Oh actually mine is. n log in. I guess there's more to this." So instead of blowing the whole exercise, we give you just enough to know, "Oh, there's actually more to be figured out here." And then you can get back into it.

Julián: How do you validate the content you have or the type of information you have with the current questions that are being ask in the different companies? Because I saw in the website that you have also sections of questions by company. How do you validate those against what it's been asked freely in a coding interview.

Parker: They're a couple things. So in general, the way we keep track of what questions are being asked is that we dialogue pretty closely with users. So as soon as someone signs up for Interview Cake, we start sending them these drip emails, we send them from our support email address and we just invite people to say what they're struggling with, what kinds of tricky problems they've been getting, stuff like that. And so we hear from people what's going on, what stuff we have prepared them well for, what stuff blindsided them. And so we continue to tweak the content around that. Since we stay sort of on top of trends in general at a high level, this stuff hasn't moved much in the past few years. The coding interview has stayed largely the same, but there is some interesting new things around some companies that are moving away from the data structures and algorithms part of the coding interview and instead they're giving you what are sometimes called take home projects.

Parker: So they'll say, "Go and build an app that does this." Or they'll give you like a problem that's set up on a platform like HackerRank or something and you have a certain amount of time to build a thing where there's a little bit... they're paying attention to the efficiency of your solution, but it's a little bit more focused on, "Can you write code that successfully does the thing in a timely manner and is your code well styled and stuff like that. So there's some new trends in the space, but when it comes to the data structures and algorithms questions, those have largely stayed pretty similar over time.

Julián: Yeah, I know there is people that even do these as an exercise. I know people and I have friends that they go through different interviews at big companies, but just for practicing, they are not looking forward to landing to a job. They just want to go to the technical interview process to see if they are able to pass it. Do you have that type of users as well? People that are only looking forward to increase their expertise on tested out in our real code interview?

Parker: We do, yeah, definitely. And it's always exciting to me to hear about those types of users because to me it means that we're doing something very right. If someone thinks that this stuff is actually fun, it means that we're doing something right. So yeah, one of the things that we do to cater to those folks is we have a mailing list you can join where we take one of our practice problems each week and we take it out from behind the paywall and send it out to everybody. And so this is a way that without having to pay for our course, you can get this nice little drip of practice problems and stay sharp. Once in a while I hear stories about folks who get together to do the problem together, people in the same office or schoolmates. And I think that's just like super fun.

Julián: And what about competitive programming? You have also training material for joining a programming competition?

Parker: Yeah, that's a good question. That's actually something that we have been not steering towards. If you look in our space, there are a lot of companies that have started off doing something a little bit more like what we do, the coding interview preparation, and then they've sort of moved slowly into some recruiting stuff. So it's like, "Okay, well now we have all these great engineers, let's sell access to them to companies." And then it's like, "Well, okay, so if we're doing that we need to figure out who's the best among these engineers." And so they get more into evaluation and competitions and stuff like that. And over time our contention is when you're doing that with your product, as you become more focused on evaluation and sorting, right, you become more focused on figuring out who's already good. You get worse at making everyone better.

Parker: We've experimented with this stuff a little bit over time, but what I've learned is that for me, my superpower, the thing that I'm good at is teaching and so we don't focus on some of the other stuff around letting people compete and figuring out who's already good. We focus on just making everyone better.

Julián: Through making the interview a piece of cake.

Parker: Exactly.

Julián: Exactly. To learn a little bit more about the technical aspects of the platform, what type of languages do you support or what type of other exercises can you host in your platform?

Parker: Yeah, so our content is available in 10 different programming languages. That means that the practice problems, the code samples and also the code editor and the test cases and stuff are available in those 10 different languages. But it also means that the text of the problem is available those different languages. That means that when you change the programming language, which you can do on any question without a page refresh, it'll just change right there in front of you, not only do the code samples change, but the variable names might change from camel case to snake case and then whole sentences and whole paragraphs might disappear or appear depending on the different affordances of the language. So for example, a problem that's about reversing a string in place is going to be a little bit different in a language that has immutable strengths. So we really go back and rewrite each bit of content for each different programming language.

Julián: If I don't know pretty much anything about the technical interviews and I'm just new in these world of computer programming, can I benefit from Interview Cake or do I need to have some initial knowledge to use the platform.

Parker: We try our best to be able to take people from completely green on data structures and algorithms all the way up to ready to interview a Google. That is ambitious, but we really think it can be done. So the only prerequisite to start learning from Interview Cake is to be proficient with programming in general: variables and loops and all that good stuff. As long as you can sling some code pretty comfortably, you can start learning about data structures and algorithms with Interview Cake.

Julián: Do you have any other advice or recommendation for listeners?

Parker: I guess the biggest one is... and something I was also thinking about just now with your question about how much experience do you need before you can start using Interview Cake. A thing that a lot of people struggle with the coding interview is imposter syndrome.

Parker: And this is something we talk about a lot. Yeah. And it's insane that it happens to all of us, right? And we all think that the person next to us has it all figured out and we don't actually belong in the room, but that person next to us has that exact same thought, and especially in the context of interviewing it makes a lot of sense that we would start to doubt ourselves because we know that the game of the interview is, this person sitting on the other side of the table is trying to figure out if we're good enough, right? Or maybe put a little bit less judgmentally if we're a good fit, right? That's makes us ask ourselves the question, "Are we good enough? Are we a good fit? Do we know how to do this stuff? How can I prove that? How do I even know that for myself?" Right? And that's where the doubt creeps in.

Parker: So the advice that I like to give people is to first of all, just know that that's part of the process. It happens to everybody. That's just a part of your mind that you have to take as a given that you're going to have those thoughts. You're going to feel like you don't belong. You just have to remember that everybody feels that way. Even people coming out of MIT with fancy degrees and the way specifically that I try to help people to reprogram that thought process is to reframe things a little bit. So again, this a little bit easier to explain visually, which we do on the interviewcake.com website, but the fear that a lot of us have is that our knowledge is we know that it's... we don't know everything, right? We know that there's a lot of stuff that we haven't learned about yet and it seems like there's more and more stuff every day that we haven't learned about, right?

Parker: Suddenly everyone's talking about machine learning. Everyone's talking about data science, everyone's talking about neural networks, whatever, all this stuff, and you're like, "Oh my God, how can I learn all this?" And you have this idea that everyone around you knows more than you, but we've all had those moments where we've realized all at once that actually that's not true. What we picture in our minds, this thing where our knowledge set is like a small subset of everybody else's. The reality is, it's more like a Venn diagram, that same person who is sitting next to you in the office making you feel like an imposter because there's such a wizard with algorithm stuff and they can whip up some fancy backend tree traversal algorithm in a second, the next day they might come to you and say, "Oh my God, I've been trying to center an image for an hour and I can't figure out how to do it right." And you're like, "Oh my God. Yeah. I can sling CSS like nothing else."

Parker: The examples are going to be different for all of us but the bottom line is that there are these moments where we realize, "Oh, it's actually not true that, that everyone knows more than me." It's more true that we just have different little knowledge circles on this big enormous plane where nobody knows everything. And so there are moments where we're humbled and there's more stuff that we don't know about yet. And then there are also moments where we get to be the expert. And so I encourage people to have that picture of this big knowledge plane where all of our circles are small and overlapping various ways rather than thinking like everybody else knows everything and you're just this little speck.

Julián: Totally agree. I've been in this industry for more than 15 years and I constantly feel the same, that I don't know anything and there is a lot of people that know way more than me, but that's as you say, is not the reality, everybody knows some aspect of their technology or they master some things and they can help each other with others, which is pretty awesome.

Parker: Yeah.

Julián: I want to recommend something that helped me a lot when I was going through this interview process. Since I don't come from a computer science background, there is a series of books that I like a lot called The Imposter's Handbook. I'm not sure if you know that serious book.

Parker: I think I've heard of it.

Julián: Yeah. The Imposter's Handbook, it's a brief introduction to computer science terminology and concepts. It will teach about Big O notation data structures. It will teach about algebra, all of the different knowledge you'll need to have to understand what's going on with the whole interview preparation. So it's a very good starting point if you don't have that knowledge before going out to do practices and go on following a website like Interview Cake. So if you have the opportunity to search the book, I will be sharing the link with you all. It's very recommended and can give you a very good introduction about computer science.

Parker: Nice. That's great.

Julián: Beautiful Parker. Thank you very much for all your information about the how to pass coding interviews by using your platform on all of the different tips and tricks you gave to our audience and this has been another episode of Code[ish]. Remember I was Julián Duque and looking forward to hear you on the next episode. Thank you very much Parker for all your time.

Parker: Thanks Julián.