S1E8: How to rock your technical interview with Parker Phinney

Laurence:
Hey everyone, it's Laurence Bradford from the Learn to Code With Me podcast. Thanks so much for hanging out with me today. In this episode, I talk with Parker Phinney from Interview Cake. Parker is academically trained in computer science. He has worked in tech for some time, but now he helps others excel in their technical interviews. In our interview, we talk about what you can expect in your technical interview, as well as different ways you can prepare for it. The show notes for this episode are at learntocodewith.me/8.

If you've been enjoying the Learn to Code With Me podcasts so far, make sure you subscribe to the show. That way, you'll know whenever new episodes come out. Enjoy!

Hey guys, today I'm here with Parker Phinney. Parker, how are you doing today?

Parker:
Good, how are you?

Laurence:
I'm doing great. Thanks so much for talking with me.

Parker:
Yeah.

Laurence:
So, just to give the audience a sense of who you are, could you introduce yourself quickly?

Parker:
Yes. My name is Parker Phinney. I started interviewcake.com. Interview Cake is a study tool that helps software engineers prepare for coding interviews.

Laurence:
Nice. When did you start that again?

Parker:
About two years ago now.

Laurence:
Two years ago, wow. That's actually around the same time I started my site, Learn to Code With Me.

Parker:
Oh, cool.

Laurence:
Yeah. So before you started Interview Cake, what were you doing?

Parker:
I was working at a startup in San Francisco. It's called Symphony Commerce. It's a shopping site platform. When I joined there I was a software engineer and after my first year, or my first six months, I transitioned into the product management.

Laurence:
So you are academically trained in computer science, right?

Parker:
That's right, yeah.

Laurence:
Okay, cool. What gave you the idea of starting the Interview Cake site?

Parker:
A few things, I guess. I was at my job in San Francisco and kind of looking for the next thing. I wanted to have something of my own, but I didn't really have a co-founder or an idea yet. I was kind of on the lookout for ideas. Seemingly unrelated, at first, a good friend of mine did a coding bootcamp and doing the program was a big deal for her because she actually really needed a career change. She had fallen on hard times and lost her apartment and was out of money. So doing the program was a big deal for her and it was a big risk for her.

At the end of the program, when she was getting ready to start interviewing. This was the thing she had put all this time and money into preparing for. We sat down and I did a mock interview for her. So I did an interview like the one I was doing at the company that I was working at. And she really struggled with it. It was difficult for me to watch, because I knew she was a smart person. I knew that she knew how to build a website and I knew that if we had just talked about some of the concepts that we were going to be using in the interview, she would have done just fine. It wasn't a skill issue, or a smarts issue, it was just a familiarity issue. There were some data structures and algorithmic concepts that she hadn't talked about before.

So that kind of got me thinking about what the resources are that are out there so far to teach this. As I looked at stuff to recommend to her I kept thinking, well, I think I can do this even better. That was the beginning.

Laurence:
Yeah, that's really cool. You helped your friend prepare for this interview and she ended up getting the job, I imagine. Or at least one of the jobs she interviewed for, right?

Parker:
That's right, yeah. She's at Facebook now.

Laurence:
Oh wow, really cool. Okay, so when you're doing these mock interviews it sounds like it was really the technical kind of questions she was struggling with.

Parker:
Yeah, in particular it was the algorithmic questions. If I had asked her how something worked in Python or to write a function that did some kind of string manipulation or something, she would have been just fine with that. Where it got tricky was stuff like, what kind of data structure could we use to do this kind of thing or what's the difference between an array and a hash table and what are the strengths and weaknesses of a linked list and an array, stuff like that.

Laurence:
Your site Interview Cake focuses mostly on the technical types of problems, right? It's not the other questions you may get in an interview. It's really just the technical stuff.

Parker:
That's right, yeah.

Laurence:
Okay, cool. Turning back to you now, I'm just curious, was interviewing something that you were always naturally gifted at?

Parker:
No. Well, it's interesting that you would mention the non-technical stuff. I think when it comes to the non-technical stuff, yes, maybe? I feel pretty comfortable talking to people and being in front of an audience and such. But I really struggled with coding interviews at first. Just as I think most people do, right? For better or for worse, the particular game of the coding interview just is something that few people are naturally good at. It's very learnable. It does take specific practice.

Laurence:
So, when you were doing your interviews before and, also I know from looking at your LinkedIn, you worked at Google before the startup, right?

Parker:
That's right. Yeah, that was a summer internship.

Laurence:
Okay, got it. What would you do on your own to prepare for the interviews that you had?

Parker:
I just ran a lot of practice questions. I used a book called Cracking the Coding Interview, which is available on Amazon, definitely recommend it. I did a few mock interviews with friends I think, but mostly just kind of read through a bunch of practice questions. The biggest help, to be honest, was other interviews. This is something I always say is the best preparation for interviews is other interviews. When I got the job at Google, a big part of why it worked out is because I carefully ordered my interviews so that Google was one of the last companies I was talking to.

Laurence:
Yeah, I definitely think that is something that applies to almost anything. The more you do something the better you become at it. So the more actual interviews you do, even if you don't end up getting the position, the better you're going to become at interviewing in the future.

Parker:
Definitely and I think that there's a silver lining there for folks who are dealing with a string of rejections early on in the process. It's important to remember that part of what's happening is you're getting better, even if you're getting 'no's' early on.

Laurence:
Yeah, that's definitely something good that people can keep in mind. That's really interesting that, it's something that most people struggle with, the technical components. What I'm thinking is, even when you're reading the Cracking the Coding Interview book, or any other book about going over questions you may get in a technical interview, I feel like when you're there in person, especially when you have to explain the steps that you're going through, it's so different from working on your own. It's kind of like a communications skill then. You don't only have to do the problem, you have to explain how you're going about it.

Parker:
Absolutely. I think that's something that gets a lot easier with practice. And I think that's true for two reasons. One is that there's kind of a threshold you can get to where you could solve the problem but it's going to be difficult and it may not work out all the way in a high pressure environment, like in an interview. And then there's a threshold that you can get to where you can definitely solve the problem with your eyes closed, you know what I mean?

So part of what happens with nerves with people, when they talk about kind of freezing up in the interview? Part of my advice is, just keep practicing. Because as you go, you're going to get better at solving these problems. So you're not going to be nervous, because when you hear the problem you're like, "Okay, I totally know how to do this." And of course, the other way to sort of undo the nerves is to do a lot of interviews and to realize that you're not going to die and just develop some kind of comfort with that process of thinking out loud and solving a problem in front of someone.

Laurence:
Yeah, that's a good point, you're not going to die. What's the worst that can happen? Even if you totally freeze and you totally fail, unless the interviewer is totally heartless, they're not going to be mean to you. You may not get the position but. you're not going to die or anything. That's a good way of thinking about it.

When people are practicing the problems on your site or anywhere else for that matter, if they're alone practicing, do you suggest that they speak out loud when they're going through them? Kind of acting like they are talking to someone?

Parker:
Yeah, that's an interesting question. I'm not sure, I haven't suggested that specifically. I would have to practice that. I can kind of see that working or not working.

One thing I have heard of is people doing mock interviews where the interviewer is actually non-technical. Which is really interesting and actually really cool to me to hear about. I hear from folks who use Interview Cake for example, that their spouse or partner or whatever who is non-technical themselves, would pull up a question on their computer or on their iPad. The way that Interview Cake is laid out, they can kind of read the content on the site like a script, including the back and forth dialogue of hints and nudges that come up in a real interview. So that's one sort of way to try to capture the out loud element.

The other piece of advice that I give people, in terms of trying to capture the real nature of an interview is to not use a computer. To actually write code on a piece of paper or a whiteboard. I had a lot of companies that's how they'll do it.

Laurence:
Yeah, that's definitely a really good tip. I never even considered that, but you're right. You would be on paper or a whiteboard, so using that would be a lot, at least me, I'm thinking, I never write stuff out by hand, so just doing that alone could be kind of a jolt or something you're not used to.

Parker:
Absolutely. Just as with thinking out loud, it's one of those things that just adds one more bit of awkwardness. Again, it just takes a few practice runs to kind of get comfortable with it. But the first time you make all those mistakes of, “Oh I didn't leave enough space and now I have to add a line and I'm doing an arrow and I'm running off the edge of the page.” The medium gets in your way when you're not used to it.

Laurence:
So, right now, since I'm taking some notes since we've been talking. As far as the tips I've gotten so far, writing, like physically writing the problems on a piece of paper or a whiteboard, speaking aloud could be something to potentially try, having a practice partner to kind of run through the script with going back and forth.

Is there anything else that you suggest to people when they're practicing for an interview?

Parker:
Definitely, yeah. One thing I'm thinking a lot about, this has been kind of at the core of how I think about Interview Cake from the beginning, and I think there's a lot more for us to do still in this vein.
When you think at a high level about what you're trying to do when you prepare for the coding interview, I think a lot of people think that what they're trying to do is run a lot of problems in the hopes that one of the problems that they get, or hopefully all of the problems that they get in the interview, are problems that they've already done. That they remember the answer too. But of course it just doesn't work out that way. Because there are thousands of problems, right? Once in awhile you get lucky, or you have an interviewer that doesn't care so much about having a totally original problem.

What's really going to make you resilient is developing the ability to answer problems that you haven't seen before. If you understand yourself as doing that when you're preparing for the coding interview, I think it changes a little bit the way you think about running an individual practice problem so that it's not just about understanding what the answer is and why it works, because that doesn't matter that much unless you get that problem again and you remember the answer, right? What matters is understanding how you could have, from first principles, derived that answer, does that make sense?

Laurence:
Yeah, and when you were just speaking before, for some reason I was thinking about the SATs or maybe the GRE or GMAT, if people are familiar with those kinds of standardized tests, because I feel that no matter what, you can run through every essay question or every math problem and every vocabulary problem, and you're still going to go to the test that day and get questions you've never seen before. So it's kind of like, knowing that's going to happen and, as you said, preparing yourself to answer problems you've just never seen before.

Parker:
That's right, yeah. This is why a lot of services for coding interview preparation use what I call a flash card model, so there's the question and then you can flip to the back of the book or scroll to the bottom of the page and you can get the answer. What's missing is that process of how to derive the answer, right?

That's why with Interview Cake we have a little bit of a different layout with a bunch of hints and kind of the opposite of a hint, what I call a 'gotcha,' which is meant to catch you if you have a good answer but not the great answer. It walks you through how to derive the answer from first principles. This is all kind of a roundabout way of saying my advice to people is to really focus on that process of learning the way to derive an answer. This is where it gets concrete, right?

My advice is to get fresh notebook and every time you run a practice problem, take five minutes after finishing the problem to look back on the process and remember the moments when you got stuck. Think, 'what was the insight that you needed to have to get unstuck?' Maybe another way of thinking of that is, if you could have whispered one thing in your ear at that moment to get you unstuck, what would it have been? Actually write down that one thing, or those one to three things that were kind of like the core insights for the problem. If you do that for every problem, you'll amass this list of kind of like tips to yourself and filling in the gaps in your ways of thinking about things.

If you read through those notes at the beginning and end of every practice session, you'll get a really nice extra layer of rigor on your practice, so that you're not just learning a bunch of answers to a bunch of questions but you're learning a way of thinking.

Laurence:
Yeah, sounds good. The process of answering the questions. And then I liked the tip of writing it down, these little reminders, as you said the little secrets, like how to get through the problem. Using those to help you better prepare. That's all good stuff. Quickly, I'm kind of changing topics a little bit here, but as far as technical interviews go, do they vary depending on if it's a big tech company, maybe IBM or something, vs. a smaller startup?

Parker:
Yeah, good question. It's hard to say, unfortunately. You mentioned the SATs, unfortunately this isn't a standardized test, right? There's a lot of variance. One thing that ends up happening at a lot of companies, and a lot of people don't realize this, is that the kind of question that you get ends up depending more on which engineer is randomly assigned to interview you, than which company you're talking to. So there's just kind of a lot of variance.

I can say, at a high level, like a broad trend is that the big companies all generally use the classic, what's sometimes called a Google-style whiteboard coding interview. That's going to be really focused on things like data structures, algorithm design, Big O notation, stuff like that. That's going to be true at Google, Facebook, Microsoft, Amazon, Twitter. I'm not sure about IBM specifically, but I imagine it's probably the same.

As the companies get smaller, it becomes more of a mixed bag. You have some companies where the founders are a couple of engineers and PMs who quit their jobs at Google to start their own company and they do basically the same thing they used to do at Google. Then you have some people who themselves would never be able to pass the Google interview and think that it's a totally flawed system and instead will give you something more like a project. They'll say, "add this feature to this app," or "Build a simple website that does this. You have three hours, come grab me if you have any questions." So it's definitely a mix.

My advice to people is, in general, to focus on the algorithmic stuff, the classic Google style interview stuff. Mainly because that's where the weakness is for most people, you know what I mean? I don't know that there's a whole lot that you can do to prepare for those 'build an app that does this' kind of interviews. Presumably, if you already know how to make a website, then you'll do fine.

Laurence:
Yeah, that's interesting. So it's kind of like, some of these smaller companies, or maybe even big ones as well, they'll give you more of a real world "project" to build in a limited amount of time. Then some of the bigger companies you mentioned, it's more of the classic whiteboard style interview.

Parker:
Yeah. Although I would say there are many small companies that do the classic whiteboard style thing. So it becomes much more mixed as the companies get smaller. One thing you can count on is for the big companies, you'll definitely have the whiteboard style coding interview.

Laurence:
Do the bigger companies ever give assignments like that? Maybe it's like 24 hours or what have you but kind of like a 'build it then show me' type of thing?

Parker:
They sometimes do. I know in the past, I don't know if it's true anymore, Facebook worked with a company that was called Interview Street at the time and I think is now called HackerRank.

Laurence:
Oh, okay. I've heard of HackerRank.

Parker:
Yeah, so they would give you what's sometimes called a 'homework assignment.' So it was just as you described, like a timed challenge. Usually though, when that's done at a bigger company, it's a screen, so it's like the first step in the process.

Laurence:
Oh right.

Parker:
The heavier stuff, basically everything past that is still the classic whiteboard coding interview, I believe, at least in the United States. Apparently it's very different in India, I've been learning recently, but that's a whole other story.

Laurence:
Yeah, that's makes sense though about the screening and having you do the task or assignment, homework, whatever you want to call it, before you even get brought in for the in-person interview. And I definitely heard of that as well. One of the last people I interviewed was talking about his interview process and that was one of the first things they did to kind of screen people out. They have you do that first assignment.

Okay, we're getting towards the end of our chat here but a few more quick questions. About how many hours, or maybe you can even do something like weeks, should a person spend preparing for an interview. And let's just pretend this person has a very good understanding of all the technical stuff. They went to a coding bootcamp or they graduated with a CS degree.

Parker:
Well, I think there may be a somewhat big difference between those two, actually, the coding bootcamp and the CS degree. Just because the Google style whiteboard coding interview deals a lot with algorithm design and Big O notation and stuff. Some folks coming out of coding bootcamps are really comfortable with that. Some folks haven't covered that very much. I think people who have done less of that will definitely need to do more practice.

One kind of ballpark is, I think something like 30 real practice questions is a super solid foundation. So if you can kind of shoot for that and imagine each question is maybe about an hour as you're getting started, they might be more. As you get more comfortable you might breeze through some of them in like 10 minutes, 20 minutes. If you can get through about 30 questions and they're about an hour each, that's maybe a month of an hour a day, or if you can spend a little bit more time on weekends, maybe you can get through it in a couple weeks. That's kind of a ballpark I would say.

Laurence:
Okay, yeah cool. That's a good point about the difference between coding bootcamp and computer science. They are quite different. I guess what I was trying to say is, assuming the person did have some level of technical knowledge, so not a person who couldn't even comprehend some of the common questions. I guess with the computer science degrees and the coding bootcamps as well, it could probably vary a lot depending on where you went, like the school or the program you went through.

Parker:
Definitely. A big part of the coding interview is algorithmic thinking, for better or for worse. And that's why I say, it's one of those things that requires focused practice, no matter where you're coming from, I guess unless you were doing algorithms research. It's something that requires focused practice for most people.

Laurence:
Alright, last question. A person has a technical interview coming up. What is one thing that they must do to prepare.

Parker:
Well, I will say, if people are kind of coming in cold, if they've never done a coding interview before, and this is a little bit of a plug, I would definitely recommend reading the coding interview tips article that we have on Interview Cake. I believe the URL is interviewcake.com/coding-interview-tips. The reason I recommend that is because it gives you a step-by-step process for how to solve a single coding interview question, including a lot of common mistakes.

One example is, it's very easy as you're solving a problem on a whiteboard, to get stuck in the weeds of one small detail like, 'should this be a less than, or a less than equals or something. And then you go in and you trace through the code in your mind and you go, 'okay, it should definitely be a less than.' Then you fix that and then you zoom back out and your forget what you were supposed to do next. This is a very common, very easy mistake to make. My advice is to first sprint through a draft of the code and whenever there are those things that you're not quite sure of right away, or places where there might be a bug or an off by one error or something, just put a checkmark to remind you to come back and check it, because you're going to have to go back and debug anyway.
That's just one example, but there are a lot of common pitfalls like this that are spelled out in that article.

Laurence:
Okay cool, I will definitely put a link to that in the show notes and I'll make sure to double check if that is the right URL or not so it will be there. Thanks so much Parker for talking to me today. Where can people find you online?

Parker:
The website for our interactive practice tool is interviewcake.com, so you can remember it because it makes interviews a piece of cake. We're also on Twitter and Facebook with the name Interview Cake and people can email me, parker@interviewcake.com. I don't always have time to respond but I can say I read every single email.

Laurence:
Alright awesome, thanks so much again.

Parker:
Alright, thank you.

Laurence:
I hope you guys found our conversation helpful. Parker was kind enough to give a special 20% discount off Interview Cake to Learn to Code With Me podcast listeners. Simply go to learntocodewith.me/interviewcake to access the deal. Again, the URL is learntocodewith.me/interviewcake, just one word. Keep in mind that this discount is available for a limited time. If you're interested, make sure to take advantage of it sooner, rather than later.

You can also visit the Show Notes page at learntocodewith.me/8. There you'll also find a transcript to the episode.

In today's show, we talked all about acing your interview, but how do you even get a foot in the door to the office? You need to get the attention of a hiring manager or a recruiter. And in my opinion, one of the best ways to get their attention is on LinkedIn. That's why I created my five day LinkedIn crash course. You can find it at learntocodewith.me/linkedinbook. Inside, you'll find the basics of setting up your LinkedIn profile, how to write a compelling headline, summary, and experience section, how to format your LinkedIn profile in a way that will attract the right recruiters and hiring managers, and much more. Again, the URL is learntocodewith.me/linkedinbook.

Again, I hope you enjoyed today's episode. I really appreciate you tuning in. Next week I'm going to be talking with Becca Refford. Becca is a young woman who left college to pursue coding full time. Her story is awesome, you don't want to miss it. Thanks again, this is Laurence Bradford, and I'll see you next time.