From Application to Offer. The Insider's Guide To Getting a Job In Tech

1. Introduction : Hi. My name's Andy, and I'm thrilled to welcome you to my first ever course. And this is all about helping you get a job in the tech industry. I'm an experienced software engineer and engineering manager, having worked my way up from a humble intern to senior roles in both large tech giants and small startups. Over the years, I've learned a ton, and I'm here to share those insights with you. I've had the pleasure of working with folks brand new to tech and seasoned engineers alike, helping them craft and follow custom plans to propel their careers forward. I've been on the front lines of the hiring process, interviewing hundreds of candidates and designing the interview processes that you might even have encountered yourself. Plus, I've sifted through thousands of resumes, so I know exactly what makes one stand out. But enough about me, let's talk about you. You're here because you want to land a new job in tech, right? Whether you're a new bee breaking into the industry for the first time or a seasoned pro looking to level up, I'm here to help you understand how tech teams hire and how to unlock your full potential. Together, we'll make sure you shine and stand out in the competitive tech landscape. Now, let's dive into what you'll be learning. First up, writing a resume to get you noticed. I'll show you how to craft a resume that not only highlights your skills and experience, but also catches the eye of recruiters and hiring managers who turn your resume into a golden ticket that opens doors. Next, we're tackle solving technical tests. These tests can be daunting, but fear not. I'll break down the common types of technical tests, teach you strategies to approach them, and provide tips to stay calm and focused. By the end, you'll be crushing those tests with confidence. Moving on, we'll cover handling system design questions. System design can be tricky, but with the right framework and approach, you'll be able to tackle these questions like a pro, I'll walk you through real world examples and show you how to structure your answers for maximum impact. Finally, we'll dive into how to answer behavior questions. These questions are about showing who you are as a person and how you handle challenges. I'll teach you how to tell your story in a compelling way and structure your answers to leave a lasting impression. Along the way, we'll also chat about how to get homework exercises done, asking questions back to the interviewers and a ton of tips to help you shine. Are you ready to take your career to the next level? Let's go. Together, we're going to make sure you stand out in the tech industry and land that dream job. So buckle up because this journey is going to be incredible. 2. The Application Process: Hello, and welcome. Before we dive into your specific application, let's take a moment to explore the job market and share some tips along the way. I'm absolutely thrilled that you've chosen to continue the journey towards landing your dream job in the tech industry. You're about to embark on a crucial step, and trust me, it's going to be a real game changer for you. Today we are going to deep dive into how to effectively apply for jobs in tech companies. First off, let's be real for a moment. You likely won't get many of the jobs you apply for. The odds just aren't in your favor. Each role attracts hundreds of applicants, making it really tough to get through. I know it's hard, but try not to take it personally. Rejection is part of the process. Each know you here is actually a stepping stone getting you one step closer, and every interview is just a learning experience. As you gain more practice, you'll become more comfortable and your true self will start to shine through. So it's time to start looking for a new role. It's easy to get stuck in something called perfection paralysis. This is when you divert all of your energy into doing something perfectly the first time, so much though that you never actually end up doing it. You might find yourself spending loads of time trying to learn a specific skill or perfecting your portfolio, telling yourself that you'll start applying once all that's done. But remember what I said before. The odds are not in your favor. So the key to standing out is practice. The longer you put off applying for a role, the longer it will take you to get a job. Perhaps you're stuck hunting for that perfect role, waiting for the one that takes all of the boxes before you apply. The problem here is that you're putting all of your energy and hopes into a single role. And what if that isn't it? What happens if you overlook the perfect opportunity just because it didn't meet your initial definition of perfect? So here's what you're going to do. Once you finish this course, take everything you've learned and start applying for jobs right away. Promise me. Yeah. Cool. Next, let's talk about the interview. Interviewing can feel incredibly unnatural like you're on display. But the best approach is practice, and you'll get more comfortable. Eventually, you may even come to enjoy them. I know that sounds a bit crazy, but think of it like this. How often do you get a chance to talk to people who work in some of the most interesting companies in the world? Settle into it, ask them questions about their work, their role, and have a great time. Think of each interview as a stepping stone. Each interaction is a chance to refine your approach, understand what employees are looking for, and most importantly, showcase your unique skills and personality. And here's the big one. Don't worry if you're not fully qualified. Especially for graduates and interns, companies are often looking for smart people who can learn and adapt, not those who tick all the boxes. So go ahead and apply. Even if you don't meet every single criteria. Many companies consider the exact things on the job spec more of a guideline than an absolute. If you think you have value to add to the company and know how to present your best self. Thanks to this great video course by some enthusiastic British guy on the Internet, why not apply? Lastly, networking is another vital component of the job search process. Engage with professionals in the industry, attend webinars, and join tech forums. Building a strong network can open doors to opportunities that might not even be advertised. Remember the cliche. It's not what you know, it's who you know. Alright, that's it for now. Remember, the job market is a journey, not a destination. Keep applying, keep learning, keep growing. You've got this. 3. A Resume to Get You Noticed: Welcome back. This lesson will be a crash course on creating a resume that'll make hiring managers sit up and take notice. Are you ready to transform that blank page into interview success? Let's dive in. In this lesson, we're going to unravel the mysteries of the perfect resume. We'll explore what it's really for. Hint, it's your personal marketing brochure. What those recruiters are looking for and how to make sure your resume doesn't end up on the rejection p before it even gets a fair chance. We're going to dissect every element of your resume like expert surgeons from eye catching layout to the juicy details of your work history. By the end, you'll be armed with the know how to create a resume that's tailor made to showcase your unique awesomeness. And we're not gonna talk theory. We're rolling our sleeves up and getting our hands dirty. Together, we're going to build a resume from scratch for our imaginary friend John the engineer. Feel free to play along at home and create your own resume masterpiece as we go. So are you ready? Great. Let's kick things off with a blank canvas. Don't worry if it looks a bit intimidating right now. Trust me, we'll fill it up in no time. Alright, let's start with the basics. Instead of agonizing over perfection, we're going to jot down some core details and polish as we go. First, our candidate's name. In this case, John Doe, we'll pop his name, email address, keep it professional, and phone number. See, we're already making progress. So that's the contact information on the page. Told you it would soon start filling up. Let's push on and pop in their education history. I'm going to just paste this in because I promise you don't want to sit and watch me type it. See how I've cherry picked the most relevant education history for our candidate. What's relevant for you might be different. So give it some thought for yourself, but here's some stuff to think about. Recent and specific is what catches an employee's eye. Got a degree? Slap it on there. But your elementary recorder recital, maybe not so much. We're going for him now, not. Acute. Here's a protop. So space and keep things snappy. You can bundle those older qualifications together. No need to list every single one. Think of this as a highlight real, not an encyclopedia. Next, let's paste in some employment history here, too. Boom. As before, and notice how the most relevant roles are first. I've also opted to leave out any less relevant experience. The three months he spent working in a fast food restaurant over summer isn't going to help him get a rolling tech. It just takes up precious space. Finally, I'm going to paste in a summary of the skills he's best at. I've indicated for each one the approximate level of proficiency he has in that skill. Is he just learning for the first time? Has he used it quite a bit, but never in a professional environment, or is he an expert who knows everything about it and could help others learn it, too? This is useful information for a hiring manager to have, but it's very subjective, so there's no need to go crazy here. Don't provide graphs or percentages, et cetera. What does 60 versus 70% proficient mean anyway? Okay, that's all I'm going to add to this resume right now. But depending on you, there might be some other things you may want to think about. Certifications and awards. If you have any industry certifications or recognitions, list them out. Publications and patents. If you have published any works or registers and patents in your name, firstly, nice, well done. Secondly, make sure you show them off on your resume. Languages. If you speak multiple languages, list them here and indicate the level of proficiency in each one. This is particularly important if your first language is different from the one you'll be using at the job. Great. We've got the basics down. Now let's go back to the top and polish it up a bit. We're looking at a rather plain page here, so let's add some style to make it pop. But before we do, let's discuss what a resume is truly for and equally importantly, what it's not for. When you apply for a job, you may be one of hundreds of applicants, and the hiring team will work very quickly to filter that down to a much smaller number to speak to in person. Your resume's job at this stage is a personal brochure, working hard to tell everyone why you may be the perfect fit for the job. It should be uniquely yours and reflect some of your personality, but not too much. It has an important job to do and needs to do that quickly and easily. So stay away from overly extravagant style choices. Hiring teams will often extrapolate a lot of information from your resume, what you've included, what you didn't include, and how you presented it. So try and get a picture of the kind of person you are and what it might be like to work with. So there's a fine balance you'll need to strike here. On one hand, you don't want it to look like you just used the first default templating word for resume. What kind of person do you think that makes you look like? No going the extra mile, maybe not a creative thinker? These things might not be true of you or even relevant to the job, but they can create a subconscious impression of you that can cost you dearly at this early stage of the hiring process. On the other hand, a resume that's too unusual or creative, may be hard to locate the required information. For example, initial screening of applicants for a job may be to just see if they have the amount of experience they are looking for or you know any of the key skills they require. If these are formatted in a hard to find way, you may frustrate the person reviewing it. At best, this isn't a good place to start from. At worst, they could just give up. It's also worth mentioning at this point that it's good to be aware of your audience's expectations. For example, in the US, it's typical for a resume to be a single side of paper. In the UK, however, it's more common to be two sides in length, while in India, resumes are typically much longer and more detailed. It's out of the scope of this video to investigate the length expectations of all countries, but it's just to say it's something you should be aware of and look up when applying for jobs, as failing to meet these cultural expectations, again, could cost you dearly at these early screening stages. For a resume here, I'm going to aim for a single side of paper as that will meet the expectations of both the UK, where I am and the US. It's incredibly uncommon these days for any interviewer to be actually printing your resume and have a hard copy, but it's not unknown. So once again, it's a good idea to tailor your resume to your company's printer. If you're applying for a European company that'll be using a four paper while in the US, it's the slightly wider letter size that will be used. It might sound dumb, but you don't want to put all the effort in now to make your resume beautifully typeset only to have it run off the side of the page when printed. Okay, where were we? Oh, style. So we have all the main points down on our resume, so we can start tweaking it to look amazing. The first thing I'm going to do is narrow the margins on the page. Word has very wide margins by default. This is mostly to support the rollers or very old inject printers, so I don't think we need to worry about that anymore, and I personally feel like they make the page look very narrow and cramped. It's just my style preference, so you do you here, but it does give you a lot more space to work with. Let's add some style to our core information. Let's make John's name nice and large and add a little color to help it pop. Now, I'm going to do something controversial. I'm going to add a profile picture. I personally like this because it gives the resume a touch of personality and breaks up the pages of texts that a hiring manager has lightly been staring at for hours. Notice that our applicants used a dedicated professional headshot featuring only themselves. Avoid that one photo of you in a suit where you've cropped out the best man from a wedding. We're not applying to be models or movie stars. So, in theory, the photo is just to make the resume look nicer. It's important to recognize that this can be a potential vector for discrimination, though. Ultimately, I'll leave it up to you to decide what you feel the most comfortable with. Okay, let's make our headings a little larger and the same color as the name, so they're easy to spot. Worry at it. Let's also clean up the individual items of those lists. Let's make the headings bold and add a little bit of extra information under each. Pay attention to the small details here. As I said before, a potential employer may extrapolate a lot of opinions from small details. So try and keep things consistent. Notice how I've used the format start your hyphen end colon space institution, and I've used the same format for every entry. I know it seems like nitpicking, but inconsistency can create a subconscious impression of poor attention to detail. I often see issues with this in more recent entries on resumes. Remember, if you're updating a previously written document, match the style, size, and font of what you already have. You don't want to give the impression that you didn't put much effort into this application. After all, nobody wants to hire someone who appears laxadaisical. Let's apply the same formatting to the employment history, and I'm also going to add a few sentences to each describing our candidate's main responsibilities. Since our candidate has worked in several positions, I'll include a bit more detail for the recent roles or being concise with older positions to save valuable page space. Ah. Look what's happened here. With all our extra information, the list of skills has spilled over to the next page. To fix this, I'm going to add multiple columns and make better use of the horizontal space. This allows me to achieve my goal of being a single page resume. If this happens when creating a resume with more than one page, pay attention to where the page breaks. Rather than splitting a section across two pages, move the entire section and its title to the new page so it can still be seen in one go. One last thing I'm going to paste in here is a few sentences at the top, just to introduce our candidate in their own words. That's it. Our resume is complete. So we're finished, right? Not quite. We're not done yet. The next stage is important, perhaps the most important. Proof read it. If possible, get a friend to proof read it. The last thing you want is for all your hard work to be undone by a spelling mistake. One tip I was once given was to use a text to speech software and listen to what you've written. I find it really helps me to spot errors that I couldn't spot visually, or you can always get some help from an AI. Before we wrap up, should we have a look at some of the things I chose not to include? Take a look at this slight modification to our original resume. First thing you'll notice is that there's icons on all the headers. I see this quite a bit, and I think it looks pretty old fashioned these days and doesn't bring much to the resume. The other changes are in the personal details I've shared for address. Why? Who's mailing things to you? It's just noise on the page. It makes it harder to find really useful information. Likewise, your date of birth should have no bearing on your eligibility for the job, so it has no place on the document. Of course, someone can make a fairer guess of your age from your education and employment history if they really wanted to, but I prefer not to hand it them on a plate. And that wraps up our guide on creating a standout resume. Remember, your resume is your first impression on potential employer, so make it count. Take the time to tailor it for each application, highlighting the skills and experiences most relevant for the position you're seeking. We've covered a lot of ground today from structuring your resume to styling it effectively, but don't forget a great resume is the first step in your job search journey. In the next module, we'll be diving into what you can expect from your first interview. We'll discuss common questions, how to prepare, and tips to help make a lasting impression. So stay tuned and get ready to ace that interview. Until then, keep refining that resume and best of luck with your job search. 4. The Initial Call: Hello again. Great news. You've polished your resume, and now it's working its magic, showcasing your amazing skills to potential employers. So what's next on the exciting career journey you guessed at interviews? Buckle up because in the coming modules, we're going to take a tour through the typical tech interview process. We'll dive headfirst into each stage, giving you the inside scoop on what to expect and how to shine. Are you ready to rock those interviews? Let's go. As I progress through my career in tech, I discovered that one of the key things that improved my confidence and performance during interviews the most was being on the other side of the table, interviewing other people. Progress through my career in tech. I discovered that one of the things that improved my confidence and performance during interviews the most was being on the other side of the table, interviewing other people. When I first sat opposite a candidate, I was so nervous, my notes were practically shaking. However, as I got more practice and coaching for some truly great interviewers, I began to understand what I was looking for and how to put candidates at ease and help them showcase their best selves. By understanding what I was looking for in candidates and the discussions that interviewers have when making decisions, I was able to refine my own skills as a candidate. This knowledge helped me highlight the most relevant things and make the most of our time during the call. In the next few lessons, I'm going to pull back the curtain a little and help you learn what I learned so that you, too, can make the best possible impression to prospective employers. So let's jump in. Often, the first conversation you'll have with a company will be the initial call or an informal chat with an internal recruiter, HR representative, or sometimes the hiring manager themselves. This call is generally shorter and less structured than a full interview. It's an opportunity for you and them to get on the same page about job expectations, what you'll be doing, where you'll be working, and maybe how much you'll be paid. Now, here's a pro tip for you. During this call, honesty is your best friend. Don't just say what you think they want to hear. That's a recipe for wasting everyone's time. Let's say the salary they're offering doesn't quite match your expectations. Don't be shy. Mention it politely. They might be able to help work with you on that, or they might not, but trust me, it's much better to have the conversation now than go through the entire interview process only to drop that bombshell at the end. Remember this call is about finding the right fit for both of you. So be open, honest, and most importantly, be yourself. Alright, folks, it's time to put your interview game face on. There are two questions that almost guaranteed to pop up every time. And trust me, they're not trying to trip you up. They just want to get to know the amazing person behind that resume. So let's get you prepared. Here's a little homework for you. Don't grow. Promise, it's not as painful as your old algebra problems. So grab your favorite notebook and let's tackle these two questions. Question one, tell me about yourself. And question two, why are you looking for a new job? Now, I know what you're thinking. These sounds simple enough. Why do I need to prepare? Well, my friend, that's exactly why we're going to break them down. Trust me, a little preparation goes a long way in making you sound like a rock star candidate. We know you are. So, who are you? What's the story that brought you to this point in your career? Here an interview is looking to get a high level understanding of your expectations and motivations. Start by explaining your current situation, your current role, your most recent position or education or milestone and your responsibilities. Then work backwards through the most interesting steps in your career, painting a picture of how you've grown and the various skills you've developed along the way. For example, if you've been in the industry a while, you could say something like I'm currently a lead engineer at company name. Well, I work on a team of six on the whatever product. I previously worked at wherever, for X years and I joined as a mid level engineer before being promoted after my contributions to their product. Of course, this could be an application for your first ever role in tech. Welcome, by the way, we're so glad you're here. So you may want to emphasize your academic and curricular achievements instead. You might say something like I've recently graduated from university name with grade in course, and I'm currently looking to start my professional career in tech. Outside my studies, I've also contributed several open source projects, including, whatever, and frequently post about new technologies I learn about. See, it doesn't have to be long and complicated, but it very much helps if you've got some thought in advance, so you're not ming and Ring your way through the actual interview. Now, the second question, why are you looking for a new job? This one is more targeted towards candidates moving from one job to another rather than starting their careers for the first time. They want to understand your motivations to ensure they align with the expectations of the role, and that you'd be a good investment for their team. Think about it, bringing in a new person and teaching them everything they need to know about the company is a very expensive process. So they really want to know that you're going to be a happy, productive, long term investment for now, I want you to be really careful here. Remember I said that you should be honest and authentic? Well, if you're leaving your current role because you're unhappy there, make sure to frame it diplomatically. I've heard too many candidates digging into everything that's wrong with their current company, why they suck and everyone else is wrong. I felt that way before, believe me, and it could well be true, but there's no way for me or an interviewer to know for sure. But if evaluating someone who you think would be a good fit for a company, hearing them rant about all the leaders in their current company is not a good look. So some things you might like to think about instead. Are you looking to move into a slightly different role? Maybe you're looking to try something else or try your hand at leadership. Explain why you've come to that decision and what you hope to bring to a new role and what you might get from it yourself. Maybe it's about the working environment. Perhaps you're looking to work from home more or less. Perhaps you've progressed a lot in your current role and would like to try a new challenges. Of course, it's perfectly okay to be honest about any other reasons you're looking, such as layoffs, start up failings, or you've had a career break for whatever reason. Remember, unfortunately, the current market conditions meant that the company was not able to succeed is much more diplomatic than the CEO didn't listen and made poor choices. Like I said, it's great if you have a good answer to these questions lined up, but it doesn't mean you have to have a script and read it like a machine to every interviewer. Keep it like, keep it natural and keep it authentic. You can even apply some light customizations to make it relevant to the specific company you're talking to. Okay, one final thing you might get at at this stage is some basic technical questions to validate your baseline skills. Since you're not talking to a technical person, they might ask fundamental questions like, explain the difference between pass by value and pass by reference. Or what is object oriented programming? In these places, clear rational communication is key. Take a beep before you answer and think it through. Often, you're asked these questions because they're both evaluating your technical skills and your ability to articulate them. So when you answer, imagine you're teaching a non technical friend. Take them gently through the constructs, maybe why you might use such technology. Example, when answering explained the difference between pass by value and pass by reference, you might start by explaining pass by value, then contrast it with by reference before concluding with a discussion of why you might choose one over the other. They might choose to ask you a really short coding challenge. For those, you can answer them just in the same way as larger more complex coding tasks, which we're going to look at a little later on. So we'll see you there. 5. Bonus. Mock Initial Call: Hello. Great. How are you? I'm great, thanks. How are you? I'm good, thanks. Cool. Okay, so thanks for taking the time to speak with me today. My name is Jerry. I'm a manager here, and I'm looking to find some great candidates for some roles we've got. This is just a real quick informal chat to take you through the company and the role. Then for you to tell us a little bit about yourself. Does that sound good? Yeah, that makes sense. Great. So let's jump right in then. Just to give you an overview of who we are. Um, we are currently looking to launch two new countries next year, so we're expanding our engineering team quite a bit, as you can imagine, and there's a lot to do already. We're currently hiring for all seniorities in our mobile apps, as well as our back end and database teams. Mm hmm. Typically, in our interview process, we will take you through all the rounds and then the team would make a call on the seniority level based on how you performed in the interviews you did. That makes sense. Okay. So before we move on, do you have any questions about who we are or what we do? No, I think you've covered it all pretty well. All right. So I told you a little bit about it s. Do you want to introduce yourself? Sure, so I'm Andy. I'm currently working as a senior Android engineer at a small UK startup. We make a product that matches pet owners with pet sitters in their area. I work as part of their mobile team, and I'm responsible for all areas of the mobile app, including the UI and integration with the API that's developed by our backing team. Uh, last year, we brought on board some interns that were with us for 12 months and I was chosen to be their mentor. I helped them learn about our app and the frameworks we use, as well as working with them to debug issues. Previously to working there, I was a web developer at a major UK supermarket where I joined as a graduate and was promoted up to mid level. That's awesome. It looks like you've been at your current delta for about 2.5 years. How come you're looking for a job now? Yeah, when I joined, I was a mid level engineer and I've since been promoted to senior and I've had the opportunity to coach and manage some interns. While doing that, I actually found that I really enjoyed that role, helping folks in their career get the best start. I'd like to do that more. I'm looking for opportunities at larger companies where I can expand my coaching skills as well as grow my own career. Okay, makes sense. What attracted you to us specifically? Well, I've known about you folks for a while. I've used the app a few times myself and looked after other people's docks. I think it's a really great idea and the playful tone of the app really appealed to me. When I heard you're expanding, I thought that it sounded like there would be some really good opportunities for someone at my level to sort of learn and grow. Great. Yeah, we're really big believers in career growth and feedback. So I think it might be a good fit for you here with lots of space to grow, as well as teach others. Nice. You mentioned earlier you had done some coaching already at your current job. Could you tell me a bit more about that? Yeah. So over the last couple of years, I've been getting more and more knowledgeable in our app and how it works. I've been working with some engineers to help them design things. I was actually super worried at first that it was taking time away from my coding, but my manager pointed out that I was still being impactful by helping others. So that was a really interesting adjustment for me. Um, then about a year ago, we brought in our first ever interns. They were on a 12 month program, halfway through the university course, they knew how to code, but had never really done it in a professional environment or with a larger team. I was their manager for those 12 months, so I helped them get on board and worked with them the whole time to coach them through sort of problems with their code, putting together poor requests, responding to poor request reviews. By the time they went back to their studies, we really thought of them as sort of core members of the team. They'd even run some training sessions for the senior engineers on the things they'd learned. That's awesome. Did you find that being an intern manager slash coach or something you enjoyed? I really did actually. It was a bit of a surprise, to be honest. Okay. Like I said, this is only a quick chat to make sure we're on the same page. For my part, I think you sound like a great fit. I think we should continue on to the next stage of the interview. This will be two more interviews, both with our engineers. The first is a coding challenge where you'll use shared coding tool to solve a problem. The other is a design challenge where you'll be asked to design some piece of software and a whiteboard together. How does that sound? Yeah, that sounds good. I'm really excited. You guys seem great. Okay. I'll get some link set over to help you find a slot for your next interviews. Before we go, is there any questions you wanted to ask of me? Yeah, just the one. On the listing, it says the job is hybrid. Could you elaborate on what the sort of work from home and office balance would look like? Hmm. Sure. We're actually mostly a remote team, but we do ask everyone to join the office twice a month for an hands get together. It's usually on the first and third Monday of each month. Okay, that's interin with me. I really like meeting people I work with. Yeah. It's a bit like a big party, to be honest. Is there anything else you wanted to know? Not at the moment. I don't think so. Great. In that case, I'll get those booking links sent over to you today. It was great talking to you. You too. 6. The Dog Ate My Homework: Hey, friends. So you've done the introduction call, and they think you're a good match for the company. But they've gone and done the unthinkable. They've given you some homework to do. Oh, gross. I know. What now? These homework challenges come in many forms. Sometimes you'll receive a template project with instructions or a link to a Github repo. Other times, you might use a dedicated coding test platform. These platforms are becoming increasingly popular as they track various metrics alongside your code, including your editing history and completion time. While many interviewers value these tests, others don't, so you may or may not encounter one during your interview process. The test often involves a simplified version of the company's own product with specific instructions for completion. Follow these instructions carefully. If you're given an interface to implement, don't modify it, they might use automated testing to evaluate your work. That being said, though, they're typically less interested in whether you completed every feature and more focused on the approach. Though a small project, they're trying to understand what kind of coder you are. So when you come to complete it, take a moment to think about the architecture. As this is a model project, think of how you would build it for an established company and to be used at scale, not just the quickest solution to make the code work. Make sure you're using your neatest code, clear variable names, reusable blocks, broken into function, comments and consistent styling will all help show what a diligent and detailed focused engineer you are. Also, don't forget your tests. A bare minimum unit test. If integration and UI automation tests seem appropriate and you have time, that's also great. Gosh, that seems like a lot to do. Don't they know you have a family to care for and an existing job to work at? I hear you. There are some things you can do to help here. Remember that they're looking to understand what kind of developer you are, so you can focus your attention on the things that matter. For example, if you've demonstrated you know how to write a unit test, do they really learn anything more from seeing you do it another ten times? Probably not. You can write one solid test, they mentioned in a comment that others were omitted for brevity while listing out the things you would have tested. The same applies to the change itself. If they're API cure for many similar points, show that you know what to do with one or two and then explain that you ran out of time to implement them all. Personally, I'd rather see you demonstrate an understanding across a range of topics than complete a full solution focused on one. If you try your best but run out of time, make sure that you submit what you managed to do. Just mention that you're unable to complete the full task, and that's usually fine. Now, don't tell them I said this, but you do have one more option, and it's up to you. I can't tell you if it's a good idea or not, but you can simply refuse to do it. I've seen candidates decline homework citing their home commitments that would make completion impossible. They've often made it to the next round, anyway. Like I say, that's a judgment call for you, and it may be the end of the interview process if they consider it mandatory. What happens next depends on the company. They might review your work and decide whether or not to invite you for another interview, or they may use it as a discussion point in the next round. Be prepared to discuss the decisions you made and evaluate the pros and cons of your architecture, especially how it would handle increased scale. One final point, don't cheat. Interviewers want to understand how you write code and will likely ask questions about your choices. Using AI to complete the task or outsourcing it, yeah, it happens is risky. If you're caught, you could be blacklisted from other interviews with that company and possibly others. It's simply not worth the risk. Alright, that's it for this module. Now, your homework for this module is no, I'm only choking. There's no homework in this module. In the next module, we're going to be looking at some tips for dealing with the technical challenge. I will see you there. 7. The Dreaded Technical Challenge: Hello again. How's it going? You've made it to one of the most dreaded parts of the interview process, the technical challenge, sometimes called problem solving. May seem scary, but there's nothing to worry about. Once you know what you're looking for, you can settle in and have some fun showcasing your amazing skills. So get yourself comfortable and let's dig in. Unlike previous conversations with the company, this is often the first time meeting people from their technical team. You're usually talk with engineers who may become your peers rather than managers at the company. It's a great opportunity to showcase yourself and show them what an amazing teammate you'd be. So what's involved? Well, the first thing they will want to know is about you. They may or may not have read your resume and notes from previous stages before going into the call, but definitely will want to hear in your own words who you are and why you're amazing. Remember the Tell me about Yourself question from the introductiory call module? You watch that one, right? Well, you're probably gonna hear it again and again and again because every person will want to ask you this. Sorry about that. The same tips still apply. Be authentic and highlight the key points in your career, education, or extracurricular activities that have led you to this point. Since they're talking to fellow engineers, you have an opportunity to geek out a little bit more if you want to. Feel free to dive diaper into technology you love. You may get asked some really simple technical questions again. If it's the beginning to feel a bit like groundhog day in here, don't worry. At this point of the interview, everyone is just getting warmed up and we'll soon kick into high gear. As with the introductory core module. You really have watched that now, yeah. They aren't looking for a binary right or wrong answer. They just want to hear how you communicate and describe technical complex things in clear terms. Now, finally, this is where it gets interesting. The problem solving portion. In this part of the interview, you'll be asked to actually write some code. They're on a call you usually share some link to a shared coding tool. So be sure to join an environment where you can think clearly and type. Believe it or not, I've had to reschedule the coding interview because a candidate joined on their phone in the car and wasn't able to type. If you have any accessibility requirements such as screen readers, voice to text tours or specialized keyboards or hardware, be sure to share this with your recruitment contact at the company while booking the interview. This prevents wasting time getting set up during the call itself. So here we go. This is much more than a simple coding test. There are four main elements your interviewers will be looking at. One, taking vague problems described in real world terms and translating them into technical requirements. Two, the quality of communication and collaboration with interview panel while clarifying those requirements and explaining your approach as you work. Three, how clear and methodical your approach to developing a solution is for the quality of the actual code produced. You can think of this as a mini simulation of what it might be like to work with you and develop a large complex feature for their product. While the problems you'll be solving here are not the most realistic. They give you a small opportunity to collaborate with your peers and explore possible options, evaluate pros and cons and eventually produce software. Imagine you've been asked to develop some complex feature, but you're stuck and you don't know where to start. So you grab a friend and start exploring the problem together, explaining what you're thinking and listening to their feedback. So it's really important that you communicate and listen. Now, you're all set up and good to go. The interviewer has asked you something like, please write a function that can print the first end prime numbers. Here's what you do. First, validate you've understood the assignment. Rephrase it into your own words so you can check that you're on the same page. If you like, you can start writing requirements in the comments at the top of the code, so don't forget them later. Next, ask any questions about what you will or will not build. It's likely that the problem you're asked was deliberately vague because it's expected that you work to define the scope as part of your answer. Next, ask any questions about what you will and will not build. It is likely that the problem you're asked was deliberately vague because it's expected you work to define the scope as part of your answer. Next, establish any assumptions you're going to make, anything you're not going to do because you expected the input to be correctly formatted, for example. This shows that you've understood the edge cases of the problem and chosen to focus elsewhere. This is a lot of prep, isn't it? It might seem a little over the top for what you've been asked to do. Admit it, you've already decided how you're going to solve the expert ample question, haven't you? That's right. I'd do the same. But remember, this is a simulation of how you would behave in a larger situation. So it's all about showing you know what you need to do to be successful. There's just one more piece of admin before you start writing code. Verbalize what you're going to do. At this point, you might already know exactly how to solve the problem. So take the interviewers through your plans. On the other hand, you might still be working it out and just want to get some of the prep out of the way. In which case, mention that to the interviewers and tell them what you're doing. Finally, it's time to start writing some code. Now, while I won't tell you exactly how to code, there are some important things to keep in mind as you begin. One, keep communicating, explain your thought process and decisions as you code. The interviewers want to hear your reasoning, not what you silently typing. You're not making an ASMR video. Keep them engaged and informed throughout. Two, write nice clear code. When working in a team we share code, it's important everything is clear and easy to read. So the interviewers will be looking to make sure you're following good practices. Make sure you're using descriptive variable names, adding helpful comments, and splitting appropriate sections into their own methods. You know the drill. Three. Listen to the interviewers. Don't assume they're right. As you code, they will ask you questions about your solution. Listen carefully and think about their answers. They may have some different motives. They might just be trying to get you talking if you've been quiet for a while, or they could be guiding you to reconsider your current approach if you've taken a wrong turn somewhere. Or on the other hand, altogether, they may be challenging you because you're not wrong, but because they want to understand the reasoning behind your choices. Sometimes they just want to hear you defend your decisions. If you get stuck, ask for help. There's no shame in this. If you're working in a team and need help, they would rather you ask them than sit unproductively at your desk, so it's not a sign of weakness. So there you have it. The technical interview shouldn't be anything to be scared of. You're a good engineer. I can see it from here. You just need to make sure you're showing that to the interviewers and you'll have no problems at all. In the next module, we're going to have a look at the next stage, the design challenge. See you there. 8. Bonus. Mock Technical Interview: Yeah, welcome to the coding portion of the interview. I as you can see, we've got a shared coding tool here and there's a little test harness already in there. What I'd like you to do is implement the anagram method there to build a tool that this tests if two input strings are an anagram of each other. Just case you didn't know, an anagram is when two words have the same letters in, but they may or may not be in different orders. So, I'd like you to implement that in that method, please. Okay. All right. So okay, we've got a bunch of tests here already. Empty string troop? No, I guess that is true. That is an anagram, isn't it? Hm. Okay, uh keep an eye on that in case we need a special case. Okay. And then we've got Oh, okay. Um, we can run it? Yeah, so we'll run real time. It's quite slow, unfortunately, so you have to wait a few seconds. Oh, well, Wasome, that's useful. Okay, so everything's failing right now except for the falses of course. So, um, et's let's get rid of that. So thinking probably what I'll do is um, look for evidence that it's not an anagram. Yeah. So it'll turn true at the end. Um, Uh, cool. Uh, so I guess a really, really obvious first thing to try would be to compare the length. Uh um two dot length. Uh, Cannot. It's about wrong, cannot be an anagram if don't match. Cool. And I think we've got some of those. Three pass at the moment. So if we run that now, uh, actually pick up some of our stuff. Oh, of course, all our grams are now returning true because of that. Okay. Fine. So, um, how could we do this then? I guess for anagram, they would have the same number of each letter. So, um, create a couple of new dictionaries. I'm gonna try spell it correctly. There we go. Hart against the count. I'll make a copy of that for two. Mm hmm. Um, then we need to chew, just little check. I don't believe there's a Increment Insert. So what are you sort of attempting to do here? Yes, I just need to check if the dictionary already contains the character, and if it does, then I need to write it as one, and if it does, I want to increment the current value that it has. So I think we can use contains like that. And then we can do dict one S. Um, Yeah. Mike, is there any reason you switched from the post increment to the pre increment? Oh, yeah, it's actually it comes from a lecturer. I had while I was at university who was doing advanced programming, they called it. It was all in C, and he was very particular about how we wrote our code to make sure it was always optimal. One of the things he pointed out was in an optimized. If you're using the post increment, it has to store the value of the previous value before it increments it so that it can return it afterwards. Um, so technically, it's one more instruction in the compiled machine code. So is actually less efficient if you don't need the original value, and he would mark you down in your code if you did that inadvertently. I'm almost certain all modern languages are going to deal with that during optimization, but it's a thing that stuck with me a little bit. It's almost a bit of a trademark at this point in the code, right? Uh, okay, yes. So, um so, oh, yeah, we want to add that, don't we? W zero, one, one. Um, cool. And then, um, I guess we repeat that for, um, the second Dictionary, make sure we correct all these. That's going to suck. Okay, should we just give that a run? Not too sure on you a completion on here. No, I thought we might have. Some issues. Oh, Oops. Uh, vada. See. Hmm. I did your e does no good. Oh, it's, it's contains a key, isn't it? There we go. Fumbling my code. Input two does not exist. Oh, Eat put. Is that a deliberate to catch people a? Well, that's just me. No. Okay. Uh, okay, let's see how that goes now. Cool. Still failing on these ones here. Um, I interesting more passing, even though it got bugs. So, um, now we need to compare these dictionaries. Um, so, I guess, again, we could check the length of them. Tell us what we've got. Different. How come you're comparing the length? Yeah, because we've been adding a key for each character into each dictionary. If there's letters in the one string that aren't in the other string, then the dictionaries will be different lengths, so it can't be an anagram, so we're going to return false for that. And then we know Now that there's the same number of letters, but they might be different. So we still need to compare all of the keys and all of the values of all of the keys. That's going to be um a pain, but we'll persist. Um so uh, It's key value pair in, uh, **** one. And then if di two contains key doesn't contain the key. Oh value pair key. Um, I'm going to return False, because that's a letter in dict one that isn't in **** two. Um, else we will we can just return. Uh pair dot h value equals two, four value pair K. So if the value of that is different, that will also return false. Not too sure about the type this is returning. It's been a while. Oh, okay. There's no length for a dictionary we're gonna need. Um Uh collections dot. No, we need Link, don't we? Uh, and then we're gonna use the extension method. Kant. Like that. Anything else? Get upset with us? No. Okay. Um, Brackets. Brackets, Brackets brackets. Where have I written bad brackets. Line 57? Oh, yeah, of course. That one. I just staring. Awesome. Okay. So I was expecting that to work, so uh it failed. Oh, wait, hang on. Expected true, but got false. Wait. That's another bug in the test glass. Yes, cool. So I'm gonna just correct that. Cool. Uh, I think that's done. Awesome, yeah. That has implemented the problem. As you can see all your tests have passed, and you corrected the one, I got wrong. There's a couple of errors in our test template there that'll correct when we're done here. How do you feel about your solution? Do you think there's anything you could have done better or anything you don't quite like? Yeah, there's a lot of looping here. So got to go through both inputs. And then the dictionaries afterwards. You think there's a better solution you could have done? Oh, I guess we could see we could have sorted them, couldn't we? We could put them in alphabetical order. And then if they're anagrams, they would be be identical. Yeah, that's another way we could have done it. Obviously, we probably ask you to implement a sorting algorithm then and go a little bit deeper. We don't really have time now. We've got a solution. We're pretty happy with it. We know it works. I think we've seen enough for today. With what we've got, it's fine. So I think we'll wrap up for now. Thank you for taking the time to take me through this. 9. Architecture & Design: Hello again. I'm so glad you're back. In the last module, we took a look at the coding interview. So now we're going to dive headfirst into its close cousin, the system design challenge. The system design challenge is very similar to the technical challenge. You'll presented with a problem and asked to find a solution. However, instead of solving a coding problem during the interview, you'll tackle a much larger scale issue. Rather than writing code, you'll be diagramming out the architecture of the system. You're going to get bored of me saying this. But in these sessions, the interviewers are looking for you to demonstrate your communication skills. They want to see how you collaborate with them, to first understand the problem, then clarify it and finally drive to a solution. Of course, they are also assessing your knowledge of common patterns and ability to anticipate the system's edge cases and needs, but all of this is wasted if you're not communicating with them. This might sound a bit abstract, so let's dive straight into example. Every company and sometimes even individual interviewers within the company will have their favorite questions. So it's important to listen carefully to what they say. Often they present a trim down model of their own company, but not always. One of the most interesting questions I was asked as a candidate was simply Build Twitter. Yes, it was a few years ago. This is a shockingly short question that seems both at once too big and far too simple. So our first job is to define the scope of what we are and perhaps more importantly, what we're not going to do. This is important because often the question is left deliberately open for you to take it in the direction you choose. So the interviewer expects you to interrogate them on what they would like. Think of it this way. Imagine you're a software engineering agency and there's a client who has just sat down at your desk and said, Build this massive product. You're absolutely allowed to say, wait. What? Let's look back at our example. If they've named a specific service you're unfamiliar with, you absolutely can tell that to the interviewers and ask what features they'd like to see. There's no need to blunder on and make assumptions. If on the other hand, you're already familiar with the service, you can start by defining it as if they don't know, just to make sure you're on the same page. So, for example, you could say something like, Okay, Twitter, let's define that as a site where any account can post short messages to their timeline and can follow or be followed by any number of other accounts. When a registered user accesses the site, they see a chronological timeline of messages from all accounts they follow. If you like, you can even note that down on whatever shared whiteboard you're using. With a high level description of the system noted down, you can dive deeper into what they might actually entail. This means defining what elements of the system you will produce a design for. Take a look back at your high level description and think about what will be needed to make it work. Remember this is a model system. It doesn't have to attain every single feature. Indeed, we'll come to what it doesn't include a little bit later on. On your whiteboard, you can start jotting down bullet points of what you'd like to cover. In an example, we can see that we've got user profile, so we might need some kind of sign up and sign inflow as part of our design. What might a profile contain? Display name, user name, bio? We also need to include a profile picture, so we'll to have upload features for those. We mentioned these accounts both follow and are followed by other accounts, so we'll need some kind of system for tracking follows. Finally, we got the timeline. We need a way to show posts from user accounts to user follows in chronological order. Awesome. You probably don't have enough time to design an entire product that has taken years to develop. So there may be features that would just be distractions. You've already outlined what you'll be doing, but there are any major features worth mentioning that you won't cover. This is a great opportunity to show that you've understood the system's complexities and are simplifying it for the interview whilst demonstrating that you could go deeper if needed. So what kind of things will we not be covering? Authentication and password management are notoriously tricky to get right. So we could mention that we expect to use an external service for this. How about other product features direct messages, blocking users, favorites, tagging all out for now, unless the interviewer asks you to add them back in. There's one final question you should ask your interviewers before starting. What kind of scale are they expecting? Ask about the expected number of users and anticipated growth rate. This information will help you estimate the number of requests users might make and design the system to handle that load. It's crucial to pay attention to the scale requirements. If you're told to expect 1,000 customers per month but design a highly complex system capable of handling 10 million customers, while impressive, you've ignored the specifications and overcomplicated the design. Keep your solution pragmatic and aligned with the agreed upon specifications. With all this setup done, you're now ready to make a start. The way you design your system is up to you. Depending on your experience, role, and the company, you may choose to take a platform focused direction, considering the databases, load balancing, and caching. Alternatively, you could take an application focused approach examining the data structures and how information flows through the service. Whatever direction you go in, it's important to try and be methodical. You're inventing a system in real time in front of other people who are trying to follow along. If your brain is firing off in 1 million directions bouncing around between different elements, you'll confuse the interviewers. You can start at the top of the system in a very high sense and zoom into each element as you go, or you can start at the minutia and bring it up to the higher level. It's up to you, but jumping up and down isn't ideal. Whatever approach you pick and I said you'd get bored of me saying this, communicate. Explain what you're doing and why you're doing it. Start to create your diagram based on what you're saying. Generally, in this kind of session, you're not expected to produce perfect UML that you could send to other engineers, but just use a diagram as a way to drive the conversation forward. I tend to use boxes to articulate parts of the system and focus on how data moves between those blocks using annotated lines. More so than with other interviews, the system design one is one of collaboration between you and the interviewers. Imagine you're standing at the whiteboard with your peers working out how to build something together, critiquing and building off each other's ideas. So you will likely be interrupted several times. The interviewer may ask to clarify a path you are taking and how it relates to the spec you agreed at the beginning. This can be an opportunity for you to work together to improve your design or if you're confident, defend your approach by explaining your methodology. Once you approach a more complete solution, your interviewers may throw some modifications at you. For example, let's imagine our service is really successful and our usage increases 100 X in one month. How might your system handle this? When asked a question like this, pause for a moment and really think about what elements of your design may be involved. Discuss which sections are likely to have issues and propose possible modifications you could make to handle this. It's as simple as that, really. You're working together to create a design that implements your agreed spec and then exploring the limits of that design. If you can relax, it can even be a fun opportunity to design something from the ground up. Before we wrap up this module, it's time for some homework. Your task for this module is to create a design of your own for the example we looked at here and post it for your classmates. Then take a look at what others have done. In the next module, we're going to take a look at what the deal with behavioral questions is. See you there. 10. Bonus. Mock Design Interview: Hey, yeah. So this is the system design challenge. I'm going to ask you to use a whiteboard I shared to sketch out a design for a system. I'm going to tell you right now. So the system I'd like you to design is a video streaming service. So it's a subscription service where a user pays a subscription, and then they can watch any number of the movies we've got on our library in the browser at any time and as many times as they want. Very similar to Netflix. Okay, so video streaming service. So let's just take a note down of the features that it might have. So obviously, we've got video video playback. Uh, Got browsing. Um, I also gonna have user accounts. Uh, they've got subscriptions. Slash payments. Um, I might have things like resume points. Browsing is in points. What else would we need Authentication. And then there might be some kind of back end stuff like ingestion of the movie that have been played. Okay, I think that's reasonable. I think I'm going to focus on sort of the browsing, playback experience, um and, uh, maybe leave some things like authentication, like video transcoding, kind of we just assume maybe an external service is doing that or buy that in or can not include it in the scope of this design for now, if that's okay with you. I think that's reasonable. I think we'll probably include payments in there. We can assume that we're maybe using something like stripe to handle payments on our behalf. They, they have APIs as well for things like subscriptions. Um, which is all pretty cool. Great. Okay, so I think what I'm going to do here is give a kind of high level design of the major bits in each system, and then I can sort of dig down into them and how they fit together. So just sort of for my benefit here, let's make some boxes. So I think we've got, like a like a website. I'm going to assume maybe again, maybe we'd add that to our assumptions here that we're not designing an app here. We can assume maybe there's an API down the road where we can build an app, we may outsource that, but probably don't want to get way laid into the weeds of app development here. So we can assume that the website is going to have a library. Um, you know, homepage. Well, actually, let's separate that out. Um, you know, that's gonna have, like, a public section, which is gonna be like Homepage sign in slash U maybe some help pages, you know, that kind of thing. And then we can have a private section for log in users, which might have like account details, payment details, like a watch list and obviously, like playback, assuming here that you need to be signed in and paid for in order to see playback. So we've got these kind of public and private experiences there. Cool. So, I mean, we can assume then that's going to probably communicate with an API over here. And just for completeness, here, let's pop up. Mobile app. There, let's just say, like, not in scope. Like that. And we can pop a couple of arrows here just to kind of show that they're consuming. How are you imagining the website UI is communicating with your back end? Oh, well, we can assume that's kind of a HDP driven interface here, so we could use something like Rest and Jason, um, or if we were feeling a little bit kind of different, we could even use maybe GraphQL. Do you have any thoughts on why you might pick one versus the other? Yeah, I think probably kind of given the nature of what we're doing here, which is more kind of just sort of signing in, viewing your account details, playing back movies. I don't really think graphiosnecessary. We're not doing sort of complex queries on big datasets that are sort of linked together. That's probably just a little bit more than we need. So probably here we'd be looking at sort of a rest API would be the uh the right approach here, I think. Um, now within our API, that probably would be a relatively thin layer, I believe, that would be a enduring public interface which allow us to handle older clients and changes as we go that doesn't necessarily link our external API to our internal structure, gives us a bit of flexibility later, then we would have our back end here. A nice big box here. I just want to say that's our back end. So yeah, I think that's probably our high level idea of what it would look like. So we can start to fill in that back end book that I've left blank because I think that's where a lot of the meat here lives, and then start to play a little bit with our interface here as well. So if we, um, yeah, so if we dig in a little bit, let's make this box really big, um, and let's think about, uh, what our internal service structure might look like. Uh, so maybe we might like to think about sort of a microservice architecture. Can you think your thoughts on why you've gone down a microservice approach versus a modern this? Yeah, I think a microservice architecture here would be pretty useful. We've got some quite distinct blocks that require different levels of authentication from must be authenticated, your account details to, um, definitely no need to be authenticated, such as, um, the homepage and maybe browsing the catalog. And then there are some ones in the middle where it might be interesting discussion to have things like playback, where ideally you want to be authenticated, but we can talk about maybe failure cases where if the authentication service is down, maybe we don't want to lose playback. I think that's a sort of business discussion, but we can leave that level of flexibility open here. So, um, Yeah, by having this sort of breakdown as well, we can scale different parts of our system differently, so we might need kind of different levels of caching or scaling depending on what each service does. So if we break this down and have maybe a library service here. So the library service is going to have maybe, like, get movies, Get TV shows. I want to say search, but I'm going to leave that off for a moment because I think search might actually be an interesting, service in its own right. So get movies, get TV shows, you know, like get genres, um I think would be a good service in its own right here, dear. Um maybe we'd want a database here as well. Et's see if we can draw one of those. There we go, have that going into there. So thats a library service, we'd probably have maybe a user account service. Here we could say, the user account service might have sign in, sign up, edit details, things like your name, profile picture, that kind of thing. Now, potentially we could say, Now, potentially we could say this has its own database, which I think might be true, but this would also be a moment. So we probably here I think we'd say it has its own database that would store things like your name, your email address, profile picture, details that are specific to this service for you. But I also think outside of our boundary here, we probably put the authentication provider we'd be using over here, as we said previously, we weren't going to build authentication. We'd outsource that so this could be something like Cognito or Google Firebase. And then we'd draw a Larrow here. That just takes that guy up there, like that. I don't know why we can't have an arrow with a bend in it, but never mind. Aurdr is there. What else do we have subscriptions and payments. Again, I think we'd have a subscription service, which would be responsible for understanding if you have a valid subscription for a user, get for user. And so that's going to store the status of your subscription again in its own database. Worse at drawing these each time. Again, we said that would be handled externally as well. So we'd have a payment provider like stripe up here for actually taking the money I think that's belt wrong. Provido. There you go. And let me just hand draw that arrow so I can go around the other stuff. So that would be that. And yeah, so I think that's probably enough. For now, we again have inside our system somewhere. We'd have the ingestion pipeline. I'll add it here for completeness again. That would be in gestion here where new movies would be uploaded and that would um add into the library service, uh the details of the movie, and then probably you'd want to store in some external provider, the actual movie storage, like that. And then I think the final bit we would want is a nice, simple web provider here, so thing like that. And then we go like we just sort like a web provider. Like that. So what are you thinking with this web provider? Yes, my idea here is that the actual client app that runs in the browser, the HDP, can just be delivered by a website here, we can probably put some level of quite robust caching in front of that. As it's just sabbatic pages, we can cache that quite heavily rather than serving it from origin every time, whereas some of the web requests specific for people can plow straight through, into our back end to get fresh data relevant for that user. We can probably pop that on our diagram here. Um so we could put a little cache here, something like Cloudflare. We'd just be delivering that traffic to our web user. Unfortunately, our mobile app is in the way. So it's just pop up. Actually, we said we actually, we will keep it. Changing my mind a bit here. So we'll move that down there. We'll pop our mobile app. There we go. Lovely. We lost the arrow there. We say let's rest. Cool. So then we've got a highly cashed HDDP request going up here. I was going to say that. How are you imagining playback itself actually works? Like I'm not seeing any sort of video player stuff here. Yes, for playback itself, I would imagine we would be delivering the files here for playback out of whatever storage system we've got them stored in, could be an on prem solution or some cloud provider. I imagine we'd probably deliver that through a content delivery network. Again, it's the files themselves are not going to change per user as long as the user has the relevant license for them. Um, so I'd imagine a CDN here, and that would be delivering video files like that into the CDN. And then they would be delivering those files to our clients down here, probably via HDP again. Those are specs that are in the way. Let me just move them. So kind of from an outside perspective, then, Nate, what's a full user flow you might see if someone actually coming to our service brand new for the first time and actually getting all the way to watching a movie? Yeah, so in terms like how a user would actually interact with the system, I'd imagine you coming to our website for the first time. We're delivering you the homepage, either from cash or from our web server up here. That's going to provide you with information on the service and details about how to pay and provide. And that service is going to be communicating via REST API up into our API gateway here. And that's going to be coming into individual micro services. So for example, when you create an account, you're going to be using the WebUI and then making a HDP request up here through REST to our user account service that will then register you as a user, storing it in our account provider, and then uh signing you in. Once you're signed in, you can access the library of films we've got. So you'll be making another rest request to our API, which would then be going into the library service and returning you those details. Once you've selected a movie to play, that movie object would contain some information about where to download it from. So I'm imagining some kind of progressive delivery HDP thing here. And you're going to make a request to there, which is going to come from our movie store via a content delivery network, who would probably cash it for you. How are you authenticating between these services? Yes, I imagine when you authenticate, you'll get a token back, probably a JWT token, which would be signed by us or our provider here. So when you are making requests to the library service or the playback service, you can make those requests directly, and they would be able to validate the validity of that token without necessarily having to come back and talk to your authentication service. How do you great scaling of the system? Are there any areas you want to address for? I think this would scale reasonably well, actually. We've got good levels of caching, so we're not really handling our movie files that much. Actually, the more traffic we get and the more people we get, the more our cachet ratio here would go up. This egress here is probably going to be one of our greatest expenses, but the CDM will help greatly there. Um, probably our biggest point of contention is going to be the library service, particularly if we include searching, which is why I left it out here. I imagine we could probably use something like elastic search to allow for more creative searching without creating large contentions on this library table here. But each of our services, as they grow, there's pretty good scalability here. So, um if we needed more more web traffic for loading the web UI, we could easily double these up, go for multiple instances. There's no state here at all, that's really that problematic, um, are things like our library service and our user account service, it's more challenging. The services themselves. We can obviously have multiple instances available, very easily without much issue. But then database scaling becomes a challenge in its own right. Then we're looking at having maybe geo local replicas which might be available in the countries of the peak customers we're having, so they're closer to the database, and we have more read databases available. That would particularly be useful in the library service where we are doing many, many, many, many reads. All of our customers are reading, but our only writes happen in our ingestion service, which potentially is happening overnight or is not necessarily required to update real time. So we could have that NSL some kind of replica that moves across and not w too much about kind of loading there. Cool. I think we've probably done enough for now. I've got a general idea. I think there's a few areas we could dig deeper. But I've got a good picture. So I think we're kind of done for now. So thank you very much for taking the time to walk me through this. Oh. Ow. 11. Now. About Your Behaviour[al questions]: Hello, again, you're almost done with this course. Now let's cover one final type of question in detail behavior questions. Depending on who you're interviewing with, these questions might appear in their own dedicated interview, but they're often scattered throughout other interview rounds, so keep your eyes peeled for them. Behavior questions aim to understand how you've handled various situations in your professional or academic life. They're not trick questions, another chance for you to show off how amazing you are. You'll know you're being asked one of these questions because it will sound something like tell me about a time when you when you're asked something like this, the first thing you need to do is breathe. Don't rush into it. Take a moment to consider the question. And if you need clarification, don't hesitate to ask. If you're early in your career, you might be asked about a situation you haven't experienced yet. In that case, be honest and tell the interviewer. You haven't been in that situation. They'll be happy to ask an alternate question that you can better answer. Whatever you do, don't make up a situation that you think they want to hear. They want real examples, not fictional stories. If you do have a good example lined up, I want you to try and remember the star format as you answer that situation, task, action result. Start by describing the situation you are in. What company was this at? Was it part of your academic studies, maybe? What were you building? What was your role? Now, what was the task you were working on? What was the feature? Then, what action did you personally take to resolve the situation? Finally, what was the result of your action? Did it go as planned? Were there additional actions needed? What long term changes did you make to prevent the situation from happening again? It's important to be honest with your answers. They're looking to understand how you actually handled the situation, not how you think you should have. Be sure not to misrepresent your contribution to the solution. If you had help from others, be humble and acknowledge that. You might be a little uncomfortable telling an interviewer about a bad story where something didn't go well or where you were somehow at fault. It can be tempting in those situations, try and sanitize the story, downplay the errors, and exaggerate your heroics. Employers aren't looking for perfection. We all make mistakes, and we know it. What they really want to know is how well you handle those situations after they've happened. Consider this for a moment. You have two identical candidates with a decent amount of experience. One has never made a mistake and everything has gone perfectly for them. The other has made a sizeable error, but identified it quickly, then worked to resolve the situation and took ownership of modifying the company processes to ensure it can never happen again. I don't know about you, but I'd rather have the second candidate on my company. They have experience dealing with issues and a proven track record of handling them well. Far from being off putting, this shows the candidacy is experienced and professional. So what does this mean for you? It means you shouldn't be afraid to talk about your mistakes. So long as you discuss them from a position of growth, this means taking ownership of the situation and explaining what you did both during and after the initial resolution to ensure it never happens again. After initial answers, the interviewers may ask follow up questions to learn more about your contributions or to clarify details. This is perfectly normal and doesn't mean you got the original answer wrong in any way. Unfortunately, one great answer is unlikely to be enough. They may ask you several of these questions. Each one will likely focus on a different aspect of your behavior such as how you collaborated with others. Just remember to keep using the star format and you knock it out of the park. See, it's not all that scary. We talked in detail about the main stars of questions that are likely to come across. Take a look at some of the bonus modules from quick fire tips on how to get the job. 12. So, Do You Have Any Questions For Us?: Hello again. Welcome. We've covered many of the questions you're likely to be asked during interviews, but there's one more important topic to discuss. At the end of most interviews, the team will ask you if you have any questions for them. This is your chance. I know it's a little cliche, but you really are interviewing them as well as them interviewing you. This is your time to speak to real people who work there, learn about their roles, and get a feel for the type of place it is to work for. When I'm a candidate, this is actually one of my favorite parts of an interview. Most companies are faceless entities from the outside, and this is your opportunity to chat with real people inside who make it run. You can learn about them, what they do, and how they do it. It's brilliant. Generally speaking, you're not being judged on the questions you're asking. It's not a trick to catch you out. When I interview candidates, I always make a point of closing my notebook and putting it to the side to show that I'm not making secret notes on their questions. That being said, you do want to create a general impression of being interested in the role and engaged with the company. I'd strongly encourage you to ask questions here, and the less generic, the better. You might have some practical questions that could influence your decision to work there, such as flexible hours to accommodate childcare or hybrid working arrangements. These are great questions to ask. Just make sure you're asking the right person. For example, if you're speaking to an engineer after a coding session, they might not know much about the details of the pension scheme. You may want to learn more about their technology stack, and this is also a fantastic opportunity to show off your fascination with technology. Be sure to listen carefully to their answers and ask follow up questions as they come up. You can also ask questions about the working environment, although be mindful not to put the interviewer in an uncomfortable position by trying to bait them into saying unpleasant things. Well, I'm not saying you can't ask what's the worst thing about working here. Be thoughtful about your tone when doing so. Other areas you can explore, particularly if you're interviewing at a startup or very small company, involve understanding the business and its future plans. This can be a great way to not only see if you get excited by their future, but evaluate the stability of the business for yourself. Before your first interview, take some time to jot down some questions you might have for them. Give it some thought and see if you can tailor the questions to that specific company role, technology or conversations you've had with them already. Don't be afraid to add extra questions as they come up during the interviews, though. Right. So what are some good examples? Could ask. I need to collect my children from school every day at 3:00 P.M. Are there any flexible working arrangements to accommodate this? Or how do you manage career growth, feedback and promotions for engineers? Or I see you're using MSCQOL. What strategies have you used to optimize your service for growth? Or you mentioned that you're planning to launch in six months. What's next after that? Like I said, this is an opportunity for you to not only get answers to questions that matter to you, but also have a little fun and learn about the people who work there. Here's some simple homework for you. What are the three best questions you'd like to ask a potential employer or have been asked by somebody else? Post them in the class for others to see. 13. Bonus. QuickFire Tips: Hey, we talked in a lot of detail about the different steps you encountered during a typical interview loop, and I know you're excited to go out and start putting everything into use. So in this bonus video, I'll give you my ten best tips for interview success. One, whether an interview is in person or by video, make sure you're dressed smartly, or at least the parts that are visible on video. Does that mean you need to wear a suit and tie? Almost certainly not. For most UK and US companies, business casual will be fine. That's a smart shirt, tidy jeans, and mud free shoes. But be aware of the cultural norms in the country you're interviewing if in doubt, nobody was ever criticized for being overdressed, but you certainly don't want to show up in a pizza stained t shirt and ripped jeans, creating the impression you didn't care enough to clean up. Two, when interviewing remotely, make sure your setup works, webcam plugged in, headset volume turned up, or the permissions in Kromenables, take a few moments before the interview to test it all. Most meeting apps will allow you to make a test call to try it out. Three, find a quiet place where you won't be interrupted and distracted. This will allow you to focus on giving your best performance and reduce background noise that may distract from the points you are making. If one of your kids walks in or the cat jumps on the desk, don't worry, though. We're all human. Laugh it off and let them see what an awesome parent you are. Four, don't be afraid to ask questions. Whether you want to clarify a question they have asked you or you're asking them questions at the end, being inquisitive and detail focused will always work in your favor. Five, read any information they send you in advance. Some companies will give a lot of information in the run up to a call. This might include details of their roles, their culture, or what to expect in the interview itself. Six, don't be afraid to admit you don't know something, whether it's a technical interview you're stuck on or you're being asked about something you don't know, be honest about what you do and do not know. Interviewers value honesty and willingness to grow. Seven. Have fun. No, really. How often do you get a chance to chat with engineers doing cool work at great companies? This is your chance to learn some cool new things. And if you relax and have fun, you really will see more confident. Eight, make some notes in advance. Before doing a behavioral interview, take a little time to think about and write down some good examples of things you're likely to get asked about. Times when you've collaborated with others, things have gone wrong or you struggled. Refreshing your memory now will make the interview itself much more slick. Nine, if you don't get a job, ask for some feedback. Often the interview will happily provide some areas that you might like to work on in future interviews. And finally, ten, keep at it. Remember, every interview is a stepping stone. Even if you're not successful, you can learn from it. As you get used to it, you'll be more relaxed and more confident. 14. Bonus. Help! I Didn’t Get The Job: Oh, this is a bummer. You've tried your best. You've polished, refined, and reworked your resume. You feel like you nailed the technical and design questions. You did your homework. You even ask some brilliant questions in return. You've just got the call, and they're unfortunately not gonna offer you the job. This really is an awful feeling and can be devastating to your confidence. Believe me, I've been turned down for roles that I was really excited for, and I thought I was a great candidate for, and it really knocked me back for a while. What I want you to know, though, is that just because they did not offer you this job does not mean they're rejecting you. There are many reasons why they may choose not to make an offer, and many of them are simply outside of your control. They may have had another candidate who was interviewing at the same time, who they felt had slightly more relevant experience, or they were looking for something very specific for their needs, and you just weren't quite the right match. What you need to do now is take a moment to regroup and reflect. If they've given you specific feedback, maybe there's something you can work on. Remember to listen and grow rather than get angry and assume they must be idiots for rejecting you. But like I said, it's simply outside of your control. So you need to regroup and try again. With patience and persistence, your confidence will grow, and sooner or later you will find the perfect match. Keep at it. I know it's hard, but you can do this. 15. Wrapup. Thanks and Followups: Wow, that was a ride. Together, we walked through the process of applying for a job from finding the right job for you to refining your resume and even how to approach some scary sounding interviews. I hope this course was useful to you and you've learned something you can take away from it. This shouldn't be the end of your journey, though. Growing your professional skills is a lifelong journey, and you'll never stop growing. If you want to continue learning, there are some great videos on YouTube of people doing full length real time coding interviews and technical challenges where we didn't have the time to cover here. So it's worth checking them out if you're brand new to the industry and want to see what others are doing. If you're looking for more tailored support for your resume, interview technique, or career growth, you may consider booking one of my one to one classes where we can spend time really digging into what you need. If you have any comments, questions or feedback, I'd love to hear it through one of the social links on the screen. Really enjoyed sitting down and writing and filming and editing this course, and I hope you got something from it. Thank you so much for watching.