Video details

Preparing for the Technical Interview

Career
03.21.2022
English

___ 💻 WWCode Digital Events: https://www.womenwhocode.com/events 🔎 Job Board: https://www.womenwhocode.com/jobs​​​​ 💌 Make a Donation: https://www.womenwhocode.com/donate

Transcript

Alright, let's get started. Yeah. Women Who Code Again, preparing for the Technical interview is the official title of our event today. Our lovely presenters, Miriam and Nicole, they are both engineering managers from article. They're very busy people. So we highly appreciate their participation in this event. And talking to us today, it's very, very nice of you guys. Thank you so much. So this is our agenda for tonight. We'll do the welcoming bit which is what I'm doing here right now. Then we're going to go over the presentation and then after that we'll open up for questions and then just say goodbye. This today is a quick event. We only have two presenters and we're hoping to have enough time to talk to all of you. So the event is just going to be a 1 hour. I know everybody is busy, it's just a Wednesday, so. Yeah, thank you. So I just wanted to go over Women Who calls mission, which is inspire women to excel in their technology careers. Myself as a person that's been following Women Who Code for a while can tell that this really is the thing that women helped me to do. So, yeah, that's our main mission. Our vision is a world where diversity, where diverse women are better represented as engineers and leaders in technology. With that said, if you are a woman, if you're in technology and you want to be a role model, you want to be part of this community. You're welcome. We're looking for volunteers at all times. So yeah, just send a word. Our cut up conduct is a bit long, so there is a link for you to see. But the main code of conduct is that we are an inclusive community and we support people regardless of their gender, their gender identity, gender expression, sexual orientation, ability, physical appearance, body size, race, age, religion, socioeconomic status, Catholic or preferred programming languages. We don't judge people who like Java for example. And our events are intended to expire to excel in technology careers and anyone with that purpose. So women, men, all gender expression and all people from all sides of the world, there is a member. Sorry, the code of conduct. We do not tolerate harassment of any kind to any members or to anybody who's participating in the event today. So please be very careful with what you say at the questions moment when you have the opportunity to speak and in the chat, we will be monitoring that. And if we notice something, you will be removed from the event. We take our credit very seriously. So again, thank you. Yeah. I hope you have a great event. I will now give control to Miriam so she can share and start her presentation. Perfect. Thank you, Camilla. Alright, can everybody see the slides? Okay, perfect. Well, thank you everyone for joining today. This is Secrets of the Technical interview from a couple of hiring managers. I'm Mariam. I just want to acknowledge, first off, that I'm coming in from the Southern tip of Vancouver Island and we acknowledge and thank the Laquangan people, also known as The Song. He squawalt First Nations communities for allowing us to live, work and play on their lands. A little bit. About Me I've been working in software for about 13 years. I started as a software engineer. I've spent the last few years in leadership and I've really been enjoying it. I focus quite a lot on building really happy and healthy teams and I take a lot of pride in leading with the core value of equity and inclusivity. So that really means that we prioritize inclusivity and everything from recruitment, how we work and communicate together, and how we grow our people. I joined Article as an engineering manager about a year ago because I was really excited to learn more about supply chain. I run a team called Fulfillment Logic which focuses on broadly like the most important things across the supply chain for article. And it's really fun for us because we get to work on the things that you hear about in the news, like Port congestion, manufacturing restrictions, container shortages, all of this interesting topical stuff and the common thread is software, so it's pretty fun. And if any of you are interested in supply chain, definitely ask me about that. Or if you're interested in inclusivity in the software engineering industry, ask me about that too and I'll hand it back to Nickel for an intro. Thank you very much. So my name is Nicole McKenna and as you know, I'm an engineer manager. Article I'm not a native Canadian. I immigrated here last year. Article is my first job in Canada. Prior to that, I worked for 18 years with JP Morgan in Glasgow. From working way up from being a software engineer to a software engineering manager. Article I run the architecture team so we get to play with all the nitty gritty technology and deep into digging into some of the deep and interesting things that help support the rest of the Article platform when it comes to running teams. Very much like Mariam, I really enjoy running happy teams that enjoy their work and do my best to make sure that everyone feels that they're contributing in a way that just makes them feel valued and lets them express their true needs. And once into the article system. Perfect. So some of the topics that we're going to go into today are starting from what you need to do before the interview. So what to expect, how to prepare, how to write your story, what not to do, and then at the interview, how to address nerves, navigating problems, how to ask questions, and then finally after the interview, how long to wait, and how to solicit feedback. So we'll start with before the interview an overview of what to expect is you might not see all of these steps, but this is largely what you'll see in a typical technical interview. So first off, you might have a technical screen. This comes typically after a recruiter call. This is really just to determine if you've ever coded before in your life. If you've even done like first year at University for computer science or software engineering, you'll pass this. It's really just seeing as an organization, if it's operationally, worth their time to pursue you as a candidate. So most people will do excellent at this and it'll be something like either a coding assignment that you can take home or a live coding session if it's a particularly hot market, or if you've been reached outbound by a recruiter. We might omit this step. So you might never do this, but it's good to prepare for anyway. Something that you can pretty much always expect in a software engineering interview is a coding assessment. So this again can be a take home or it can be a live coding session. So this will be an algorithm problem with the intention of assessing your programming depth and proficiency in algorithms, data structures, how you communicate complex logic and how you solve problems, and how you approach software design. And then finally there can be a system design. You'll typically see this in either like an intermediate level or above interview. So if you're just starting out, you don't necessarily have to prepare for this. But there have been junior interviews where we do these as well. So this will be a high level real world based architecture problem. So something like Design Facebook Newsfeed or how would you build Uber? So at this stage we're trying to determine your technical breadth and system architecture knowledge. We'll chat a little bit more in depth about how to solve these problems as well in a little bit. So how to prepare. So I've broken this down into three steps of researching, revising and reaching out. Firstly, at the research stage, the best thing you can do is read the corporate website and study their mission and values. It's really great to see where you align and actually bring these things up in your interview. So you can either write that down to prepare. Also study that job description and make sure that you really have a good grasp of what the strengths and opportunities are, either for growth or for you to bring up in the interview as a strength of yours. So websites like Glassdoor and Blind are really great resources as well because people actually will post interview questions as well as like the general process. I don't recommend studying the answers from glass door blind because typically most employers will actually keep an eye on their own glass door. So if you just give a carbon copy of the answer that's on glass door then it might be a red flag. And also you don't really have 100% certainty that the answer on glass door is great. So really feel like you're familiar with the questions yourself that you can confidently speak to them. And then the next step is revising. So now that you've done all that research, you can leverage the insights you got from your research to practice the types of questions that you know are typically asked in the interview, and actually also review the concepts in the job description that you might be unfamiliar with. So if you have typically relational database experience, but you see that they use quite a lot of no sequel databases, you might just want to brush up on those concepts. And you don't need to pretend that you've had that experience before. But just mentioning that you've researched it can go quite a long way to impressing your interviewers. And also make sure to revise the technical details of your story. We'll chat about that a little bit more in a bit. So tools at this stage, Lead Code and Hacker Rank are excellent. If you're looking for a specific company that's well known, they'll typically have the main questions that you can solve for that.org. Also, cracking the coding interview to this day is still the gold standard for technical interviews. You can pretty much pass a lot of technical interviews with this one resource alone, so I highly recommend purchasing it. And then finally, I love this stat on networking. Networking alone is responsible for filling as many as 85% of all jobs, so I really let that sink in for a second. I think we really don't lean in on networking enough, although this group is probably biased because you're here. But I really recommend adding recruiters on LinkedIn. They'll come to you with jobs so that you don't have to go looking for them. And also you might skip some steps if you go through the recruiter. Also, it just looks better. Oftentimes a lot of work won't even look through the applications that they get and also go to meetups and conferences and ask really thoughtful questions to the people you meet. Don't Google questions. Think about the topics that the person that you're talking to brought up, and think about what came up as they were talking that you might have been interested in because they'll really remember you and think of you. All right. And then also you'll want to cycle through these steps over and over throughout your interview process. You might interview for a couple of weeks or a couple of months, and you don't want any of these pieces to get stale. So I chatted a little bit before about writing your story, and I want to talk a little bit more about what that means in depth. When I say write your story, I mean literally write your story. So you'll want to actually put pen to paper on this. Because the number one thing that I see in interviews is that people forget their own experience or they don't see the importance in pieces of their experience that they've actually had a lot of people say, oh, I don't have a lot of breath of experience, or I don't have really important things to bring up. But as you deep dive into questions like this, you might find that you have relevant examples to bring up. So these are some prompting questions to think about as you're writing your story. And we'll share these after, so you don't need to memorize them right now. But some of these will be things like when did you do something that was challenging technically? When did you overcome an unforeseen obstacle? There's a difference between these two. Like something challenging might be a challenging project, an unforeseen obstacle might be like a big incident that happened or new requirements that came up that you weren't expecting. What's a system you know really well, I really recommend whether it's like a small project you worked on or an application that you either maintained entirely or that many teams helped maintain. Draw out that system and study it really well. Like every single component of it, how data flowed between different services, what the different models that were involved were, what the different APIs were. You might find that you're asked to either draw out a system you're familiar with, or it might translate to a system design that you do in the future, or it might even translate to a coding problem that you solve. Also, when did you have to work with someone from another team? When did you make use for design pattern? There's quite a lot, but one thing that I really recommend here is thinking what the common spread amongst these experiences is. So like, set another way. If you are a superhero, what's your superpower? And then as you're answering questions in the interview, revisit that one superpower as your centered value that you're bringing. Because once you center on that one source of truth, you can really own it and make sure that your answers have a clear purpose that they're delivering on. Also remember that the experiences that you bring to your story don't need to be career experiences. I recognize that a lot of people on this call might be earlier in their career. So think about your academics or personal projects you work on. If you find as you're thinking about your story, you're deficient in any of these. It's a great time to consider contributing to open source projects. There's lots of threads and forums that suggest projects for this. So if you're curious or you want to find out more about this, you can reach out to me after. So now that you've got that story, I highly recommend you review and revise that story regularly. I often think of the French phrase les free descalier, which is like staircase, which. So really, when you walk away from a situation and you think of the perfect response or the perfect answer to a question, don't save them for the staircase. Really make sure that you nail it in that interview. So a great way to do that is to actually reread your story over and over again and make sure that you reflexively know specific examples in your career that you can point to when you're asked a question about a specific concept. I often see that people just completely lose all confidence in their skills or their previous experience when they enter the interview. It's an unexpected phenomenon, so make sure that you're actually building those neural pathways ahead of time so you save yourself later. Also, I highly recommend practicing without the tooling we all think because we write code every day. I write less code these days, but when you're writing code every day, you think you'll be prepped for a coding interview. But I've been a part of countless interviews where candidates forget basics, syntax, or functions, and the language they use every day, and that's because it's not an everyday situation. So practice writing code in either a Google Doc or a sheet of paper. Lots of our orgs like Google actually to this day still do coding interviews without an idea. They'll just have you open a Google Doc, so don't let your mind go blank. Make sure that you're prepared for this. It's kind of like it feels a little out of the ordinary to do it, but it's well worth it. So what not to do? One of the things that I see quite a lot of people do at the beginning of the interview is just read out their resume as an intro. It's really not a great way to introduce yourself because it's confusing and it's long winded and it uses up a lot of the interview time. You can expect that your interviewers have read your resume before and they know all of those things. So this is a really great chance to give a high level overview of your passions and skills, but also point to the things that make you human that might be compelling and interesting for your interviewers. So you can give that high level overview and just say, I'm happy to talk more about any of these points more in depth, and if they're interested, they'll ask you. And the best way to make sure that you incorporate those things that you think they're really impressive is try to work them into your answers. If they're relevant, they'll actually come up in questions as well. So another thing not to do or try to avoid doing is speaking in high level abstractions in your answers. It's best to point to specific examples in your previous work if you can, just because this isn't like a theory test. And oftentimes interviewers will actually Mark you down if they feel like you're just giving surface level answers. So try again. This goes back to building the muscle memory of linking concepts that you're asked about to an exact specific example in your story where you experienced something like that and you'll know you've done this well if when you're asked about something, you reflexively remember a time in your history where you experienced that. Another thing to note here is if you're more junior, you might find that you don't have specific examples in your experience to point to. So I recommend pointing to acknowledging that you don't have experience that specific thing. They'll usually reward you for being humble and honest and pointing to a related thing that you kind of think might be relevant, or pointing to a case you might have heard about, like on a tech blog or in the news. So maybe they ask you about the most challenging engineering problem you've worked on and you genuinely haven't worked on anything super challenging. You might be able to point to something that you did and something that you know was challenging that was more at scale. So maybe you had to upgrade a version and that was really challenging for you because you never did that before. And you might be able to point to something like the Instagram Django version upgrade, which took many months and involved a lot of tests in preparation. It also shows that you have knowledge of the tech industry and you're curious. So we're going to chat a little bit about tactically at the interview, and I'm going to pass it to Nicole. Thank you very much. And really first thing to address here is that nerves are a fact of life. We all feel them, we all go through them. And one of the biggest reasons we all get nervous before anything at all is the fear of the unknown. And that's especially true for an interview. You can control these nerves, you can bring them under control slightly or more so by properly preparing for the interview. And this really can make all the difference to your confidence levels. It's one point as well that not all of us have just that level to deal with. Some of us have anxiety disorders and other challenges. And in those situations, you may want to make your interview aware of them beforehand or on the event itself so they can take that into account before the interview. There's a few things you can do, and many of Marian already pointed out researching a company and reading the job description, making you sure that you know exactly what you're getting into and what you'll be talking about. Planning the story about yourself, planning the story of what you've done, where you're going, what you want to do ahead of time. All this makes all the difference. Think through the questions that you might be asked, either based on your work history, your resume, anything you want to talk about. Prepare for understand what you make question and prepare some questions for your interview. This really helps to show how interested you are in the job and helps make you stand out from the rest of the crowd. One thing I've always done and quite everyone might hear, especially I was very, very shy and very much, I think, very hard to talk to an audience, very hard to pick up my phone and answer the phone. And one thing that really helped me when I came to an interview was I rehearsed in my head time and time again the first few sentences I wanted to say my introduction. And that meant that I had a nice, easy entry into the conversation ahead of me. One really neat thing you can do I've done this myself many times is make an interview. And that's just not upon the questions I want to ask or extra notes or things I might want to remember doing interviews I don't want to forget about. As an engineering manager, I would much rather see somebody walking into an interview with plenty of notes, plenty of references, everything like that. Because then it makes me realize I feel that they are actually prepared and researched for this on the day of the interview. There's a few things you can do as well. Use any breathing exercises you've practiced in the past or find some and research. This can really help center your focus and can the nails before the event. And just remember, this is not like a one way street if you have a conversation, it's just like talking to anyone else when there and just try to engage with the person across from you. There are lots of other little tricks you can do. Your body language everyone can control to certain extent of body language. And there's a thing down there for the power policies, practice of these and use them on the day. It can really make a difference, not just to what the interview proceeds when you're talking to them, but really to your own confidence levels. And that really is what it's all about. Can we go into the next slide? Maya? So I want to chat a little bit about actually navigating the problems at the interview. So I've also broken this out into three steps. So the most important one, I think is at the start of the interview, when you presented a question before you actually jump into solutioning, make sure that you're asking questions to actually scope that problem. Not only does it show your competency for solving complex problems, but it also shows that you understand business needs as well. And also, as you're going through the solution, make sure that you're communicating your thinking. Your interviewers aren't mind readers and you could be designing the best solution in the world, but your interviewers will have no idea unless you actually think out loud. So as you're doing this, if you're silent during the interview, pretty much there's something you could be saying at every point in the interview. So if you're writing a line of code, explain why you're writing it or what the logic is, why you've chosen your data structures, any risks or edge cases that come to mind. Remember that this is the only way that you'll get credit for what you know. Your interviewers can't assume based off of your vibe or how confident you are. That would just be expressing bias. And then finally make sure to ask questions. So not just at the end, but when you're stuck. Don't go silent, ask questions. It'll show your curiosity. It also shows the extent of your knowledge, so your interviewers aren't expecting that you know everything. That's not realistic. So if you can be humble and show when you don't know something, it gives them a lot of signal of what you do and don't know. You can mention what's blocking you and ask questions to help you get to the solution, which might actually allow you to perform better. I see lots of people get stuck and ask a simple question and then they just ace the rest of the interview. Also, if you finish early, your interviewers might ask you to extend the problem, or you can ask the interviewers how they'd solve the problem, and you might actually learn something that might help you perform better in your next interview. Another way that I like to think about this is just remembering the software development lifecycle, which all of you should be familiar with. So remember that your goal in the interview is to show that you understand each one of these steps and you should be able to represent that as you navigate the problem. So at the start requirements analysis, that's just going to be framing the problem, making sure that you understand what's going into it, what the constraints are. Design is how you are breaking that big problem up into logical sub problems that you can show competency in. Development is super easy. It's the actual coding part. Testing. You can go about a few different ways. You can either mention edge cases or things that might be tricky that you'd add extra testing for. You can add testing right at the end if there's time, or if you're familiar with test driven development, you can write your test right at the start. And that's really great because it's something that's really popular with interviewers. And also you can see how you're progressing because your tests will pass as soon as you hit the solution. Hopefully. Although I don't recommend going with TDD if it's something you don't have experience with, because your interviewers might ask you deeper questions about it and you don't want to seem like you're in a bad spot if you don't know an answer there. And then finally maintenance. This could be either mentioning how you scale the solution, or as your interviewers ask, to extend to another input or parameter, you can show how you'd extend the solution as well. I wanted to focus a little bit more deeply on framing problems because this is probably in the actual coding interview. One of the things that most people lose points on. A good thing to remember is that in real world scenarios, when you're given a feature request or you hear about a new project, you don't just go heads down and start building the solution. So you do need to ask questions. And a good thing to remember as your source of truth is that a big part of elegant software design is making sure that you're building the right thing for that context. So it's not impressive to crack a nut with a sledgehammer, and it can actually hurt your overall performance because it can make it seem like all you did was study online resources and you don't have like more tactical on the job skills. So a great way to ask framing questions is thinking about what the range of values might be, what the throughput might be. These are just some questions I got online, but there's lots that will apply more to the question that you had asked. So as you get problems or as you practice, think a little bit more about if this were a real world problem, what would be the constraints that you'd be asking your project manager or product manager like business analyst? Another thing to look out for in the interview is bike shedding. We all have an affinity to trying to kill time when we're in really nervous scenarios. So you have to kind of push through. This bike shedding is probably a term that a lot of you are familiar with, but if you're not, the main crux of it is like imagine you're building a big, expensive nuclear plant and you have like an hour to talk about it and you spend almost the entire time talking about what color the bike shed is going to be, rather than the risks of the nuclear plant and all of the engineering that's associated with that. So the bad part of that is it'll make you look immature and inexperienced because you're focusing on a trivial thing. It's kind of in this Quadrant of easy and trivial, and it wastes a lot of time in the interview that you're not getting points for. So the whole time that you're burning, spending, talking about the supposed bike shed there, you're losing out on things that could actually impress the interviewers. So make sure not to fall into that trap and consider what might be in this right Quadrant that you might know a little bit about. Stuff that's really consequential and important to the problem and also challenging, but not so challenging that you're out of your depth. So things that you are familiar with that you can confidently speak to. Nicholas. So we're going to talk about questions again, and we keep coming back to this because it really is quite an important thing and also from a personal point of view, it's both a candidate and a hiring manager. It's one of my favorite parts of every interview that I've all done from the point of view of a candidate. Asking questions is key, right? It lets you show your interest. It lets you see as well. Is this wrong? Actually, for me, you're effectively interviewing the company at this stage, you're interviewing your hiring manager. Do you want to plan ahead and have some questions ready for them? From the perspective of a hiring manager, I really enjoy seeing what people ask. I like the questions come through and it really shows me the level of interest and engagement someone has in front of me some really good questions to ask myself down here one or two of my favorites. When I was interviewing to join article last year, one of the questions I asked my boss at the time was, why do you work here? What do you get of working for article? What do you really enjoy? This was really so I could find out. Are their values the same as mine? Do they enjoy the same things that I do and will actually enjoy my time working for the company? Other nice ones to ask you is what is there about this role this company excites you? Or can you tell about the team I'll be working with? What's it like working here? What are the expectations? Or if I'm hired, what does success look like in the first 30 days, 60 days, 90 days, so you can get a feeling of what you're getting into. The real thing is ask questions, be interested and show that interest. Next slide, please. I think we're going to talk on now. What happens after the interview? You've been through the process, you prepared, you're prepared, prepared. Again, you had the interview, and now this is for me, the hardest part, the wait. I kind of remember the very first job I ever applied for, straight up University. I sent the application away. I had to be. And then the same day I got thank you for applying in one letter and in the same post, another one saying you've not made it. And that's a hard, long way. But you don't have to wait that long these days. Okay. If you don't hear back from your interview, Doroth don't worry about it. It's normal for some time. These things take five to seven days before you hear back. And really, you don't have to wait that long before you make contact and talk about that in the next slide. But each hiring company's process is different, right? There's a whole lot of factors that can affect what you go through and how long you have to wait. For instance, you might have been the first candidate to talk to. They might have a whole host of candidates to talk to, and they want to go through that entire process. Your hiring manager may have fallen sick, might be away for some other reason. You have to wait for them to return. There's a whole lot of things that went so if you are waiting, don't get responded. Don't worry about it. And also, please don't stop applying for other companies. Don't just apply once and then wait. Get as many applications out there as you can and keep moving forward. Next slide, please. Like I said, you don't actually have to wait a few weeks period before reaching out or hoping to make you something back. You should actually, as a matter of practice, email your recruiter back within a couple of days of your interview. Basically just like a quick thank you email. This again, lets you stay in contact with the interview, make sure stand out from the crowd, but also gives you an opportunity to raise anything you might have forgot about during your interview, any critical piece of information you might want to share, and also let you share your appreciation for their time. Thank you for the interview. Thank them for anything you went to and tried to mention a few things you appreciated about the process of the interviewer. All just helps build that bond, that network between you and the company. So even if you don't get the wrong that you're after, they might come back to you later on. And I've certainly seen that happen. Now you've waited. Save this five to seven days and you maybe have heard something, or maybe you haven't. In either case, this is where you want to start asking for feedback. The feedback is crucial to me because it lets you know what they thought. It lets you know where you might do better or you might have excelled. And both of feedback and the thank you emails. It's also using email for us and not messaging. Email gives people more time to think about things, more time to consider, and you tend to get a more full response when you do get one much to your bank, you almost thank you interviewer. And if you've had a rejection, but just express your disappointment and say thanks for your time. And then I'm just telling you what I'm writing. I just like to get some specific feedback. It's important to be specific in there because you want to find out those details that make the difference and you're just asking about your interview performance and what they thought, how you went through the interview and anything they can give you back that might be useful. And again, always express you want to keep looking for new opportunities, new jobs you want to carry on, always be optimistic, always be on the front foot. And finally, thank them for the time. And that will leave them with a very pleasant interview process for both you and them. I will help things go forward and I think if we go to the last slide now, are there any questions? And I should know at the end of this slide we've got one more which shows some technical resources you can reach out to for place you can find help and holding questions or help on the system design questions. But before that, questions. Thank you, Nicole and Mariam. So we'll open for questions now. So if people want to unmute yourself and ask your question, you can do that or you can just send a question on the chat. I see Lindsey has her in hand up and there is a question on the chat. So I'm just going to ask the question of the chat, and then I'll give you the word cagency just a second. So in the chat from somehow says, what do you look for in an interview of a junior versus an interview of a senior Dev? So versus an intermediate versus a senior desk. So I guess all three of them, either Nicole or Maryam. If you want to answer that one. I can take a stab at this. I've kind of created a rubric for my engineers as they assess technical interviews. So I'd say in broad strokes, for the junior engineer level, we're mostly looking for how you're improving yourself and your skills and leveling yourself up and what you're looking for to improve in yourself. For the intermediate developer, we more so look for how you've had an impact at the project level. So like a project you've worked on, a project you've either been tech lead for or supported a tech lead on, and then on the senior engineer role, we look more for how you've mentored others, how you've had influence on your team, and we really look more deeply on your system architecture knowledge. And of course, at that stage, you should be ready to confidently speak as well about being a technical lead on a project. But Nickel probably has some bit points as well. Yeah. So for me, it's very similar as well, but just there is a couple of different points. I'm looking at a new developer coming in. I'm just looking for a willingness to learn. Have you got that spark that you want to learn, you want to take part attention, and you're curious. For an intermediate developer, I want to see you've got some experience, you've had some technical exposure, you've got the ability to do what we need. And you're starting to get a sense of your own impact, not just of what you're doing, but why. And that why is very important. And as you move on to being a senior, then I also care very much about your sense of ownership. How much do you care about what you're doing? And you really understand now the impact of what you're doing, if you've got that to me, is crucial as you go up that scale. Awesome. Thank you. So I will now give work to Lindsey. Lindsey, do you want to ask your question? Go ahead. I was wondering if you had any advice about specifically interviewing online via video chat. I had an interview last week where I felt very uncomfortable about whether I should look directly into the camera or look at their image. Any advice about that? I can talk to myself when I do the interviews online. I talk to people and honestly, I don't really mind too much. I'm usually spending more time looking my keyboard, making notes and what you're talking about than actually making eye contact with someone as you go along. And really, I'm just saying for them to be like that, for me, it's more important. You are comfortable having a conversation. If you're comfortable in whatever way you're presenting yourself or having a chat, that's good. If there's something specific you don't feel comfortable with, just say so until I like to keep the video off or manage it in some other way. But from a practical point of view, being hiring manager, I'm usually too busy taking notes and thinking about what question I want to ask next and listening to what you're saying to really care. It's more who you are than what you are at that stage. Thank you. Thank you. Thank you for your question, Lindsey. I'm just going to read one more from the chat and then I'll give your questions. So from Alex in the chat, roughly how many interviews can you expect as a brand new out of boot camp developer and any tips getting that first job? This is a really hard one. I've never done a boot camp, and I don't think that Nickel has either. I think that mostly one. It depends on which boot camp you do. If you do something like Lighthouse Labs, I think there's quite a lot of clout associated with certain boot camps, so they've already built the reputation for you. So I've seen folks. I think they're guaranteed to get a job within like 60 or 90 days or something like that. I would bet, though, as a complete newbie, you might have to do up to 30 interviews or something like that, just because getting the first experience is the hardest. And then after that they'll get tossed at you. And then on tips on getting the first job, I would say really, the story that I mentioned is probably the most important thing, as long as you can think of specific examples that you can point to either that you worked on in your boot camp. A lot of boot camps these days are completely full stack. So any question that you get asked, you should be able to think of a project that you worked on and being really honest. So as Nicole and I are people that have probably done like hundreds of interviews at this point. And same with technical interviewers as well. We can really tell when somebody is bluffing and making something up on the spot. So be really honest in your interview and that'll get you a lot of points. What do you think, Michael? The only thing I would add to that is that when you're coming this freshness for your first interviews, especially going through a boot camp, you pulled out a lot of coding by now, so try building up your portfolio. Whether you're working open source products or if you're doing front end, you don't have a nice little portfolio. Front end apps out there, things that you can Show Off You may not always get a chance to show them off during the interview, but you can reference them during the interview and use them up as backing for everything you're doing. And to help get those interviews, join the meetups. Join your community network as much as you can, and then just keep applying. Keep applying. Keep going until you get the one you want. Awesome. Thank you. So sorry if I say your name wrong, but please go ahead and ask your question. You said it correctly, don't worry. So yeah, my question is more or less about asking for salary. In which step of the interview did you recommend to ask that? Because sometimes I figure out that some interviewers will want to save the range of the salary, but then you go to the process and go to the end and maybe that was the amount that you were looking for. So in which step do you recommend to ask for that? I feel like you should definitely ask the recruiter, because if they don't know, that's kind of a red flag too. And if it seems like they're intentionally hiding it from you, that's not a great sign. So, like my experience, the orgs that do that you'll want to leave them pretty soon after. So ask initially, and if they give you too many, sometimes they might say that you need to speak to the hiring manager or like something I find often is like the recruiter you're speaking to is like brand new. So if they genuinely don't know, you can send them that request in the email too. And if it doesn't come up before you get to the end of the interview, it's probably good to at least tell them what you're expecting and make sure that they understand that you're only interested in pursuing the interview process if they can meet that range. What do you think, Nicole? I think you're very right, and I think you're starting to notice as well more and more jobs when the postings go up, they actually include a salary range in there at the start, and that helps to guide you. And I think honestly, as soon as you start talking to a trooper or a hiring manager at any stage, there's no harm in talking about salary and raising up what your expectation is when it gets the final stage offer, you actually have to make a decision and you're discussing it. Then you can maybe get into that sort of stage where you say, look, you're offering me X, but actually I need X plus ten or X plus five, and you can start doing that back and forth discussion. But I'd certainly set your expectations up in the earlier stages, one because you want to find out what they're willing to do and to each one to waste your time. If I'm not going to match your expectations, move on and find the next one. I think somebody else asked about this, too. Yeah, we have another one here. It's mostly focused on negotiation as a newbie how we negotiate, if you want to continue talking about that. But with the negotiation in mind. Yeah. I think what Elena said is exactly what I'd recommend. It's way harder to have the negotiation right at the end. And a trend that's kind of bubbling up quite a lot in tech these days is some companies will say that they absolutely don't negotiate salaries and it is a practice for inclusion because some people are genuinely not suited to it. We find that women and people of color don't typically negotiate on salaries. So if some people are allowed to negotiate, then it undermines their kind of reinforces the pay gap. So it's really excellent to come with exactly what you're hoping for right at the start. So don't be worried if that's about overreaching. They'll offer you what they can. Also, it's way harder to negotiate after they've given you an offer because it seems like now that you know that they want you, that you're kind of twisting their arm into getting more and depending on the hiring manager, it can leave a bad taste in their mouth. But I mean, a mature hiring manager will understand. But I wouldn't recommend leaving until the last minute. Great. Thank you, Marianne. So we have another one here. It's more focused on LinkedIn. So, William, sorry if I say your name wrong. How can you deal with pressure on LinkedIn from recruiters? Do you have any thoughts on that? I guess I'm not quite sure what mostly I get from when it comes to recruiters, when they contact myself or we don't contact in case of what we've got this opportunity, or would you like to join? And generally they are offering opportunities. I've never really experienced any pressure for them, so I'm not sure what classification is. I'm not sure. Mariam, do you know. I'm wondering if the person that asked that question can maybe specify specifically? Do you mean like you're getting a lot of recruiters reaching out to you and you don't know how to they keep persisting. If you keep getting a lot of recruiter messages, I recommend just responding with no, I'm not interested because otherwise some of them don't see you as a person beyond the screen, especially if you're not responding. They might just think that nobody's seeing the messages. But if you are getting pressured throughout the interview process, I would see that as signal that maybe the company doesn't have the best practices in terms of recruitment. It might not mean that the team itself is bad. So if you are interested in the company or the product, I would recommend if you're in touch with the hiring manager to send them an email and just ask some questions about it or give that feedback directly to them instead of the recruiter. And then that's probably something in their process that they can fix. Awesome. Thank you. We are running a bit out of time, so I'm just going to do two more questions here from the chat. So we have a question from Taylor. So she asks, do you think it's important, even from a junior developer to contact a recruiter directly? Sometimes it feels like they're more interested in intermediate and senior developers. I think it's still important just because it's in their best interest to close roles. It's something they're proud of doing and they always get some companies will have better incentives if the recruiter comes with a candidate that they source rather than somebody that came through the application process. Also, if you're applying to their company, like you are in a flood of applicants, there's nothing that you can do to stand out. So even if you've applied, it's probably worth mentioning to a recruiter just sending them a message or a note on LinkedIn saying, hey, I sent an application for this role or the hiring manager themselves, especially if it's a small company or a small team. Yeah. You have nothing to lose by sending them a message. They're sending you all messages all the time. So they get it. That's right. So our last question of tonight, it's from Ask Wong and they're asking here, I guess we have a lot of immigrants in the tech industry. I am an immigrant. So I think this is a very important question, which is, is it hard for junior web developer outside of Canada to get a job in Vancouver? Like one or two years of experience? Any tips for them to increase their chances of getting a job? Then I assume people outside of Vancouver. Actually. As an immigrant kind of myself, I've got to say I don't actually know about the junior development stage of that. I would say that anything is possible. But ma'am, you might have more information than me on that one from the Canadian experience. Yeah. One thing on this that if you have a work permit, it's probably worth mentioning that like your resume somewhere, because sometimes if your address is outside of Canada, they might just turn away from that immediately. I moved to Canada a few years back from the UK, and I saw the immediate difference from when my most recent experience was in the UK or my address on my resume, which I don't recommend having your address on your resume was in the UK. Like, I basically got way less responses. So mentioning that you have a work permit or if you have citizenship is great, especially if you have recent experience abroad. And also if you're a junior web developer, having your GitHub or whatever you use with lots of like resource material to show that you have experience is also a great leg up. That's probably the best thing. And then like networking through meetups like this because we do tend to have an affinity to hire people that remind us of ourselves. So make sure that you're connecting with other immigrants or other women. They'll always want to find an opportunity for you. That's awesome. Thank you so much. Unfortunately, I see we have more questions in the chat but we reached our time. Nicole and Miriam still have to say a couple more things so I will let you do your final slides if you want to continue and finalize the presentation. Now is the time. Thanks for the questions, everybody. I actually don't think we have anything else to share but just one last slide for that one. Just those resources after that final slide. Yeah, I'll share them. So we've kind of compiled some links to some things here that either you might have seen before or you might not have just more tactically on the coding portion as well as system design. Anything else you want to see on this, Nichol? No, that was just to get those resources. Those links out there, they've all been fairly useful. Perfect. All right. Thank you, everyone. This is so great. Thanks, everybody. Thanks so much for joining. Just want to again reinforce connect to Nicholl and Maryam on their LinkedIn talk to them. I think Oracle is hiring right now. Is that correct? So yeah, go after those jobs. Talk to them, let them know you're available and yeah, don't be shy. Thank you so much, everybody, for participating for coming and asking questions. It's been a lovely evening. So thanks until next time. Bye. Thanks. Bye bye. Thank you. Bye.