[00:00:00.29] SY: Huge announcement! We have dates for CodeLand 2018! It'll be in New York City on May 4 and 5 - that's a Friday and Saturday. It's our two-day conferences filled with talks, panels, workshops, and amazing people. We've got a limited number of super early bird tickets available right now, so grab yours at CodeLandConf.com. (Music). Welcome to the CodeNewbie 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). This is the story of two developers.

LP: My name is La Vesha Parker, I go by Vesha.

TP: I'm Tiffany Peon.

LP: And I'm a full stack developer at Etsy.

TP: And I'm a software engineer at the New York Times. I work on the cooking website.

SY: They work at two very different companies, and they took two very different paths to get to where they are today.

LP: My junior year in college, I got an email from the college of engineering at Cornell, and Etsy was one of the companies listed as a company looking for interns.

[00:01:08.06] TP: I would touch base with them every few weeks, and then after about two months of talking, I sort of just figured it was never going to happen.

SY: They're going to take you behind the scenes at their two companies, and show you what they do, how they interview, and how you can get a job at a tech company like Etsy and the New York Times. And later on in the show, we have a new episode of the Coding Corner, about how to ace a very popular interview question, FizzBuzz. After this.

[00:01:36.29] If you're dreaming of a career that gives you a flexible schedule, the chance to work remotely, and tons of jobs security, fulfillment, and freedom - all with a nice big salary - you need tech skills. And that's what Skillcrush.com is for. Their all-access career blueprint is the tech industry's most personal and supportive online learning program. You'll see just how easy and affordable it is to get a head start in tech. Enroll now and get ten percent off your annual blueprint subscription when you use the promo code newbie. See you in class.

[00:02:09.06] If you're building an app, you'll probably have users. And when you have users, you'll have to talk to those users, usually, via email. Which means, as a developer, you'll need to pick an email service provider. Which means you should check out SparkPost. They are the world's most reliable and fastest-growing cloud email service provider, with a robust API to fit right into your app. They're super developer-friendly, they've got free start-up accounts, perfect for solo developers, and sophisticated enterprise options, which is great for teams. So, if you need to send an email, which you probably do, check out SparkPost at pages.sparkpost.com/CodeNewbie. Link is in the show notes.

[00:02:45.05] When I first learned to code, all I wanted was to be a developer. But then I actually learned to code and realized - you don't become a developer. You become a frontend developer, or a Rails developer, or a full-stack engineer, or a backend engineer, or the 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 designer job title, and Dice helps you find other job titles you might 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. (Music).

[00:03:45.09] So, first let's talk about what they do. Let's start with Vesha. She's a full-stack engineer, which means -

LP: You can feel equally comfortable working on the frontend of code - like client-side stuff, working with JavaScript, and really fleshing out interactions in the UI, and you feel just as comfortable doing that as you do working on the server side, so working with databases and implementing business logic and things like that.

[00:04:09.01] SY: What are some of the projects, features, what are some of the technical problems you get to work on?

LP: So, one of the things that I've been working on recently that I'm really proud of is order management software for our sellers. A lot of people, I think, when they think of Etsy, they think of the Etsy marketplace and what they see if they approach Etsy as a buyer. I work on the seller side, so we build tool that empower small and creative entrepreneurs. So, right now, I'm working on order management software, and it's basically a place where we aggregate all of the data about orders that come in and help sellers understand how they can most effectively and efficiently fulfill those orders.

[00:04:55.07] SY: Which is very different from what Tiffany does.

TP: So, I'm part of the beta products division at the New York Times, so we have a couple different free-standing websites. Cooking is one of them. And we're operating kind of like a start-up within the company - it's not exactly like that, but we try to move really quickly and release new features. On a day-to-day basis, I work with a pretty big team of pretty wonderful people. We work with the food desk, so editors, we work with a group of designers, we work with product people, and then I work on a team of iOS and web developers. I primarily do a lot of backend work, but occasionally I get to do some JavaScript work in the frontend depending on the project that I'm working on. But I'd say that my typical day involves your dev stand up and then working really closely with the other engineers, both backend and frontend, to work towards introducing a feature, support for existing issues on the site. We're a Ruby on Rails application, I started here primarily as a Rails developer, but I'm now in the process of learning Go for some new features that we're rolling out.

[00:06:03.21] SY: Her role comes with a different set of technical challenges.

[00:06:07.25] TP: Because we have so much data, we have over seventeen thousand - it might actually be eighteen thousand - recipes from New York Times writers on the site now. There's a lot of overhead as far as database queries and trying to make the site fast. And then you add to that the number of people who are coming to the website on a regular basis, because we are the Times, you run into some interesting challenges as far as website performance. So, one of the reasons that we're looking at Go is two-fold. One is obviously, Go has a reputation for being faster than Ruby. That's definitely debatable, and there are a lot of people smarter than me who would argue either way. But it's something that we're interested in looking at because of the specific challenges that we face with data and with traffic. And then we also are interested in looking at some of the tooling around Go. So, some of the teams here work with Google cloud platform, and that Google cloud platform has a lot of exciting services that they seem to be rolling out, and ones that potentially could work well with the needs that we have. And so we're just in the process of figuring out whether that might allow us to develop some of the things that we're thinking about doing that are on our road map more quickly, and sort of after this exploration period I'll get to report back and say, oh, I think that this is a route that we should go down, or maybe it's not. But for me, I get to spend the time looking at a new technology and learning a new language.

[00:07:30.28] SY: So, tell us how you got that job. How did you get there?

[00:07:34.02] TP: I've always wanted to work at the Times, ever since I was a little kid.

[00:07:37.24] LP: I'd known about the company for years before. I think I started off listening to their How-Tuesday video podcast series, where they showed how to make different crafts, way back when I was probably twelve years old.

[00:07:51.05] TP: When the New York Times released the cooking app in beta, I was actually at new-hire training for my last job, I was holed up in an Embassy Suites in Waltham, Massachusetts, watching Unsolved Mysteries and eating take-out, because I didn't know anyone there. So I'm just spending hours on the internet, and I found some article saying the New York Times just digitized all of their recipes, and I think I even still have the email. It's pre-our official launch that I sent it to my aunt saying, "This website's absolutely awesome. I know you love to cook. I'm so excited. Isn't this so cool?" And I'd even looked at the job board -

[00:08:34.07] LP: But I didn't think of it as a place where I could work, because I didn't realize how technical it was.

[00:08:39.15] TP: But I thought, oh my gosh, I wonder if one day I could work here.

[00:08:43.14] LP: So, over winter break, my junior year in college, I got an email from the career services in the college of engineering at Cornell, and Etsy was one of the companies listed as a company looking for interns. That was a beacon of light to me, because it was a company I thought was really cool, and I thought hey, they have engineers, which in hindsight, of course we do, but I didn't realize at the time. So, I applied, I sent in my resume and a cover letter -

[00:09:18.13] TP: And then I sort of filed that away, didn't do anything with it. I was just starting a new job that I was really happy with. And it wasn't until I met someone at a conference who was just about to take a job at The New York Times, and I ended up in a slack group with him and a few other developer friends. And so, a few months later I was talking about how a lot of people in my company were leaving and he mentioned that the New York Times cooking team was looking for a tech lead. And I totally freaked out, even though, again, I didn't have the experience to be a tech lead. But I was like, I'm absolutely obsessed with that product, I use it every day. Is there any chance they're looking for someone a little bit more junior? So it was at that point that he put me in touch with a couple people, one of them became my manager eventually. I had a couple very casual breakfasts, drinks, things like that, talking to people. I really was just talking about my experiences, what the future of the cooking team was, and kind of just nerding out about the product, almost informational interviews I guess. So, that was about seven months before I actually received an offer, because they didn't have a position open at the time, and while they did give me the code test, which is sort of our next step as far as interviewing, after like a phone screen, I didn't really feel comfortable with the requirements of the test. Like, I was trying but there was a lot of stuff with frontend, I'd never written a custom CSS grid for responsive web layouts before - there were a bunch of things that I hadn't done. And while I'd been in debt for about two years, a lot of the things that I'd been working on, I'd kind of gotten pigeon-holed for the past six-months. So I was feeling rusty around making a new Rails app, and some of the testing. So because I was nervous and because I knew the position wasn't quite open yet, I kind of dragged my feet. And at the same time, I was also interviewing for a financial institution, where I had to do all this studying for CS questions, and I was freaking out. So, it kind of got back-burnered, I would touch base with them every few weeks, and then after about two months of talking, I sort of just figured it was never going to happen. And I think there was some - one of the people that I met with got moved to a different division, so I sort of thought, ok, this isn't the right timing. And then, I was still fairly happy with my job, I was sort of taking interviews here and there, nothing really compelling had come to me, so maybe a few months after that I just got an email one day - from the person who's now my boss - saying "We found a tech lead. And now, the position's opened up. Are you still interested?" And of course I was, and at that point, just that maybe five or six months of experience that I had since then made me feel confident in my code test, and from there, I came in for an interview and now I'm here.

[00:12:18.14] SY: So, you started off as an intern there. And internships are awesome and frustrating. Because, if you can get one, it's great. It's an awesome entryway, and it's a great way to launch your career. But for most of us, for a lot of us listening who don't come from a computer science background or didn't necessarily have those opportunities in college and are now trying to break into the industry, having those internships can be really tough because internships are generally designed for students. So, from your knowledge of Etsy and other people who have gotten jobs there, is the internship the only way to get to where you are?

[00:12:56.18] LP: I don't think the internship's the only way at all, I think it's just one of many ways. One of the things that I've really liked about working at Etsy is that we have a pretty long history of Recurse Center people coming in and working as developers. One of the things that I really loved about being able to work alongside folks who attended the Recurse Center is that they have a love for programming, and this voracious need to explore code in ways that don't just involve getting their current project done, that we all end up learning a ton from them. I think that being able to show that you have a real love and need to code is something that you can leverage to your advantage when trying to get a job. And, I would also like to note that there are many different ways to enter a company that aren't just starting full-time or working directly as an intern in school. You can also ask for many internships through your bootcamp, perhaps, you can talk to them about working part-time. When I was in school, I actually worked part-time for Etsy during my senior year in school, and that was something totally different. I didn't know that I could do that, but I did that. And I think that you have a lot of flexibility because for programming, you don't have to be in person to do a good job. So, you can explore remote opportunities.

[00:14:29.12] SY: So, you have a computer science degree, you graduated from Cornell, which is very awesome, very impressive. How much of what you do at Etsy now is what you learned in school, and how much of it is you learning and figuring it out on the job?

[00:14:45.19] LP: I think about this sometimes. So, when I was at Cornell, I focused on artificial intelligence within computer science, and -

SY: That sounds hard.

LP: It is. (Laughs). And my education there was really technical. I shouldn't say technical - it was really theoretical. And I don't think that I used most of that theory day to day. The thing that I do use that I really appreciate having learned during my time at Cornell was how to think about problems and how to break them down into very digestible chunks. I think that that helps when scoping out projects now, it helps when understanding timelines, it helps when explaining things to stakeholders, like project managers and program managers and designers. I think that that has helped me immensely in my career as a software engineer. I will say that the actual hands-to-keyboard programming part is something that I learned by and large on the job. I didn't know JavaScript or PHP very well before I applied to Etsy.

[00:15:55.08] SY: Tell me a little bit about the interview process.

[00:15:59.04] TP: I think one of the things that made me so confident about taking the job offer was that this has been one of the most painless interview processes I've gone through. And I think it's kind of like that thing with dating, where it just felt right the whole way.

[00:16:14.24] LP: There are sort of two pathways into the first major landing point in the interview process at Etsy. So if you know someone who already works at Etsy and knows your programming ability, you can ask them for a referral. We have an employee referral program, and that just gets you in the pipeline maybe a little bit faster, because we're about to vouch for you and discuss your skills and things like that. If you don't know anyone who already works at Etsy, that's totally fine, you can go to our website, Etsy.com/careers, and find a job listing that you think you fit. And when I say that you think you fit, I don't mean that you can check out exactly every single technology that we may note, but more that you think that you can embody that person that's described in the listing, and know that you can rise up to meet the level of expertise and efficiency and problem-solving skills that we expect. You start off by just sending in your resume and a cover letter explaining who you are and why you're interested in Etsy. Then, somebody from recruiting will reach out to you to set up an initial phone screening.

[00:17:26.18] TP: So, the way that our process works for my team at least is we tend to do a phone screen, maybe with just the manager or just a couple of the developers.

[00:17:37.04] LP: We at Etsy are very big on making sure that first you're a great programmer, you can code, that's what we do day to day, that's very important. But we also really stress the importance of being able to communicate with people and being a good, personable person. So, that's also a decent portion of the interviews that you'll see. So, we have a bit of variation between teams and how different groups do things, but the general line-up is that your first interview is just getting to know you, understanding what your skill is, we'll ask you about some of the projects you've done, we'll ask you about some of the times that you've worked with a team. And when we're asking these questions, we're really trying to understand, if this person started working here today, what would that be like. Would we enjoy working with them? Would they be able to keep up with things? Would we have to maybe teach them a lot? And having to teach someone a lot isn't necessarily a bad thing, it's just something that has to be thought through, but considering what our time constraints are, and what bandwidth we have to teach people, things like that. So, the first interview is really just trying to get a holistic view of who you are and the skills that you have.

[00:18:49.15] SY: Ok, so phone screen, we did the phone screen, everything is awesome, we love each other, it's a great fit. What happens next?

[00:18:56.27] TP: If the person sort of seems like a good fit, we just go ahead and give them a code test. And there are some hard requirements, some loose requirements. I'd say that I probably spent like twenty hours on the code test, so it was a good chunk of time for me. I actually had fun doing it - I learned a lot, I learned how to write a CSS grid from scratch. I'd never really written raw JavaScript before, I came from a CoffeeScript world.

[00:19:24.19] LP: So, next many teams send a homework assignment and basically the homework assignment, it differs what we're testing based on what skill-set we need. So most people at Etsy are full-stack developers, so there's a chance you would be given something that requires you to write some client-side code, so some JavaScript, that talks to an API that either we have - we have a public API - or an API that we ask you to write, using some data. I've also seen people ask to have games implemented using someone's favorite JavaScript framework. The homework is another place, I think, a bit of a fit check. But also just understanding how you think about code - do you document it? Do you have appropriate variable names? Is it organized in a way that makes sense? Is it written in a way that's super opinionated, but opinionated in ways that we don't think is right? Like, we tried to form a picture of the person as a developer in that space.

[00:20:26.14] SY: So, how much time does this homework generally take? Because I've heard of take-home assignments that end up being - it took me two weeks to put together, and I'm interviewing with ten other jobs. So, that's two months of doing nothing but take-home assignments, hoping that I can make it to the next cut. So, how big of an assignment are we talking?

[00:20:44.24] LP: I believe about one to two and a half hours.

SY: Oh, that's not bad.

LP: Three, absolute max. I think that we tried not to take up someone's entire life in the process of applying.

[00:20:58.00] SY: Thank you, appreciate that.

LP: So, yeah. It shouldn't take a crazy amount of time.

[00:21:00.15] SY: Ok. So, for something like that, for the homework assignment, what are different things that a junior might do that would be detrimental? Like, what are things not to do in a homework assignment?

[00:21:19.02] LP: So, something that I think not everyone thinks of, is explaining how to actually build and run their code. They might have a setup that works great for you, you might have a specific version of Ruby if you decide to do your project in Ruby, or a specific framework that you have set-up, but if you don't tell us how to run it, we will go back and figure out what software we need, but we shouldn't have to. So I think -

[00:21:49.16] SY: That's a good point, yeah.

[00:21:49.16] LP: - that's it's important to make it really clear, this is exactly how you run this. And one of the things I've done for friends who do apply for jobs, is I have them send me their homework, and then I run it on my machine and just make sure it runs fine. And if I do need other software, if I need an upgrade, then I can tell them, hey, these are the things I was missing, make sure you add it to your read-me. And mentioning a read-me - I think that having a read-me is really great, because in that space, you can take the time to explain your thought process, you can take your time to explain any trade-offs you may have made, note places that you might want to improve it in the future, and just really be explicit about how you thought about this assignment. And I think that having a thorough read-me really shows your interest, versus just sending in an assignment that works but maybe has no explanations anywhere, no comments, no way of determining or understanding why someone may have chosen a specific framework over the other. So, I think that a read-me becomes your space to explain your thought process and advocate for yourself, since you won't be able to explain anything to the people who are reading your code.

[00:23:08.04] SY: That's really good. Yeah. And I feel like it also hints at, or shows off your communication skills, too, right? Yes, I'm technical, and I can make this thing work, but by providing a read-me and making sure it's really easy to run, I'm not just thinking about the code, I'm thinking about your time, and I'm thinking about your developer experience running my work and making sure it works out for you, too. So I think it's very, it's very thoughtful. I like that. Ok, so I submitted my homework, I got an A plus, it's amazing, everyone loves it. Then what happens?

[00:23:42.15] TP: At this point, we like to bring candidates in for a not full day, but a decent amount of the day length -

[00:23:51.13] TP: I wasn't really sure what to expect with the final interview. It wasn't, like many dev interviews are, a four-hour chunk of time, which if you're coming from a different industry, like auditions in music and then being in customer service and event management, it would be like thirty minutes and the main thing you have to say is like, where do you see yourself in five years? And you just say, at this company, of course, and you're great.

[00:24:19.05] LP: We bring candidates into our Brooklyn office, that's where the majority of our technical team exists, but we do have many remotes. And you have a series of interviews with people from many different backgrounds at the company.

[00:24:32.03] TP: I came in and I just met with different members of the team, and really most of the team, and so the first couple of pairs of people who came in were developers, and we had really easy conversations. Like, there was some whiteboarding, but it was more in the context of, tell me about the architecture you've worked with, and I think because I had a little more experience that time, and I was about two and a half years into my career, it was less the quiz style interview, and it was more talking about my opinions.

[00:25:01.20] LP: So, you generally interview with a few engineers throughout the day, engineering managers, designers, product managers, program managers, just getting a slew of different people from different disciplines to sit down and talk to you, and see how you interact with them.

[00:25:18.14] TP: There was none of that, ok, let's ask you a technical question, and your hands start sweating moment. Which I loved because I usually become an entire ball of sweat within like ten minutes.

[00:25:31.05] LP: And a big reason that we do this is because at Etsy, every day, I work with other engineers, I work with engineers on my team, I work with engineers on other teams, but I also work closely with designers and project managers and program managers. And we're always communicating and collaborating with each other, and our interviews serve to understand how you would work with all of these different groups, so that's a really big part of your job. I think when we think about programming jobs, a lot of the time we think of just sitting down in a room, either alone or with only people who are also programming, and slamming at the keyboard and having stuff come out, and that's not the case. While you do that a decent amount of the time, you're sitting with people who do totally different jobs than you, and you have to really understand how to work with them, so we try to have a bunch of interviews with people from sort of all over the company.

[00:26:27.12] SY: What are some examples of those more technical questions?

[00:26:32.07] LP: We have a few technical interviews set up throughout the day for the final round. So one typically is simply making sure that you understand the technologies that you say that you understand, so if you say that you know JavaScript, we'll ask you to do something small with JavaScript. An example of that, I recently had someone implement json.stringify, which is basically a function that you pass an object, another function any variable input, and it generates a string representation of that input. That question sort of has multiple pieces - like if you use JavaScript, you probably know what json stringify is, so even knowing what it means, and knowing if you don't know what it means and what it does, that you can ask questions. That interview really just serves to see you write code that isn't necessarily super complex, but just something that you can get on the page that we can run and test against edge cases. Different interviewers have different styles. My style is typically to present json stringify or whatever questions, since we switch up questions, and in its most simple form, make sure that the person gets something down that works, compiles, runs properly, and discuss edge cases and things like that with them. And then sort of dig in more, add more constraints, add more types of inputs, and make sure that they can change their code in ways to make it more feature-friendly. Like, something that you can more easily build on, to see how they think about building on to existing code. When they should re-factor, when they should just slap something on top of it, things like that. So that's one type of interview that we do. Another one is we like to do a bit of system planning in a more architectural interview, so one interview for that that I've heard given, is we have a system on Etsy called Convos, and it's essentially a messaging system between buyers and sellers, and we explain what Convos is to the candidate. Essentially, it's a platform to communicate between buyers and sellers, and then we ask them to explain how they would architect this if they had to build it from scratch. And that question is one that I'm not sure how frequently really new programmers do well with it, because it's a different way of thinking, it takes all the control and puts it in your hands, and makes you the captain of everything that happens. Whereas, a lot of times you have a chance to collaborate with others and get some feedback. And it's very much a conversation, still, like you can ask questions, but at the end of the day, we want to make sure that if you are asked to implement a feature, if you need to do it from start to finish, you could actually do that. Another aspect of interviews, or a third type of interview we do, is a deeper dive into the homework assignment you submitted. And I think that quite a few companies do this, so that's another reason that I think that it's good to write a really well-explained read-me, so that people fully understand what you're doing so that they can better frame the questions they'll ask in that interview in a way that can go along with the narrative you were already telling in your code. [00:29:59.28] So, in that they might ask you to add a new feature to it, maybe a bigger feature, maybe a feature that breaks the code as it currently stands, and they want to see how you interact with the code, how you think about the code that you've already written, if you remember the code that you've already written, or it it's something that you trip up on a lot. Just really looking at how you think about modifying your code, since that's something you're going to have to do every day here.

[00:30:28.17] SY: (Music). Coming up: we're going to dig into the scariest part of the interview process - the technical interview. We'll show you how to prepare, do your research, and share some common things that juniors are likely to mess up during their interview. We'll also stop by our coding corner with Joe Burgess from the Flatiron school, for a step by step breakdown for how to solve a very common technical interview question, FizzBuzz. After this.

[00:30:49.26] One of the most important features of any app is talking to your users, whether it's an email notification, a password reset, a new user welcome, emailing your users is an essential part of the app experience. Which means, you need to pick a reliable email service provider you can count on. SparkPost is the world's most reliable and fastest-growing cloud email provider. They're built on AWS, and trusted by the world's biggest senders to deliver unmatched uptime and resilience. And they're great for developers like you! They've got an amazing resting API to fit right into your app, or you can use plain SMTP. So check out SparkPost, at pages.sparkpost.com/CodeNewbie. Link is in the show notes.

[00:31:29.22] 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 twenty 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 if you're being 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. For more info, go to Dice.com/CodeNewbie.

[00:32:12.01] So, you're feeling trapped. You've got a dead-end job, you want to get out, do better, make more money, but you don't know where to start. That's exactly why SkillCrush was created. SkillCrush is designed for total tech beginners to learn digital skills and launch better, higher-paying, and fulfilling careers. And that career comes with real mobility, so you'll never feel trapped in a dead-end job again. Their all-access career blueprint program provides premium tech classes, one-on-one mentoring, and a thriving student community to support your journey from tech newbie, to digital pro. They're offering ten percent off your annual blueprint subscription to CodeNewbie listeners, just use the promo code Newbie. See you in class. (Music)

[00:32:55.17] If you're like me, the scariest part of the job interview process is the technical interview. So to better prepare you for your next technical interview, we're going to visit the Coding Corner with Joe Burgess.

[00:33:09.12] JB: I'm the VP of Education at the Flatiron School.

[00:33:10.29] SY: So, have you personally ever had like a terrible technical interview experience?

[00:33:15.04] JB: I had an interview with Google, back actually when I was still in school, and I was actually TAing at the time. Rookie mistake number one, I messed up the time. They were Google, so they were on the East coast, I said yes to something, and I was actually TAing during the time slot. I got a call from the woman who was going to interview me, and I was just like oh yes, of course I'm at my desk ready to answer your questions.

[00:33:41.19] SY: Oh my god, it's like my nightmare.

[00:33:44.00] JB: Yeah, it was rough. So I - oh my gosh, I have like a very vivid memory of this - so I remember leaving, I walked around the corner, I felt bad, walked out on my students, I had another co-TA and I was like, I have to go, I have an interview with Google, I mean it's Google.

[00:33:56.22] SY: (Laughs). Yeah. Sorry kids.

JB: So I left and I remember sitting down, and it was one of my first - every previous technical interview I'd done, I'd always been on my tech center on my computer. That just feels comfortable.

[00:34:10.25] SY: Yeah, it's your world.

[00:34:11.23] JB: And she goes, why don't you just open a Google Doc? And this was right when Google Docs had just come out with that new feature where you could see what other people were doing while you were typing. And she started asking me questions in the Google Doc, I can't remember exactly what it was, let's say it was find return if this string is a palindrome. It was something a bit harder than that. I started writing code, and first of all, just writing in a Google Doc, instead of in a text editor which auto-indents and auto-closes print, all of those things yeah, what you said, it's so weird. That threw me off. I got the solution, and I said ok, cool, that should work. She goes, okayyyy, but what if the input looks like this? And I was like, oh, yeah, you're completely right, this is wrong, we just need to add an if statement to the top that checks for whatever it was, if the first letter is B. And then it'll all work. And she's like, alrightttt, but it also will break if we put this in. I was like, ok cool, another if statement, ok, great. And by the end of it I had like eight if statements at the beginning, four different ways to return, and then it's after an hour, and I have a feeling she had other questions for me that we just never got to, and I now do interviews myself and I always have a warm-up question to hopefully ease people's nerves a bit, and then a real question.

[00:35:40.05] SY: Was that your warm-up question?

JB: I think was the warm-up question, but I don't know, I didn't get the job so I couldn't ask her. But I, at the end of like an hour she's like, okayyyy, she was so nice, she was trying to be so nice, but I was just bombing so bad. And she goes, ok, so there's a lot of if-statements here, catching like weird cases. Um, could you like re-factor this at all?

[00:36:09.03] SY: And you're like nope.

JB: I had nothing. I had absolutely nothing. I just told her, I was like, um, no. I honestly don't know.

[00:36:13.24] SY: Good for you. Stand up for yourself, Joe. That's right.

JB: Yeah, I stood up, but in an interview, saying no, I don't know, is not the right - is never the right solution. You always want to like, oh, ok, I could do this, I could do that, do you have any hints, you want to kind of keep the conversation going. Whenever you just say no, which ends the conversation and leaves a bad taste in people's mouths.

[00:36:39.11] SY: But what do you do when you genuinely don't know, like when you're stuck. What do you do?

JB: So, we have a few techniques we tell our students about. My favorite one is to try and build comparisons. So if they say, oh, can you implement Dijkstra's algorithm, and you have no idea, that's cool. The best thing to do is say I don't know Dijkstra's algorithm, but is that similar to this algorithm? Is it similar to that algorithm? And a lot of times, most algorithms are similar to something else. Sometimes you'll be able to compare it to something you know and then actually transition the conversation to something you know. Right, so if they say, implement breadth first search, and you say, oh, is that similar to depth first search, sometimes they go, oh yeah it is, why don't you just do that one, and you can do that one. Or, what they'll do is they'll say, oh, it's really similar except normally when you go left, you should go right. Then, what you can do is you can use the fact that you already know what you're comparing it to and trying to really use the moment to show that you can learn on the job. In the end, if you're getting hired as a junior engineer, most companies are evaluating both for your technical performance right now, but also your ability to grow. And if you're able to come in, have something you don't know, compare it to something you do, then get it mostly right in an interview, that's pretty huge. Even if you don't get it mostly right, if you leave, go home, send them an email the next morning going ok, I implemented the algorithm you wanted, here's a quick web app, go to googleimsorry.herokuapp.com and enter your name, you'll see that I can prove that it's all capitalized, or whatever the problem is. And then talk to them about how you did research and here's all the articles you read and just show that you may have some holes in your knowledge, own it a little bit, but you're willing to work super hard, you want to work super hard, and you find this stuff fascinating. At the very least, what you can do is you get to leave that interview learning something, and being better for your next one.

[00:38:40.16] SY: Absolutely. Each interview is just a practice round, is the way I think about it. I think that just makes it a lot more approachable -

[00:38:47.09] JB: Yeah, you have to remember that every person who has a job probably went on twenty interviews and failed most of them.

[00:38:54.11] SY: Yep, yep. That's good perspective. So, one of the most popular questions, technical questions that people might see in an interview, is FizzBuzz. What is FizzBuzz and how do you solve it?

[00:39:04.02] JB: So, you walk in, you get the interview question, they say hi Joe, nice to meet you. They say, ok, real quick, in whatever language you'd like, open up a Google Doc, implement FizzBuzz. And they kind of lean back and watch. First thing you should do is don't start coding. Clarify the problem. Ask them, ok, if my memory serves me correctly, this is what I think FizzBuzz is. And start writing and talking, write and pseudo code. If number is divisible by three and you're typing this into Google Docs, they can see it, we're all on the same page, then print Fizz, if divisible by five, print Buzz, if divisible by three and five, print FizzBuzz. And then ask them - is that correct? They'll say yes, they'll say no. But make sure before you start that you really understand what the problem they want you to solve is. FizzBuzz is simple, but when they say find a minimum spanning tree of blah blah blah blah, it's going to be a bit harder. Hopefully while you did that you successfully wrote down in a Google Doc a bit of what's called pseudo-code, which my favorite - by the way, pseudo is pseudo -

[00:40:26.07] SY: Yes, good clarification.

JB: You're going to write down in English-y terms at the level of specificity required for code, the algorithm. So you're going to write down, if num divisible by three, print Fizz, else if num divisible by five, print Buzz, elseif num divisible by three and five, print FizzBuzz. That's your first start. Now, you need to convert your pseudo-code into your code code. And let's say you don't remember how to figure out if something's evenly divisible by a number. It's ok to ask and say ok, I'm pretty sure the way to figure out whether a number's evenly divisible by three or five is modulus. And they'll say yes or no. The key here is that most technical interviewers really don't care about your memorization skills. Oh, I don't remember if the size of an array is length or size or count. Just ask them, they'll tell you. I don't think any interviewer's like ugh, they haven't memorized this method. And you know, let's say you ask them, and they explain it to you, and the answer is, you use this thing called the modulus, which is in most language the percentage sign symbol. What is does, is the modulus operator returns the remainder from some sort of division. So three modulus three, evenly divisible, so the modulus would be zero, there is no remainder. Then, we get to the more difficult ones, let's say eight modulus three. Three goes into eight twice, but what's your remainder? Two. Eight modulus three will return two. So, the way to figure out if something is evenly divisible, you take the number, modulus it with three, and if it returns zero, then it's evenly divisible by three. You continue on, translate the code from your little pseudo-code stuff into actual code, if it's in JavaScript or whatever, you do if, space, parenthesis, num, modulus three, = = = = zero, console.log, Fizz. Right, else if num modulus five = = = = = three zero, console.log Buzz elsif num modulos 3 ==== 0, and, remember your ands and ors - remember that and means both sides have to be true for the entire expression to return true. If it's evenly divisible by three, AND evenly divisible by five, then print FizzBuzz. And then you're done, you solved it, your very first solution to any technical interview problem should be the simplest first thing that came to your head. Then, take a look, think a bit about it, if you remember something from math, you'll then remember something from your logic table, you'll then find a bug. If it's divisible by three and five, when it hits the divisible by three to start with, it's just going to do that one. So then, go through it, run the compiler or the interpreter in your head and realize that bug. Bring the check for three and five to the top, right, that's going to help you.

[00:43:46.26] SY: Is it better to just run through different examples in your head, or is it ok to actually test it out in front of the interviewer to catch that bug?

[00:43:58.21] JB: Whenever you need time to think, you should just spend five minutes summarizing what's going on. It's a great way to -

[00:44:08.19] SY: Yep, use it all the time.

JB: It's a great way to catch your own bugs, right, same as rubber duck debugging, by verbally expressing your code you'll find your own bugs. And, it allows you to make sure you and the interviewer are on the same page. So, if here, if I put in a six, ok, it's going to catch that there, ok now let me try a fifteen, which is divisible by both, ok put that in - ok, I'm going to catch it myself. So whenever you have a pause you need to think, constantly summarize. It's better on you if you can solve them yourself, that you can just be like, ok, let me just try a few test cases. The first test case is something divisible by three. Great, it works. Something divisible by five, great it works. Something divisible by fifteen - oh, nuts, it doesn't work. How do I change this? Ok, I'm going to bring this up to here and be good to go. It's completely fine to make bugs and make errors. Actually, it's almost good in that the interviewer gets to see your debugging process.

[00:45:03.13] SY: Right, yeah, yeah.

JB: When they see you debugging, they want to see that you're logical, that you're methodically, A to B to C to D, and if you show that off, you'll actually get more points, I would bet, then if you just got it all right the first time. Make it work, make it right, make it fast. I didn't come up with that, I can't remember who did. But it's correct.

[00:45:24.00] SY: It's really good, yeah.

JB: Don't do the fanciest, most algorithmically perfect blah blah blah - just do whatever comes out of your head. Spit whatever's out of your head onto the paper, and then you factor, you factor, you factor. By writing a terrible first version, you will understand the problem much better than if you try to go into a super advanced solution on the first shot.

[00:45:46.05] SY: If you want to learn more about the Flatiron school and how to get started learning web and iOS development, check out Flatironschoolnewbies.com. Link is in the shownotes. So, one of the things that always throws me off about the full-day, half-day interview is there are so many people, and I never know what's the best way to prepare. So, sometimes - well, always whenever I can, I will email the person who's arranging the interviews, and I'll say hey, can you give me a list of who these people are so I can do a little bit of research, you know, make sure I'm as prepared as I can be, figure out what roles I'm talking to and that kind of thing. And about half the time, they're able to give me that information. The other half, they kind of give it to me a little too late so I just don't have time to prepare as much as I would like to. How does someone prepare for that?

[00:46:34.20] TP: Number one, wear comfortable clothing. I know, but especially as a girl - and I'm sure guys have this too with suits or whatever, although I don't think one really wears suits to programming interviews - don't wear that skirt that makes my ribs feel like they're going to like crack after I sat in an upright position for four hours, just because it looks slightly more professional than say a pair of black pants that are secretly the maternity top, or whatever. (SY laughs). You don't need anything going against you, right. In whatever choices that you make for that day, like I'll eat yoghurt in the morning because I know my stomach won't get upset if I eat yoghurt, and those are really small things, but you're already going to be so nervous that trying to just take away any variant is helpful. And I'll do stupid things, like I print out my resume, even though I've never been asked for my paper resume in an digital coding job interview, but there's that little psycho in the back of my head that remembers from like the first career coaching you get at eighteen, that's like, they're going to need your resume!

[00:47:48.16] SY: And I find that in those interviews, the amount of time that you have with each person is - it's pretty short depending on how many people you meet with. I've had interviews that are just thirty minutes long, which isn't - it's not really a ton of time to get to know people, especially since every interview starts off with the same questions - tell me a little bit about yourself and why you want to work here, and just sort of say the same thing six times. How do you make the most out of that time? What can do, what should you keep in the back of your mind as a strategy to really nail it in the short time you have with each person?

[00:48:23.08] LP: I recently had this discussion with some people I was interviewing from City College, and I was helping them with the mock interview, and one of the things we discussed was that something that's very powerful to be able to develop with the people who are interviewing you, is a concept of persona. So, when I say this, I mean that before your interview - and I think you should do this before all interviews, where you're speaking with people - decide what you want that person to leave the conversation thinking about you, and make sure that every question that you answer just serves to reaffirm and reinforce that idea. So, if you want to go in and be known as a hard-working engineer who really advocates for the rights of their users, and is really easy to work with design and product, make sure that every question you answer is a hint to your interviewer that that's who you are. And I think that this advice works because frequently, when a company is hiring, they're usually interviewing a lot of people, and you want to stick out because over time people will forget your answers.

[00:49:38.00] SY: Exactly.

LP: And your interviewer can take notes and can do their best, but at the end of the day, maybe you've interviewed five other people and honestly a lot of times things all sound the same, everyone says they're hard-working, everyone says that they're passionate, it's like, we get that. You want a unique view of who you are, so when that interviewer is asked by the hiring committee - tell me about person X, they can say oh, yeah, that person, they are really passionate about open source and they spent a lot of time volunteering in their community, maybe. You want them to be able to think something about you that they couldn't think about other people. And I think that that is a way to make the most of those thirty minutes, because you really can't do a ton in that time, and that really stinks. But you can try to really reinforce your narrative with every one of those thirty minutes.

[00:50:36.03] SY: I absolutely love that, yeah. And those are things that you can do with the clothes you wear, the way you speak, everything about you, you can make a message of some sort. So if you have a clear idea of, I'm going to be a user advocate in every way - there's many different ways to show that, so I think that's really, really good advice. So, what's something that junior developers are likely to get wrong?

[00:50:58.06] TP: The majority of my experience has been junior developers. We would do something called a code kata, which I'm sure most people are familiar with, but it's like a little logic problem, that shouldn't be that difficult to solve, but might be a little out of the realm of getting done in thirty minutes. So, we didn't have the expectation that they were going to finish the challenge, we actually just wanted to see how they think. And I would always be completely transparent with this, and say hey, you can Google, you can ask questions, we can pseudo-code, you don't have to get it right, a lot of people don't get this done in thirty minutes, all that we care about is seeing the way that you approach a problem. And I think that junior developers, particularly, you haven't yet developed a toolkit of how you go about solving a problem. Like, I now know when I start on something, I have four or five different ways that I approach the problem, depending on it. And if one thing doesn't work, then I move to the next. You become pretty methodical, because you've already had the painful experience of like, especially in a high-pressure situation like an interview is, trying to just barrel into it, not reading all of the instructions, not asking the clarifying questions, trying something over and over again without going like, let's break this down to the smaller piece, let's get the very, let's get the minimum thing working first. So, what we tended to look for is someone who'd go ok, here's the problem. Here is the base case that I should satisfy, or let's just try to do this. Something as simple as you're trying to figure out the right method to call on say, like, a string, and you don't know it, and you keep getting an error every time that it runs. A developer who would just go into - I'm going to use Ruby for this, but irb, just like your console where you can try something out and go, does this method work correctly, or if it doesn't, can I Google for the documentation, or do you know what method I should be using if this one doesn't work? That's a good indicator of a person who would be trainable and easy to work with, because rather than them going down a rabbit hole for three hours and trying to figure out something just because they don't want to seem dumb, they're just coming up and asking me something that might take me two seconds to answer, and if not, it's probably something I need to learn, too.

[00:53:24.24] SY: So that interview process doesn't sound too bad. That sounds very manageable. But I feel like that's because we're talking about it and we're not actually in an interview process right now. What part of that process, from your experience both as an interviewee and an interviewer, would you say is the hardest part?

[00:53:43.20] LP: One of the hardest parts, as an interviewer, is trying to determine what parts of the interview that someone might trip up on, or might not give the best answers to, are just like interview nerves -

SY: Right, yeah.

LP: And what parts are actual issues or things that just exist that would exist also in the job. So, I've seen some people come in and they're very self-deprecating, and it becomes very hard to parse what they're doing well versus what they say that they're doing incorrectly, because like you said, you really only have about thirty minutes with them, it's not that much time to understand them. So I think separating the person as an interviewee versus a human, for me is the hardest part, though that's not just one aspect of the interview or one specific time frame, I think that's more of a general issue I personally have as an interviewer.

[00:54:48.26] SY: And I feel like the other side of that is there are people who are really good talkers -

LP: Exactly.

SY: Like me, I talk all the time, I'm talking right now, and I've gotten to a point where I've got sound bytes - I know the stories that people like, I know the jokes to tell, I know when to tell them. I've got things very organized - I've got my life organized into sound bytes in my head. So, I'm very good at making the impression that I want to make and half the time, I'm like, can you really tell if I'm putting on a show and am a really good interviewer, and how do you distinguish that are really good presenters and the people who may not necessarily have that same polish but still have substance?

[00:55:30.16] LP: That's one of the things I've been working on, and I think that I've started finding places to do that. When I think that I might just have someone who's really great at talking, one of the ways that I determine whether there's a lot of substance behind what they say, is that I really dig into everything that they say. So, if they say, I love contributing to open source technology, I say great, what do you do? And they can name a few things.

[00:56:00.24] SY: They're like uhhhhh....

LP: Yeah, each time you progressively dig deeper in, just to make sure that there's something there. And it's not that I don't want them to succeed, it's more that I want to be sure that they are presenting themselves in the most accurate light possible. And I think that the deeper you dig, you honestly can ask maybe three questions before most people, if they're just really great talkers, start to fall apart. But people who maybe undersell themselves can excel at.

[00:56:32.20] SY: The great equalizer, yeah.

LP: Exactly, it's the great equalizer. And the flip-side is that if someone just seems a bit scattered and seems like they just don't interview much, I like to dig in with questions in a different way. I like to try to take note of the places that they seem to feel the most comfortable, and then dive in a little deeper and try to get them to start speaking about things they're really comfortable with, so they feel like they're in their own domain, and they feel like an expert about what they're speaking about, and can then really open up. And we we can go back to other questions, once they've opened up a bit, and warmed up, and feel that they have control over the interview.

[00:57:13.20] SY: You sound like a really nice interviewer. And that makes me very happy. Thank you, thank you for thinking about us - that's really thoughtful. Really appreciate that.

[00:57:19.21] LP: I've been on the other side and it's not the most fun thing in the world. (Laughs).

[00:57:26.26] SY: So once I go through the interviews again, and everyone said I'm amazing, I have a great persona, super memorable, then what happens?

[00:57:37.02] LP: Then, you go home, and you wait. I was an intern and I waited about two weeks to find out. I think others might get offers in a week, maybe a month, it really just depends on the volume of applicants coming through. But then you're contacted about whether or not you were accepted or not, and you can make a decision and have a conversation about compensation and things like that.

[00:57:57.04] SY: So, what advice do you have for folks listening who are just getting started? How can they best prepare?

[00:58:01.06] TP: I am always available for coffee or phone calls or emails, I'm sure that my Twitter handle and stuff like that will be up with this. You can contact me and I will give you my honest feedback. Otherwise I'd say, it's the same with any company that you want to work at - stalk their job board, figure out who's willing to grab coffee. I know a couple people who are interested in working here, and they've at this point met with a couple different people. One guy left our time, so this girl reached out and said, hey, I used to talk to this guy on your team, I'm really interested in working for Cooking, can we grab coffee? She was interested in a position that we don't have right now, but I just said - hey, keep looking at the job board every month or so, and if anything pops up, I'm happy to refer you because she was proactive in reaching out. So, I think that that's always good, and the other thing is asking those types of questions like where do you see the technologies going, what needs do you have in the future that you might be looking for people with those skills, and then trying to base it off of that. Obviously, it's hard to recommend like, learn some random language that no one really seems to be using just because one company does, but maybe if you find some sort of overlap in a couple companies you like, try to get some feedback. You might see that a lot of the industry is going from backbone JS to React, which is something I've seen a lot of. Ask, are you guys doing that too, is that something you're going to be looking for developers for. That increases your odds of just having the right fit for an open position, even insofar as just getting to that initial phone screen, because I think that is a lot of times the hardest part, especially like a company like the Times. I don't know for a fact, but I'm sure that our recruiters see tons of resumes for every posting.

[00:59:50.13] SY: So thank you so much for being on our show. You want to say goodbye?

[00:59:52.07] TP: Yeah! It was great, I had a great time talking with you, and I hope that this is helpful for anyone. Yeah. Bye.

[01:00:00.14] LP: Definitely, thank you for listening, I've had such a great time speaking, and have a great day!

[01:00:06.23] SY: And that's the end of our sixth episode of Season One. We've got just two episodes left for the season, so let me know what you think. Tweet me @CodeNewbies, or send me email, hello@codenewbie.org. If you're in D.C. or Philly check out our local CodeNewbie meetup groups, we've got community coding sessions and awesome events each month, so if you're looking for real-life human interaction, look us up at meetup.com. For more info on the podcast, check out www.codenewbie.org/podcast, and join us for a weekly Twitter chat. We've got our Wednesday chats at 9 PM ET and our weekly coding check-in every Saturday at 2 PM ET. Thanks for listening, see you next week.