Frontend Interviews

Season 2 Episode 7 | February 24, 2020

Programming interviews are terrifying. There’s so much to learn and nobody enjoys answering technical questions in front of a complete stranger. In this episode, we’ll dive into the frontend technical interview and give some tips and tricks for nailing it.

00:51:41

0:00

Volume On

Show notes

2:06 - Our experiences with technical interviews

3:36 - The interview process

14:15 - Phone screens

20:32 - Take home challenges

34:43 - In-person interviews

46:08 - Resources to get better at interviewing

49:00 - Shoutouts

Resources

Transcript

We provide transcripts for all of our episodes. You can find them here!

Ali 0:00
technical interviews can be terrifying. There’s so much to learn and nobody enjoys answering technical questions on the spot in front of a complete stranger who’s deciding your career future. In this episode, we’ll dive into the front end technical interview and give some tips and tricks for nailing it.

Unknown Speaker 0:22
Welcome to the ladybug podcast. I’m Kelly.

Emma 0:24
I’m Allie. And I’m Emma. And we’re debugging in the tech industry.

Kelly 0:30
AWS implies a suite of tools and services that enables developers to build full stack serverless and cloud based web and mobile apps using their framework or technology of choice on the front end. Using amplify, you can quickly get up and running with things like hosting authentication, managed graph qL server list functions, API’s, machine learning, chat, boss and storage for files like images, videos and PDFs amplify is built especially in a way to enable traditionally for non developers like myself to be successful because they can use their existing skill set to build real world World full stack apps that in the past would require deep knowledge around backend DevOps and scalable infrastructure. The amplifi console vent allows you to use the GitHub repository to deploy a globally available CDN with ci NCD built in. To learn more, visit AWS dash amplify github.io. So I’m really excited to talk about for non technical interviews, because I have never actually done a front end technical interview before and you’re lucky as heck. So I’m going to be leaning on the two of you for a lot of this.

Emma 1:30
I’ve gone through an absurd amount of interviews that sounds like, but like, it sounds bad, but the same time. It’s not a bad thing. It’s a skill. I think we forget it’s a skill that you need to learn. Oh, absolutely. I’m excited to talk about it because I’ve had a lot of experiences, especially interviewing abroad. And it’s important to note too, that every interview has a different path. It takes a different path to you might have a take on challenge in one interview, which you’re talking about later, or you might not have a take on challenge you might just have a phone screen so it’s kind of like you know Take all this advice with a grain of salt, you might not need all these skills, but I think they’re going to be aware of.

Unknown Speaker 2:06
I think it’s worth actually just starting off by talking about your experience with with technical interviews.

Unknown Speaker 2:11
Yeah. Alan, do you want to start?

Unknown Speaker 2:12
Yeah, so for me,

Ali 2:14
I haven’t interviewed very much at all. And most of my interviews have been for just generic software engineering roles or full stack roles, for the most part, to not run. But I have delivered a lot of interviews and have greeted a ton of code challenges and also work with students on their interviewing skills. So that’s something that we do like a two day workshop on at the end of every cohort that I teach. And so I have more experienced with the other side of interviews rather than being an interviewee but definitely have done some of that and have some questions that I have been asked in those and no different format so can be helpful in this conversation, but haven’t done As many interviews as Emma I’m sure has,

Emma 3:03
that’s really interesting that you have the like the interviewer side, and I’ve got the interviewee side and like maybe we should do a segment during this episode where you asked me interview questions, and I answer them.

Unknown Speaker 3:14
Sounds like a lot.

Emma 3:15
Yeah. Well, you know, it’s just payback because on the last episode of j s party, one of the last ones, we did JavaScript Jeopardy with Jake, Dom, and I gotta be honest, like, I would not have wanted to answer those questions. So I guess that’s payback. Oh, my goodness, that’s terrifying. Jake is my

Ali 3:30
favorite though. Go follow him on twitter will put his link in the show.

Emma 3:36
Okay, so in terms of the flow for an interview, the general process that I’ve encountered follows basic, four basic steps. So the first is a phone screen where you would meet with a recruiter or someone from HR just to kind of make sure that you’re a human and that you know how to talk to other humans and they kind of just tell you More about the role, it’s really good idea to have some questions to ask them, right. So basically, this interview decides whether or not you’ll move on through the technical interview phase. So it’s really don’t take this for granted. First of all, read the job description. Like I can’t stress that enough. If you go into an interview, and you don’t know what job you’ve applied for, like if you’ve just mass applied for a bunch, like that’s not good. So make sure you reread the job description, come up with one or two questions to ask whether that’s about like company culture or the workflow like if you are going to work with designers or if you’re using agile things like that,

Ali 4:30
definitely. And it’s usually a check to make sure that you have the experience that’s necessary for the role and that’s just general ballpark. Like, we may have discussed this on the show before but you don’t need to meet every single requirement for a job in order to apply for it or to interview for it even. But just making sure that the person is in the ballpark of what they’re looking for. So if they’re looking for a front end engineer, maybe not somebody who has seven years of Java experience but has never touched HTML in their life. Like, just making sure that experience lines up with the

Unknown Speaker 5:04
role. I think the phone screen is probably the the least stressful part of the interview because it’s also a good opportunity to see if the company is a good fit for you as well. Yeah, based on you know, what, what they’re telling you about the position, maybe about the company, if you’re asking questions about the company, and also please do a little bit of research into who the company is and what they do. Before going into any interview, whether it’s the phone screen or

Ali 5:34
further into the process from an interviewee position. This is when I am by far the most selective, at least in my experience, because I don’t want to have to take off time from work to go interview at a bunch of places and I don’t want to deal with the pressure of that. And so when I was looking at roles, I would take like every single phone screen possible and they look different or different companies like somebody them actually get really technical in that initial phone screen, it just depends on the company. So I would take a phone screen with anybody, but then I only actually decided to interview at two or three companies because I didn’t want to take off the time from work in order to do that.

Emma 6:18
I had a horrible phone screen once. It was with Canva, which is a company I really like. I’m gonna be honest, and I had had a great first round of interviews with them like a year prior. So I was really excited to come and talk to this recruiter. Again, it was the same recruiter from a Europe before and it was awful. It was a train wreck. And this is something I want to caution you against if you are a recruiter. So first of all, we get on this call and his attitude changed completely since the first time like the company have been growing and a really rapid rates. And it felt like he had such a big ego about this. And it was really like it was it was basically him like sitting there being like, yeah, you want to come work for us. You know, like we’re growing so well like basically making me feel like I had to want to be there. And then not only that, it’s what it was like 6am my time because I was in Germany, he was in Australia. So I had gotten him super early. And he starts throwing these technical interview questions at me at 6am when this is supposed to be just a chat about like, the role. And he’s asking me questions like, define a promise. And I’m sitting here thinking, like, I straight up, told him I go, I was not prepared for a technical interview. It’s pretty early my time like, and the fact that he just threw me into that in the phone screen was really unprofessional, in my opinion. So it does happen. And I think I was so shocked because like, the first time I interviewed with him, it was nothing like this. And so to go through this, again, with the same recruiter, the same company and have a totally different experience was really kind of soft on honesty. So if you are a recruiter or someone who does these phone screens, like if you’re going to be asking technical questions, like please make your candidates aware of it. It’s really just a courtesy.

Ali 7:57
Yeah, I think a lot of companies do like a hybrid. First round phone screen type situation where you have a first round phone interview is your first point of contact on there. I don’t know if that’s just my experience, but that’s what I’ve had seen,

Unknown Speaker 8:11
honestly, like we used to do phone interviews before we do the the depth test. And we found a lot of candidates would say they could do something and then they couldn’t deliver on the dev test. So we we’ve been playing around with the the structure of our interview process and actually starting with the

Emma 8:32
shorter depth test, essentially. Oh, well, I heard like, like, silly but I had started to tell you about, like what the general process looks like. And then I got caught up in this bad interview I had. So let me just go back and like actually say what I was going to say. So typically, you’ll go through this phone screen with someone from HR or your recruiter and your recruiter will generally be your point of contact throughout the entire process. And don’t take them for granted because they can make or break your application. Like if you’re kind of on the edge with the hiring committee. Your recruiter will push for you. So make sure you have a really good relationship with them. If you make it past that, the next step will be one of two things. You’ll either go strange, like a coding challenge generally, or they might give you a take home assessment, or you might do both. So you know, some of these larger fortune 500 companies I’ve had, would they would do a coding challenge is generally about an hour where you live code either like in a Word document or in like a code editor. And then I’ve actually had to do a take home assessment on top of that, which is something that you’ll get, it’s nice when they give you a couple of different prompts for projects, you can kind of pick or choose which one you would like to do. And then you can use basically any technologies you want. And you would talk to them about your process and all of that you do it on your own time. And those are generally really I enjoy those Personally, I don’t know have you guys done take home assessments Do you like them?

Unknown Speaker 9:51
We’re a fully remote company so we only do take home?

Ali 9:55
Yeah, I have done them and also, I create a Lot of the take home challenges for instructors at General Assembly. And then also for other roles that I’ve been into these are going to look different in different companies. So some places they have essentially a multiple choice test. I had this at one company that had a multiple choice questions for fact based knowledge on a programming language. But it was like Python, it was so so strange, because that’s not really assessing how good somebody is at programming. It’s just how well they know random facts about a programming language. But it is what it is. And it’s quick for them to create because it’s automatically assessed, right. And then I know some companies have automatically graded code challenges. So you’re actually writing code solutions to problems but then they’re automatically graded by a algorithm. So in that case, make sure that you’re following the style guide, they’ll usually give you a style guide, and it’s going to grade mostly based off of that style guide. And then also How many of the automated tests that your code passes, so it’ll run those tests and greet it based off of that. So then it will usually put you in a category of junior developer, mid level developer, senior level, expert level or whatever like that according to the greeting, I would make sure again, that you follow the style guide, and that you try to get as much functionality as possible. And if there are multiple sections that all fit within the same time for those tests, to make sure to balance your time so that you are getting through as much as possible, don’t get stuck, especially if they are time limited what a lot of these automated ones are time limited. And then the other category is they’ll just give you like a GitHub repository and ask you to write a mini app or a front end piece of code or something like that. And then they’ll manually greet it based off of your codes. They’re so two different categories, I would say those depending on the type of company. Digital Ocean offers the simplest, most developer friendly cloud platform. It’s optimized to make managing and scaling apps easy with an intuitive API, multiple storage options, integrated firewalls, load balancers, and more. From predictable pricing to flexible configurations to World Class customer support, you’ll get access to all the infrastructure services you need to grow. Plus digital oceans community provides over 2000 tutorials to help you stay up to date on the latest open source software languages and frameworks. Get started on Digital Ocean for free with a free $100 credit@do.co slash Ladybug. That’s do dot CEO slash Ladybug.

Emma 12:56
We’ll dive a little bit deeper into the coding challenge. The take home challenge and the onsite interview in a second. But the last phase, as I just mentioned, is the onsite coding interview, which these are typically the scariest, in my opinion, because it’s one thing to code over a computer or an online meeting with someone, it’s another to have all day interviews in person with people. So, you know, the most recent onsite interview I had was for a large company, and it was an all day thing. So I came for five interviews. Two of them were algorithmic based. Two of them were JavaScript programming, and one was like in an agile workflow, culture fit kind of interview. So we’ll talk more about those in more detail. But let’s start with the coding challenge over a web meeting. I’m Allie, do you want to start in with some of the things or some of the skills that you should study for this?

Ali 13:44
These are ones that I personally haven’t had much experience with. But I know at least some companies they’ll have you like write code in a Google Doc live with somebody. have done that before was not For fun experience, because Google docs are not really built for writing code. I’m not super, super fun to do that. I’m, like, at least use live share VS code has that built in. It’s so nice.

Emma 14:15
So if you’re going to do live coding and a Google Doc, let me give you some advice, because I’ve also had to do this. Um, the first is I always change my font, like a monospace fonts. So it does kind of resemble more of my code editor, which, you know, doesn’t really affect functionality, but it helps me. Secondly is turn off auto capitalization and formatting because it’s gonna save you a lot of stress. When you know, your text editors trying to like capitalize all of your function words, and all of that. Those are two big ones. I know Google Docs also has code snippet integrations, which is like a hacky way if you want to do it, but just practice, just practice writing code in there before your interview. It’ll help you a lot. I have gone through a lot of these like phone screen challenges. So let me give you an example of something you might encounter. I’ve had several interviews where they asked multiple questions. like two or three questions in the span of an hour, and they get progressively more difficult. The first question is typically something that will give you a quick win, it should give you a quick win and have you become more confident in your skills and then they start adding in the harder questions. They can be anything from algorithmic, so sorting and searching algorithms. And if you haven’t listened to our data structures and algorithms episode, I recommend going back and checking that out. Yeah, you’re going to want to study algorithm algorithms, specifically sorting searching and know the performance of those. So know the benefits of having two top level four loops versus to double nested for loops and the runtime implications of those. So typically, yeah, it’ll be like, oh, like if you have an array of words, for example, or integers, like tell us if this one is included. So those are pretty standard. I also got one that was super fun. I actually had a good time with this. And it tested my knowledge of the DOM of CSS in JavaScript all at once, so I had to do a lot of dominantly And dynamically generating DOM nodes. It was basically like given a string input, return the string such that each character is evenly divided up with the colors of the rainbow. It was so cool because originally my thought process was like, okay, so like I need to figure out, you know, we know the colors of the rainbow are RGB roji piv. I can’t like sparklers, man. Right? Red, orange, yellow, green, blue, violet, indigo, violet. In no particular order.

Unknown Speaker 16:32
We’re gonna test we’re gonna test Emma the colors of the rainbow.

Emma 16:37
My goodness. Okay, so, so basically, my thought process was like, Alright, so like if there are five letters in the string, and I have to give them each a color from the rainbow like that’s totally fine. It’s less than Roy G. I’m telling you, my fingers are seven colors in the rainbow. So I’m like, all right, if the string has five letters, just give each you know one from zero to five. Leave off indigo and violet. And the interviewers want you to succeed. So they’ll ask you clarifying questions about like, Okay, well, what if we wanted the entire rainbow represented in the string, which at that point means Okay, well, if there are less letters, I need to calculate the, the value or the gradient for each letter. And it was really fun because I got to practice, you know, my RGB calculations, like in CSS, you can use RGB values from zero to 255. And being able to calculate based on the number of characters, the percentage of each value you would need to to have on that letter, and then return it back to the DOM. That was a really fun challenge. Because it tested skills that I feel like are really practical for a web dev job versus like, tell me the runtime of this algorithm and tell me why it’s broken.

Ali 17:44
My only one like this was doing a graph traversal algorithm. I forget the exact question, but it was like, if you’re on a website that links to a bunch of other websites, how would you write a search that would never traverse from the first website to all the other ones and all of their children and etc. And so it’s like a graph traversal search. Not not fun at all. So I’m jealous that yours was some except

Emma 18:14
for a front end job.

Ali 18:15
No, that was for just generic software engineering. Because I think, I don’t know if I’ve ever done a straight up front end engineering interview. I think it’s mostly been for generic software engineering jobs,

Emma 18:29
for sure. Yeah, I mean, the phone screens are definitely scary. One other thing I want to mention is I’ve actually had quite a few logic tests. I don’t know if you all have gone through this. But both Spotify and IBM had given me logic tests where they want to test your ability to make deductions about data sets, and patterns. And so it’s basically timed. I think it’s like 15 minutes and you go through as many of these as you can, and it’ll give you a series of numbers. It’ll start out easy, you know, with integers and ask you to find the next number in the sequence, or it’ll give you a patterns. And then I’ll switch into fractions and decimals and it gets a little bit harder. And you’re not meant to get a perfect score on these but it’s just meant to see if you can deductively reason about data sets. And I’ve gotten those at two different companies. I actually kind of like those like, I don’t like the time aspect of it, but I think understanding how to reason about logic is is more valuable in my opinion, then understanding how to regurgitate bubbles or mergesort

Ali 19:21
agreed. I’ve heard of other ones as well. Okay, so if you hear any background noise, my dog Blair is literally on top of me right now. I’m in Kelly can see her right now on her zoom call, but she is literally standing on me right now.

Emma 19:38
Well, did you hear when my cat was going to the bathroom in the corner? And none of y’all listening heard that. But you know, that was a lesson. So in any case, pets are fun.

Ali 19:47
Yeah, so Okay. Other ones like that would be to estimate how many windows there are in New York City. I’ve heard of that as an interview question that people have

Unknown Speaker 20:00
Why

Ali 20:01
I no idea but it’s supposed to be your logic skills as well. Another one is how to add two numbers without using the plus sign. I think that’s another one. Maybe not something along those lines.

Unknown Speaker 20:18
I’m interested interesting.

Unknown Speaker 20:20
I feel like interview questions should be more related to I don’t know, they’ll work that you’re going to

Emma 20:25
be I know they should. And that’s another thing if you’re going to be interviewing ask practical examples or questions, please.

Ali 20:32
Yeah. So agree they’re absurd, but heard of all sorts of things.

Emma 20:38
That’s why I really enjoy the take home challenges. I feel like these are where I do really well. And I’d like to talk about my take on challenge that I just, you know, I did in the past and I think when it really well, so that you can get a bunch of different take on challenges. So let’s talk about a few of them. So I interviewed for a meal delivery service quite a popular one. Hello friends. which you may have heard of. And basically, they had me. This is so ridiculous. They had me redo their entire UI. Basically, they were like, you know, create, maybe I misinterpreted it. But I spent so many hours doing this take home assessment, and I redid their entire UI and at the end, and I use vanilla JavaScript, right? So at the end their feedback from you as well, you should have used a framework, we really wanted to see a framework and they they never explicitly told me this is a requirement. So this is twofold here. If there are specific requirements that a candidate must have to do well, in a challenge, please tell them. And secondly, as a candidate, please ask clarifying questions because I didn’t and that was, I guess, on me. So that was one of them.

Unknown Speaker 21:45
I’ve experienced that as well, like on on our take home tests where we have a very specific guideline setup as far as like what you need to be using, and to come back with the dev test at the end of it and be like, well, I couldn’t figure it out. So I built a react app instead. I’m like, That was not what I asked you to do. And it’s not at all relevant to the work that we do. So I love that you enjoy react. And I love that you can create a react app, but it’s not going to be relevant for this position.

Ali 22:12
So oh my goodness, my biggest pet peeve with these And so again, I have greeted so many code challenges. I do it on a contract basis for the company that I work at is people who do not read the instructions, like I give people a PDF of instructions, it’s a full page and has pretty much every single thing that you could ask about it pretty much like and I would be fine if people ask me clarifying questions that would be hundred percent fine would love that. But so many people will just skip sections or leave pieces off or whatever. And so my advice is to read the instructions of the beginning, maybe make notes to yourself of how you’re going to approach different pieces of the problem. And then at the end, read the instruction Again and use them like a checklist like, did I actually do all of the requirements for this take home challenge, because it’s going to look like you are not detail oriented at all, if you just leave chunks of the challenge off.

Emma 23:13
And the other thing too is like for companies, please give you a cam that’s like reasonable tasks to do. So like that hellofresh. One was really frustrating for me, because I spent a lot of time doing it. And it was not containable for someone with a full time job. The second take assessment that I have was for my current role, and they had me created to do application, which is everyone’s favorite application to make. I did mine in vanilla JavaScript. But if you work with reactor of uJs, or other popular JavaScript library or framework, I would ask if it’s cool to use it, but I would recommend using it because it’s really good to have data stores and all that stuff. But I would also caution like don’t over engineer it. Please don’t use every technology under the sun. The last take home assessment that I had was really fun. They give me a couple of choices so it was nice to be able to choose And it was really UI oriented. So it was to build something similar to like a timer application. And

Ali 24:10
so it was, it was

Emma 24:11
pretty easy in terms of scope, it was there was a finite scope. But when you’re doing these assessments, there are a few things you want to keep in mind. One, like we both said, make sure you’re reading the requirements, make sure you’re hitting every single point that they asked you to do, and you’re giving it to them in the correct format. Secondly, if you are asked for like a document explaining your process, please explain your process thoroughly because they can’t read your mind. And make sure you’re writing clean code. So like dispose of any console logs, and you comments and things like that. And look for areas of improvement. Like if they asked you to create, I don’t know what to do application, find something that wasn’t in the general requirements that would be nice to have. And and think about user experience and user architecture, your architecture information. You know, if you’re building To do application, what are some of the enhancements you can make? Maybe you want to have different categories for to do items. So you can create different color coordinated categories, but also make sure it’s accessible. So don’t rely just on colors have labels that also indicate what category it is. So by thinking about not just the requirements that they asked for, think about other user experience enhancements, and things like that. But again, don’t spend four weeks doing this right, make sure it’s all within the scope of what you’re able to do. And if you can add a couple unit tests in there awesome.

Ali 25:33
That was going to be my piece of advice is that of the bonus, the features that you could add in their testing is one that always impresses me and would be one of the first things that I look for. So if you just have a couple minutes, write a couple tests. Also make sure that you’re writing this should go without saying but it does need to be said looking at these code challenges is make sure that you’re writing to clean code and following the good stuff. Anders that you would at work and running a linter on the code, maybe before you turn it in, so that your indentation between files is consistent or whatever. Like, I feel like this is one of those things that, you know, kind of should be on people’s radar, but maybe it’s not. So make sure that you’re still following your best practices of your language. If you’re writing Python, follow Pepe, if you’re doing JavaScript, follow some sort of JavaScript standard, like the standard j s or something with esslyn, or whatever.

Unknown Speaker 26:33
Just gonna say I see that I see a lot of dev tests that I get back from, from candidates who definitely do not review their own code, which blows my mind, like you want to put your best work forward. So you should like I see, you know, things just commented out in the code. Like maybe you were trying something out and it didn’t work, but that should have been cleaned up. I see code in the wrong files, you know, with with building shop by themes. There’s a very specific structure to the way you build out your shop by themes. And there are best practices when it comes to how your theme can be more performance and people just not abiding by those best practices and putting out that as their dev test. I mean, that’s a that’s an immediate loss. Yeah,

Unknown Speaker 27:16
do the housekeeping.

Ali 27:18
Yeah. HTML and CSS validation to just do like the W three C. HTML CSS validator, it takes eight sec. Yeah.

Emma 27:28
Yeah, run your challenge through lighthouse to see your score. And also mention that in your write up, if they asked for a write up, like mentioned the fact that you consciously thought about accessibility. Another thing I like to do? Well, I have two tips. One is if you’re not good at design, don’t forget about it, use a UI library. And I would recommend material design. I think that that is a great library. It’s popular and it’s accepted, and it’s accessible. So I can’t I can’t stress that enough. Use the UI library as opposed to just forgetting about design. Secondly is to think about future enhancements you can make, this is another thing they want to see, because they want to see if you can deduce where there was room for improvement. So as an example, so when I was making a timer application, I’m like, Okay, well, maybe when the timer finishes, you could add a sound, because maybe if someone’s blind, they want to actually be able to hear that it’s complete. So these things show that I’m conscious about accessibility, that I can think about future enhancements. And those are all really good. And also be aware of the trade off. So like, if you don’t have all the time in the world, and you’re like, I would love to do custom design, I don’t have time for it, I’m going to use the UI framework. If you keep adding all these libraries and tools in there, it can be seem like you’re very reliant on them. So maybe just be very explicit about the fact that hey, this was a trade off for me because the opportunity cost here was either don’t style and kind of just forgo that or use the UI library at the expense of You know, not being able to showcase my CSS.

Ali 29:03
Yeah. One other thing that I’ll make a note of for both companies in for interviewees, I guess, is to make sure that these are well scoped in time. So I think an hour is a good amount of time as a rule for how long the take home should take your candidate. If you are asking them to do something that is hours and hours long, or something that you might even use for your company, you should be paying them. I’ve heard so many stories of people doing take home tests that are really just freelance work, that’s unethical and make sure that you’re not doing that. In addition, if you are a candidate, and they’re asking you to do an absolutely unreasonable takeover challenge, it’s probably not a great sign that they have an amazing culture and are going to be a really great company that interview at moving forward. So I would always take red flags in the interview processes red flags about that. company,

Unknown Speaker 30:01
for sure, for sure. And you know, I can I can be, you know, totally transparent here and say our original dev test was too long. And I didn’t realize it because I didn’t actually go through the dev test myself, I just built it. And I was not expecting this to take as long as it did. And, you know, I appreciated the feedback that I got from some previous candidates saying, you know, it would be a little bit better of experience if it was, you know, a shorter test. And I took that to heart and I rebuilt the test and now I’m basically just having them fill in blanks as opposed to build a lot more. You know, and I find that being transparent in the when you’re submitting your your take home test, you know, I like when you tell me about, you know, what it is that you use, why you use them and provide that little bit of feedback that, you know, this is this was my my thought process during the test. I found that to be you know, for me, it’s more of a personality thing as well that yet you feel open to to providing that feedback. Yeah.

Emma 31:04
And I think I have a couple more tips from my experiences doing on these as well. That phone line. First of all Can I just want to say like, I think it’s that concept of giving them a scaffolded project and say fill in the blanks is really cool because a it doesn’t take up all their time and be contest also whether they can read other people’s code and understand how to use Yeah, really nice. Yes, exactly. So I actually paid one of our contractors to build out this new dev test. So his time was compensated, he set it up to be like this is what we’re using. This is our first that the framework for it. We’re using parcel which is my first time actually using that for for doing the local build and everything which was awesome. And this time around, we actually got some really good feedback that they they liked parcel so much that they’re changing their their internal build process to use it to love that. And then I see the point of like paying your candidates. I actually had An interview with gaspee, I, unfortunately had to pull out just based off of like, what was going on my personal life. But I will say it was a great experience because they, it was putting you into the shoes of what you would be doing day to day. So it was really an open source maintainer role and they were going to actually have me do tasks that an open source maintainer would do to see if I even liked it. And it turns out, it’s not actually a role I would like anyway, which was really good, because mutually like, it wouldn’t be good if I did end up joining and then realize I didn’t like it, but they also paid you for your time. And I think that’s so, so great. So please pay your candidates if you have that ability, and it’s going to be taking a ton of time. Just a couple of tips. So the first is if something comes up in your life, whether you’re traveling or I don’t know, your spouse, or your partner or your cat gets sick, like Please tell your recruiter that like hey, life kind of got a little hectic. Can I have you know, I want to do this project to the best of my ability. I want to show you what I can do. I won’t be able to focus on it fully right now. Is it okay if I get it to you in another week? And I have never had someone come back and be like, actually no, like, that’s not okay. They’ve always been like, Yes, absolutely. Yeah, take your time, we’d rather take longer and you do well. So please ask for an extension if you need it. The second thing is know your code, please don’t just copy and paste from Stack Overflow and put it into your project. Because you will be asked about it, you will be asked your thought process and why you wrote it the way you did. And why is this more performance than another solution? So if you can’t answer those, it’s kind of a red flag, and you’re probably not going to make it further. And then lastly, would be if you’ve seen a question, and this is not just pertinent. So the take home assessment, if you’ve seen a question in an interview, please tell them because they’re going to be able to know if you’ve seen it before based on how fast you can regurgitate the answer. And again, this goes back to knowing your code. If you found an answer for a Fibonacci recursive solution, for example, and you’ve seen it before, and you spit out this response, they’re going to know you’ve seen it and they’re going to ask you about it and You can’t explain it, it just shows that you’re really good at memorizing and not comprehending what you’re learning.

Unknown Speaker 34:04
I just want to touch on the asking for an extension as well, I find that, again, that level of transparency and your own process. I’m fully aware that these are some people who are working full time, full time jobs right now who are looking for a switch, that means they’re having to do this take home test in their, you know, in their free time. And people are busy people have things come up on the on the weekends or on the evenings they have vacations planned, I really appreciate when somebody is transparent about the fact that something is going to take them a little bit longer. I find that that that open line of communication is very telling for a position where you’re going to be communicating with people on a day to day basis, not only internally but in our case with with clients as well.

Ali 34:43
Okay, so now let’s talk about the biggest part of the interview, which is the on site or multiple sites depending on the company. In my experience, there’s usually been multiple rounds of on sites. I don’t know if that’s you also experiences as well.

Emma 34:59
Yeah. I my actually only had one onsite interview before because when I was applying for jobs, they were not in the vicinity of my area. So like when I graduated college, I got a job in Austin. So I was in New York, that was pretty far. And they, they just hired me based off of my, like remote interviews. And then the second one, I mean, I was applying for jobs in Germany, and I was in Texas that they weren’t gonna fly me out. So I’ve only had one onsite interview. And it was five rounds of interviews. So each interview was 40 minutes. And I had mentioned this previously, but it was two algorithmic interviews. It was for a software engineering role, but JavaScript based, so to software, or algorithmic based interviews, one of which I had to code a binary tree on the board and explain, or like, I didn’t have to code a binary tree, but I had to explain how I would fix a broken binary tree like how did you know if it was broken? And I think my solution was something along the lines of while each node can only have two children, Max and so like, as it was something to do with another edges. And I kept track of like which children I had visited. And I’d already been there before. Oh, that’s what it was, I had to know if there was a loop in a binary tree. So I was like, find the broken edge, find where the loop in this tree is. And so if you’d already visited, the node, obviously was broken. And you can remove that, something like that. And the other one was something to do with recursive, like geo mapping or geolocation. And to do with like maps and how to actually like render, like pins on a on a map, maybe. And there was some kind of recursion problem, but on we had some some issues with that technically, like, it was over a virtual meeting. And there were some technical and technical issues on that one. So I didn’t get to finish that one. I then had to JavaScript interviews, they were very, very practical really enjoyed them. They tested my knowledge of the DOM of accessibility of design. So really know how UX are some basic UX principles. So we’ll link in the show notes, but if you haven’t heard of Jacob Nielsen’s heuristics for UX, I would recommend checking it out. It’s basically things that you should do for your users. So make sure that any relevant information is shown at every step of the process. So this would be something like when you’re checking out, for example, like if you’re buying a flight, you want to know that you’ve booked the right dates. I do this all the time. You want to know for a fact you’ve got the right dates in your cart, because if you buy the wrong flight, like that’s a problem. So make sure you’re showing your user every step of the checkout process, like what flight they’ve chosen. We’ll link those in the show notes, but but knowing about UX is good. And then the last of the five real quick was, it was kind of about agile and how to solve team communication issues, things like that,

Ali 37:39
in my experience, the first one of the sites is normally like, technical questions. So you’ve done white boarding, I have not done white boarding actually, other than the Google Doc white boarding or just like kind of counts but not really but I’ve had mostly rapid fire technical questions where it’s just back to back to back. What is this feature in this programming language? What does this do? What? How do you write a media query? What is a media query? How does CSS actually work? What’s the difference between script and script script is sink in script differ like things like that at a rapid fire basis. That’s kind of what I have had more the on site. And then also something that I really liked is that I had a company who had me bring in a piece of code that I was proud of. So a script that I had written that I took pride in thought was a good representation of my skills, and then we walked through that. I really enjoyed that. And then also just conceptually explaining how I would solve different problems, how I would work on a team and then another set where it was more like behavioral question. of how you would interact with other people and all those types of things.

Emma 39:09
There was another there were a couple interview questions I really enjoyed. It was during my phone screen my technical phone screen, ironically, but they asked me how I stay relevant in the tech industry, or like how or like what blogs or books I read. And this really indicates like, do you stay relevant? How do you stay relevant Do you like to learn? Those types of interview questions are really beneficial, I think for both sides. Um, but make sure you have like answers prepared for these. So they’ll, they’ll often go on you too about like, what’s the conflict? or How did you resolve a conflict on a team? So don’t take these questions lightly, because actually, they can have a big impact on whether or not you get a job.

Ali 39:49
Yeah, what am I most difficult ones I was ever asked was explain what react is from zero, like pretend I don’t know what react is explain it and how it works to me starting from Zero and like, to some extent that’s not the most difficult question in the world. But to explain every single piece of react without prepping for it at all is pretty challenging and to pretend like somebody has no knowledge of it, too. Oh, for sure. My other piece of advice that I would give to you all who are interviewing is to admit what you don’t know but spin it as a positive. So if you are given a question that you have no idea even what they’re asking or they ask you, like, what’s your experience with react and you’ve never written react code in your life? Say that don’t bs it because it’s gonna be easy to tell when they ask you about the component lifecycle and you’re like, what is that? Or if they follow up with you or whatever? If you get the question like super, super, super wrong, and you pretend like you know it, that’s going to look much worse than you just not say you saying that you are not Experienced than that, but you can show a growth mindset in this and say, I don’t know this thing yet, but I love learning new things, or I taught myself x and y. And so I’m sure that I can teach myself that and I’m excited to have a rule which I can grow into and keep expanding my knowledge on the job or something like that. Or you can tell them relevant knowledge that you have that’s related to what you’re talking about, but is tangential if you don’t know where to even start with the question.

Unknown Speaker 41:31
That’s actually something that’s very important to me when I’m interviewing people is one of our one of the professional competencies actually look for is creativity and innovation and productivity. I also look for as far as outcomes go, that they’re introducing ideas and you know, new solutions that’s going to positively impact the project. So what I’m asking questions and you don’t know the answer, but you’re saying like you’re, you know, you’re you want to learn or I’m this is what I’m working on so far, too. Learn how to navigate that. To me, that’s a really important thing, because I want to know that you’re, you’re striving to continue to learn more as well.

Emma 42:06
Yeah. And I also have a couple tips. First is think out loud, the interviewer is not going to know what’s in your mind. So you need to be very vocal about it. Even if it feels awkward to you just explain your thought process, even if you know, it’s not the most optimal solution. The second is, if you don’t know the most optimal solution from the beginning, start with the brute force method. So for example, if you’re asked to search for an integer in an array, you have several options. But let’s say I don’t know the most optimal solution. So I know for a fact that I can check every single index federate and see if I found it, and if I find it, return true. And if I don’t find it, return false. So you could use to use a simple for loop, which would be O of n and being the number of items and then array, at worst case if you don’t find it. But there are also other methods. Let’s hear ray is really, really long. At that point. Maybe you can use an algorithm like merge store, which is Is the divide and conquer algorithm and it’ll break it into, you know, smaller and smaller pieces. It’ll have it. It’ll have the the length of the array, every single iteration. And I think that would be like oh, of login, right alley. Yeah. It’s much shorter. Oh, yeah. So start with the brute force method. And even if you don’t know the runtime, even if you don’t know the optimal solution, just just work through it and ask questions, and your interviewer will help you. And then the last thing is to ask clarifying questions. So clarify your requirements is a big one, because often they’ll give you these challenges with some of the information missing and they want to see if you can figure out what information is missing and ask them for it. So make sure you’re asking questions. If something doesn’t seem like if it seems like you’re missing information, you probably are and you should ask.

Unknown Speaker 43:45
I think that’s a really important point to make. You know, with with some information missing, I think it’s important to note that your interviewers are not trying to stump you. Like if they are trying if they’re trying to find a Way to make you falter or make you fail and a test, it’s probably not a company you want to be working for

Emma 44:05
definitely.

Ali 44:06
And a lot of times these interview questions aren’t always looking if you’re going to get the right answer. They’re more trying to see you how you think, especially with whiteboard and questions or whatever. So show your thought process show your diagrams like drawing out diagrams of your Logic Pro flow or something like that could be really cool. Um, show your intermediary code, explain the pitfalls over your approach to like, tell them, I think there’s a faster way to do this, or if I’m working with a really big input set is going to be less advantageous or if I’m working with a small set of data, this is going to be less optimized if I’m using a large data set. So I would definitely try to explain the pitfalls of your approach as well. Or if you’re using recursion, say this code might be elegant and it might be easy to write but If I’m working with a really large input size, then I’m going to overflow the stack. And that’s not good.

Unknown Speaker 45:06
I like to kind of close this out with one final tip. And I think this is a very important thing for everybody to internalize which is it is completely okay to be rejected. You cannot get a job offer for every single job that you apply to every single interview take is not going to go as planned. The more honestly that the more interviews that you’re doing, the more you’re going to learn how much it varies from company and you will find one a company that’s going to be the right fit even from the interview process. You can you can really learn a lot about the company when you’re going through that process.

Ali 45:47
Yeah, a toxic interview process usually signifies the toxic company. If you their meetings go through rounds and rounds and rounds and rounds and rounds of interviews for no apparent reason. They’re just Doing it to stress you out. Essentially, that’s usually not a good sign that the company is going to be a great one to work for.

Emma 46:08
Absolutely. So, you know, kind of to wrap up this episode a little bit, let’s talk about some resources that you can use to practice or to learn more about the interview process. Then there are quite a few websites that you can use to actually practice your coding challenges. Some that I’ve used in the past are hacker rank, which they’re really hard I’m not gonna lie, some of these hacker problems are really difficult. So don’t be discouraged if you can’t get too far. educative. io is another site I’ve used again, I think hacker it’s free. I believe you have to pay for educated by Oh, at least for full access, but I would recommend it if you can afford it, and if not totally fine, and you’re not going to be in any worse position. And then there are a couple others. The code wars is another one and exorcism IO as well. We’ll link these all in the show notes. But then there’s also one course that I loved and I want to shout out To Kyle shovelin, he has a negative course, about data structures and algorithms and JavaScript. Because typically you see a lot of these courses or books, but they’re written in Java or c++ or other backend languages. So the fact that he has it written in JavaScript is really fun. And one thing I did when I was taking that was to, like refactor his code, so I think he was using like, class components. And I was like, I’m going to use stateless functional components. There’s I don’t know, I like I did it in a different javas or react, not react, sorry, I did it in a different JavaScript format. So I was still using the logic behind that. But I was rewriting it in a way that was more relevant from like, it made more sense to me, but also it helped me learn. So that’s what I’d recommend is like, and also if you see some of these example problems in a different language like Java, if you can understand or maybe it’s pseudocode, try to code it in JavaScript or try to code it in your language and see if you can get the solution.

Ali 47:55
Definitely. There are also so many databases of questions that people have been asked in interviews, there are GitHub repositories that are just lists of interview questions. So we can link some of those in the show notes as well. There’s so many blog posts of how to kind of tackle interviews as well. And also Cracking the Coding interview, which we talked about a bunch and the data structures and algorithms. What I have a weird feelings about there being this whole small industry within tech about tech interviews, like that feels really strange to me that it’s kind of an industry of itself. But that book has a lot of really great computer science knowledge and a bunch of practice problems, which I love. So we’ll check that out as well. Even though the examples are in Java, you could complete them in JavaScript, and that would be a great learning experience. Awesome.

Emma 48:46
So before we wrap up, I think that you know, I just want to reiterate Kelly’s points Okay, if you’re rejected, I’ve gone through many rejections and it has nothing. It doesn’t mean you’re not valuables as a person or As an employee, it just means it wasn’t the right role for you. And if you can’t ask for feedback, you know, I would recommend asking for feedback. A lot of times they can’t give it to you for legal reasons, but it doesn’t hurt to figure out some areas for improvement. But with that, let’s, let’s talk about some shout outs. So I’m gonna kick it over to you, Allie, you want to tell us a shout out for this week? Something cool that happened?

Ali 49:21
Yeah. So I moved to New York City. And so I want to shout out the city. It’s, there’s just so much to do. It’s kind of the epicenter of everything. I feel like everything that you could possibly imagine is a couple blocks away, and it’s just kind of magical. So big shout out to New York City. Emma, how about you?

Emma 49:42
I would like to shout out undraw, which has been my favorite open source libraries for illustrations where you can actually go you can export like PNG as an SVG is and you don’t need a credit, Catarina or undraw at all. She’s just an amazing designer and I think she lives in Greece. It’s just a really great platform. eminence, they’re constantly pushing out new illustrations. So shout out to them. We’ll link them in the show notes as well. How about you, Kelly?

Unknown Speaker 50:06
So when this episode launches, I will be back to work from vacation. So my shout out is going to be the fact that I’m finally going on vacation and completely disconnecting from work and deleting my email from my phone and creating a filter essentially on my my email just basically says like if it doesn’t have the word urgent in the subject line, I will not receive it. I will see it when I get back. So I’m really excited for Finland because I live in Atlanta and it we don’t get winter weather here pretty much ever. And I’m excited to just disconnect for a little while

Ali 50:44
amazing. I love that.

Unknown Speaker 50:47
So if you

Ali 50:48
liked this episode, tweet about it. We’d love to read your feedback. Oh and leave us a review on iTunes to we like are always looking at those two so it helps other people learned about the show, so please, both Twitter and iTunes. And for one Twitter each week, we’ll give them a smashing book. They’re really really awesome books and really excited that we’re giving those away. And we’ve already given out a bunch of different listeners and you could win one too. We post new episodes every Monday, so chat with you next Monday, subscribe to be notified and leave us a review