How to Fail the Technical Interview and Still Get The Job

Maya: [0:00] Hello, everybody. My name is Maya and I also go by the moniker "The Black Female Engineer" on my YouTube channel. Today, we're talking about how to fail the JavaScript hacker Rank and still get the job.

[0:15] Let me actually move my face over here so you can actually see what this slide is talking about. I am a finance graduate turned software engineer. I graduated from college, what? May of 2020, so exactly last year after being a dual major in accounting and finance. Just six months later, I got employed by a Fortune 50 company to be a software engineer for them. Now, what happened in between there?

[0:45] When the pandemic hit, I was faced with a very real fact that now, I was graduating in the midst of a recession because of the pandemic, everything very much stopped. I needed to figure out what I wanted to do with my life because I am now faced with a realization that it's going to be hard to find a job. I was one of the lucky ones.

[1:13] I was able to get a job in finance. It was really nothing I was too interested in. It was a very small firm with very little pay. In general, I realized I didn't like finance enough so I had started learning how to code for just a couple of days. I loved it so, so much. I'm about to graduate college. Here, I am faced with this amazing career that I didn't even see for myself.

[1:50] How, what can I do to make it happen? I joined a coding boot camp. I joined Flatiron School. That was about four months. I've trained from June of 2020 to October of 2020. Skipping through all of that, of coding boot camp, the intensity, the hassle, it's a lot. Now, it was time for me to start looking for a job.

[2:14] I was mindlessly looking around for jobs, applying to anyone and everyone, playing the numbers game. After about six weeks of applying, I found what for me was my dream job. I applied. I was so happy to hear that I got a first round, behavioral, then a second round, and that it was my third round. It was a technical. I did not do very well.

[2:47] Let me move my face again so you can see just how not well I did.

[2:54] After submitting the assignment and whatnot, I saw that I had a HackerRank score of out of 70. Yeah, that is the zero. I remember seeing that score and be like, "You know what? I'll just go. I'll just stand up, go, and thank you for your time."

[3:14] To my, you could say, surprise, I ended up getting a job offer 20 minutes after the interview was over, which is still so wild to say. When I look back on the experience, when wondering why that was, I realized it's because I broke down the problem not only in thought, but in procedure. What does that mean?

[3:43] It came down to these four things and a bonus fifth thing. The four things are breaking down the problem, inspecting my inputs, maintaining efficient and proper coding procedure, if there's a roadblock, go around it, and keep the company's goals and objectives in mind.

[4:06] The best way I can go about explaining how to do all these things or at least how I did all these things, I'm going to actually present to you all with a technical problem that we'll use.

[4:18] The problem. At the Black Female Engineer Theme Park, visitors want to maximize the time they can spend enjoying the ride and activities in the park while minimizing the time they spend waiting in line. We would like your help implementing a feature to help park-goers tailor their BFE Park experience to their needs.

[4:39] We want to calculate the current wait time for each ride in the park. This will help park visitors decide which rides to attend, I believe, is the last...to enjoy is the last word there. This is the problem we're working with. Seems pretty simple, OK, pretty easy to comprehend.

[5:01] Now, let's break down the requirements. Typically, when you get some type of technical problems, some type of coding question, there's the overall objective. Then, there's the nitty-gritty of things, which is really where trouble can arise. You are given first, the number of rides, then an array of strings representing rides.

[5:22] Each string includes the ride's title, type, like coaster simulator, water, etc., ride length in minutes, number of seats, and current number of people in line.

[5:33] An example of what one string could look like, is Despicable Me Minion Mayhem simulator and 4, 20, 30, which is the ride length in minutes, number of seats, and current number of people in line. It'll be a bunch of all of these strings all in one array. This problem comes down to two things, the calculations and the sorting.

[5:59] The calculations. Complete the function gateway time estimates, which will organize the rides based on the right type and wait times. Calculate the estimated waiting time for each ride. Then the sorting is first, sort the rides in alphabetical order by ride type? Within each ride types, sort rides by estimated wait time from shortest to longest.

[6:20] For rides of the same ride type and wait times, write them in alphabetical order by title. Then, print the sorted list of rides with each ride's title, ride type, and estimated wait time. OK, this is the weeds. Remembering number one is to break down the problem, inspect your input.

[6:47] The very first thing that I want you all to understand from this talk and if not the biggest thing that I want you to understand is that we're trying to show employers what type of employee we are, what type of developer we are, and what we would be in the company.

[7:05] Overall, with this breaking down the problem, inspecting your inputs, we are people who will make sure things are running as efficiently as possible before we just jump into a new problem.

[7:20] With this, if you recall...Let me move this a little bit. If you recall, our input would look something like this, let rides array.

[7:32] It would equal this one array of all of these strings and this is just two strings. Imagine like 20, 30, even 100, because it's a theme park. Imagine a lot more strings like this, all in one array. There's a problem here. In these strings, we have different types of variables, basically, different types of inputs. We have strings. When I say strings, I mean words.

[8:03] We have words. We also have numbers that we actually need for calculations and things. When it's separated like this, it's very hard to grab these items because, four, you can't use this because our code does not recognize it as a number because it is in a string.

[8:24] The very first thing we need to do is identify that things are not presented to us in the best way possible, in the most efficient way possible. This doesn't directly coincide with answering the question, specifically. You could find a way to and solve the problem without doing this, but we're trying to show the employer what type of employee we are.

[8:44] With this, we are able to show them that we can take a second, take a breather, step back, and do what needs to be done to make sure that our code in the future will be as smooth and efficient as possible. That's where this function comes in.

[9:00] With this function...and I'm not going to go too deep in the weeds here. Basically, with this function, we are splitting up the strings we get to be their own little array. In that array, now if you see the output, there's Despicable Me Minion Mayhem which is a string because you know, it's a word, so that's OK. Same with simulator. Then we have 4, 20, 30 all represented as numbers. Do you see how they're out of that larger string?

[9:31] Now each little element has its, basically, own space is occupying instead of being gripped in all in one string. Now, in the future, we'll be able to use these numbers for calculations and grab them much easier.

[9:49] Like I said, inspect your inputs. Whenever you get a problem, take a second, take a breather, and ask yourself, is this the most efficient way that these inputs could be given to me? One very clear way you can see that it's not is when you see numbers inside strings.

[10:06] Number two, maintain efficient and proper coding procedure.

[10:13] Coding exams, technical interviews, they are stressful. They're very, very stressful. However, again, we're trying to show them who we are as developers.

[10:26] We are people who, even in the midst of stress, we are not going to let that be the reason why we submit sloppy code and we just throw away all of our time of training, learning, and practicing. Yes, you get the answer, maybe you get the answer, but it's in this terrible package.

[10:45] When you think about working, odds are, what you are given, it is not something that's going to end with you. It's going to be given to somebody else in the future. Whether it be another developer, another team, or a whole, another department, you want to make sure that it is as clear and efficient as possible.

[11:02] Make sure you're doing things like making sure that your functions aren't ridiculously long, making sure that your variable names are descriptive instead of saying X equals this and Y equals this, actually making sure that they are descriptive. Let line length equals this. Let seats equal this.

[11:22] Then, wait time equals line length divided by seats times duration. We don't want decimals so we're going to do Math.floor(). Making it so that ideally, someone who doesn't have a background in coding, in tech, in JavaScript can still look at your function and get a good idea of what's being done here.

[11:48] I believe that my mom, a nurse, can look at this and be able to say, "Oh, OK. The purpose of this is to get the wait time for a ride." That comes down to how you break down the problem. Make sure that in all the angst, all the hurry, and worry, you are not throwing away the fundamentals of coding and making things just as easily digestible as possible.

[12:14] Number three. If there is a roadblock, go around it. If you recall from the calculations piece of the problem we were given, we needed to calculate wait time. In the problem given, ideally, they would tell you how to calculate this, either wait time or any other calculations, they would give you the formula for it. What if they didn't?

[12:42] If they didn't, let's say, we don't know what the calculation for wait time is because we're so stressed so we can't remember 10th grade algebra. We're stressed. There is a way to go around it and that's by simply commenting, "Hey. Due to the lack of formula for wait time, I will generate a random number between 1 and 10 to act as the wait time for visitors.

[13:04] Then, putting in something like this, let wait time equal Math.floor(), Math.random() times 11. This would produce a random number between 1 and 10 to serve as the wait time in minutes for a specific ride. This, of course, it won't feel great not being able to provide the calculation wanted.

[13:29] However, we're trying to also rack up as many points as possible. Odds are, you're not going to be sitting there for six hours. That it's not that much they gave you. They gave you 45 to 90, usually. It seems like a lot. That time goes by like that.

[13:47] You don't want to waste too much time trying to remember things at calculations that don't even directly relate to your coding abilities. We want to show them what type of coder we are. In the workplace, if you had this job, you would have access to something called Google, to something called Stack Overflow.

[14:07] You would have access to these things to say, "How would I calculate wait time?" Then, get the formula right there and put it in. You don't want to waste your time trying to remember things that, on the job, you actually really could easily ask the buddy next to you or search up.

[14:25] We want to instead focus on getting as much points as possible to show them what kind of developer we are. If there are roadblocks and you spend a couple minutes on it and you're fumbling around, and if you ask for the formula, they say, "Sorry. We can't help you there." Do something like this. Just go around it. Put in a random number. Then, move on. Time is of the essence here.

[14:51] Number four, keep the company goals and objectives in mind. Yes, we are trying to be developers or trying to get hired as developers and software engineers. But, we are also people who understand that this problem given to us, and not only this problem, but any problem given to us on the job, again, will not end with us.

[15:16] Even if we solve the problem, it's important to understand the impact that these problems have on the business, on stakeholders, and things like that. A lot of times, if not all the time, when you're given a technical problem, it directly relates to the work the company you are interviewing at does.

[15:43] You want to show that you understand that this is more than just a technical interview. This is somebody's actual jobs, an answer that somebody, if not you, have to answer for at some point.

[15:55] In this example, one thing you could say is, "Thank you for this question. This is actually very interesting because I imagine during the time of COVID, in the pandemic, needing to look at things like wait time, because if linings are too long, then that really impedes on the health and safety efforts of park-goers, of state officials, and people of that nature.

"[16:20] Because if lines are too long, then the place is probably crowded and now there's more risk of infection or transmission of COVID and other illnesses. I'm really excited to just dive into this."

[16:34] Being able to say that very quickly after you receive the question to show them that you understand that your job is not just be a robot, to just spit out answers, but you are able to critically think about the impact these problems have on the company and on consumers.

[16:53] Another thing you can do at the end of the interview is saying something like, "Now that we've gone through this question, I would love to see what other departments do with this information. For example, operations or the team responsible for designating which rides go where.

"[17:13] I would love to see what they do with this information and seeing how when inspected quarterly and annually, wait times and things like that, seeing how that affects business operations in the future."

[17:26] Again, spotting it off with, "I understand that this is important. I understand that this is why you gave this to me. I am more than just a person to spit out code for you. I will actually be a part of the thought process behind our business problems." Something quick like that can really, really, really help turn things around for you.

[17:47] Bonus, enter the interview with a refactored form of your solution. If you received the technical question while you're at home and you had, let's say, 90 minutes, a timer, on you to go through it all.

[18:05] If you do have the chance to see them in person afterwards, try to enter with a refactored form of your solution. Not only that, but if you do the technical interview, the coding challenge live with the interviewer right there staring at you, for the last five minutes ask, "Can I get about three to five minutes to go over my code one more time and make any edits to make sure that this is as efficient and proper as it can be?"

[18:34] Just then go back and go through your code. See if you named variables correctly. See if you actually could condense lines of code and condense functions.

[18:45] Just see ways to edit, because again, we're trying to show them the type of developer we are. We are developers that don't just settle for the right answer. We then go back and kind of like proofreading to make sure that things are as simple as they can be for the next person who has to have our code.

[19:03] Because it is not fun, y'all to be the person who makes other people's lives harder. That is what happens when you provide people code, that is just willy-nilly. That just is all over the place.

[19:15] Even if it has the correct calculations, it still is going to take hours, if not days, for them to decipher what you have going on there. Make sure you don't forget that part.

[19:26] Thank you so much, everybody. It was a pleasure speaking with you all. I hope you got something useful out of this. You can come out feeling a little bit better about technical interviews and knowing that you can indeed fail and get a job.

[19:45] If you would like more tips or anything, again, I have a YouTube channel called The Black Female Engineer. You can also email me @theblackfemaleengineer@Gmail.com. Thank you so much. I look forward to hearing from you. Bye.