[00:00:10] SY: Welcome to the Code Newbie podcast, where we talk to people on their coding journey in hopes of helping you on yours. I’m your host Saron, and today, we’re talking about technical interviews. (Music) Parker Phinney is a developer.

PP: My name is Parker Phinney -

SY: And he’s had his fair share of being interviewed, conducting interviews, and now-

PP: I run a company called Interview Cake that prepares software engineers for coding interviews.

SY: So I wanted to hear his thoughts on the interview process, why so many people find it so scary, and how new coders can do well in their next technical interview. After this. (Music)

[00:00:48] When I first learned to code, all I wanted was to be a developer. But then I actually learned to code and realized that you don’t become a developer - you become a front-end developer, or a Rails developer, or a full stack engineer or a back-end engineer or a million other job titles that involve coding. So how do you pick? And once you get that first job, how do you turn it into a career? You can use the Dice Careers Mobile App. This is the tool I wish I had when I first started. You pick the tech skills you either have or hope to have in the future, you type in your desired job title, and Dice helps you find the other job titles you may also be interested in and maybe didn’t know about. But they take it a step further by telling you what skills these job titles require, how much they pay, and - based on your profile - they tell you what skills you might want to learn so you can one day apply for those jobs. They simplify a lot of the chaos of job hunting, and it’s totally free. So check out the Dice Careers Mobile App. Go to dice.com/codenewbie for more info. That’s dice.com/codenewbie.

[00:01:45] SY: Flatiron school teaches you how to code from anywhere. They’ve got an awesome community of career changers, and a number of different options for you to pick from to become a software engineer. They’ve got full time, in person courses, self-directed introductory courses, and a remote online web developer program. They even have a free, 75 hour online prep course where you can learn JavaScript, Ruby, and do some interview prep. 

Go to flatironschool.com/podcast to learn more. That’s flatironschool.com/podcast. Link is in your show notes. 

[00:02:23] One of the best parts of being a coder is finally being able to bring your passions to life. You have the skills go design, to code, to create the thing you’re excited about, and share that passion with the world. And Hover can help you with the first step of sharing your passion with the world - getting your domain name. They’ve got really easy and beautiful to use interface, where you can find and register your new domain name in just a few steps. And to give you full control, they separate your domain name from your hosting. So you’re never stuck with one service. They keep your domain name safe while giving you the flexibility to use whatever hosting service is best for you. They also give you free WHOIS privacy, so your personal information is safe too. To get started, go over to hover.com/newbie to save 10% on your first purchase. That’s hover.com/newbie. Link is in your show notes. 

[00:03:08] SY: So I’m so excited to dig into this because I think that the technical interview process might be the scariest part of being a developer, no matter if you’re a code newbie, if you’re an experienced developer, I feel like it’s just scary to everyone. Was it scary to you before you started Interview Cake? 

[00:03:26] PP: Absolutely. Yeah.

[00:03:27] SY: So what makes it so scary? 

[00:03:28] PP: I think the thing that scares a lot of people is that - for better or for worse - the coding interview at a lot of companies is somewhat divorced from the day to day of what you actually do as a software engineer. In particular, companies like to ask about data structures and algorithms, right? Where data structures are, like, low-level computer science-y stuff. Stuff that people might not have touched before if they’ve never programmed in a language like C or Java. And companies like to ask about this stuff to get a sense of whether or not you can see that low down in the stack. But for a lot of people, the day to day of building a web application doesn’t have to do with that stuff. 

[00:04:09] SY: Yeah, and that thing you said at the very beginning, where it is removed from what you actually do from the day to day - if it’s removed, then why even ask those questions?

[00:04:22] PP: I’m not entirely sure, but I have some guesses. I think there’s some history to it. My understanding is that Google really popularized this type of interview, and it was at a time when Google was smaller, and they really had a rep for being where all the nerds went. And so there was all this mythos around the Google interview. And there were these articles that would come about, you know, here’s some sample Google interview questions, and they were very math-y and technical. So I think there was a moment that was kind of the game, and there may even, like, be some amount of one upmanship to the coding interview at some companies sometimes. Some companies kind of take pride in having particularly hard interviews. So that’s kind of the pessimistic story. But I also think there’s a more optimistic story, which is that at a company like Google, you’re building applications that have to run at really large scale. So YouTube has to process, like, massive number of requests every second. And so in order to do that, your code needs to be really, really efficient. You actually do have to think about this data structures and algorithm stuff. So I think there is a way in which if you’re really building something at scale, data structures and algorithms stuff is really important, so there are ways in which the coding interview could be pretty relevant. 

[00:05:43] SY: I think there’s also a third reason, which is a more - I don’t know if it’s pessimistic - but, more practical - Which is that, if it’s good enough for Google, it’s good enough for me. You know, it’s way easier for me to pick a handful of really hard computer science-y questions that have already been vetted by some of these big tech companies than to figure out a whole new process of how to assess technical skill.

[00:06:07] PP: I think that’s absolutely true. I think there’s a bit of a copycat kind of aspect where the process was kind of popularized by Google, and then everyone wants to be like Google, right? Another thing that I think is kind of interesting about the history of the coding interview is that data structures and algorithms are things that people coming out of big name computer science programs will have drilled quite a bit. In particular, it’s a way for people that are already in that cohort - like really dig deep and see if you’re in the top percent of people coming out of MIT or whatever. Which I think makes it interesting that it’s still in a lot of ways the defacto standard because people are learning to code in all kinds of different ways now.

[00:06:51] SY: Right. Yeah - that is really, really interesting because if I’m expecting to get most of my employees from CS programs, then I want to pick the smartest CS student. And, how do I do that? Well, I measure how they do on the questions that they've already been studying and the topics they already know. So in that sense, it’s almost like the technical interview might be designed for one particular audience and maybe that was fine for a while, but nowadays, with so many people learning on their own, learning through bootcamps, learning through online courses - so many different ways to get into tech - that really sucks for everybody else.

[00:07:31] PP: Yeah, I think that’s true. I think there’s also an idea that - especially if you’re hiring junior developers - there’s this idea that there’s a distinction between the skills that can be learned, and the skills that can’t be learned. Some people use the word “smarts,” and I think part of the idea behind the data structures and algorithm and coding interview is that it really pokes the smarts piece. Whereas the skill of, you know, writing very clean code is a little bit more learnable.

[00:08:05] SS: So, given your vast experience with technical interviews and technical interview questions, do you think that’s true? 

[00:08:11] PP: I’m being honest when I say that I’m on the fence. I think there’s some truth to it. I think that people underestimate how learnable of a skill algorithmic thinking is. And so I think there’s this idea that writing clean code is something that just comes with practice, whereas some people when they’re given a difficult algorithmic problem are able to just have blind insights and be struck by genius, and give you the answer. But I think that even when it looks like someone is doing that - like they’re really kind of Rainman-ing their way to some immediate stroke of genius - there’s an underlying process that my contention is that process is actually very learnable.

[00:08:56] SY: Yeah, I remember Sarah Drasner tweeting something that I really, really liked recently where she was talking to beginners, new programmers, code newbies, and she said, Do you remember what it was like to first learn how to drive a car. When you first get in the car, you don’t really know- you can’t  feel how big the car is, and how hard you need to turn, or how much you need to press the brakes. You don’t really have a sense of it. But over time, eventually it becomes so normal that it’s natural - how could you not know how much room you have and how much space the car takes up. And I think coding in a lot of ways is like that. It's so amazing to me how many times I’ll look at something - this new problem that I’ve never seen before - and I think, Oh man, how do I even begin to unpack this? But then once it’s unpacked, and once I’ve crossed over to the other side, I look back and I go, How could I not have understood this? (Laughs)  I don’t even remember what it’s like to not know how to do that. And so, yeah, once you cross over, it’s so easy to look back and feel like, you know,it’s this natural thing, but you’ve still learned it.

[00:10:04] PP: Yeah, and I think algorithms are something that seem particularly abstract to people, and I think that it’s - that's a fallacy that actually comes largely from the fact that a lot of people that teach it just don’t teach it very well. 

[00:10:20] SY: Mmhmm. I agree. (Laughs)

[00:10:21] PP: A lot of people teach it in a kind of very math-y kind of way, very proof focuses. But people don’t think in proofs. People think in shapes and relationships. (Music)

SY: Coming up next, we talk more about how to prepare for technical interviews, and what the future of these interviews might look like. After this. (Music)

[00:10:43] SY: When I learned to code, I was so excited to finally bring my passions to life. I could build things that I really cared about, and share them with the world. And the first step in sharing is getting a great domain name. That’s where Hover comes in. They’ve got a really slick, easy to use interface. They’ve got awesome domain names to pick from, and they separate your domain from your hosting, so you have full control and flexibility over your online identity. So go to hover.com/newbie to save 10% on your first purchase. That’s hover.com/newbie. Link is in the show notes. 

[00:11:16] SY: You wanna get serious about learning to code, but where do you start? Flatiron School’s got the perfect thing. They’re offering their free, 75 hour online prep course, where you dig into JavaScript, Ruby, and more. If you’re not sure where to start, start there. And when you’re done, you can keep learning with their self-directed introductory courses, remote online web developer program, or full time in person courses. Whatever your schedule, they’ve got options to help you reach your coding goals. To learn more, go to flatironschool.com/podcast. That’s flatironschool.com/podcast. Link is in your show notes. 

[00:11:53] Getting a job is one thing. Building a career is another. With Dice you can do both. They’ve been helping tech professionals advance their careers for over 20 years. Which means they have a ton of data and tools to help you navigate yours. Looking for a job right now? They’ve got thousands of positions available from top companies like AT&T, Dreamworks, Adobe, IBM, and Dell. Wondering what’s next in your career? Use their career pathing tool to find new roles based on your profile and see how much more money you can make. Not sure you’re getting paid what you’re worth? Use the Dice salary predictor to see real numbers on what your skills are worth. Don’t just look for a job, manage your career, with Dice. (Music) for more info, go to dice.com/codenewbie.

[00:12:37] SY: So, we’ve talked a good amount about our opinions and a little bit about the history of technical interviews, but we haven’t really talked about what a technical interview actually is. So for people listening who have never done a technical interview, they’ve maybe heard a little bit about it here and there, how would you describe it?

[00:12:51] PP: Yeah, so it varies quite a bit by company, but the standard Google-style coding interview usually lasts about an hour, and your interviewer will kind of bookend the interview with ten minutes at the beginning and at the end, first to kind of chit chat about your resume at the beginning, and then to say “do you have any questions for me” at the end. But the bulk - solid 45 minutes - is going to be spent solving a technical problem. It could be a small set of two or three problems. But very often it’s just one long and kind of tricky problem. One common interview question, for example, is write a function to reverse a string in place. If it’s a phone interview, they’ll give you a link to a webpage that you can use to write out your code by hand in your web browser. If it’s an onsite interview, they may set you up with a computer. Traditionally, though, they’ll put you in front of a whiteboard, so you’ll actually be writing out your answer on a whiteboard. The interesting part is, the interviewer doesn’t just give you the question and then sit there silently, or leave the room and say, “I’ll be back in 45 minutes for your answer. “ They sit there with you and - some interviewers are more quiet than others - but the majority of them work on the problem with you. It’s something that I think a lot of people forget, and people that are new to the coding interview don’t realize, but should take some comfort in. Which is that your interviewer is there, kind of on your team. And the more that you think of them as someone who is solving the problem with you, the better off you’ll be. So there are gonna be moments when you slow down, or you get stuck, or maybe you start solving the problem one way, but it turns out there’s a better way to solve it. And your interviewer might interrupt you and suggest new ideas or ask questions about what you’re trying to do. What you’re trying to figure out as an interviewer is the answer to the question: Okay, if this person were on my team, and I was having a moment where I was having difficulty solving a problem, is this the person who I would want to turn to and say, “Hey, do you want to grab a white board and help me figure this out?”

[00:15:03] SY: So what are the rules in that situation? You mentioned ideally, hopefully, usually, the interviewer is kind of a collaborator, kind of a team member. It’s usually conversational. You’re allowed to talk to them. Are there certain things that you are expected to do, or maybe things that you should maybe avoid doing?

[00:15:21] PP: So one of the things that you’re expected to do is to think out loud. Which, again, you may do naturally if you easily settle into the idea that it’s a collaboration with you and the interviewer. But some folks need a bit of practice or a bit of prodding on this. So the interviewer gives you the question, and you’re supposed to sort of immediately start asking clarifying questions about the question, or explaining sort of what your first ideas are, or drawing out pictures on the whiteboard, but all the while you’re supposed to be talking. You’re never supposed to be silently working on the problem. 

[00:15:59] SY: So what happens if you don’t know - if you’re just stuck, you don’t know what to do? Are you allowed to admit that?

[00:16:02] PP: Yeah. I think the answer is yes. You can just admit that. Say in particular, as specifically as you can, what you’re stuck on. Because again, the thing that the interviewer is trying to do is picture what it’s going to be like working with you on a problem. And if you’re the kind of engineer who says, “It doesn’t work. I don’t know why,” and asks someone to help you debug something, but without giving any specificity, that’s going to be frustrating. But if you’re the kind of engineer who says, “You know, this isn’t working, and I’ve been able to isolate the problem to this line. I expect it to give me this, but instead it’s giving me this. Do you know why?”

[00:16:48] SY: Yeah, that’s good. That was a good one.

[00:16:51] PP: If you’re really stuck, sharing as specifically as possible what you’re stuck on can be a big help.

[00:16:56] SY: And even in the version you just did right now off the top of your head, it showed me what you do know. So in the process of admitting, reviewing that you’re stuck and you’re not sure what to do next, you’re also telling me what you do know, and that makes me go, okay, so it’s just one little piece. And maybe as the interviewer, I decide to help you out. Maybe I say, “Oh it’s just this one thing. Let me give them that one piece of information,” and then hopefully you can get yourself unstuck. 

[00:17:23] SY: So tell me about your personal technical interview experiences. How many technical interviews have you been on?

[00:17:30] PP:The last time I interviewed for a job, I was in college. So it was a little while back. I remember doing quite a few interviews and in particular, I think I was clever at the time, I kind of bombed my first interview, and I did a little better on my second interview, and I realized, Oh, you know what? I should really be treating these as practice, and so I should put the companies I care the most about at the end. And maybe reach out to a few more companies that I’m pretty lukewarm on, just to get some practice in. Fun fact, one of those companies I was pretty lukewarm on in the beginning, ended up turning out to be a great fit and I ended up working with them. So it’s not entirely dishonest to do that. But I’ve also been on the other side. Out of college I was working at a small company that was growing really aggressively and I was interviewing as many as, like, one or two candidates a day -

SY: That’s a lot -

[00:18:33] PP: - Which was, you know, gave me a lot of insight - being on the other side of the table - definitely. 

[00:18:38] SY: I was going to say, you know all the secrets. So, as someone who’s doing an interview a day - wow, that’s a lot of people. How did you - and maybe as a team effort, you and your team - how did you decide what questions to ask? 

[00:18:52] PP: I don’t have a great answer. Each person kind of had their own pet question, and as far as I know, that's true at a lot of companies. People like to ask, you know, tips for the Google interview, or tips for the Amazon interview, or whatever. And what I tell people is the specific question that you get, and the rest of your interview experience, is probably going to have more to do with which engineer at Amazon gets randomly assigned to interview you that day, than whether it’s at Amazon versus Google versus Microsoft, etcetera. As to why that happens, I’m not entirely sure. I think there’s - people really have their pet interview questions, and some people really, really stand by them. So our interview questions were pretty all over the board. 

[00:19:39] SY: So I’m trying to decide how I feel about that. Because on the one hand, if I come in for an interview, you’re interviewing me, and you’re the person I’m also going to either work with, or work for. It kind of makes sense that you get to decide what question to ask me, because you know, we have to work together, right? So I have to kind of work up to maybe your standards, to a degree, and you have to feel confident in my skills and abilities. But on the other hand, it feels weird that individual engineers have that much power. I would think that the company as a whole would have maybe a problem set, you know, or here are the ten questions we generally ask, and you pick from them. It feels a little unfair, maybe. A little strange, a little concerning that you even get to have a pet question.

[00:20:34] PP: And it gets a little weirder because at smaller companies lie the one where I worked at, it is true that if you got the job you would have been working with me. At bigger companies, including really big companies like Google, the people that you interview with are not likely to be people that you will work with. So there’s really a lot of randomness then. It might be luck of the draw that you get some interviewers that are really difficult, or that you, personally, find difficult, because they’re on topics that you’re a little bit weaker on. I vaguely understand that Google in particular tries to have a lot of tracking around that stuff, and normalize for that. I’m not sure how that works, but I have some guesses about, you know - they may notice that an interviewer's evaluations may be a little harsh, and then change the weight around that or something. But even so, yeah, there’s quite a bit of chance. 

[00:21:27] SY: So, yeah, did you have a pet question that you liked to ask? 

PP: Yeah, I think the question was: Given an array of numbers, where all the numbers are in the range one to a hundred, but the array is huge, it has hundreds of millions of numbers in it, so there are going to be a lot of repeats. Return a new array that has those numbers in sorted order. And the reason that I liked that question is because there are a lot of different ways to do it. It's a real data structures and algorithms question. Because the difference between all the different ways to do it  is how efficient your answer’s gonna be. 

[00:22:06] SY: So with that question in particular, what information are you hoping to get about the interviewee?

[00:22:11] PP: I’m hoping to get a sense for if they understand how different data structures work, and how algorithmic efficiency works. When I ask this question, I expect us to talk about Big O notation which, if people haven’t worked with it before, it’s the language we use for talking about how long a function takes to run. It’s a question that really gets in the weeds a little bit.

[00:22:41] SY: So, given the earlier point earlier in the conversation about how the question doesn’t always match the job, did your pet question change, or was it affected at all by the specific role that you were interviewing for?

[00:22:59] PP: Not generally at the time. I think there were some cases where we were interviewing folks for purely front-end roles, the expectation was that they weren’t really writing code, they would just be writing markup. So in those cases I just talked about style sheets, or something, I think. But for the most part, I used the same question for everybody.

[00:22:23] SY: So when you think about your role as the interviewer, if the person got the answer right, or got the answer that made you think that this person would be a good fit, but they got there because they essentially crammed - they spent the last week, two weeks just memorizing all these things that they could - and, let’s even put some more on there. Let’s assume they heard that question before. They found that question and it happened to be one of the five questions they studied. Do you worry about that? Do you feel like it’s - I don’t want to call it cheating, but - more than likely they’re probably going to forget a lot of the stuff they crammed for because it’s crammed, right? So how do you feel about that? How do you feel about it from the employer’s perspective, having all these really amazing talented people, but in the questions that you’re asking in the interview, they might only know it for the sake of the interview. 

[00:24:12] PP: I’m not so worried about that. In particular, this potential issue of maybe they know the answer because this came up in a practice session. The interview is, this is the thing that people forget - it’s a dialogue. So if someone kind of gave the right answer right away, I would ask some questions, right? I would say like, ”Oh, okay, that’s interesting. What if we did it this way? “ Where I would suggest a worse way of doing it. If they said, “Oh, yeah, you’re right. We should do it this way,” I would go, okay, either they were lucky that their first guess was the best way to do it, or they had already seen the problem, or something. I think when I tell the story sometimes, they think I’m trying to trick the person, or set a trap. The idea is to kind of poke at the difference between a lucky guess or having heard the answer before, and a deep understanding of why this is the right answer. Because that’s the important part, right? And that’s something that you can’t cram or memorize. 

[00:25:10] SY: So, when you were talking about how the dialogue, the conversation that happens in the interview, is probably the most important part - more important than maybe the actual question and answer, that’s so different than I think the way most people who are still figuring this out, who are still relatively new to this, how they think about it, and how they study for it, because I remember when I was sitting for technical interviews, my strategy was to learn and basically memorize as many technical interview algorithm data structure type questions I could find, and hope that the person asked something that I had seen before. That was my whole thing. That was my whole strategy. And I kind of figured out over time - after a number of, you know, terrible, and some good interviews - that huh, what really matters more is the conversation, and I was able to adjust my strategy and really optimize for that. But I wish I knew that sooner. I wish I knew from the very beginning that it’s that conversation that’s so important. So when you think about people who are either going through that process now or are going to go through that process, how can they study, how can they prepare for a way that optimizes for the dialogue instead of just memorizing questions? 

[00:26:30] PP: I have a bunch of ideas for that. But first I just want to echo what you just said, because that’s absolutely true, and it should bring some comfort to folks who are scared of the coding interview. One thing I want to say is something that surprises people - is that sometimes your interviewer does not fault you for needing a hint. And in fact, if you jump right to the answer right away, your interviewer might just say, “They solved the problem right away; they had probably seen it before. So like, it was a wash.” 

26:43 SY: And they give you a new one (Laughs)

PP: Well, yeah, if they have time they might. If not, they might just kind of throw that out. The reason I point this out - and this is again, one of the defenses that I can think of for the data structures and algorithms coding interview - is that it’s sort of designed to make you get stuck. Because they want to see what happens when you’re not sure what comes next. To the point where, again, if they don’t get to have any of that experience because that problem was too easy for you, they may just kind of throw out the interview and say, “I didn’t get o get any signal. I didn’t get to see them get stuck.”

[00:27:39] SY: That’s really comforting and what I’m thinking about - how do I optimize for that? How do I build a technical interview prep strategy, it sounds like it’s more valuable to understand the foundation of some of this stuff more so than just trying to go through a large set of questions. So you know, maybe for the questions that you are able to study and go through, really making sure you have a fundamental understanding of why and where it came from, and what are the building blocks that you can apply that - or at least have a conversation about it - for the question that you might get that you haven’t seen before. 

[00:28:18] PP: Exactly. That’s what I’m all about. It’s all about not memorizing the answers to common questions, but really developing the skill of algorithmic thinking which, in my curriculum just kind of breaks down into a small set of common patterns. One of those patterns is take two pointers, and point them to different parts of your input, and move those pointers around as you iteratively solve the problem. So, for example, the classic problem where you are reversing a string in place. The answer is to put a pointer at the beginning of the array, and put a pointer at the end of the array. And by pointer I mean depending on your programming language, you just keep track of the zero index and then the last index of the string of the array. And you swap the characters, and then you walk the indices towards each other until they meet in the middle, and then you swap everything. That idea of two pointers also comes up in classic problems around linked lists. There’s one question when you’re checking to see if a linked list has a cycle or not. And that idea of two pointers comes up again. There are a few other linked list problems where that comes up. If you’re paying attention when you’re doing your interview prep, you’ll notice coming up again and again. And once you have those patterns, that’s when you unlock the ability to seemingly kind of Rainman answers out of thin air. 

[00:29:44] SY: SO I think the other part of technical interviews that just makes it really hard is even if you have that knowledge, you have that foundation, it’s just really scary (Laughs) It's just - your nerves can get the better of you. It’s just you and this person you’re trying really hard to impress. Especially if you’re new, you don’t have a computer science degree, you have all kinds of - you second guess yourself, you feel totally self-conscious. It’s not necessarily a very high confidence type of situation. On top of that you’re job searching, so there’s a lot of pressure probably financially to get a job and get paid. So, it’s such an emotional experience, and a stressful experience. How do you manage that side of things?

[00:30:29] PP: It’s a context in which for a lot of people imposter syndrome can start to creep up. And it’s not at all hard to understand why, right? Because you’re thinking about the job search, and you’re realizing that the question that person is going to be asking is “Are you good at this? “ So how do I prove that I’m good at this? And then you ask yourself “Am I good at this?” You’re like, “Oh, my god, am I good at this? Am I not meant to be an engineer?” The first step that I like to teach is to just understand that that is a natural part of the process. That’s a feeling that is very common, and it makes sense. It would be a little weird if you weren’t a little scared, and you didn’t feel a little bit like an imposter. Hopefully, it’s also comforting to know that your interviewer also has a lot to learn. 

SY: Mhmm. Yeah

[00:31:17] PP: Even if she is much more senior than you. And I think we’ve all kind of had moments like this. ANd they only come up more and more as we advance in our careers where there's someone who we really put on a pedestal, and then you notice that they’re working on a project and they spent two hours trying to figure out how to center an image on a webpage. 

SY: (Laughs)

[00:31:42] PP: And you're like” Wait, I know how to do that. In CSS that’s easy.” So we all have our proclivities of different types of problems, different types of work. But we also just all have things that we haven’t learned yet. In the context of the interview, it’s going to seem like the interviewer is this amazing expert, because they’re going to be an expert on the problem that they’re asking. But you’ve gotta remember that they’re an expert on that problem because they’ve asked it a hundred times already -

SY: Yeah -

[00:32:12] PP: And in fact, probably the reason that they’re asking it is because when they were asked that problem, it was really hard for them. Yeah, you have things to learn, but so does everyone else, even if that's going to be a little hidden to you in the interview process, just because of the format. Hopefully gives people a little perspective. 

[00:32:32] SY: I love, I love, love, love that point you made about the interviewer. Because they probably like that question because they’ve asked it a bunch and they’re really comfortable with it. Maybe it was a problem that stumped them, and they want to see how others hold up, and they’re not necessarily the expert of all things computer, but they’re an expert on that one question, and I think if you keep all those things in mind, the power differential is maybe a little bit smaller, you know, it maybe feels little more like this is a partner, a potential team member, someone I’m going to work with, and not a god of tech, gateway, entrance. It kind of becomes a little less serious, and a little more approachable. 

[00:33:16]  PP: The advice I like to give around this is - because sometimes it's hard to fix a way of thinking by just saying “don’t think this way” so it’s easier to replace it with another way of thinking - So I try to tell people instead of thinking about you know, “Am I going to get this right,”replace that with “This is going to be a cool opportunity to work on some potentially really hard and interesting problems with some really smart people.” And the more that you can really think of it that way, and think of it as a free tutorial - if you can, try to convince yourself that that’s fun, and try to picture that that’s what you’re doing. 

[00:33:54] SY: Yeah, I really love that. So when you think about the future of the technical interview, one thing that I find really fascinating is more and more developers - especially senior developers- are kind of speaking out against the traditional whiteboard interview specifically. And they are saying a lot of the things that we’ve already discussed. Which is - doesn’t quite actually match up to the actual job. It’s kind of testing more CS degree fundamentals versus actual applicable things you’re going to do day to day. And especially, the other part of it is, you know, a lot of technical jobs don’t really require understanding as much as it used to - understanding the full stack. Even what we call the full stack developer now is not the same thing as what it used to be, even ten, twenty years ago. So given all of that, there’s a lot of pushback against whiteboard interviews, technical interviews. So how do you understand that? Do you feel like we are soon going to make a real shift in expectations for what a technical interview is? Do you feel like it’s kind of a small group that’s making a little bit of noise but we’re mostly going to continue as we are?

[00:35:08] PP: I really don’t know. It’s hard to say and again, you know, I’m kind of on both sides of the fence in terms of the ultimate efficacy of the coding interview. I think there are ways in which it can, when done well, poke at smarts as opposed to skills. And I think that’s part of the power of it. But especially when done poorly, it can single out people who don’t have a more traditional computer science background. Whether or not it's important that somebody knows data structures and algorithms depends on the company. My best guess is that what we will see - and I think we’re already seeing this a bit - is just sort of different camps evolving. And different companies doing things differently. And it’s already true that a lot of companies, the way the interview works is you show up and they say, “Okay, here’s a laptop. Build a web app that does this. And you have four hours, and then let’s talk about it when you’re done.”

SY: Not to bad. I don’t mind that.

[00:36:10] PP: I think it’s great. So yeah, I think we’ll see a division kind of continue to happen where now instead of just one way to interview, which is the old popular Google style whiteboard coding interview, there will be kind of a menu that companies pick from.

[00:36:27] SY: A build your own technical interview. That sounds great. So what advice do you have for newbies, for folks who are pretty early in their career, who are still trying to figure out how to do well on these technical interviews. What advice do you have for them? 

[00:36:44] PP: Yeah, the biggest advice I have is to practice. TRy to get more interviews. You first intevriews are going to be a little bit more rough, and as you interview a few more companies, it will start to come together a little bit more. Do mock interviews. You can grab a buddy, or you can use any number of online mock interview services. A couple that are coming to mind right now are interviewing.io and Pramp. And run practice questions just on your own. We have a bunch on Interview Cake and interviewcake.com.

[00:37:18] SY: Very cool. So now let’s move on to fill in the blanks. Are you ready?

[00:37:22] PP: Yeah.

[00:37:23] SY: Number one. Worst advice I’ve ever received is…

[00:37:25] PP: First answer I  thought of for this was not to build Interview Cake. 

[00:37:29] SY: Oh, interesting. 

PP: Yeah-

SY: Why did people say that?

[00:37:31] PP: Well, it’s interesting. In the early days, before I had built anything, I sort of pitched people on the idea, and everyone said, “I used the stuff that’s out there right now to get my job at Twitter, or whatever, so I think that’s fine.” But I just couldn’t shake this idea of man, when you see it, you’re gonna want it. And the funny thing is a lot of those friends, another couple years later would email me and say “ Hey, can you comp my Interview Cake account.” So once they actually needed it, they, they wanted it -

[00:38:07] SY - They came knocking. (Laughs) That's so interesting. And, you know, it’s interesting, because I think that that relates to a lot of people when you have an idea and you think, wow, there’s this problem that I really care about. I really want to solve it. And then you ask yourself, well, how are people solving it now? And you think, well, if the problem was that bad, and the solutions were that terrible, then someone else would have come up with a better solution by now, right? And then you just kind of eliminate yourself from that, right? 

PP: Yeah.

[00:38:32] SY: Ready for number two?

PP: Yes.

SY: My first coding project was about…

[00:38:39] PP: I think my very first project was a game reviews website. I think maybe I tried to make a game before that. I made like a Breakout type game. And then I made a game reviews website, and then - this is the one I really want to talk about - I made an ASCII art website. So for people who aren’t familiar with ASCII art, it’s A-S-C-I-I is a character encoding that only has the small number of characters. So no unicode stuff. No fancy right arrow or symbols for mother, languages or whatever. And definitely no emojis. There was this community and it started from way before my time when people were playing terminal based games and stuff. Where people would figure out how to draw pictures with text. And I got really into that community. And so I remember it was a geocities website. I think it was called Parker’s ASCII Art, and I had a bunch of stuff on there. I made the whole website look like it was ASCII art, but it secretly was -

[00:39:40] SY:-Wow, that sounds hard. 

[00:39:41] PP: It was. It was. It was all table based. It was hip at the time, but not good by today’s standards. And I was in two webrings. 

SY: What's that?

PP: Yeah, so this is- again, and I think this was already outdated at the time. My understanding was that in the early days, before search engines got good, and especially before social media, people’s relationship with the internet was- people kind of thought like, “Oh, maybe this is sort of a phonebook kind of thing. Like, I can look stuff up on here.” And then when the internet got interesting was when people kind of opened up the ability to quote unquote surf. To really kind of click around and get lost and see a bunch of stuff. So this was how Yahoo got big. And with my understanding of directories. So you could type in a topic and comb through and click through to hundreds of different h of websites that had stuff on that topic. Webrings were basically glorified directories. 

[00:40:44] SY: Number three. One thing I wish I knew when I first started to code is…

[00:40:48] PP: Well, so something I did know that I think other people struggled to know when they first started to code is that it’s supposed to be fun. It’s supposed to be a little subversive, right? It should make you feel powerful a little bit. I think that coding had that kind of feel. It sort of felt like “I can make something and make it exactly the way I want.” I think that some people have maybe a little bit too much seriousness when they approach learning how to code. And what I want to encourage folks who struggle with that, well you know, if you're not having fun, mix it up. Come up with a thing that you wish existed, or a thing that you think is lame. You know, find a website that you think should work a little bit differently, and write a browser extension that makes it so that the website works more in the way that you want. Or make your own version of the website. But really kind of get in there and make stuff work differently. 

(Music)

[00:41:49] SY: Well, thank you so much, Parker, for being on the show, and telling us all about technical interviews. And that’s the end of the episode. Let me know what you think. Tweet me @codenewbies. Or send me an email: hello@codenewbie.org. If you’re in DC or Philly, check out our local COde NEwbie meetup groups. We’ve got community coding sessions, and awesome events each month. So if you’re looking for real-life human coding interaction, look us up on meetup.com.

For more info on the podcast, check out www.codenewbie.org/podcast. And join us for our weekly Twitter chats.  We've got Wednesday chats at 9PM Eastern time,  and our weekly coding check-in every Sunday at 2PM Eastern time. Thanks for listening. See you next week.