Video details

What They Don’t Tell You About Tech Interviews

Career
06.02.2022
English

Presented by Women Who Code CONNECT Recharge 2022 Speaker: Fatima Taj (she/her), Software Engineer @ Yelp CONNECT Recharge 2022 Playlist: https://youtube.com/playlist?list=PLVcEZG2JPVhcLkMbJ3TkSajGDfFNOdCEd
Are you terrified of the tech interview process? Do you wish someone could just give you an end-to-end overview of what the whole process is like? Or are you someone who’s very frustrated with how you just don’t seem to understand what the interviewer wants? You get interviews and you seem to do everything right on paper, but something’s still amiss? If you find yourself saying yes to any of these questions, then this workshop is for you. In this workshop, we’ll walkthrough the tech interview process, including the art of networking during COVID, the standard tech interview process, tips and tricks for behavioural and technical rounds which go beyond just getting the question right and that’ll really help you stand out as a candidate, post-interview etiquette, compensation packages and negotiation etc. The best part? I recently went through this process myself so you’ll also get to hear the silly mistakes that I made along the way and what I learnt as I went along!
💻 WWCode Digital Events: https://www.womenwhocode.com/events 🔎 Job Board: https://www.womenwhocode.com/jobs​​​​ 💌 Make a Donation: https://www.womenwhocode.com/donate

Transcript

All right, everyone, we're going to go ahead and get started. My name is Molly, and I will be the moderator for today's chat. What They Don't Tell you about tech interviews with Fatima Taj. Fatima is a graduate from the University of Waterloo, Canada. Post graduation, she's worked full time as a software developer at DRW, a trading firm, and she currently works at Yelp. As a software engineer. And I'm going to go ahead and turn it over to Fatima. Thank you. Hi, everyone. My name is Fatima, and I'll be conducting this workshop on What They Don't Tell You about Checking Abuse. So, as it's already been stated, I currently work as a software engineer at Yelp, and the idea for this inspiration for this workshop was actually inspired by my move over to Yelp. I joined Yelp roughly like, seven to eight months ago, and as I was going through the technical interviews myself, I felt that while there's a lot of discussion that happens around technical interviews, most of that discussion just happens to be around, like, the technical knowledge that you're required to have for a technical interview. Right. But through my experience, I felt that there's a lot of other factors at play that really contribute towards your success in a technical interview, and that is what I hope to shed some light on through this workshop. So this is roughly what the workshop is going to look like. We're going to go very chronologically all the way from the very beginning, where you're just starting to shortlist jobs and reach out to recruiters and people within your network, all the way to the very end where, let's say you're trying to decide between multiple offers and you're thinking about things like compensation and negotiation. Okay, so to start off in the pre interview stage, I'm not going to delve into any of the prerequisites. So I'm assuming that your resume is ready to go. You have all that covered. I want to talk about more on the subject of how COVID has impacted the recruiting landscape. Right. Because obviously recruiting looks a lot different now. It's not at all what it used to be in the pre pandemic world. Obviously in the pre pandemic world, we were used to in person interactions with our recruiters. And what that typically looked like was you would meet your recruiter to either like a tax fair or conference or hackathon, and you go up to them, hand them your resume, and kind of go from there. But obviously, now that we don't have the luxury of in person interactions, how do you go about networking in this virtual world that we live in now? And I want to talk that leads me to basically the concept of an elevator pitch. An elevator pitch is essentially this brief introduction that you prepare for yourself. And as the name implies, it should be effective enough to catch someone's attention in the same amount of time as an elevator, right? So ideally it should be very short and sweet, but effective nonetheless. Now, a couple of tips for your elevator pitch. First of all, please be genuine. I think that if you're genuine, your enthusiasm and passion will really show. And I also say this because keep in mind that recruiters deal with a lot of people on a daily basis, so they're pretty good at figuring out whether or not someone is or isn't being completely honest about either their skill set or their past experiences. Secondly, express genuine interest in the company. Like really sit down and think about why you want to work for a particular company. Is it the engineering culture? Is it the product that really excites you? Is it the culture of innovation, mentorship? Whatever it is, I highly encourage you to actually think about this question for a couple of reasons. One, this is a fairly typical question that your recruiter is going to ask you. And again, this is also a question that's bound to come up in even later parts of the interview process. So I think it's just better if you do your due diligence early on in the process as opposed to later on. Secondly, as someone, I personally conducted a lot of interviews myself and you would be surprised to know the number of candidates that come into interviews having not a clue what the company does. And obviously, if you don't know what the company does, you're not going to be able to answer why you want to work for them, right, or why they interest you. And it just makes you look very disinterested. And obviously it doesn't reflect positively on you. It just tells me that I'm just probably another statistic for you and you're really not interested in this company in particular right? Now, when I say that, like, express genuine interest in the company, by no means am I saying that all you need to know what their last quarter EPS earnings were. But at the very least, go to their website, read up on their mission statement, read up about their values. I can give you a personal example of how I like to answer this question. So assuming that I'm applying to a software engineering posting, I like to talk about three different things in my response to this question. So for the first part of my response, I talk about the technical appeal. So if I were to join this company, technically, how would they help me improve my skill set as a software engineer? In the second part of my response, I talk about the culture Lupio. So if there's something about their culture that I really like and I want to be a part of and in the third part of my response, I talk about particular initiatives that the company might have taken that I really liked or appreciated. So for example, when I was interviewing with Yelp, I told them that I really liked the way Yelp responded to small businesses when the panda kid. I think this just gives like a more personalized kind of touch to your response and it also shows your interviewer just the level and the depth of your interest in this particular company. Moving on. So on this side, you'll basically see two screenshots and these are basically just personal messages that I sent out in my most recent job hunt. And the whole motivation behind this site is to basically demonstrate how you should tailor your approach based on the person it is that you're reaching out to. So the one on the left is just a message that I sent to a recruiter on LinkedIn. I think as far as recruiters are concerned, I think it's perfectly okay if you're just get straight to the point. You don't need to sugarcoat your message. You don't need to beat around the bush again. I always like to tell people that, be respectful of a recruiter's time. Obviously, just like yourself, there's likely a lot of other people that are reaching out to the very same recruiter. So in your messages to a recruiter, be sure to be very crisp and make sure that your message is very well formatted and to the point. Like, a rough template that I like to stick to is quickly introduce yourself, then mention the exact opening or the exact posting that you're interested in. If you can include a link to it that's even better, quickly talk about why you would be a good fit for that opening. And then lastly, always include your resume for the reference. So I think that's like a good template that you can stick to as far as recruiters are concerned. Coming to the screenshot on the right, I do think that as far as people within your network are concerned, like, this includes friends, former colleagues, people that you went to school with. I do think that your approach should be a bit different because ultimately you share a different sort of relationship with these people. So you don't want to make them feel like you're just using them as a means to an end. So don't make the conversation sound too transactional. Like this message, for example, the one on the right, this was a Facebook message that I sent to, like, a former colleague of mine, and I was hoping that they could refer me for an opportunity that was open at their company. But yeah, I would always suggest that whenever you're reaching out to people within your network, don't be too direct. I think one of the best ways of kind of going about it is that in your first, ask them to have a virtual coffee shop with you, just to kind of break the ice. Try to have and build a very, very natural, very organic sort of a relationship with them. Ask them about what they do, what their day to day looks like, what parts of their job that they, like, dislike. Try to get an insight into the company culture, the internal workings of the company, and then you can slowly kind of maneuver the conversation into asking them to refer you. Also, keep in mind that these people, like people who already exist within your network, this is the best opportunity that you have to get to know kind of both sides of the coin, right? Like, these people will usually be a lot more forthcoming about both the pros and the cons of working at a given company. So again, I think that's something very useful for you to know beforehand. So, yeah, something to keep in mind. Another very popular question that I tend to get is just the question of how many jobs you should be applying to. I wish there was like, a magical number, but sadly there isn't. But I do have a couple of tips as far as this is concerned. One, I would really encourage you to harness the power of platforms like LinkedIn, Glassdoor, etc. So I personally use both these platforms very successfully. I got an internship off of Glassdoor and then I got my most recent job off of LinkedIn, honestly, my most recent job, and I just stuck to LinkedIn. I didn't check password too often because I also felt that there's, like, a lot of overlap between the postings that you see in all these different platforms. So I think it's perfectly okay if you just stick to either one, whatever you prefer. Secondly, just as far as the process of applying to jobs is concerned, there's no denying that that's an incredibly boring process, right? There's no two ways about that. Like, all it is, is you're kind of sifting through jobs, you're shortlisting them, you're filling out the same fields over and over again, uploading your resume repeatedly so it can very quickly get very tedious and very overwhelming. So I've kind of experimented with both ends of the spectrum as far as that process is concerned. So I've been the person who used to sit down, like, every Sunday, go through thousands and thousands of postings, and kind of applied to jobs in bulk. I personally wouldn't endorse that way of going about it because I think it's a very indefinite use of your time. Right. Obviously, when you're going through that many openings, you're not going to be able to finish going through them within an hour. It's likely going to take you a couple of hours. And again, like I said, this process is already so tedious, you might just give up and be like, I don't want to do this anymore. Right. And again, when you're going to that many jobs, there's a pretty good probability that you might skip out on a couple of really good ones. So, again, I wouldn't endorse this way of going about it. What I did in my most recent job hunt was that I kind of incorporated this into like a part of my daily routine. So every day I would set aside anywhere between 30 to 45 minutes where I would just apply the jobs, right? Like, if you can, I would apply the filters. I'd like filters out the jobs for you that were posted within the last 24 hours. Obviously, that list isn't going to be as long. I would quickly go through them and I would apply to the one that I was interested in. I think there's a couple of benefits to going about it this way. One, you time box yourself, right? Like, you tell yourself that, okay, this is something that I'm doing every single day, but I'm not going to exceed this 30 to 45 minutes mark, right? So one, I think it's like overall, it's just a lot more efficient use of your time. And then secondly, I think it really takes the mental pressure off of this whole process as well. As well, I know that for a lot of my friends, the part about looking for a new job that they dread the most is just this part where you're just applying to jobs over and over again. So when you have the assurance that this is something that you're going to be doing every single day, it really takes the mental pressure off of this whole process as well. Okay, so moving on to the actual interview, I'm going to first start off by giving you an overview of what the standard interview structure is, at least as it applies to kind of big tech companies. Obviously, this can look a lot different for smaller or medium sized companies or startups, but you'll see common elements in all of them. So it starts off with a recruiter reaching out to you with either a phone screen or an online coding challenge. In some cases, you can also get a take home assignment. Now, I personally never seen a big tech company kind of give out a take home assignment. From what I've seen, they like to stick to traditional phone screens or their online coding assessments. But just so you're aware, I'm personally not a fan of take home assignments at all. I think the amount of effort that you put into them is absolutely not worth what you get out of it, but it's part of the process. Then, depending on the outcome, there can be a small behavioral round following this. Again, not every company might do this, but this is usually conducted with an engineering manager and the purpose of this is to assess a cultural fit. And then lastly, you make it to your onsite. This is a standard four to 5 hours. It varies a lot by company. It's a combination of technical, behavioral and system design rounds. There can be anywhere between two to three technical rounds, one system design and one to two behavioral rounds. In the prefrontal world, obviously, the onsite was the part where the company would fly you out to their headquarters and basically spend an entire day at interviews. But obviously, in the virtual world that we live in now, this is also conducted virtually. And like I said, this varies a lot by companies. So to give you a couple of examples, some companies can choose to do like, hybrid kind of rounds. So those rounds will be a combination of behavioral and technical questions. But then other companies might have dedicated rounds that are either technical or behavioral in nature. So, for example, when I was interviewing with Amazon, their final on site was five rounds in total. Each round was 45 minutes. I would get like a 15 minutes break between each round, and for each round we would start off and the first ten to 15 minutes were spent on behavioral questions and then the rest of the time was spent on technical questions. So, yeah, you can see a lot of variation here. Another thing that I wanted to mention is that different companies, again, this is very company dependent, but different companies might offer you different sorts of accommodations for your final onset. So, for example, when I was interviewing with Twitter, I was actually given the option to either do my onsite in one go, or I could split it across two days. So again, like I said, not every company might give you this flexibility, but I think it's something useful to know. And again, this is definitely something that you can bring up to your recruiter if you feel that if you're very overwhelmed by the prospect of doing your onsite in one go, on the subject of your recruiter, your recruiter is basically your point of contact throughout this entire process. And as you move to the onsite, they'll also set up like a chat with you just to give you an overview of the logistics of what your onsite will look like. And I highly encourage you to use this opportunity to ask them anything that will put you at ease. So you can ask them things like, when can you expect to hear back after the interview? How will the technical rounds be conducted? What kind of a platform will the interviewer be using? Would it be like something as simple as a Google Doc? Or would it be something like Hacker rank or CoderPad, things like that. So you can basically ask them anything that will put you at ease before your interview. Now, moving to the knees and bones of this workshop, I'm going to start talking about the behavioral parts of the interview first. Now, I actually have a very interesting kind of history as far as behavioral interviews are concerned because for the longest time I used to really underestimate behavioral grounds and in my head I used to think that all this is like the easy part of the technical interview process. It's just a conversation ultimately, right? It's just a conversation that you have with your interviewer. So why on earth should I study to have a conversation with someone? It should be like a fairly natural sort of a process. Let me tell you right off the bat. That is a very misguided way of going about it because your behavioral interviews are as important as your technical interviews. They're there for a purpose. They're not like still around. And through your behavioral interviews, your interviewers are basically looking for certain signals from you as a candidate, right? So to begin with, this is a list that I've put together. These are some very typical questions and the list extends to the next slide as well. These are some just very typical questions that you can expect to be asked in a behavioral interview. These are questions that I've historically been asked and again, just based off of research that I've done. In terms of your responses to behavioral questions, I do have a couple of tips. First of all, please be honest. Don't fabricate experiences because you will most likely be caught. It's okay to do little minor modifications here and there, but I wouldn't advise you to share something that's completely fictitious. The reason why I say this is because interviewers always ask follow up questions. So let's say that you're asked a question and in your response you share something that you just made up on the spot. Now, what's going to happen is that the interviewer is going to listen to what you had to say and then they're going to pick up specific elements from what you just shared and they're going to ask you about it. So in that follow up cross examination that happens, if you haven't had a chance to really think your response to the interviewer will figure out that you're either not being completely honest or you just want well prepared to answer this question. Obviously, you don't want your interview to be thinking either of those two things about you. So I think that as far as behavioral interviews are concerned, just always be honest. Secondly, be a good storyteller. And one of the best ways to go about this is to use the Star format. This is like a very widely used, very popular format within the tech industry. And this is definitely something that you should look up on your own time. Then for each category that I showed you on the previous couple of sites, I would always advise you to prepare at least more than one experience. I know obviously it can be very overwhelming, right. For me, at least whenever I used to be preparing for my behavioral interviews, the part that I used to kind of dread the most was just like sitting down and thinking about all the experiences that you can talk about. Right. But as overwhelming as that might be, I do think that ultimately it ends up serving you pretty well because you might find that a lot of these questions are being repeated by your interviewers, they might change the wording of it, but the central theme of the question might stay the same. So just to avoid sounding like, too repetitive and just to avoid rinsing and repeating the same story over and over again, I think it's always better if you go into your interviews having thought of like, multiple experiences and multiple scenarios that you can share with your interviewers. Next, show what you've learned from their experiences, even if there were failures. Now, I included this bullet point very specifically because I know that for a lot of people, questions that have to do with failures that you've experienced or setbacks that you've experienced can feel very daunting. And I know that for a lot of candidates, we tend to think that all these are meant to be chip questions and there's not really, like, right answer to them. Okay, first of all, I want to clarify that the right response to tell us what a weakness share, like, a weakness of yours is never that you work too hard. That is absolutely not the correct way to respond to that question. And in fact, I think it actually kind of backfires on you because it kind of shows that you don't have humility coming back to what I was saying, the trick to answering these sorts of questions is that you want to show your interviewer what you've learned from your failure, right? So I always try to respond to these sorts of questions, keeping three key components in mind. So one, obviously, I'll start off by sharing my experience, then I'll talk about what I learned from that experience. And then lastly, I'll wrap it all off by talking about how I changed my ways moving forward from that experience. So I think when you incorporate these three distinct elements to your response, you kind of show the interviewer that you've come full circle, right, like, you've shown the interviewer that you actively learn something from this setback that we've experienced, and then you kind of change your weight moving forward as well. Because I think about it, ultimately, what is a failure? At the end of the day, every failure that you experience always presents an opportunity for you to grow from, for you to learn from, right? And that is exactly what they're hoping to see in your response to these sorts of questions. Lastly, if you ask the question that you don't have an answer to right away, you can always ask your interviewer if you can have one to two minutes to think about it. I personally wasn't aware that you could do this, but I have done this and this is perfectly okay. However, I will say that please keep in mind that interview rounds are anywhere between 45 minutes to an hour. So obviously you don't want to be thinking about a question for five to ten minutes at end. Even if you are, you're in a real will just move you on to the next question. But if you do need like a couple of seconds or one to two minutes to just kind of structure response in your head, it's perfectly okay for you to take that time. Okay, so moving on to the technical parts of the interview. Like I said, the purpose of this workshop is not to tell you what technical knowledge you should bring in. I'm not here to tell you what algorithms you should know or what data structures you should know. I want to focus more on the optimal strategy that you should have for your technical interviews. So, first of all, please keep in mind that questions are purposefully made and it's your job to clarify, because a big part of technical interviews is that they're looking for your abilities as a software engineer. That goes just beyond turning out code, right? Obviously, there's a lot of other components to being of the software engineer. For example, one of the abilities that you should have is the ability to do requirements gathering, right? So that includes things like asking good, meaningful, insightful questions. How do you deal with the specifications and the question prompt? Do you or do you not clarify assumptions in a technical interview? Please keep in mind that you do not have the liberty to make any sorts of assumptions, okay? Even if you're considering making an assumption, please run it by your interviewer. And I would say that the best way of going about it is to just quickly make a comment and note it down, right? Because again, the better document in your code is it's just a better reflection on you at the end of the day. It's a great testament to your communication abilities as a software engineer as well. Next, write down test cases, specifically corner or edge cases. And I say this very early on because I know that, again, as software engineers, we tend to have this horrible, horrible tendency to not think about testing. Either we don't think about testing or we try to delay it as much as we can because our focus is always like, oh, we just need to get the logic right and then we'll think about testing. You cannot do that in a technical interview. In an interview setting, even before you start working on your core logic, you need to show your interviewer that you thought about the corner and edge cases, right? So what you should do is, again, note down the corner edge cases and then quickly work with your interview to see what the expected test outcome should be for these test cases. Because doing this check kind of reinforces whether or not you understood the question correctly, right? Like, you don't want to be stuck in a situation where you didn't clarify with the interviewer whether or not you had understood the question correctly. You went straight into implementing the logic and then five minutes left to the interview and you realized that oh, I hadn't understood the question correctly, right? Like, you don't want to be stuck in that sort of a situation. So it's always better that before you dive into any coding, you identify the corner cases, you make a list of them, quickly, discuss those with your interviewers, see what the expected test outcome should be, just so you're 100% clear that you've understood the question and all its requirements. Next, communicate effectively, talk things out loud, discuss trade offs, different strategies that you're considering, et cetera. Please don't be that person who within a technical interview. Like, once you get the question, you just kind of shrink into your corner and then you're selling for the next 30 minutes, working on the problem. I can assure you that even if you've got the problem right, you would not pass that interview because the interviewer has absolutely no idea and no insight into what your process was. Right? They can't tell what's going on, obviously, in your mind, right? And that is exactly the point of a technical Indian view. They want to see your approach towards technical problems, and they don't know that. They don't have any insight to that if you're just silent throughout the process. Right? I can tell you again, personally, I've been in a lot of interviews where I might not have gotten, like, the 100% optimal solution. I was maybe like, anywhere between 60% to 80% there. But just because I was communicating very well throughout the entire process, I was discussing things with my interviewer. I was discussing different trade offs, different strategies that I was considering. Not only was I able to pass those interview rounds, but I actually got great feedback about them as well. So please keep this in mind. Communication is very integral to your success in a technical interview. If you're stuck again, you can ask for help. But I'll say that there's, like, a caveat to this, right? And the caveat is that you can ask for help provided that you've been communicating well up to this point, right? Like, if you've been selling for the past 20 minutes, you can't just expect your interviewer to know what you're stuck on or what you're struggling with. In fact, I'll say that one of the biggest perks of effective communication is that if the interviewer feels that you're going to off track, they'll actually stop you right there. They'll cut you off and they'll kind of nudge you in the right direction. So overall, it also saves you potentially a lot of time. And time is of the essence in a technical interview, okay? So not every interviewer will allow you to compile your code and see if the test case is passed. Now, this kind of goes back to the point earlier that I was making about the importance of testing. Now, I'm sure that we've all been in a situation where, let's say you're working on this very challenging Nicole problem and you're almost there but you still have a couple of test cases that are failing. So what you do is that you make a little change in your code and then you hit the run button. Again, you still have a couple of test cases that are failing. So what you do is that you get into this loop of like making the change, hitting the run button, making a change, hitting the run button, until eventually you either get to the right solution or you will give up. Right? Now I call this the abuse of the run button. And you cannot under any circumstances do this within a technical interview because it tells your interviewer two things about you. One, it tells them that you don't have the development abilities to figure out what the problem with your logic is. And then secondly, it tells them that you rely on automated testing to tell you what the problem is, right? So referring back to the optimal strategy that I was talking about that you should have for your technical interviews, once you get the question, you're going to take your time to read the question. You're going to ask good, meaningful, insightful questions. You're going to clarify any big specifications in the question prompt, and you're going to clarify any assumptions that you are going to base your solution off of, right? And again, the more well documented your code is, the better. The better it is. Then you're going to identify corner or edge cases. Again, you're going to note those down. You're going to quickly work with your interviewer to see what the expected test outcome should be for these test cases. Because again, this is a great testament to whether or not you understood the question correctly. Only now will you delve into the actual code, right? Once you're done working on your quote, before you hit any sort of run or submit button, you're going to do this exercise where using the code, the test cases that you identified earlier, you're going to step through your code line by line. And I'm not exaggerating that. I actually mean line by line. Now, right now it might feel that like, oh, that should be fairly simple. I can assure you that it's actually not. Stepping through your code line by line is actually pretty challenging because when I say line by line, you're basically seeing how, like line after line, how the different variables are being updated, right? And especially in an interview setting, it can be pretty challenging. So I would actually advise you that even in your own personal time when you're doing legal problems, try to do that. Try to step through your code line by line just to see what that process is like. Now, when you do this exercise, again, it shows your interview a couple of things. One, it shows them that you actually have the skill to step to your code. And then secondly, it shows them that, okay, this person has reasonable assurance that their piece of code is going to work as expected, right? So at the very least, please don't forget to do this exercise. Even after having done this exercise. If there's minor errors here and there, that's perfectly okay, that's very normal. But at the very least, you need to do this exercise to show your interviewer that you have reasonable assurance that your logic is going to work as expected. Now, moving on to the system design rounds, I actually don't delve too deep into system design rounds in this workshop because I think, honestly, system design rounds are like a completely different beast altogether. I could have a completely separate workshop just dedicated to how they work and things that you should watch out for as far as they're concerned. But the only thing that I'll say right now is that for your system design round, it's very important to have. It's very important that you have a visual component to your responses. It's very important to draw diagrams or class diagrams if the question is about object oriented design. And this is because a big component of system design interviews is that the interview wants to see your understanding of how different components of the system are interconnected. Lastly, if you're nervous about your technical interviews, I would really advise you to watch, like, real life technical interview videos. This is something that I did and honestly, it was a lifesaver for a couple of reasons. One, it just kind of put me at ease, right? Because I think when we go into these interviews, a big reason that we're so scared is it's just fear of the unknown. We don't know what's going to happen. We know the format and all of that, but we haven't really experienced it. So for me, at least, a big reason that I used to be so scared was that it was just fear of the unknown. I just didn't know what I was kind of getting into. Secondly, I think that at this point, technical interviews definitely have a reputation within the industry. They're supposedly so scary and so overwhelming and so intimidating. Every time I go on LinkedIn, there's like 20 different people talking about their different experiences and obviously everyone has a different experience, right? And then lastly, I think that as candidates, when we go into these interviews, we go in expecting perfection from ourselves and we think that if there's anything less than perfect, we're not going to get that coveted offer, right? And that could not be further from the truth because no one expects perfection from you in a technical interview or any interview for that matter, right? Because at the end of the day, an interview is an interaction between two human beings. So by the very nature of that, there's bound to be issues or little mistakes that you make here and there. And most of these mistakes are like very forgivable mistakes. So, like, for example, a lot of people stutter when they're nervous. I do that. It's perfectly okay to do that. It's okay to be stuck. It's okay to ask for help. It's okay not to have the right answer right away. So I think watching these videos, it just kind of humanized this whole process for me, right, and it helped me realize that a lot of these mistakes that we think that, oh, this is going to be like an immediate deal breaker. A lot of these mistakes are pretty forgivable human mistakes for you to make. We're almost at the end of the presentation. This is kind of like the last part. So in the post interview part first, I want to give you like a quick overview of what happens behind the scenes once we're done our interviews. Because I think that, again, as candidates, we tend to assume the worst, right? Like, if we're not hearing back immediately after an interview, we tend to think that all, we're probably been rejected, they're not, we didn't do well, and that might not necessarily be true. So basically what happens is that once you're done your interview, your recruiter basically puts together this package for you that includes your resume, any code samples that you submitted throughout the entire interview process, and then feedback from all the interviewers that met you. And then this package is then sent over to the hiring committee, which makes the final decisions as to whether or not an offer is going to be extended to a candidate. Now, the frequency at which hiring committees meet can look very different based on the company. So I've interviewed with companies where the hiring committees would meet as often as three times a week. So obviously with those sorts of companies, the turnaround time is going to be very quick. You're likely going to hear back about the results of your interviews within one to two days. Right? But obviously, like I said, the frequency can look very different based on the company. So that's why there might be like a considerable gap between once you finish your interviews and then once you hear back about the results of your interviews. This is a very oversimplified, high level view of how hiring committees work. If you're interested, definitely go look up on your own time. It's very fascinating to just kind of learn more about them. Google, for example, is very famous for how their power companies work. Then obviously, as far as hearing back from your recruiter is concerned, I think there's a couple of things that obviously we should keep in mind. One, obviously no candidate ever wants to hear back and everyone wants their recruiter to tell them that they've been rejected. But I think even in cases of rejection, I think there's much better professional ways of going about it. Please don't be that person who just leaves the rejection email and then off to the junk folder. Out of sight, out of mind. I think at the very least, please talk to your recruiter. You have to realize that your recruiter is someone who's with you from the very start all the way to the very end. So thank them for their time. If company policy allows, you can ask them for feedback. Now, bigger tech companies actually have explicit policies against giving feedback, so they'll just straight up tell you that we don't share feedback, but smaller companies are usually pretty okay. I personally asked two of the companies that I interviewed with for feedback and they were perfectly okay sharing that. And honestly, that feedback is just invaluable. Right? Please be respectful of other companies that you might have interview scheduled with in case you've accepted an offer. Please don't coast anyone. Be respectful of their time and respectfully let them know of your decision. And I say that in my opinion, I think irrespective of whatever the outcome of your interview is, it's always better never to shut the door completely on a given company unless you saw some explicit red flags in your interviews with them. I think it's always better to propose things connected for future opportunities. Because this way, not only does your network continue to grow, but the next time that you're in the job market, you have some solid places to start from. And just to kind of give you an example, this is an email that I sent out to a company that I was no longer interested in interviewing with, just to kind of demonstrate this post interview etiquette that I was talking about earlier. Okay? I promise. This is the actual last and final part of my presentation. This is something that I'm very passionate about. I love talking about negotiations for a couple of reasons. One, this was something that I didn't do for my first full time offer out of school, and I regretted it so bad for the next two years of working at that company. Ironically enough, I actually knew about the importance of negotiation throughout my undergrad, but somehow when I got to that time, I just kind of chickened out. I got so conscious of myself. I felt so underconfident and so unsure of what I was bringing to the table that would justify asking for a higher salary that I decided not to try to negotiate, which was a horrible decision on my part. Secondly, I think there's a huge lack of awareness about as far as negotiation is concerned. Right. I know that there are so many people out there who are not even aware that you should and you can negotiate your offer. And lastly, I think there's also a lot of awkwardness that surrounds this conversation. Right, and I'll get to that later. But to start off, I'm just going to give you, like, a quick overview of what typical compensation packages in tech are like because they can have multiple components to them. So there's a base salary which is usually like this is pretty standard, obviously, and this is usually the most difficult to negotiate. Then there's your restricted soft units or your RSU's. Now, with your RSU you need to understand the vesting schedule. So typically companies follow a four year vesting schedule. And what that means is that each year 25% of your RSUs will vest. Your RSUs are only kind of monetary worth anything to you once they have vested. So let's say that tomorrow you sign a contract with the company and they grant you 100K worth of RSUs they haven't vested yet. So technically they don't really mean anything to you right now. They're equivalent to like $0 to you right now. However, after your first one year anniversary of working at that company, 25% of your RSU's will west. And at this point they're just company share. So you can basically do whatever you want with them. You can choose to sell them at the time or keep them sell them at a later time. It's all up to you. But yeah, with your RSU you have to be mindful of the best thing schedule. Then there's a yearly bonus. Again, I think this is pretty standard. It's a set percentage of your base salary and this is prorated. So what that means is that if you worked for a company for half a year, your yearly bonus would be half of what it would have been if you had worked there the entire year. And lastly, there's a sign in bonus and this is usually where you have the most room to negotiate. Please do keep in mind that your signing bonus is a one time thing. You only get it in your first year. So if you're calculating what you're going to be making after the first year, it will be your base, your yearly bonus and then your Rs. Use that with that year. As far as research about compensation numbers is concerned, obviously talk to your friends if they're comfortable sharing their packages. I always think that it's better to talk to friends across a wide variety of industries because I think it just gives you a much better idea what the market might be willing to offer you. So talk to a friend who's working as a software engineer at the day, like a bank versus say, a hedge fund versus a big tech company as far as resources online are concerned. I actually wouldn't recommend Glass Store in this case because it can be pretty unreliable. I would recommend something like Level FBI. I personally use it and I highly recommend it for a couple of reasons. One, it breaks down the salaries for you into these different components that we talked about. Then it also shows you how salaries differ based on location. So keep in mind that you could be working for the exact same company in the exact same team, but you could be making something very different. If you're, say, based in San Francisco versus Toronto versus State London. So levels offers you that sort of a transparency as well. And lastly, it also shows you how salaries differ across different engineering levels. So overall, I'd say a highly, highly recommended resource. Okay, so moving to the actual negotiations, so please never accept an offer as soon as it's presented. This is called Negotiation 101. Your recruiter will let me call you to discuss the compensation package at this time, just jot down the details, thanks them, and ask them for how long you have to accept the offer. And this is usually because a lot of offers in tech are called exploding offers. And that's because you usually don't have a lot of time to accept the offer. Usually like a week or maybe ten days. So I think it's always better to have a tentative timeline in mind. Then I got a lot of advice in terms of how I should go about negotiating. So whether it should be like a phone call or an email, ultimately I think obviously it depends on what you're more comfortable with. I personally thought that I wouldn't do so well over a phone call, so I decided to email my recruiter instead. In your follow up conversation, always thank them for sending the offer to you. And at this point, you should have concrete numbers ready and mention any competing offers or deadlines. However, please never lie to a recruiter about competing offers or compensation because one, they're very well connected, and then secondly, they can also ask you to submit proof of competing offers of compensation. So don't do anything to jeopardize the offer at this stage. And lastly, recruiters really like it if you can wait that you'll be ready to sign the contract immediately if they can get to your proposed numbers. And just to kind of demonstrate this, I've included the email that I sent out when I was trying to negotiate. So you're absolutely free to use this email template if you want. Going back to what I was saying earlier about how awkward this conversation sometimes can be, these five lines that you see here, it took me 30 minutes to come up with these five lines, and I was still so unsure of myself that I forwarded this to five of my friends to Crew Freed, and only once they had given me the green light did I eventually forward this to my recruiter. So for sure, this conversation can feel very awkward for a lot of people. But yeah, that brings me to the end of this workshop. I think we made it in my time. If you have any questions, I'll be more than happy to answer them right now. Otherwise you can reach out to me on LinkedIn or you can email me. But yeah, thank you so much for coming to listen to me today. Really fantastic. Thank you so much. Actually, there were a lot of great questions in the chat, so if you all hang on for just a little bit, we'll answer some of those. So one of the first ones that was mentioned was, do you have any tips for what to say if a recruiter asks why you left a previous employer? But I do know that people usually advise not to kind of bad mouth your previous company. Other than that, I think I actually saw this question in a chat somewhere. I can look it up. But yeah, I think for now, I'll just say that don't say anything that will don't say anything that makes you sound like you're kind of bad mouthing your previous employer. But otherwise, I think you could say something like, I've been asked why are you looking for another opportunity? And to that I like to say that it's because I'm interested in this new domain that I want to explore, or I'm looking to be in a role with kind of more responsibility, things like that. That's how I typically answered this sort of question and usually goes, okay, but yeah, I don't know if that was adequate. Absolutely, I think that's a great answer. I think I've been in a similar position where I'm looking to continue growing, to continue building. If anyone has mentioned anything like that, would you recommend tailoring your resume specifically to the job role description or kind of keep a separate generic resume? And some people ask in particular to this, especially in some of those entry. Level positions, I will say that I think that's always a good idea. So you don't have people have this concept of having a master resume and then you can have tailored versions. So actually, I do like that idea. Usually what I do for myself is that I just have this word doc where I keep dumping things that I'm doing, and then when it comes to updating my resume, I just refer to that word doc and I'll add the details that I think are relevant to a given opportunity. But I think, yeah, I think having this master resume or like a document where you're adding everything that you're doing because honestly, over time you do a lot, and then when it comes to updating your resume, you might not be able to kind of think back to all the things that you've done. So I think having this dock where you're just adding every single thing that you're doing is always very helpful. And then I think that makes tailoring your resume a lot easier when the time comes. Yeah, absolutely. I couldn't agree more. What would you suggest for people in terms of practicing for an interview? I know you mentioned possibly watching interviews. Do you think that practicing a mock interview, maybe with someone in your area would be beneficial? For sure, yeah, definitely. Very beneficial one. Obviously, it's very good for the nurse, right? So you can get a close idea of what the actual interview is kind of going to look like for sure. I think mock interviews are a great way of going about it, especially for, I think, behavioral questions. I think for technical ones, yeah, we have a lot of resources. Obviously there's a lead for way of going about it or whatnot, but I think definitely for behavioral questions, I've personally met a lot of people. I think something that I've noticed in terms of candidates, as far as behavioral questions are concerned, is that people really tend to overestimate how well they're doing as far as behavioral questions are concerned, that you might think that, oh, my answer was fantastic, but it might not, and there might be some really big red flags in there. So I think more so for behavioral questions. I think it's always better if you can just run your responses by a couple of people. And I would actually say the same for the technical parts as well. Because like I said when I talked about the optimal strategy that you should have, leave code is not going to test your strategy. Right. Like lead code doesn't know whether you're a good communicator. So for all those little things to bridge all those little gaps in between, I think it's always beneficial to do a couple of mock interviews. In some interviews, are they going to be looking for you to solve algorithms and tech interviews for web developers, or is that going to be something that's specific to software engineer positions? That's a bit hard to say. Honestly, it depends on the company, on who your interviewer is. Yeah, especially honestly with smaller or medium sized companies, especially if they don't have like a set interview process in place, honestly, you don't really know what they're going to kind of throw at you. Which is why, again, I said that before going into your interviews. If there is an HR person or like you have a proper recruiter, always, always ask them just so you have an idea of what to expect. I've personally never been in a situation where recruiter has been like, oh, I'm not going to tell you what's going to happen. We're going to keep it a secret. So they're always very obviously they want you to succeed, right? This is something that people should keep in mind, is that they want you to succeed. What's funny is that obviously as a student, you never get an insight into what recruiting looks like. But then once I got into recruiting myself, I realized how time consuming it is for companies. And I think that's something that we really tend not to think about. Recruiting is very expensive. It's very exhausting and just very time consuming for companies. They want to find the perfect candidate, and they want to do it fast. So HR, whatever recruiter you have, they're there to help you succeed. So always ask them before going into an interview what to expect. But yeah, as far as the question is concerned, there can be a lot of variation, so just make sure to clarify that before you head in. Yeah, absolutely. From the perspective of someone that has done some hiring, would you say it's still good practice to negotiate a salary when you are in a junior developer role or looking at an entry level position? Absolutely. Yeah. No, you should even negotiate for your internships. I personally helped my younger brother negotiate two of his internships very successfully. So I went to the University of Waterloo, and Waterloo has, like, they have co op as part of our degree. So basically, we do X number of internships as part of our degree, and this was drilled into us. Even at, like, the internship level, there's no discrimination. There's no rule anywhere that says that you can only negotiate for your full time offers. In fact, I think that the earlier you get started, the better it is. Negotiation is a skill at the end of the day. It's not something that you're magically going to know how to do just because you're considering a full time offer. So I think the earlier you get started, the better it is. So don't ever let that stop you. Also, please keep in mind that the absolute worst thing that can happen if you try to negotiate is that the company will say no, that's it. They won't retract your offer just because you're trying to negotiate a higher salary. So don't ever let that fear stop you from trying to negotiate. How did you pick the companies you wanted to interview with? Did you pick larger or smaller companies? Were you interested in specific types of technology? What made you decide where you interviewed? So, for me, it was a couple of factors. One, I was looking for a very solid engineering culture, and I had heard great things about Yelp's engineering culture. Even honestly, when I was as an undergrad, yelp used to hire very heavily from Guadalupe, so I was kind of there that they have a very good kind of reputation. So once the engineering culture was a big consideration for me. Secondly, yes, I was looking to go to a slightly bigger company. I felt that right now, I felt that where I was in terms of as a software engineer, I felt that I wasn't just yet ready for the giants, but I was like because earlier I was working as kind of like a small to midsized companies. I was like, Okay, I'm looking for something like a sweet spot in the middle. So that was another consideration. And then lastly, I just wanted to be at a place which has a really conducive work culture. So, again, I had heard great things about Yelp's culture overall. I had a lot of friends who worked there personally, and they all had great things to say. So, for myself, where I felt I was as a software engineer, in terms of the growth that I was envisioning for myself the pace that I wanted to go at. I thought that Yelp was checking off all the boxes, so yeah, that's how I decided. Well, I know there were tons of questions in this chat. Thank you so much, Fatima, for all the information that you shared. And thank you, everyone, for attending this session and enjoy the rest of the conference. Thank you for having me.