How to Prepare for Technical Interviews

all right well hello world this is cs50's now annual workshop on how to prepare for technical interviews this is an opportunity that we hold traditionally on campus and nowadays also on zoom for students here at harvard at yale university as well as now anyone online who are thinking about pursuing summertime opportunities in the technology world or full-time opportunities after school or perhaps are pivoting later in life and are exploring computer science and programming and software engineering and want to ultimately move into that world this workshop is specifically on how to prepare for the kinds of interviews that you might encounter in industry it's one thing to take classes like cs50 or anything else that sort of prepare you indirectly for a foundation in software engineering and the like but it's another thing to actually ready yourself for the concrete opportunities that might be of interest to you at a tech company or really any other company at which you might be applying your technical skills so thanks to cs50's own tommy mac william who was one of cs50's former head teaching fellows today we should have an amazing workshop for you that should give you the mindset of how to go about preparing for interviews how to go about preparing your resume and really ultimately how about applying what you might learn fairly theoretically in school to the actual practical world of interviewing and ultimately working as well and wonderfully we're joined here by some of our other former and current head teaching fellows maria and connor so allow me now to introduce our friend and former colleague tommy mcwilliam who most recently worked at companies like quora.com and most recently his own startup serenade.ai tommy is hands down one of the smartest people and best engineers i've ever met indeed in preparing for today's preparing for interviews i got to thinking that i'm not sure if tommy interviewed me i would get the job uh and so it's always quite interesting to hear about the advice he has the types of experiences he's had because not only was he a former student and a former teaching fellow and now out there in the real world hiring and building software he's really seen it all and so i think we're fortunate to have not only him but also maria and connor joining us here today and so without further ado tommy welcome back to cs50 thanks dave it's always great to be back i love doing this interview workshop and helping everybody think about how to prepare their resume get ready for interviews do a great job interviewing and then think about what to do after that uh i think i've been on both sides of interviews i've probably done uh thousands of interviews as the interviewer i've also been on the other side and i've also bombed interviews myself so i know exactly how that feels and uh you know helping with this workshop and really helping hoping to help everybody uh just give the best interview performance they can and really demonstrate the skills that you have as an engineer so joining me today are maria and connor so i'll turn it over to maria to introduce herself as well uh hi everyone uh super awesome to be here and super excited for our session today uh used to be head tfcs50 for a few years back until 2018 uh since ben have worked at instagram as a software engineer and most recently is the founder of my own startup um called kangaroo and uh very excited to be here today um i guess tommy said i've also bought my very fair share of interviews uh have like some very clear memories of the ones i've bombed i've also been on the other side done probably hundreds definitely not thousands at tommy's level just yet um but the interview process is definitely something that um i'm eager to help everyone master so um excited to be here and i'm gonna hand it off to connor all right hi everyone i am connor i am currently a head ca for cs50 at the college uh and i am currently a junior at the college so i'm applying for internships for next summer 2023 or yeah 2022 sorry um and so i have been having several interviews a week for the past week so i'm right in the middle of it and uh uh just like other people have been saying i've had some of those interviews go very very well and some of them go very very badly so i'm really excited to learn more about how to help those go a little bit better than they could possibly and also to help all of you get started in interviews so today we're going to cover a few different things sort of the entire interview process from end to end so first we're going to talk about how to choose companies and pick opportunities that are great for you and where you're going to have a great experience next we're going to talk about resumes not going to spend a ton of time on this but just some quick simple rules for putting together a great resume then we'll talk a bit about how to prepare before a tech interview happens then we'll walk through during the interview sort of what's expected for you and uh as well as some tips and tricks for doing well in the technical interview portion itself and then we're going to have a couple mock interviews so one with maria and one with connor we'll sort of simulate an actual tech interview we'll use real questions that i've used in the past so these just aren't uh sort of rake you know fake random questions but these are uh real questions that you could see at a tech company we'll sort of go over some techniques there and then last we'll sort of wrap up with some things you can do after the interview and sort of looking ahead as you improve your interviewing skills so the first thing i want to talk about is choosing companies so there's obviously as you're looking around at internships and full-time opportunities there's so many companies and opportunities out there and so um what you want to do is help narrow that down into a small set you know nobody wants to be doing 500 interviews a month that's you're going to exhaust yourself it's tiring and so the more you can narrow down your selection up front sort of more efficient you can be in your interview process so i come up with here just four questions that you can ask yourself as you're evaluating the space of possible companies so the first thing you'll want to ask yourself is what are you looking for out of this internship or this full-time role so for some folks especially if you're early on in your career the thing you might be looking for out of an internship is you really want to maximize for learning you really want to go somewhere where you're able to have a lot of mentorship where you'll be able sort of in a space where that emphasizes learning and even failure as a learning mechanism and that might be different than somebody who's say is five or six years into their career and rather than learning they're looking for something to more of a leadership role or to be in a place where they can have more impact and take on more responsibility so i'll say that everybody here is is different you know you might have friends who are also interviewing and you know maybe what they're looking for is an opportunity in you know some specific city and they really want to be there and then you say oh should i should i go there too that's my friends are going no not necessarily everybody is is really really different and i think you know when i was interviewing in college something that i kind of got bogged down and as well as well i think i want this but you know my friends are doing all these things that are different so maybe i should do that too when the reality is that everybody is is really different and so just ask yourself you know what are what are your goals and what are you looking to get out of your next internship or full-time opportunity the next question that i would ask yourself is would you be excited to work with this team every day you know you're going to be in an internship or a full-time role you're going to be working with these people a lot on their mission and on their products a lot and so i'd make sure that you know you're you're as excited as you can be about that during the interview process you'll have a lot of opportunities to meet with different people on the team and hear their stories and ask them questions and that really is an opportunity for you to get more information about is this a team that i'd be excited to join is there a working style something that aligns with my working style their goals align with my goals so it's really a good opportunity to ask yourself that i think a similar question here is is whether or not your values align with the company's values so in many many many tech companies you can find on their website or on their careers page something with values and a value is is basically something that this company values more than other companies so for instance a company value might be something like uh an early facebook one was done is better than perfect you know and what that communicated was that you know we're not a bunch of perfectionists you're if you're look if you're the type of person who wants to get everything perfectly correct and be super pedantic then this isn't the company for you because we're the type of people who are going to get things done uh just as much as they need to be sort of maybe 80 of the way there and then ship it and iterate and get feedback and that value isn't necessarily good or bad it's just sort of something the company has decided about their own workflow and so you can look at that company values and can compare that to your own internal values and say is this going to be a good fit for me the last thing to ask yourself is whether or not this company's size matches what you're looking for i think i've talked to a lot of candidates in the interview process well ask them what size company you're look are you looking for and they'll say i don't know it doesn't really matter i could join a four person company or i could join a four thousand person company uh and the answer is it does matter like that's a it's maybe a bad answer to that question since your day-to-day experience at a four-person company your day-to-day experience at a four thousand person company they're just going to be really really different no matter how much the large company says oh we're just like a small team or no matter how much a small team says but we're really organized and stable like a large company the reality is it's just there's some things that become possible and impossible at various company sizes so this is a this is a chart that i that i really really like it's i think it's originally published by dustin moskovitz at asana but kind of breaks down startups into these three different categories based on how many people are there so you can see at a small company you know mentorship doesn't really exist you sort of people help you as you need it but there's no sort of formalized internship program um you know your autonomy is just sort of like whatever you got to do like you figure out what you have to do and then you go and do that could involve wearing a variety of different hats being in a variety of different roles and then on the other end of the spectrum is a large company where you're going to be hired into a specific role onto a specific team where maybe you're a back-end engineer hired onto the infrastructure scaling team for the machine learning at this company which is much more narrow you know your your agency there is you're going to have much more clear goals set by the team set by management so it's very much not a just figure out whatever you need to do and then do it it's going to be here's our team's goals for the quarter here the metrics we're trying to hit here are the projects that we think are going to make those metrics possible and mentorship can be much more formalized you might be assigned a formal mentor on your first day have a variety of different support systems internal documentation things like that and again something i really want to emphasize here is that there is absolutely no right answer everybody is really really different and as your career progresses what you're looking for might even change over time so definitely don't look at this chart and say oh the small company is the best or the medium companies the best it's more about what's the best for you not sort of the objective correct answer for what to do after you graduate college or what to do as the second company you join in your career you'll probably read a lot of blog posts on the internet claiming there's some objective truth here but i promise you there is not and so it's more about reflecting on what you're looking for yourself so that's it on choosing companies i think really the takeaway here is just spend a little bit of time up front narrowing down your search and also reflecting on what you're looking for personally as we'll see later a really common question and interview is what are you looking for and why would you want to join this team and so the more you can reflect on that up front the better you're going to do on on those types of questions so next we're going to jump into resumes and the first thing i'll say about resumes is they are not that important so a lot of people spend a ton of time agonizing over should this be a m dash or a semicolon in my resume which is going to get me the job the answer is that it doesn't really matter that much i think on average we've talked to a lot of recruiters i've been a hiring manager myself i'd say the average amount of time i spend reading a resume is about 30 seconds and so as you're creating your resume really really optimize for that the person reading this is not going to spend more than a minute or so reading it and so what i've done is i've created these 10 resume rules that are all pretty simple as long as you follow them you'll probably have a pretty good resume but before i jump into my rules i'd love to turn it over to the audience and hear what are some resume tips that you've heard in the past tommy martin mentions one page jessica notes that resumes mean a lot in south africa anna proposes that it be easy to read johnny mentions keywords uh rocky mentions targeting for the job nassar mentions concise jessica also notes to add skills in it abhishek echoes the sentiment that it should be one page keep it plain says pamika moaz says one page also nothing too colorful concise and clear not to make it too long skills at top focus on the role you played tech stack on top clear font has to be concise i think we can keep going and going here yeah lots of lots of great advice there i love the a bunch of people piling on the concise simple and often takes the form of one page i think if i had to give one piece of advice it would be that as well um so here are my my 10 rules that as long as you follow these your resume is going to be in good shape so number one one page no exceptions uh there's a lot of folks you know and again this is going to vary a little bit by by role so i guess my here's an exception to my no exception uh you know if you're in academia for instance a really long cv is much more common but if you're looking for a typical tech job of one page and don't don't make any exceptions there you know the the author of python the person who created the python programming language you know he used to be at dropbox and at some point he published his resume and just said oh here's what mine looks like and his is one page and so if the person who created the python programming language can put all of his achievements and skills onto one page so can you number two i think folks mention this as well is make it really easy to skim as i mentioned the person reading this resume is they're not going to spend hours pouring over every little detail and so if you make it really hard to find key information like what is your name what is your email what roles have you had in the past what are your technical skills if that's hard to find on your resume they could just end up giving up on your resume and not sort of taking the time to try to find it so keep in mind the person reading this they're trying to go fast make it easier on the reader of your resume to find important things number three make your contact info obvious i've had resumes in the past where i've said wow this is great some recruiter just passed it along to me this resume looks great no way of contacting the person on the resume there was no phone number no email no link to a portfolio anything i was like okay now what do i do and the recruiter had to go and track them down which was which was a pain so the whole point of your resume is to get in the door and start the interview process so make sure it's really easy for the company you're applying to to actually reach you number four you want to highlight specific accomplishments the more specific and concrete your resume can be the better so rather than having a line on your resume like improved company metrics it's really vague what are the metrics what has improved mean and proved by how much as much as you can be specific on your resume a line that said you know improve the performance of our critical machine learning ranking system by 23 by implementing back end optimizations like improved caching that was super specific i gave a metric i said what the system was i said what i actually did there the more specific you can be the more that a recruiter or a hiring manager can understand what your actual impact was and that often reflects well on you i will say that some companies will have non-disclosure agreements where you might be working on a project that hasn't launched yet or some metrics might be confidential and internal to the company so certainly don't break any of those non-disclosure agreements but many times metrics you know of the form you know improved performance or scaled some system to some number of users those are the type of things that are that are typically public and that you can put on a resume if you have any doubts you can also just ask your manager or someone at the internship you're at just say hey is my this is my resume is it okay if i disclose this particular metric next definitely include interesting personal projects say especially for folks who are a little earlier on in their career and might not have experience at multiple companies yet definitely include personal projects that you've worked on maybe that could be an interesting final project for a course maybe it could just be something you built in your spare time but it's something that that's great to highlight to show that you know you have a lot of passion for what you're doing and you know show off what you're capable of building i will say i'll caution against uh if you're able to have a project that's a little more unique and something that you designed yourself compared to you know many courses have a final project that everyone builds the same thing and it's kind of standard uh i would highlight something that you created yourself rather than some kind of standard final project if you're able to but if you're not that's okay too something here is certainly better than nothing next no charts or ratings this is maybe my number one resume pet peeve a lot of people have on their resume you know some you know chart that says you know i'm like a 5 out of 10 not javascript and i'm a 7 out of 10 at css uh to me this is just a total waste of space and i have no idea what your 7 out of 10 at css means like is the inventor of css a 10 or someone with three years of experience at 10 it just makes no sense a lot of people you know try to do this as a way of you know kind of creatively experience expressing their tech stack i really don't like it at all and it uh doesn't communicate the information you think it's communicating more likely than not next i would not have a specific objective on your resume many resumes i've seen have at the top some objective that says objective colon to secure a spot as a software engineer able to have impact on this company it's a total waste of space we know that the re you know the objective of you handing me a resume is to get a spot at the company that i work at so it's a total waste of space you've only got one page to work with putting that there doesn't really offer a lot of value again there might be some exceptions here in different industries where maybe it's not actually clear what role you're applying for but in the case where you've gone through some sort of online application that says here's the role i'm applying for or you're talking to a recruiter and it's really clear what role you're applying for don't waste space with an objective on your resume number eight use a professional email address uh i remember one one resume i got i forget what the person's name is and they said it was their name one two three four five six seven eight nine eight seven six five four three two one and that was the email they used and i was like you've gotta be i instantly think less of this person because this is their email uh if you're still using the same gmail address you used and you know 20 years ago just create a new one first initial last name is great last name first initial is great your full name is great super easy to create a professional looking email using gmail or free email service definitely do that don't have some kind of cute joke email number nine include relevant links if you have them so if you have a linkedin a github profile a personal portfolio especially if you're sort of applying for a design role include them on your resume i think sometimes a hiring manager before they interview you they might you know spend a quick 30 60 seconds skimming through your portfolio so you have something to talk about during the interview you know i've certainly you know clicked on someone's github saw you know oh like they created this library for progress bars of the command line that's kind of cool and i'll ask them about that during uh during our interview so that that just sort of helps your interviewer understand a bit more about your background and last uh definitely don't sweat the aesthetics and the visuals of your resume and many times simpler is much better simpler is often very easy to skim but don't worry about things like colors and photos and fonts just you can create a really simple resume that gets your point across without having to worry about all of that so next i have a couple example resumes and i'd love to hear from folks in the audience things that are good and bad about these resumes taking into account these 10 resume rules and i will note that these are fake resumes these are not real people so we're not roasting anyone on the internet right now so here is the first one what do people think what is good and bad about this tommy the answers are starting to fly in here uh the skill graph is commented on ratings are bad too hard to read the skill bar the rating bar is too much at once in all caps bad in a word hard to find information charts and ratings are bad using charts two columns are good more used space font charts bad all caps bars skill bars equal bad hard to skim progress bar must not be included bad in all caps i think i'm now encouraging it and there seems to indeed be a theme developing yeah so i'll go i'll go through a few things about this um so the first thing i like about this is that under the work experience and education it's pretty easy to skim there so i can see they worked as a data scientist for some reason in the two work experiences they changed the order of the role and the company so that's a little weird um but otherwise i like that it was really easy to see what their experience was where they worked the content of the resume here i'd say it's reasonably specific i'd say you know saying that they collected and studied interpreted large data sets to develop new forecasting models i think that's pretty good i'd say the part i'd make it a little more specific is if you can be specific about how big the data sets were or exactly what you did to analyze them i think that would make this a little bit better but i just call this reasonably specific this profile at the top this top left i think this is a waste of space you know saying that there are highly accurate and experienced data scientists and i look at here and they have three years of data science experience so i don't i don't need to be told how experienced you are i can sort of look at this from the resume so i don't think that's a good use of space and then yeah i included this one on purpose because it has charts uh i don't really know what these charts mean i don't know if you do either but this person looks like they're a they're a fantastic team player but they don't have attention to detail and so i look at this say well do i want somebody to have attention to detail being a data scientist i don't know i'm not really sure this this communicates with what they wanted to communicate uh if this person were a real person can i relay a couple of questions now from the chat uh sergey asks a question about the cv do we need to adapt content and keywords for ats application tracking systems yeah that's a good question um so many in many companies they'll have what's called an ats which is as you mentioned an applicant tracking system so it might be lever or greenhouse just some software that you apply to and some of these will kind of look at your resume and filter out for keywords and say you know if it doesn't have the word javascript throw in the trash um so i wouldn't go overly you know i wouldn't go crazy and trying to you know put every single keyword on your resume um but at the same time just having a short list of you know languages you know or technologies you've worked with i think even i have this on my resume just sort of listing out the languages you've worked with in the past if you wanted to have you know a little bit of you know you know a little bit of this or proficient with this language or i'm new to this language or something maybe a little bit of that is okay but in general just having a quick list that doesn't take up a lot of space is what i'd recommend and tommy another question was asked which might vary i imagine by country uh pravalika asks should i add a photograph to the resume yeah this this might vary by country i i would say that if you're applying to a u.s tech company i i wouldn't do that uh just sort of falls into the same category it's uh it's a waste of space you can probably change that photo and put much more detail about the impact you had at an internship or a company but again this is gonna this is gonna vary a bit by country and hard for me to speak to uh too much outside the us but in the us i would i would definitely not do that okay i'll continue to chime in tommy as more questions arise awesome so let's uh let's jump to the next resume things about this that are good and bad and as the comments start to come in tommy too long verbose too convoluted too much text it's a dissertation unstructured is that a page from a novel question mark hard to read hard to skim looks like a wall of text your school email will eventually expire so i wouldn't use that hard to read very hard to read hard to skim it's too much and there seems here to be a theme in fact jose perhaps says it's best t-l-d-r too long didn't read yeah i think that's that's sort of the same reaction i have here i'll start with the things that i like about this um this sort of middle section here where it says core expertise um i actually like this you know if you were this is sort of an engineering manager and so their their expertise here might be a little bit different but seeing that they have you know experience in vendor relations or um you know global projects and managing different time zones that's pretty interesting if you're an engineer a data scientist a designer this is probably where i'd put your languages or technologies you've used in the past but this is actually kind of a nice way of maybe the only part of this that's skimmable but this is a reasonable list where i can quickly skim but yeah my main feedback on this resume is basically what everyone else mentioned is that there's just so much text here the font is is really really small it's not really skimable to find the companies they worked at is shockingly difficult even though they're in all capital letters it's pretty hard to see excuse me where you get where they actually worked a good thing is that their name and the contact information right at the top that's nice but then again this sort of top section here where they're writing you know merging visionary leadership with technical software engineering expertise my reaction is like okay i don't need to have that it doesn't really add any add any value so that that section at the top could be removed in favor of making this a little bit easier to skim uh not having so much text crunched in here so i'll pause for any questions yeah some questions came up from remington if i'm a non-cs major what would be the best way to add courses such as cs50 to my resume and perhaps massive open online courses outside of college more generally yeah that's a great question i'd put it in that same section where you know languages you've used technologies you've used courses you've taken especially for undergrads or even people making a career shift where they don't have a lot of that experience yet you know we'd love to see courses especially online courses to sort of show that you've taken the initiative and you've gained some certain set of skills so i remember when i was an undergrad i had you know i had basically like name contact and then languages i know courses i've taken you know i'd say cs50 introduction to computer science yes 61 systems programming and um since the course number might not mean any something to anybody so just sort of you know highlighting the courses you've taken as an undergrad can be great and tommy a couple of folks pragya and akin have asked about tools to use when writing a resume should they use an online resume maker latex microsoft word something else yeah i would say to use what you're most comfortable with uh you know i was a pretty big lake tech person in in college and so i was a big fan of that and so my resume was was used in that but i wouldn't recommend like oh i'm going to learn some new tool just for the purpose of creating this resume since you might end up might be harder than a tool that you already know so i'd recommend uh just sticking with what you know already uh if you don't know anything yet even something as simple as google docs can produce a pretty good looking resume and a formatting question two a few folks have asked about two columns versus one column and the use of color or graphics your thoughts there too yeah a little hard to give a kind of a blanket answer there i would say you know take take the write the content of your resume first you know the first thing most important thing is the content where you work highlighting those specific achievements you know listing out those those key skills you have so do that first and then you know try a few different layouts i think people with you know a ton of experience or a lot of content might you know land on a different layout than somebody who is just getting started and doesn't have as much of that yet so i would say you know look try a few things see what looks best for the content that you have but if your resume is starting to look something like this just sort of this wall of text then i would take a step back and reconsider perhaps one final question right now amalgamated from harsh and kyle who asked questions along the lines of should your resume be job specific or applicable to any role in tech and if someone has unrelated experience for instance from chemical engineering should you or how should you include that on a technical resume yeah that's a really great question um so i've i've seen the spectrum here i've you know when we were at quora i in and also at serenade new i've seen resumes that are literally like for serenade like people who will talk about explicitly serenade their uh their background and why it's the right fit for exactly our company um i'd say you you can do that you don't need to i think if you're applying to 10 20 companies doing a good job on 20 different resumes is a lot harder than doing a good job on one resume um so where i where i would make it specific is is for the role not the company so if you're applying to an engineering role try to put as much engineering related experience as possible if you're you know if you're applying to a design role and your resume just has a bunch of back-end engineering stuff you know i don't i don't know if that makes a ton of sense i'd try to put in some design side projects you've worked on or courses you've taken or projects you've built and then the question around unrelated experience i think i'd say it depends i think for some people they've had a career and let's say i think you mentioned chemical engineering and they're looking to make a career transition into another industry if that's the case then for sure you know show the experience you have show the the impact you've had at companies and you know make it clear to the recruiter or make it clear to whoever you're talking with at the company that you know you are making a career pivot you've worked in this field for you know some time and here's why you're looking to make this pivot and here's what you're excited about but definitely don't you know submit a blank resume just because the experience isn't exactly in that precise field um at the same time i think if you're you know sort of earlier on in your career and you're an undergrad you know i wouldn't just sort of put every club you've ever joined and everything you've ever done on your resume i'd try to keep it focused to um the role you're applying to so i guess my answer is a little bit different if you're sort of had a career that's several years and you're looking to make a pivot versus you're just starting to graduate college and start to break into tech we have an infinite supply of questions but why don't we let you go on and i'll weave them in over time for sure and we'll make sure we'll save time at the end as well so that's it on resumes like i said their uh resumes are really just a tool to get your foot in the door when i say they're not that's that important that that's basically what i mean is that i've never been in a in a meeting or talking about a candidate and saying well they really didn't do well in the interviews but their resume font was just so perfect we've got to give them the job so when i say they're not that important i mean once you're in the door your resume no longer matters obviously your experience does but the specific typeface on your resume doesn't matter anymore so that when i say not that important just to be just to be clear i don't mean spend no time on it but i mean that's the extent to which they matter is that they're getting you into the interview they're not going to carry you through the whole interview process so next let's talk about what to do before the interview so the first thing i want to talk about is what to expect so with timing it's always better to interview early so especially if you're still in school whether it's an undergrad or a grad program try to interview as early as you can to put concrete numbers on this for a summer internship starting in may or june people interview as early as the previous summer so i've interviewed people in august of you know august 2020 for an inter for an internship starting in may 2021 i'd say the peak season is around october november of that year for that following summer internship or falling full-time opportunity so as much as you can if you can get into that wave that's great if you can't for some reason you know something comes up or coursework is there and you have to interview you know in let's say february or march for a role starting in in june or may it's still possible but uh keep in mind that some companies might fill up their internship class it might be harder to get a role once a lot of people have already accepted their offers there so if you can interview early if you can't it's not the end of the world also especially if you're in school plan interviewing into your schedule i'm not going to say try to take some easier courses the same time you're interviewing but if you were to do that that wouldn't hurt your interview chances it can be really hard to just assume interviews are like oh it's you know interview isn't just an hour you're going to spend a lot of time practicing the hour is going to be emotionally draining you're going to be exhausted after that so just make keep in mind that interviewing takes a lot of time and don't sort of think of it as just a couple hour long meetings you have to worry about and the last thing i say is is look for opportunities that are geared at your experience so in particular if you're you know only taking a few cs courses you're a freshman or sophomore maybe if you know early on in your cs career there's plenty of internship opportunities out there for you especially at larger companies like google facebook microsoft they have programs explicitly designed for people who just have a few years of experience so look out for those you know don't apply for the you know senior manager tech lead role if you only have a year of experience try to find the role that's designed for you um you can find these just by looking at the job description they'll often say we're looking for three years experience we're looking for 10 years of experience we're looking for zero years of experience you know even if you have 2.8 years of experience and it says three like you know still apply for that but just you know if you have two years of experience and looking for 10 that's probably not the right role for you so next just a bit on the process so every company is going to have a different process but these are the things you can probably expect so the first is some online coding challenge so many companies as a first step they'll send you over they'll send you a link to some site where you can go on and solve some coding problem maybe it's timed maybe you're allowed to run your code before submitting it i've had things that are just like a google doc like here just write your code in this google doc and whenever you're done just let me know see a pretty wide spectrum here but that's often a first step and they'll be really clear with you around what the time limits are if you're allowed to use external resources or not and if they're not just ask whoever gave you the challenge what the what the constraints are the next is a take-home interview so this will usually take the form of you know here's some larger project to build maybe you're supposed to build it in two hours maybe they're supposed to build it in in two days it's going to vary but we'll usually be a bit more on the practical side we'll be you know write a write a little command line app that takes this as input and outputs this or write a little web application with a login functionality or something like that so that's another interview type you might expect the technical phone screen i'd say is probably the most common early step in the interview process where um this is what we'll spend the most time on today's technophone screen and on-site uh where technical phone screen is often you'll meet with someone over the phone or over video for an engineer or designer data scientist at that company and those you'll do some technical questions together we'll ask you to write some code to solve a problem and you'll share your screen and write that code and then lastly on sites pretty similar to technical phone screens often many on-sites are conducted remotely so you just do this over video which makes it almost the same as a technical phone screen um the difference being an on-site you'll probably meet with a wider variety of people solve a wider variety of problems you know maybe you'll do something that's more design oriented rather than just writing code and we'll sort of go through those but these are sort of the four types or sort of four interview settings you can reasonably expect in the interview process so next i want to go through some expectations of you so before i give you mine sort of as an interviewer what i expect of you i'll turn it over to the audience what do you think your interviewer expects you to do in an interview be honest says colleen tommy talk says jacob communicate well is a theme here too good communication skills to behave professionally says aisha be precise clear communication being honest another theme don't say um too much specifically ask questions to clarify to know enough about the company dress up professionally being smart smile ask questions research the company explain your own projects well good info about the job applying because those are all those are all really good ones i think in particular around communication is maybe the most important thing uh being able to communicate fairly what clearly what you're thinking how you're approaching the problem is super super important so i have a few more specific ones here um so the first thing that i'll be expecting you to do is in this related communication is be able to think through a problem so the whole point of an interview is that i'm giving you something that you've never seen before that's sort of by design because what i'm looking for is understanding how you would think through this new challenge and how you would tackle some new problem that came up if we were working together so that's the first thing i'd expect is your ability to think critically and think through a problem second maybe this is obvious is maybe why nobody said it because it's so obvious but be able to write code that works uh sometimes that code might not have to be exactly correct uh depending on the interview maybe some interviewers are just looking for pseudo code rather than perfectly functional code your interviewer will tell you what they're looking for here but looking for you to be able to write code that works i think if i if i ask a question that um you know you can only describe like oh here's how i would do it and i said okay let's write some code and say i don't know how that you know that's that's not great uh it happens more often than you might expect but being able to actually write the code for the solution is something i'd expect next thing is i expect you to be able to fix issues so oftentimes when you're writing code there are bugs being able to fix those bugs and even better is identifying those bugs yourself um but being you know not relying on the interviewer to say okay here's your code here all the things wrong with it and here's how i'd fix them instead being able to identify problems with your own code and fixing yourself is something i expect um reasoning about runtime is really important so if i say you know okay this code looks like it works how fast is it being able to answer that question is is important you know there's you don't have to do this sort of like oh there's always fancy math that you you know might want to do or like write a proof uh really just looking for you know is this linear is this polynomial not anything much more fancy than that and the last one which everybody mentioned is communicate really clearly so we really expect you to whether or not you're right or wrong be able to communicate what you're thinking and why you're thinking that way and make sure that i as interviewer can understand you so next just some types of interviews that you might run into so the first one is the algorithms interview so this is an interview where the solution to the problem might only be like five or 10 lines of code but the challenge is figuring out the algorithm and behind those 10 lines of code so the oftentimes in the interview you might spend like 20 or 30 minutes like talking through cases together white boarding and thinking and then once you see the algorithm the process of translating that algorithm into code is is usually pretty simple and you can just do and sometimes the interviewer might be like okay great let's just go through this really quick because this the interesting part is over because you've you've figured out the the algorithm the opposite of this is a coding interview where the there isn't really any fancy algorithm or any fancy trick it's just sort of like hey we're going to write some code to solve a problem that code needs to be really clean you might be writing 50 to 100 lines of code and factoring things out into functions where the code you're writing might be straightforward but there are some interesting design challenges or how you'll structure the code and i will say with these two your interviewer will probably not tell you up front like hey you're in the algorithms interview now but many times behind the scenes companies actually do do this when they design an interview loop or sort of your sequence of interviewers they'll say okay the first interviewer you're going to ask an algorithms question second interviewer you're going to ask a coding question third interviewer you're going to ask something else so you won't probably won't be explicitly told this but you can probably tell within the first few minutes which of which kind of interview type you're in but the more important thing here is for our purposes just making you aware that these different types of interviews exist if you find yourself writing five lines of code and you think you solve a problem that might be right if you find yourself writing 150 lines of code to solve the problem that might be right too next is a practical interview so these interviews are intentionally designed to be more like real world situations so rather than you know whiteboarding some solution to some problem that you probably wouldn't actually run into on a day-to-day basis these will be you know write a web application that implements a to-do list you know maybe you're you're applying to asana which you know is a software that helps you make to-do lists and they ask you to write a to-do list application it's much more practical right because it reflects on the day-to-day work you might actually be doing so that's another interview type that exists another one is systems design i'll say that these are certainly more common for folks who are more experienced and have designed you know scalable large systems before but these will often take the shape of you know let's say that you are designing the back end for google calendar tell me about how you would do that and then the question ends and it's your job to say okay well first let's talk about the database here's the the database tables i'd create and now let's talk about the the tech stack i would use um and these are often really really open-ended on purpose because there is absolutely no right answer the sort of the the goal is to just have a conversation with your interviewer and sort of go through the the process of creating some system together so say i would say worry about this the least especially if you're earlier on your career because these are often targeted more at folks with more experience but not crazy that that you would get one even earlier on in your career so just just be aware that it exists but i'd say worry about it the least and then last is a culture interview so this will be an interview or at least one interview where you'll write zero code uh you'll just talk with somebody maybe they're a hiring manager maybe they're from hr maybe they're not they're just some person that you'd be working with on a day-to-day basis and they'll ask you questions about your prior experience things projects you've worked on in the past internships you worked on in the past you know maybe they'll ask a question like when you're at this company what are some things that the company did well and come things you wish the company did better or uh what are some of the biggest mistakes you made or what are the biggest things that you learned while you're at this interview um and so the way to prepare for these is really just reflect on your own experience before the interview be ready to talk about if you you know worked at google last summer be ready to talk about that talk about the projects you worked on talk about the obstacles you overcame talk about the team you know don't be caught off guard if someone asks you you know how was last suburb you're like oh i don't know actually i'm really reflected on that uh it's really easy to just take some time reflecting on you know your previous experience and also what you're looking for next that's sort of the other half of these questions will be what do you want out of this role what are you looking for and remember those questions that we started with questions to ask yourself for the interview if you're asking yourself all those questions you're probably going to be ready for that part of the culture interview because you've already you've picked this company for a reason and so you're ready to answer tommy a good question that came in was from sarah how do you act if you can't solve a problem or can't write some code this scares sarah a lot it's a great question i've i've been there i think probably everybody has been there so i would say that if you get a question you're not sure how to solve it well i'll say most people you know when they first get the question are not sure how to solve it and so we'll go through this but the techniques are really about thinking out loud going through your thought process you might not be exactly sure but you can say something like okay well uh you know we know this list is sorted so let's think about the different algorithms for searching a list there's binary search would binary search work here well let's see and just sort of think out loud like that and if you hit a wall which you might hit a wall um hopefully your interviewer will sort of be proactive about guiding you along and giving you hints but sometimes you just hit a wall and your interviewer is just kind of staring at you and you can just say you know i'm honestly not sure what what to what to think about next can you give me a hint or can you help me out um that's much better than just sort of spinning your wheels and just sort of like staring at the wall in silence awesome so going back into uh preparing for interviews so definitely don't go into interview cold you know always you know do some practice problems beforehand the prep the amount of preparation you put into an interview really really makes a big difference in your success some people go so far as to say that interviewing is really just a learned skill nobody is good at it by design everybody just the more you practice the better at it you get and it's just the skill that you can have by practicing it so we'll definitely say that the more you practice the more that is probably going to decrease your stress in the interview as well everybody knows interviewing is you know it's really stressful it's scary there's a lot of anxiety the more you've practiced in advance and the more problems you've seen the more times you've been in this situation with somebody asking you an unknown question and having to think out loud and type the more you've done that sort of the more used to it you get and hopefully the less stressful it becomes so definitely do a lot of that in advance the second thing i do in advance is pick a language you're going to interview in and then do all of your practice in that language so let's say that you like python great learn python really well you shouldn't have to google how do i reverse a list in python or how do i get the length of a list or how do i create a class if you have to spend any time thinking about that just create stress for you right like you just want to have this totally down cold don't even worry about you know how to create a set in python because you've just memorized it in advance and i would say that you know choose one language maybe two for some reason if you know maybe you want a backend language in a front-end language but you should never be in a situation where an interviewer asks you a question and your first reaction is huh what language should i want to use to solve this just have this down already and be ready with a language so some things that you should know how to do in whatever language you pick one is create a function again this sounds obvious but you'd be surprised how many people i've interviewed who the first thing they asked me was how do i create a function again or they had to google how to make a function should just know this in advance similarly for defining a class you might not you know use a lot of object-oriented programming but sometimes it can be helpful depending on what language you're using to have a class to sort of represent some object or represent some collection of data so just know how to do that in advance a lot of interview questions are string based and so when i say work with strings i mean how to create a string how to concatenate strings how to index into a string how to take make a string uppercase or lowercase how to get a substring sort of all these different standard library operations with strings just just know them again the more you have to think about like is it dot size or dot count it's just going to make you more nervous it's going to create stress for yourself and knowing all the stuff down cold in advance can just make your interview go a lot better same thing with lists many many interview questions have take the form you're given a list those are the first first four words of many interview questions are you're given a list and so just being able to be aware of all these different list operations like list slicing or concatenation or removing indexes or pushing and popping all of the all of those operations you might do to a list don't want to be asking yourself is it push or is it append i forget just know that same thing with trees another really really common interview question is you know you're given a binary tree uh you're given some sort of tree just do some sort of traversal on it so being able to write depth first search or breadth first search even create a tree in whatever language you're in just knowing how to do that in advance is going to save you a lot of trouble so next around complexity we mentioned that many interviewers will just ask you after you've written code what's the complexity of this code it's pretty rare i'll say it's not impossible pretty rare that you know the complexity they're looking for is n cubed plus n factorial over something it's usually just going to be is it linear is it polynomial is it exponential and that's probably it so being able to have these down cold is really really helpful whether something's constant log linear polynomial or exponential just knowing these these five and being able to identify is your code one of these five that's going to get you through the vast majority of what interviewers are looking for when they say what's the complexity of your solution so the next thing i'll say is to build up your toolbox so many many many interview problems are kind of fancy ways of phrasing or framing the same few core concepts so here are a few so one is recursion or divide and conquer basically taking some large problem being able to split it up into smaller sub-problems and then solving those smaller sub-problems so as you're doing practice problems be really familiar with recursion and i think recursion is something that for many people is really scary especially if you're early on so if it is scary for you just practice it you know you don't want to be caught in a situation where you get a problem that is probably should be solved recursively but you're uncomfortable with recursion so the more you practice it just the more comfortable you're going to be definitely don't be put in that situation because you know you just didn't want to practice recursion next one is graph searches we mentioned this with trees but many problems just reduce to just model this thing as a tree or a graph and then just do a search over that tree so being able to practice writing depth first search or breadth first search just do it a few times in advance make sure you're comfortable with it greedy algorithms is another one you know as you're sort of looking around at interview practice problems this is often a category so just being able to practice these and recognize when something might be there talked about strings as just many problems are just string manipulations at the end of the day so really as you're practicing you should be building up this toolbox as you go and just be familiar with all these concepts and then searching and sorting is another really common one how do i sort this array efficiently given a sorted array how do i search it efficiently and dynamic programming this one's a little more advanced but if you're taking algorithms classes dynamic programming is basically a way to speed up algorithms and sort of cache the results of problems as you're solving them so some tools you have at your disposal um so as you when you get a problem you should really think about what what tools do i have what sort of core algorithms do i know what are some core data structures that i know and then try to pattern match which of these data structures or algorithms fits this problem so one is arrays or linked lists be really comfortable using arrays understanding what a linked list is and understanding what problems should fit into a linked list or an array hash tables another super common one you can sort of ask yourself okay given this problem can i model this as a hash table does that therefore like instantly speed up my runtime binary search is another one any many many many problems that take the form of find x or you know given a list look for something can be reduced to a binary search problem so just be aware of that and maybe that should be your first your first check if you get a search problem is can i model this as binary search shortest path algorithms are another one i think you know given that we mentioned these a few times but given some tree how do i search through that tree efficiently and memoization which is similar to dynamic programming but can once i've solved the problem can i reuse that solution to solve some larger problem and we'll go into some examples of this once we get into the mock interviews so some more general advice as you're practicing try to really simulate the environment accurately so something i that i know i do and i'm practicing is i sort of look at a problem and i'm like oh yeah i think i can basically see it and then i'll look at the answer and be like oh yeah i could have done that but then if i try to you know force myself not to look at the answer i'm like oh actually i don't see it at all so really really simulate that environment accurately if you know your interview is going to be 45 minutes put a 45 minute timer on your interview if you know the interview is going to be on a coder pad or it's going to be on a whiteboard practice on a whiteboard or pen and paper and as you're doing that practicing look for patterns everybody's different some people are really great at recursion some people are really bad at it so if you've done 10 practice problems and you found that you got them all right except for the three recursion ones go practice more recursion uh everybody is going to be different and what they're what they're skilled and not skilled at and so really look for patterns in your own approach and then lastly if you can practice with friends you know it can be fun to sort of be you know go through practice interviews with you know you being the interviewer or your friend being the interviewer on you sort of going through that problem what this does is just simulates the environment and makes it even more familiar so that once you're in that situation of being on a a real video call writing real code on a google doc it's not the first time you've done that you're sort of used to it it's really familiar to you so now some tips for during the interview so all of that was sort of what you should do in advance preparing for the interview and so now we're going to jump into the google you know the google meet just started the zoom call just started what do we do so throughout this what i really really want to emphasize is that the most important thing for your interview is your process not your output i've been in many interviews where the person did not get the correct answer but we hired them and many interviews where the person did get the correct answer and we did not hire them and the reason was their process was significantly more important if you can demonstrate that you're thinking really critically and that you're able to reason through a problem and find issues with your solution and optimize it even if you don't get to a perfectly correct answer that's so much more important than somebody who isn't able to communicate who isn't able to think critically but is able to write correct code just because they've seen the problem before or they got lucky or maybe they didn't understand the problem but their communication wasn't there and so you know it isn't something that you want to hire onto your team so throughout all this really really emphasize that it's not the most important thing to get the perfect answer but obviously helps but your process is so much more important than what you produce so the interview will start you know the interview won't start with just a problem on the board and someone will say go but you have your interviewer there they'll probably introduce themselves and ask you to introduce yourself uh something i like to do for the call starts is just take a deep breath and relax tell yourself that it's gonna be okay and that every interview is is stressful and everybody hates them so take a deep breath relax have an intro prepared just like a minute or two like hi i'm tommy originally from boston worked decor for six years on back end i'm looking for my next role looking to transition into a front end role because i want to have a lot of impact there and i think it's really that space really interesting right now done just doesn't have to be super fancy but if someone says hi introduce yourself and you're sort of like scrambling and you don't have an introduction ready so getting yourself off on the wrong foot so just have something ready they might also ask you to tell me what the recent project you worked on have a quick three minutes ready to go there but don't ramble you know you this is meant to take you know three to five minutes just make sure everybody feels comfortable so if you're introducing yourself for 30 minutes which i've had people do you're probably doing it wrong and then you'll get the problem so after the intros the intro the interviewer will give you the problem that you're going to solve first thing don't panic you're going to get a problem you're probably not going to know the solution off the top of your head that's expected don't freak out if you have seen the problem before tell your interviewer that so maybe you know you you just practiced uh you know some like palindrome problem on lead code last night and your interviewer says given a string tell me if it's a palindrome just tell them if you've seen it uh or if you've seen something similar just say you know oh yeah i've seen you know i was actually this one of the problems i practiced uh last week so i have seen this one before they might say okay great thanks for telling me let's solve a different one they might say okay that's fine let's just solve it anyway like even if you've seen it before like i still want to see your approach it's up to the interviewer what they want to do there but the thing to not do is be dishonest i catch people all the time being dishonest one one way to get caught is we sometimes in an onsite two interviewers on this you know talking to the same person will ask the same question because they forgot to like share what questions they asked and then the second time the person would be like oh i haven't seen this before let me solve it it's just like an instant rejection uh unless you're an academy award-winning actor you'll probably get caught trying to act so just be honest don't try to do anything you know sneaky hair just let your interview know if you've seen the problem after you get the problem let's say you know you've disclosed if you've seen it before after that the first thing you probably want to do is ask clarifying questions you know really good clarifying questions are of the form okay so let me let me just be clear so if this was the input then this would be my output and they'll say yes it is like you say okay great you're sort of on the same page you've understood the problem then as you're solving it always think out loud you should basically as an interviewer never be silent for more than like 30 seconds or 60 seconds at a time it's going to feel really weird to constantly just be thinking out loud because that's not how most developers or data scientists or designers think they just sort of like think in their head and not speaking your interviewer will expect you to do this it will feel weird if you've never done it before but it is what you're supposed to do sometimes you might say okay do you mind if i just take a minute to think or draw something out on a piece of paper interviewer will say sure but if you're sitting there in silence for five minutes typing away your keyboard and not making much sense your interview's not going well if you can try talking through multiple possible approaches usually when you're given a problem you might have a couple ideas for how to solve it and talk through all of them you can say okay i have a couple ideas here one idea is to you know build a graph that has these as nodes another idea would be to create a hash table or this is the key and this is the value sort of explain it out loud your interviewer is probably going to help you here and say okay that those those both might work if i were you i'd go the second one you could say okay great now i'm going to go with the second one you're sort of making it more of a conversation and giving your interviewer an opportunity to help you um many folks are sort of visual folks um so feel free to to draw a diagram you know even if you're doing this over video having a little white board or a piece of paper handy that that can be helpful if you're a visual person so if you want to draw the diagram you'll hold it up to the whip game if you want or not depending on you know sort of what the situation is but to sort of have the supplies ready if you think you'll need them then after you sort of you've got the problem you've articulated some solutions what you really want to do is try to pattern match right we mentioned that most interview problems sort of reduce down into a really small number of core concepts like search problems strings graph problems so try to pattern match against what you know to what you think this problem is getting at so for instance you know maybe someone's described something where you're searching for something that could be a bunch of different possibilities ask yourself okay could we formulate that as a search or maybe somebody has described some problem and you're like okay well maybe there's some recursion here that i can formulate or maybe binary search is applicable but take all those things we talked about earlier in your toolbox like lists strings trees hash tables and just sort of go through them in your head does this does a hash table apply here does a list apply here does a tree apply here hopefully the answer to one of those is yes and that can really help kick-start your solution and kind of get you off the ground and then you sort of figure out you know what why is it a graph problem or how is this different than a standard graph search but it can help get you to a starting point for your solution rather than you know trying to invent some new algorithm on the spot or derive something totally new in the spot pattern match against what you know and you know a lot because you sort of went through all of the the toolbox and prep you should be doing in advance as you're writing up your solution try to write general code before really specific code and what i mean by that is you know let's say that your interview problem is you know write up write a function to compute a factorial what some people do is their first instinct is they say well i know the factorial of of 3 is 6. so i'm going to say if input equals three return six and then they come up with like three or four corner cases first i would say don't don't do that that code is probably not gonna last you know you're gonna deleting it but it can also sometimes create this mental block where you fail to see this general solution because you're zoomed in on like a small number of cases you know work so try to think about this generalized solution and then find corner cases rather than enumerate all the possible corner cases and then try to find some general solution for the most part too if it feels like your solution is really complicated like it's got a bunch of corner cases and a bunch of branching and like four different helper functions if it just feels pretty complicated it probably is and there probably is a simpler solution sometimes sometimes there's not and there's it's kind of hard to tell but your interviewer is probably going to be there asking you to simplify it or maybe there's a better way but just as a heuristic for yourself if you're looking at your code you're like wow that's that's a lot it feels really messy it's not because like oh the problem is so hard it's probably because your solution is overly complicated to get a question that we we asked earlier if you get stuck ask for help it's much better to say honestly i'm a little bit stuck here can you give me a hint or can you point me in the right direction saying that is so much better than just staring at a wall for 30 minutes then getting nowhere on the problem it's obviously better if you solve the problem without asking for hints someone who's asked you know constantly asking for hints and needs a lot of hand-holding to get the answer that's not a good interview either but sometimes you do hit a wall you can ask a question and with a small little hint you can get unstuck and then you're back off to the races also make sure before you type a single line of code explain your solution be aligned on what you're about to write before you write it you don't want to create some situation where you've written a bunch of code in the back your head your interviewer is like they didn't even tell me what they're trying to do i didn't know what they're trying to do and this is like super wrong and you don't have enough time to fix it and then your interview's over you lose so make sure you're aligned on the same page of what code you're about to write and what your general approach is before you go and write it and again this is what i mean when i say process not output if you're aligned in an approach and you're thinking critically and you're communicating well maybe your output isn't perfect but that's what we're really looking for for a good interview okay some few last tips before we get into the mock interviews here so as you're writing code constantly communicate sometimes i'll even kind of like narrate the code i'm writing i'll say well first i'm going to create a function called cache and then that's going to take two parameters it's going to take the key and then it's going to take the size of the cache and the first thing i'm going to do is i'm going to create a base case here just that kind of communication is really helpful as you're typing again it feels weird it's unnatural practice it i promise that's what your interviewer wants you to be doing next thing is always get something working sometimes people will see some simple or naive solution they know it's not optimal and rather than writing out the naive solution they sit there and they're like no i don't want to write anything until i get the perfect optimal solution then they end the interview having written zero lines of code um really good chance that that interview didn't go well you're not going to move forward definitely better to have something than to have nothing once you have something then go ahead and try to simplify make optimizations and get to that optimal solution but even if you can't ultimately get to the optimal solution but you're thinking really quickly you're communicating well maybe with like five more minutes you would have got there that's a really good interview outcome last uh listen to your interviewer i've had many candidates who do not listen to me as i'm trying to help and give hints your interviewer wants you to succeed as an interviewer like it's so much less fun like watching somebody struggle and you're trying to help when they're telling you like no you don't understand the problem you just gave me it's like i i probably do and i want you to succeed so if your interviewer is sort of like giving you little hints and guiding you in the right direction really listen to what they're saying and take it seriously um really really rare that some interviewer is going to like intentionally try to fool you or give you some hint to lead you down the wrong direction be like oh is that your final answer when it's actually correct like that's it's pretty rare i'd assume interviewer is not doing that unless you know they've already done it once or something so really listen to your interviewer they want to help you take advantage of that and listen to their feedback uh oftentimes people ask you know what what code do i write what we're looking for specifically is a function that returns the answer so don't just write a linear you know if the first line of code shouldn't be like if this and you know assume some variable exists the first line you write should be creating a function that will ultimately return the answer if that function needs to be more than one function great decompose that into separate functions as needed don't go crazy here and make sure you have something working before you spend a bunch of time refactoring code and cleaning it up a lot of good you know sort of general engineering and programming principles apply here too don't create variable names with crazy acronyms or abbreviations make sure everything is readable if you have common logic logic factor things out into helper functions again this is all about the process if you're doing this and demonstrating these things that's way more important than your function being perfect at the end last part is testing it once you have written code your job now is to be a computer so take your code and run through it line by line you execute the code as if you were a cpu make sure that if you run the code it's going to end up returning the correct answer and again do that out loud so what i would say is let's say you have that factorial function saying okay well let's try passing in 3 well as 3 my base case is checking if it's equal to 1 3 is not equal to 1 so let's move on to the next line we're going to enter this recursive case and just walk it through and make sure that you get the correct answer at the end of it as you're doing this be on the lookout for bugs sometimes you know you can in your head you know what the code is doing is different than what's actually written so as best you can do exactly what the code is actually doing and that's going to help you find bugs and just verbally reason about that out loud and walk through sort of narrate the process of this function executing to your interviewer sometimes in an interview you'll be given a computer and the ability to run code sometimes you won't either because it's on a whiteboard or because the interviewer says you're not allowed to run code i want to see your reason about it and the mock interviews we're about to do we will be allowed to run code on the computer so if you can do that i advise to you know write write a few test cases if you can you know maybe they're just like print statements at the end or something that's going to run the code and verify the output is correct but i wouldn't what i wouldn't do is is when you're given the ability to run the code is kind of like take advantage of that just by like running it a million times and like let's say you have an off by one error somewhere just sort of randomly adding plus ones and minus ones and then running it until eventually you get the correct answer even if the answer is correct that's a great example of a process that is not good we want to see you reasoning about things and arriving at a solution confidently rather than just sort of randomly locking your way into a solution and the ability to run code a bunch can be this temptation that can lead to that kind of outcome and last if you can add you know print statements or sort of debug the state as your code is executing definitely do that i think sometimes people will run the code look at the output say that's wrong change something look at just the output and say that's wrong we're printing out intermediate state and what your code is doing along the way maybe you have a recursive function you're going to print every time the recursion is called print the input so you can make sure the sort of stack is is what you think it's going to look like and that's usually the most effective way to fix issues and again i'll say one last time the process matters way more than the output here okay so let's jump into some mock interviews so what we'll do is we'll have connor and maria will be the interviewee i will be the interviewer and we'll try to simulate this uh really as as realistically as we can so there's like i said these are real problems i've really given in the past at real tech companies and then conor maria have done lots of real interviews and so they'll give you what a real performance looks like just so you can sort of take a look at how things go so i'll read the problem first and then uh we'll flip into screen sharing and start the interview so this is the first problem that we're going to be working on so i'll read it out so let's define a rotated array as a sorted array where the numbers have all been rotated to the right some number of places with numbers wrapping around when they reach the end so for instance if you've got the array 1 2 3 four five and you rotate that three times you're going to get three four five one two so the problem here is given a rotated array find the number of times it was rotated all right well hi tommy how are you doing i'm connor good nice to meet you connor how's your day going it's going pretty well on yours awesome not too bad you know it's pretty sunny out here in san francisco which uh doesn't happen too often that's great yeah it's it's pretty warm out here for october in cambridge nice all right well let's uh let's thanks for taking the time let's let's jump right into the question so uh you've got the replace open that's great notice that you've selected python there is that the language that you want to use for this yes it is perfect that works for me um so here's the question that i'd like you to solve so let's define a rotated array as a sorted array where the numbers have all been rotated to the right some number of places with numbers wrapping around when they reach the end so for instance if i give you the input one two three four five you should return back three uh since oh sorry when i rotate that three times you should return back um three as basically as you as you've written in the in the comment there so that's that's the question that i'd like you to solve okay yeah that sounds good um so i'll start out by asking some clarifying questions if that sounds good to you yeah um so just to make sure it does say given a rotated array here i just want to clarify that something like this right here would be our input so i'm i'm i don't get this original array at all i just get the rotated array as input yep that's right all right and then my other clarifying question is um we in this one all of these are consecutive integers so one two three four five all right next to each other can i assume that that will be the case or might be there be a case like um where my original array is like one three four seven ten yeah so that could exist so they're not necessarily consecutive but they are sorted okay yeah that's good to know all right um in that case let me um just look at a couple of examples just so i can see if we can start to see a pattern here um so we see when we get this first example we want that to map to three um because we're rotating that one three times um let me see if i if i were to rotate that one more time then it would look like two three um four five one and so that would be as if i had rotated it four times um and then i'll try some some ones with different numbers so if my original array has like some different numbers in it it might look like a rotated one might look like 6 8 12 1 3. and in this case um in this case we would have rotated it so one would have been the original one um and so we've rotated it one two three times so we would also want this one to return three um and then just one more uh kind of like edge-ish case is um if it's not sorted at all i'm assuming that we would want to say that that was rotated zero times yes that's right all right so just to check in do all of those cases seem good to you yeah nothing else you'll we'll probably run into here all right great um so in that case let me go ahead and run through looking for patterns so i can see like just how i would figure this out if i was looking through this as a human is i would like go to the first one and i guess the important thing i'm looking for is all of these numbers are increasing and i want to look for like the first time that they decrease so they start going down so like in this case i go like i go to zero i go to one it's increasing i go to two it's increasing and then when i get to element three it's decreasing which means it's rotated three times okay so and then just to verify that i'll go through this one so in this one i started element zero then one it's still increasing two still increasing three still increasing but at four it decreases again so i think that is a pretty good pattern to use there is that when we get to an index when it starts decreasing that's the index that we want to return yeah that looks that looks exactly right to me that's uh yeah that point where it goes from increasing to decreasing is the index that tells you that the number of times have been rotated all right perfect in that case i think i'll go into writing some code if that sounds good to you yeah let's see that all right so um i'll go ahead and define a function here and so like i guess i'll just say like get rotate number sure sounds good and it's going to take in this array uh that looks like it might be reserved so i'll take in a list ls um and now i want to go through all of the elements in ls so and the index is important here so i guess i'll go ahead and say for i in range ls and now what i want to do is for each i like when i'm here i is2 i want to compare it to the one before that and see if it's less than that so so let me uh i guess i would say something like if ls bracket i is less than ls bracket i minus one so we're saying if my current element is less than the element before that then i would go ahead and i know that that's the place that i want to stop so i can go ahead and say return i um and now looking at this special case here where nothing happens i guess i would go through this entire list and never get to that point so i guess if i finish this whole thing uh so i don't find any point where an element is less than its predecessor i'm going to go ahead and return zero since i know that the list is not um doing it is not rotated at all um so now just as a sanity check i'm gonna go through this with um this first example here um so acting is the computer i take in ls which is this list i've highlighted and then i go ahead and say for i and range ls so that's gonna start me off at zero and i'm going to say if ls bracket 0 which is 3 is less than ls bracket oh ls bracket 0 minus 1 is going to be ls bracket negative 1. um which is this two here um which i guess will not be a problem here um because our if three the only case when this first element is going to be less than the last element is when the array is not rotated at all so i would want to return 0 in that case so that actually makes me think that i may not need this return zero at the end here um just just kind of a peculiarity of python indexing where if i say ls bracket negative one um it's going to be the last element of the list instead of giving me an error like it might in c or java or some other programming language yeah i hadn't thought of that but i think you're right all right so um and then finishing going through that example for this one it would start out at zero and see that um it is in fact three is in fact greater than two so it'll continue um it'll get to this one it'll say that four is greater than three so it'll continue it'll get to 5 say 5 is greater than 4 so it'll continue but then when i is 3 we'll see that ls bracket i is it is in fact less than ls bracket i minus 1 so we'll go ahead and return i which is 3 which is as expected so just running through it like as a human uh that seems to work so now let's move on to writing some tests yeah so i can go ahead and say i'll just um print one out first to verify so i'll go ahead and say print get rotate numbers of our first list here and hopefully this will end up with three so i can go ahead and run my code here and we've got a problem here where i'm saying list object cannot be inter interpreted as an integer okay and i think what's going on here is i can't just say for i and range list um because range has to take in an integer so i actually have to look at the length of the list here yeah that's right instead so now i'll go ahead and try that again all right nice and so that's looking pretty good so that's looking like it's printing three and then i'll just go ahead and try with our other lists here so hopefully this second one should translate to four this third one should translate to three and this last one should translate to zero and we'll go ahead and run that and it looks like i added oh i forgot a dip yeah it's a bracket here i'll run that and it looks like that has given us the result we want um so that's looking pretty good to me so i guess i'll i'll check in at this point and see if there's anything that you notice about this or any other corner cases you think i should try out yeah this this looks right to me um what is the runtime of this yeah of course so going through the runtime um since i'm going through i in range length of ls i'm going to go through this loop a maximum of n times if there's n elements in ls and then just accessing elements of a list in python is o of one and comparing two integers in python is going to be o of one um in in terms of the size of the list um and so this whole operation inside the for loop is going to be constant time so i'm going to say that the entire runtime is going to be o of n so if there are n elements in the list it'll take a maximum of n times yeah i think that's right um can you think of any ways to make it faster yeah let's see so if i'm working on making it faster i wonder hmm so i i guess the way that any way that we could make it faster would be to hmm i'm actually a little bit unsure because i like going through it uh as a human i can't think of anything else i would do then go through each element um so i'd i'd love to know if if you have any hints if you could nudge me in the right direction a little bit yeah so keep in mind that the list is sorted even though it's rotated we have this property that it's sorted so is there any any search we could use that leverages the fact that it's sorted hmm we could use so so generally with a sorted list we could use a uh just a binary search um so if we [Music] uh if we're going through and doing that then how would i apply a binary search to this problem so i guess i could um let's see so so if i go through kind of the the the motions of doing a binary search with a problem like this um i would start in the middle um and see that i i've got of size five here um okay so i guess i would have to look at the first element first see that my first element is a three and then when i head to the middle i see that i'm at size five which means that whenev that it's been increasing since then which means i guess i can at that point i can go ahead and narrow my search down to the latter half of the list after i've checked that one um and vice versa if i let's say for what's a good example for this one um if i start at or i i guess a better i guess i don't have a great example for that one but but if i if i were to get to a point where i was like checking this three here then i would know like if i'm checking at this three i know i can just look at everything before the three um so yeah i think a binary search would uh be able to help us out there um just want to check in time wise um is it all right if i go ahead and try and implement that or um do you think we should move on yeah let's try to implement it quickly and then if we're not a time that's that's totally fine yeah sure so let me uh leave this other one here just to uh um just to have some something to reference um and now this newer version here um i don't necessarily want to go through um each eye in this range um i want to go ahead and say my like um let's see my i only care about when i'm going from a high number to a lower number so i'll go ahead and say that my highest number that i've seen so far is going to be um the first element in the list is ls bracket zero and then uh and then i can go ahead and say that my lowest element that i've seen so far is um we can go ahead and look at the last element of the list because i know it's going to be um somewhere in between or i guess we don't necessarily know that's the lowest let me uh think about how we would want to initialize those uh so [Music] five if if that is the lowest then yeah i guess we'll i'll just start out with zero and go through kind of the logic of this um and then uh oh although i think i'm going to actually want um so if i'm looking for a an item that is lower here i'm also going to want to keep track of the indices that i'm working with um does that seem like it's going to be on the right track yeah i think in general you'll probably want to look at sort of the left ha keep track of the sort of left and right endpoints of the search and then you can compare wherever you land on the middle to those left and right endpoints yeah yeah that's that's a good point so um let me go ahead and say that like left for now is going to be zero the like first index and then since we're starting our search with the whole list our right is going to be um the length of the list minus one um and then what i can go ahead and say like i can go ahead and instead of having this whole for loop here i can say while right is greater than left so like while we're still working on converging in then i'll go ahead and say that my current index is going to be equal to uh right plus left divided by two let me get some parentheses in there um and so that will take the middle element and then since we're working in python i realize i should probably do some integer division here yep um so that'll get us our current index that we're working with um and then i can go ahead and say so in and then let me look at this example to see what we should do so in this example our if our current index is greater than the index on the left then i know i can narrow my search to the right half so if ls bracket current so if that current number is greater than ls bracket left is greater than the left number then i can go ahead and i can narrow down the search to this right half of the list so i can go ahead and say that left equals current and then i can go ahead and say otherwise if ls bracket current is less than ls bracket left then i can go ahead and say right equals current so i know that we are going ahead and changing our rightmost there um and let me and so now we just kind of have to work on what happens after we do narrow in on that case um so let's go through the example with this top one again so we get to this point with this five here and so now we know that our difference is going to be between five and two and actually now that i'm thinking of uh yes yes we're we're looking between five and two here um so fi our left is at this point is going to be two and our right is going to be four and so now our central one is going to be one here and so now since one is less than five we would hit this case and so we would say right equals current so now our left is going to be five and our right is going to be one so we know that we're ending here when our right one is just one more than our left one um and so let me go through what the example would do in this if if left is two as we have here and right is three um so when when left is two and right is three our current is going to be three um and so this is going to say if current is greater than the left one which isn't true because uh they're the same thing and then we'll say if current is less than the um is less than the left one which isn't going to be true uh because they're the same then we can have an else statement here and if it's an else then we know that this current one is kind of one below where we want to do so we can try and return um our right here um so now just running through with an another example is kind of a sanity check so for we'll take this one here um let's let's say our so our left is zero to start right is four we can find the one in the middle which is going to be element two and then we're gonna see that two is greater than our left so that means that we're going to narrow our search down to these last three elements here and now we're going to go ahead and say that yeah so so now we're going to go ahead and find the middle element here which is one and we'll say that like uh we'll say that left uh yeah so this is our current and then we're checking is current greater than left uh no that's not true is current less than left yes that is true so we're changing our current to this um or we're changing our right to this and so now we're just looking at this section here these are our left and right and when we compare uh left to current and right to current they're both going to be the same thing so we get this else here and we return what's on the right which is one um which should be correct so um just basic conceptually wise it looks like things are working out here um so let me oh let me run through it real quick with the uh unrotated array to see how things are going there so in this case we're going to get to this middle one we're going to see that right is greater than or yeah the current is greater than left so we'll get to this one here now and we'll see that the right is uh still greater than the left so now our uh yeah yeah so our our current is still greater than the left so our left is becoming this one and now we're going to go ahead and say if the left is still going to be this one um so that's not going to give us the right answer here it looks like yeah i think the the stop condition you're looking for is sort of in that first example you can see with the one the number to the left is bigger and the number to the right is bigger so that's kind of the the stop condition for your search otherwise though that i think the binary search is right okay yeah so that that makes sense so so maybe i can go ahead and check that uh check that condition so like if we're looking at our current one we would uh yeah if would we do you think for each time we would look at our current and check if it's uh smaller than the left one and great but smaller than the left one and smaller than the right one yeah and then okay sure um so if our we're already checking if our current is smaller than the left one here um and so i can go ahead and nest a little bit of ifs here and say like if our current um is also smaller than the one oh okay oh sorry sorry but we're not looking at direct neighbors there so let's look at direct neighbors up here so that would look like if ls bracket current minus 1 is less than ls bracket current which is less than ls bracket current plus one which is a nice thing we can do in python is just combine these different inequalities um and i'll take away those parentheses for now and so in this case we know that current is the one that we want to return so we can go ahead and return current here um and then let me just uh do another sanity check um yeah i think this this looks this looks basically right just for just for time we're basically at time but yeah overall this uh this search looks pretty good all right awesome well thanks for taking the time for chatting with me today and have a have a great rest your day yeah thanks it was great to meet you awesome see you later all right and then uh for feedback is it best to keep my screen shared uh let's uh let's actually just switch to maria just for time's sake uh so maria can flip into screen sharing and we can go into the next question all right so i'll i'll describe the problem and then uh you can take it away from there so we're going to do is given a string we're going to be looking for the length of the longest substring without repeating characters so for instance if you gave me the if i gave you the string abc abc bb the length of the longest substring there is three so there's abc where it doesn't have any repeating characters in there and there's a few other ones like that um so your function would take that as input and then just return the length of that string which is three awesome um hey tommy how are you awesome how's it going good uh i'm good it's a sunny day still in san francisco so i'm loving it beautiful it's uh kind of a glowy day in new york but still pretty warm nice well thanks so much for jumping on the call let's uh let's jump into a coding problem awesome all right so it looks like you've got the replits set up notice you're set to python is that the language you'd like to use yeah that's language i'd like to use if that sounds good with you perfect that's good with me cool um just thinking through this question a little bit i guess um a few clarifying questions yeah so we just want to find the length right we don't care about returning like one or all of like the subsequences that match that length yep that's right awesome cool um and then when it comes to the input i see the example we have here is all lowercase characters should we assume that we're going to get all lowercase characters as input or do we want to handle um kind of like sanitizing about inputs yeah it's a good question you can assume the inputs all lowercase awesome cool um and i guess could then put b empty like the empty string uh it could in which case you return zero awesome cool um great i think that covered all of my questions so maybe then just give a few examples so abc abcdb the answer would be three the output that we want to give um if we have all repeating characters the output would be um just one i'm assuming yep that's right awesome um and conversely if we have all different characters the output would be um six in this case um and then as we said if we get the answer string the output would be zero um yeah awesome i think that makes a lot of sense um to cut when i'm kind of like looking at this um initial string and problem i guess the first instinct that i have for like the very naive solution is that um you know kind of brute force we can just um get all of the possible like subsequences or substrings and check whether there are any duplicate characters within those substrings so um in the abc abc bbb example that would be first starting with every substring starting with a would be a and checking if that has any repeating characters then a b um it doesn't have any duplicate characters and abc it also doesn't have any duplicated characters than a b c a which has duplicate characters um and then every single one a b c a b would also have duplicate characters given that the substring of that had them and also that b is repeating similar with abc abc abc abcb and abcdb so um it would be a very similar case if we started b and at c so it's kind of making me feel like um the naive solution we'd be kind of doing a little bit of like work that is not useful so um if we could avoid that that would be great um reasoning a little bit over like that nice solution brute force approach going through um all possible subsequences um would be quadratic time and then within that checking whether um their typical characters within each substring would be linear time so in total that probably would be um n to the third um so that is not great so i'm gonna try to optimize that if we can and um kind of looking at this um the way i like described it starting at different points of the string um i'm starting to think maybe we can kind of like have a range within the string that we track with kind of like a starting index and an ending index and maybe we can like expand um start you know um at the start of the string and expand our ending index to the right and the moment we kind of um encounter a duplicate character or a repeating character we start to um kind of move our start index forward to try to get to a subsequence that doesn't contain that duplicate character anymore and all the while while we're doing that keep track of like the longest encountered length um and i guess i have another kind of assumption question is could we use an extra data structure um in this question yeah that's totally fine i think that that sort of sliding window you're describing that sounds like a pretty good approach to me awesome yeah i think for that sliding window i'd like to use um like a hash set so that um we can have um pretty constant time in like looking up um how often certain characters are within the string already um and we can like do that like look up very quickly yeah that sounds great awesome so if that sounds good i'm going to go ahead and define our function um i'm going to call it length of longest substring um we take in just one parameter i'm assuming which is the string and then we need to define like the output which is an integer um cool so as i said would love to use a hash set so i'm just going to start by initializing it um and um i can just initialize it also zeros for now and um count we're gonna count um how many occurrences of each character that we encounter happen within um the substring and i'm gonna multiply that by 128 128 because i know that we have um 128 ascii characters um so just to start off initialize it to that um and then going to define the length um which we're going to want to track of that longest substring and defined it to zero getting some uh oh okay variable sign but never used that's okay because we haven't used it yet um and then i'm gonna use the kind of start and end index like approach that i described with like that sliding windows so um to start next maybe i'll just call it left for clarity um i'm going to assign that to zero and then what we want to do first to start going through the string um do it in a few ways um but maybe i'll do a for loop to start so um you can say for right and right is referring to my end index which i described for right in range of the length of the string um thankfully saw connor's previous interview so i now know that we can't go up here but we can we have to do the length of the string um and then the first thing i want to do in this case is to make sure that um basically what we want to do is increment the count of the specific character that we're at by one so in the hash set that we have so the way we're going to do that is we're going to say tarzan um at s at index fight because s is our string um and we're going to increment that by one um and that's okay because we've defined um all the characters uh all of them um essentially like fields in a hash set to d0 um cool so then the next thing i want to do is i want to take care of that case which i mentioned earlier which is if we encounter a duplicate character i'm kind of moving the left or the start index forward until we um don't have to do the character anymore and since we're using chars as our hash set um the way that we know that we've encountered more than one character is if um stars at um [Music] index right is greater than one and so i'm going to do a while loop here because um we could have um multiple repeating characters within the substring so i want to make sure that i get rid of all like potential uh repeating characters or the repeating character could actually be at a later point in the substring so i want to get to that point and make sure i move the start index by um enough characters forward so um the way we're going to do this is um first we want to update the um count that we're keeping track of in our hash set for that specific character uh so the way we're going to do that is we're going to say char is it s at x i think we i called it left minus equals one and then um what i'm going to do is to move left forward is i'm just going to increment um left cool and then um one thing which i haven't done yet is i want to make sure i'm keeping track of the length as we said earlier um so the length um at the first iteration will be um we've initialized it to zero and then first time we calculated um the length between two indexes in a string typically is um the ending index minus the starting index plus one because strings are zero index so in our case it's right minus left plus one if i could spell correctly that would be great and then um what i'm gonna do so that we always keep track of like the biggest um the maximum possible length is i'm gonna use the max function and say i wanna take like the max of either the current length or um or the length that we can keep track of or the current length but based on the right and left integers and then i think last thing we want to do is um return the length because we want to return that um integer um and he does just a sanity check a little bit um before i run this um just gonna do it with abca because it's a little bit shorter than abc abcb um so abca should be three um the output for that so what we're gonna do is um when we start our for loop um we're going to um say that charge that a is equal to one we're going to add one to that um it's not greater than one in the first iteration so um what we're gonna do is just take um the um length and like set it and because right and left are zero at that first um run through the for loop it's going to be zero minus zero plus one so length is going to be one at this stage and then when we get to b um charge that b is going to be connected to one um charge b still is not greater than one so again we're just going to jump with length and at this point it's going to be two because one minus zero plus one is two um then we're at index two which is the third character which is c so again um uh setting charge at c to be one and then it's not greater than one so we just jump and then increment the length again to three this time because two uh minus zero plus one is three um and then in the final run through that for loop we're going to encounter a again and so um target a is now equal to two which is greater than one so what we're going to do is uh decrement that so again choice a becomes one um and we're going to move our um forward so um or left sorry our left um index forward um and uh what we get now is that we want to take the max of either three um or um zero one two three uh so one two three which again is gonna give us a length three um and we've run through um basically all of the elements here so what we're gonna do is just between line three so just by running through this simple example i think this should work and i'm gonna write out some test cases um so maybe i'll just print input um and maybe just define a string here first to be abc abc b um our input is going to be string and then we want to say length is equal to calling the function on string and finally print output to the um cool um so may have some errors i'm just going to run it through the first time and see what happens and i see here that on line 14 we have list indices must be integers or slices not strings so looking at line 14 um oh i think this is very interesting because i referred to ascii characters in the beginning but then i didn't really um take into account that we can't have like um a character itself is like the index uh but we have to i think we have to use a function called um that's right awesome yeah i think that function returns an integer that represents unicode character so what i want to do is i want to wrap the word around every single time i'm seeing an index within chars um those should be all the times and then input abc abcd output three um that's great just gonna run through an ad like a few more test cases like the ones we mentioned uh so bbb um abcdef um and maybe just add the empty string for good measure to see if that gets the right result uh cool so we get input the output one which is great and put abcdf output six which is great um p w w e k f i think this is right yep that looks right okay f and then input empty string output zero um awesome are there um i think this looks good to me are there any other edge cases that um you want us to take a look at no this this looks great to me and i think you might have mentioned already but what's the runtime of this final solution yes so um space complexity is linear you're using touch set and then time complexity um so we have like one for loop and then which is linear time and then searching within the um hashtag itself should be constant time so um i think it comes down still to like linear time at most we have to go through each of the characters twice yeah that sounds right to me well also this this looks great well thanks so much for taking the time to chat with me today of course thanks so much too uh it was a fun problem to work through awesome have a good one all right so those were the two mock interviews i'll just say a few kind of closing words uh for after the interview and then i know we're going a little bit over time but um i'll be around uh if we want to anyone wants to ask questions and then maybe before that we can um quickly go through just some things that were went well in the block interviews and some things that that didn't so people could sort of give their give their own feedback and and thoughts but before that i'll just have a few uh few closing thoughts um so one is after we didn't simulate this in the mock interview but after the interview is over is is kind of your chance to ask questions so now uh you'd ask questions of your interviewer and here are some good questions that i like to ask asking about their team's culture what their typical day-to-day looks like things that they've worked on things that they're proud of and this is a really good way just to get a sense of what it's really like to work at that company you're interviewing with i think bad questions are things you could easily google or find online and and good questions or questions that um you know kind of kind of don't are not easily answered online and actually give you a picture of would you like to join this company and what is it like to to work there so uh sort of last last advice i'll say is don't worry interviews are really really really high variants there are great engineers who just do super poorly on some interviews and that's uh that's just sort of unfortunately how it works so just because you know you didn't do well on some number of interviews doesn't mean at all that you're not still a great developer a data scientist or designer or whatever path it might be everyone has bad interviews sometimes interviews are not fun i don't think i know anyone who enjoys interviews really on either side of it but just view every interview you do as an opportunity to get better if you do you know don't pass an interview or get rejected from a company just try to reflect on that and think about what went well what didn't go well maybe it was the type of problem maybe it was your communication just take some time to learn and grow from each experience but everyone is going to go through a bad interview i've gone through plenty i'm sure everyone else on this call has as well and so don't worry if that that happens to you so last up just some some takeaways from the talk uh one have the basics down going into any interview just know sort of the basics of the language you're going to be using be really comfortable in that setting build your toolbox be aware of the concepts we talked about in those two mock interviews we looked at a string problem we looked at a binary search problem so those sort of concepts have them ready to go do lots of practice problems the more you practice the more things you're going to be able to pattern match against and the more comfortable you're going to be in this sort of really unnatural interview setting before you write any code just like marie and connor did communicate your solution explain the code you're going to write and then write it out and then just like we saw in those mock interviews always verbally run through your code look for issues and solve them proactively so the interviewer doesn't have to tell you all of your bugs and i'll say one last time all this is about the process not about the output really focus on communicating well thinking critically and getting to a solution rather than writing absolutely perfect code at the end of the day and so that's uh that's the end of the the workshop like i said we'd love to dive into questions you have for me as as well as some feedback on the mock interview and so i will uh i'll turn it over to david to moderate questions and feedback yeah tommy the first question that came up was does tommy have any feedback on connors and maria's interviews positive and negative yeah for sure so i'd say both of those both those interviews were positive i think like i said the most important part was that communication and in both cases connor and maria started by asking the asking clarifying questions in advance they made sure they understood the problem in both cases they sort of made a list of inputs and outputs which i mentioned is a really good way of framing things uh also thinking out loud was was really really important there i think in both cases everybody was uh sort of constantly narrating they're never sitting in silence um i think uh something else that i that i like that conor did specifically was ask for a hint when he got stuck i think it would have been really bad if you know imagine conor was at some mental wall and just didn't see it and was sort of like stuck and like i don't know let me just like sit there and think about it just asking for a hint and then we were able to get unstuck in and go right down the right path um so yes i think those are those are sort of the things i would i would focus on for the interview um i think in all cases just making sure uh that you know so we didn't really have enough time because it's intentionally short but just making sure the code is really readable and clean and sort of taking the time to maybe create helper functions or more readable variable names we sort of omitted that on purpose just so the interface would be short but that would be sort of the main thing that i would that would do with more time another question that came up especially for folks who don't have the luxury of being able to do mock interviews with people like this are there recommended websites that are good at preparing you for interview questions for algorithms coding is competitive programming helpful yeah i think uh there are lots of great websites so one that i like a lot is called leet code so just leapcode.com they've got a bunch of problems there you'll probably find uh the ones that i that i posted somewhere on lead code as well because they have so many um they're also great you can sort of write up your solution and also like see the solutions another excuse me another good one i like a lot is called project euler same thing just sort of like gives you practice problems you can go and implement them in any solution any any language you want um so i'd start there if you have a competitive programming background that's awesome i i don't i'm not i'm pretty bad at algorithms problems myself so i think project competitive programming can be helpful i will say if you have done competitive programming before the difference between competitive programming and interviewing is that in competitive programming your variable names do not matter you're sort of like just trying to go super fast and oftentimes that means being sloppy or like allocating these huge arrays you don't have to like calculate the links of things so definitely don't do that in a real interview the readability of your code matters a whole lot more so other sites sort of more advanced sites or things uh like topcoder where there's other sort of problems uh um practice problems so they're you know they'll be a little more advanced but they're still good practice another question tommy that came from pamika was i wonder if most interviewers would give an interviewee a general problem like this for entry level or if they would likely give a more adaptive problem related to the interviewee and the job in question yeah that's a good question and i think that's that's sort of what we were getting at before about the different types of interviews so i'd say this is a really common interview type where what's nice is that it kind of removes a lot of the background because you can use whatever language you want it doesn't require you to know some particular framework or library you can sort of solve this in a whole bunch of ways that's the advantage of a problem like this you may also see in addition to this something that's more specific to the role that you're working on so if you're applying to a web development role you might have a question like make a website so we didn't do a mock interview for that but i'd say those are less common than these sort of really general questions but you could still run to them as part of the whole interview process and tommy for students who aren't at harvard or yale and might not be considering fang companies like facebook and apple and amazon netflix and google is the kind of prep that we're offering today focused on those types of companies interviews or tech more generally yeah these are really just focused on tech more generally i think you know every company will have its own process and might do something different but the idea of being asked to write some code in some setting where someone is watching you and having to think through your thought process and think out loud that's pretty universal at a lot of companies um and you know like i said every company might do something a little bit different or have some more specific interviews like maybe some you know online challenge or something written or something like that but holistically you're kind of thinking about all the same things and all the prep work you do is probably going to apply to a really wide variety of interviews and perhaps a question for maria or connor how do you stop getting nervous during your interviews so the short answer is you don't i get nervous before at every interview um but one thing that i i like tommy uh said before practicing really helps and not just practicing on your own or with friends but also practicing in the form of other interviews um so i i've i applied to a lot of companies um this year and so i have gotten to the point where if i i'm i'm doing a few interviews a week so like the the first week i was doing interviews i was a lot more nervous than now where it seems like kind of a routine i know i know my introduction i know how to ask clarifying questions i know what questions i'm going to ask interviewers about their job different things like that so i would say that just like a lot of things the more you do it the less nervous you'll be i would say repetition um i also think um if you can practice with friends and kind of switch up the interview or interview roles um you can also kind of like develop some empathy like on the other side as well um but really just put yourself in those situations and kind of simulate the interview situation even when you're solving practice problems on your own and don't just kind of like tommy alluded to earlier don't just be like oh i think i kind of know how to do this and then look at that solution and be like yeah that's what i was gonna do like but actually like time yourself and go through it and repeat as often as possible and tommy a technical question you mentioned one or more times that people should factor out common logic what did you mean by that something i say something i say all the time but oftentimes when you're writing code just generally but also in an interview you might found find that some of the code you have is repeated either it's repeated you know literally the code is the same like you're doing the same thing to different variables or just parts of the logic are repeated like maybe you're doing a null check or you're passing you know you're doing some kind of string manipulation that's similar in multiple parts so if you notice those kind of similarities or repeated logic in your code try to create a separate helper function that just does that logic and then call that helper function from the main function you've created for your interview so that that process is uh i think it comes from algebra like factoring things you could sort of factor out the logic by saying here's these two things that are common put it into some common function that you call in both cases and tommy a few folks have asked whether they should be commenting their code in interviews yeah that's an interesting question i i will say your interviewer preference might be different but depending on the interviewer me personally i wouldn't spend a lot of time on that because you don't have a lot of time in your interview you're already narrating really naturally what your code is doing and so if if you're just typing on a comment that matches exactly what you're saying that's just describing what the code is doing it's probably not a great use of time depending on your you know your style in your interview style maybe you know adding like a quick doc string to the function or just a comment at the top of the function that explains what it's going to do can be helpful but in general i wouldn't spend a lot of time commenting the code as you go given the setting and we do have time for a few more questions in fact if you'd like to raise your virtual hand and zoom by clicking the raise hand icon happy to call on some folks if you have your video and microphone on and tommy in the meantime a couple of folks asked among them aisha if you face a problem while writing your code and can't think of the solution even after a hint what can you do yeah i i will say it it happens i've hit i've hit many a wall in an interview i think you know even if the interviewer gives you a hint and you think about it i think it's super reasonable to say okay i see what you're saying but i'm i'm not sure how that applies to the problem or i'm not sure i totally follow can you give me some more information basically just it's a conversation you know your interviewer isn't you know there to be a to be a robot or sort of like try to put you in a situation that's tough they want you to succeed and so if they're trying to help you and they haven't yet helped you yet just keep asking for more clarifying questions or more hints until eventually you get unstuck but sometimes you know i've been in interviews i'm like hey i just just didn't get it the interviewer had to like totally hand hold me through the prod to the problem which is usually what'll happen they'll just give you hints that are like so obvious or like writing the code for you and then you know i got rejected and that's it happens but the more you're making it a conversation a dialogue the more opportunities you have to be helped okay and we have a hand up from yashvi if i'm saying that right yashvi if you'd like to say hello and what your question is and i'd like to ask tommy sir if what was the best thing one can do to impress any interviewer probably in adequates or something like that sure so if i had sort of like one thing that would impress an interviewer the most for me the most important part of the interview is communication so if i were to focus on one thing or the thing as an interviewer that i come out of interview i'm like wow that was great that thing is probably because they communicated really really well whether that was asking clarifying questions just explaining their approach or the way they thought about the problem that's usually way more important to me than oh cool they use this crazy like python built in i didn't know existed communication is way more important than that and a question from karthik if you'd like to say hello where you're from and what your question is i just have a question uh for a beginner level uh technical interview is clean code really matters like the super most optimized code really it matters or uh like you know like as like an optimum level code or an ordinary level code uh i just want to know that yeah so i think the number one thing that matters is the process so the way that you get to that code and the way you're reasoning and communicating that's way more important than how perfectly optimized your code was and then the other thing i'll say is that the expectations the interviewer has is going to vary based on your experience level so you know let's say i'm asking a question of someone with 20 years of experience i'd expect their code to be better than you know i'm interviewing someone for their first internship so i think it's going to vary as you're practicing i'd say write the best code that you can uh you know make sure that you're thinking about is the code clean but uh like i said the process and your thought process communication is is always going to be more important than the code you write michael would you like to say hello and ask your question next yeah hi my name is michael fairfield connecticut um so this is kind of just like i had to think a little bit about this question because you guys covered so much and i felt like any technical questions i had were already answered so anyway i'll just ask you um i'm a pretty big dude you know like i'm 6'4 260 pounds sometimes i don't have the nicest face on you know what i mean so what can i do when i get to the interview and i'm nervous and i just look mean what what are some things that maybe i can do to make my interviewer feel a little bit more comfortable and know that you know we're here trying to accomplish the same goals yeah it's a great question i think i'm also someone who i'm pretty bad at like hiding my emotions uh which you could probably see as i'm talking about resumes and things i'm tired of seeing on them uh i think the biggest thing is just you know the interviewer can tell when when you're really nervous like sometimes i go in an interview and i'll be like oh man this person i can tell within like 30 seconds they're like super nervous uh me as an interviewer i'll try to like keep it light and you know help calm you down or make you less nervous not every interviewer can or wants to do that um the number one thing is just the more practice you have i think is really important for some people having like a glass of water like available to them can be really helpful so just like bringing a couple water bottles if it's on site i have a water bottle here just having that ready taking a deep breath before you start talking or before you turn on that zoom call makes a huge huge difference um so i think i think little things like that every everybody is a little bit different about sort of like you know how to make them feel left nervous but i think you know how nervous you are on your first interview and how nervous you are and like your 50th is like such a big gap that you just sort of have to like pay that cost go through a bunch and then for for many people just eventually it starts becoming less and less nerve-wracking sarah would you like to say hello and ask your question next hello and first of all thank you very much for your information and i want to ask that how can we explain our job gap before starting this field rt career i had a different experience in different fields and then i gave a break like five years after that five years i'm starting to searching for a job in it fields so how can i explain this gap in my job experience thank you yeah it's a great question and and something i'll say is that the experience you just described of coming from a different field or taking a break in between roles for some number of years it's becoming more and more common so you know maybe 10 years ago this was something you really had to worry about people were only in engineering if they had a degree in engineering i think now so many people are coming from other career paths and going through boot camps or online courses or switching careers into engineering that it almost doesn't need to be explained as much today as it would many years ago but i would just sort of be honest i'd say you know here's my background it was in some other field could be totally unrelated to software totally unrelated to engineering talk about your experience there the impact you had the the sort of what you learned and then um you know just talk about why you want to switch to engineering and what you've done so far and why you're excited about it why you're excited to learn more and help a company and have impact but i would say my short answer is i wouldn't worry too much about it and then to explain it to sort of be honest about what you've done in the past and why you're looking to switch and nissarg if i'm saying that right would you like to say hello and ask your question uh my name is mr kudvanti and i'm from india and uh greetings to tommy sir and david sir and everyone else so over to my question if you get stuck on a problem uh what is the optimum time to think over it before stating that we are unable to solve it yeah that's a good question so what sort of like at what point do you do you ask for the hint um i'll say one thing to keep mine is just sort of the total duration of the interview so if you know you're in a 45 minute interview versus you're in a two hour interview my general heuristic is something like three to five minutes if you've made like no progress in three to five minutes that's when i would try to ask for a hint sometimes just as you're sort of thinking out loud you'll eventually have run out of things to say because you've run out of things to think of and at that point too if you find yourself being silent or just not making any progress you know think for a minute or two and then say actually i'm not sure can i have a hint so if you're thinking it's you know in the ballpark of like 20 to 30 minutes i'd say way lower than that but i also would say you know much greater than like 30 seconds because you'll give yourself a few minutes to actually process it and think we have time for a few more questions do feel free to raise a virtual hand and turn on your camera if you'd like to ask on camera or re-paste your question in the chat if we might have missed it we're doing our best to field as many as we can uh yuvraj if i'm saying that right would you like to ask your question so uh hi guys my name is raj and uh i would like to ask a question from a entrepreneur's standpoint right so a lot of companies in the recent times have you know changed the whole paradigm of hiring people and all that so how do you expect that it might change furthermore like even as a student if i look at you know things have changed you know from going offline doing interviews and all that to going online due to this pandemic and all that so do you think things could change further or this is the like the top that was or something like that yeah it's a good question sort of how interviews how evolved and where they're going um certainly these virtual interviews are way way more common um you know many companies even if you excuse me even if you could come on site just so much more convenient to sort of interview someone remotely rather than traveling you know six hours in a plane being tired at 9am the next day for the interview which is not fun so that's definitely a big one i think that's a trend that will stick i think many companies will still do on-sites but i think before you know i remember the companies i've worked at and friends have had like a hard policy on we have to meet you in person before you hire me like just cannot join the team unless we meet you in person i don't know why but that was a policy i don't i don't think you'll see very many things like that anymore um i think another thing that's been changing is that many companies are asking more of these practical questions especially to folks with more experience um and i think that's that's good and bad i think for many folks coming out of university or or new grads asking them a practical question in many cases is worse just because they haven't ever written production code or launched a production website and so asking somebody to do that it actually doesn't give you that much signal and asking an algorithms question to a student who's taken algorithms classes and they're really good at that can actually be higher signal and so where i see the shift coming is that if you have the experience of building these systems we're going to ask you about it and maybe ask you to build something similar and if you don't then then we're not where i think you know a few years ago there's this blanket everybody has to do whiteboard questions because whiteboard questions are the be all and all and i'd say they they have a purpose i'm a lot of people are like whiteboard questions are always bad they're useless i don't subscribe to that at all i've interviewed so many students who do better on these than they do on the you know build a website questions so they have their place and i think they're becoming more more of a specialized thing than a blanket part of the process and tommy a couple questions that have come up a few times now in the chat relate to folks who either don't have much work experience because they're just coming out of college or they're older and have gaps in their resume for some reason are what kinds of personal technical projects should people in those situations take on and when it comes to languages given that they might have a choice of languages which languages should they be picking up for interviews yeah it's a good question i'll i'll start with the second one i would pick up languages that are more popular so i think that takes the form of python or javascript would probably be my my top two um those are languages you could use to you know build a little web application or visualization or a command line application these are you know i wouldn't try to you know pick up as a first language something like haskell or rust or some of these more sort of less mainstream and have a higher barrier to entry so python or javascript are good ones to start with um and then for personal project i would say build something that's interesting to you you know my best advice to people is that everyone in their day-to-day has some problem that they're dealing with maybe it's taking notes in class or um you know organizing some files in their their laptop or you know everyone sort of has these little problems that they deal with and just write a little app to solve them for yourself maybe it's um you know i remember like one of the first things i built was this little like weather visualizer because i like didn't like the weather.com things like oh let me like use their api and just build like a little weather app and i just like had that like on my you know in my room where i could like wake up and check my little weather app and it was like you know there's thousands of weather apps out there but like who cares it was like a problem that i thought was kind of interesting and i went and solved it so you know everybody has those little things that are interesting to them so um pick something that's interesting to you and write a little you know command line application or web application to solve it a few few final questions here uh sarah would you like to ask your question and tell us where you are in the world hi i'm sarah from algeria and i was wondering do you think i could ask all the questions that are in my mind about the work in the company to my interviewer even after i know that i failed in my code and writing the code and solving the problem they'll have the right to ask them or not oh like at the end of the interview sort of like when they asked you have any questions for me even if you did you know you know that the interview didn't go well yes yeah i think i think so i think you should always you know they're they're they're still interested in giving you a good experience with the company even though you didn't pass this interview who knows you might come back a year or two later interview again and then do fantastic and so if the interviewer you know can give you a good picture of the company now that might help you say oh you know i will go reapply again because i really like the person i talked to and i've learned a lot since that first interview so yeah i would definitely say you know it when when you have a bad interview experience it happens to everyone try not to get too down on yourself uh you know when they ask you any questions for me i'd still ask the prepared questions you had about you know the you know their day-to-day or the things that they changed about the company so i wouldn't change any of that and then you know who knows you could you could see that same interviewer again a few years later and tomas would you like to say hello and where you're from along with your question uh what's up guys um i've enjoyed a lot and i'd like to know sometimes when it comes to the interview there are companies that ask you about your salary oh by the way i'm from venezuela at the animation so um when it comes to interviews there are companies to ask you about the salaries so is there a way to know what would be the best because i think this was not so covering like in this yeah so it's how to think about salary and negotiation generally like a way to to know what would be the best amount or because sometimes we could ask like too much or too little and are we even supposed to answer that or we can just avoid that question yeah this one this is a tough one because it's going to vary a lot by role and country and company so i can give i can try to give some some general advice that uh may or may not be you a little too us specific just because i'm not super familiar with uh all the different international conventions but um something that that is certainly applicable is before you go into a role uh try to get a general sense for what the sort of the market is paying for that role there's lots of sites online you can look at whether they be glassdoor there's another one that's in the us called levels.fyi where people just sort of publish here are the here are the ranges of you know what i'm making at this role um the company might also publish it in advance there are some sites like angelus that startup used to recruit and it's sort of a required field as how much are you going to be offering for this role so uh yeah just have some juice do a little bit of research in advance i'd say try to give a range too i think some people are like i must make you know at least an amount of dollars or i'm not interested i think that's usually not the right approach but giving sort of a general range um also sort of talking about what you're currently making in your role and if you'd like to what you'd ideally like to be making more than that you know having your current compensation can be kind of a kind of a baseline there so i think yeah my general advice is just to be you know try to be honest and try to do some research in advance and then that can help you avoid this outcome where you're asking for something that's way too low or way too high but yeah every company is going to be a little bit different in how they they handle this some companies want you to disclose what you're looking for first some companies say here's the role and the level we're going to level you out here's what people in that role and level make going to be a little bit different but the more reason the research part you can you can always do i think we have time for a few more questions hope folks will forgive if we don't get to everyone we also want to leave a moment at the end for maria and connor if you're amenable to offer just some final thoughts of your own uh but first aisha if i'm saying that right would you like to say hello where you're from and your question um i am from pakistan and um it's aisha and first of all yeah and first of all i have to say that this lesson has been great i did not know most of the things and um some things really surprised me so i absolutely enjoyed this um lesson and my question is that um does it like matter like the style of the interview does that differ if you have like a different level of experience or your level of your um education or something like that or the level at what you are like in cs if i'm like a absolute beginner or like i have done like really less experience like one year or two year does it matter like style of the interview or the interviewer itself or the assignment yeah it's a great question uh so sort of how things vary based on experience so um the general setting tends to be the same of even people with a lot of experience will still ask a question of the form you know write a function that takes this as input and takes that as output i think the expectations will vary a bit for someone who's really new to cs the problem we ask might be a little easier a little more straightforward to solve for somebody who has more experience might ask something a little bit harder and then i mentioned before something that you'll see as you have more experiences more questions that are a little more practical telling me about how you've architected some large-scale system in the past or to build something from scratch that would be production ready where for students they're usually more asking questions about um you know the things that you've covered in your courses you know many people take a data structures or an algorithms course and so we'll ask a question about data structures or algorithms i think in general you know the ideal interview and what a lot of interviewers do and hopefully they're all doing is sort of looking at your experience seeing what you've done in the past and then asking questions based on that so if you've never built a large-scale back-end system asking you to build a large-scale backend system doesn't really make sense i'd rather ask questions that you were going to get a lot of signal out of or i'm going to understand are you a good fit for the role i'm hiring for and if i just ask you something where you have no idea then i'm actually not getting any information and andrew we saw your hand go up earlier would you like to say hello and ask your question my question is can i get a job after completing university only tommy can one get a job after completing university yeah definitely there's lots of job opportunities that are especially designed for folks who are just coming out of university and haven't had any jobs before internships can also be a great way of getting a role if you haven't had any experience yet so definitely lots of lots of great roles you can get just out of college nice and can we go next to shalom if you'd like to say hello and where you're from with your question my name is shlom and i am from south africa currently in beijing my question is i studied um chemical engineering and technology so this is really new to me um i recently started my course on cs50 my question is what do i study after completing that course yeah that's a great question sort of after cs50 where do you go next i'm sure david has has thoughts on on this as well um but i would say in general for interviewing specifically any course that has data structures or algorithms written in it uh those can be really really helpful so the course is where you're going to learn you know how to do you know what what a binary tree is and you know how to implement a hash table some of which you cover in cs50 but there's sort of more advanced data structures and algorithms so i'd say those are the most useful courses you can take for interviewing and then maybe david wants to answer the more general question of where to go next yeah we often recommend that students explore another type of programming functional programming object oriented programming keywords like those as well as a good course on data structures and algorithms for instance i'm biased too because i work with a whole team here that produces courses that can be taken both before and after cs50 but maria can we perhaps ask you having been in the real world as an engineer for some time what you find found most helpful after an intro class like cs50 yeah um so i think really kind of trying to get like a breath like classes out there and exploring different interests would be good like when i first took cs50 some of my next uh classes that i took were like systems um like operating programming um you know data structures and algorithms um data visualization and i found like a lot of like the more visual and design oriented classes super interesting so definitely got a chance to focus in on that as well but definitely would say that um exploring a breadth of things so that you can really decide what you want to hone in on and what really interests you is always a good idea and i think tommy's emphasis on personal projects earlier is important because we see among online students a real tendency to take one course then another course then another course and it's never really clear when it ends and it doesn't need to end but at some point you should really leave the nest so to speak and take on some personal project pursue some work project so that you feel like you're actually now applying the skills that you've learned in classrooms uh some final questions can we go next to remington if you'd like to ask your question and say where you're from my name's remington i'm currently in um the uk in quarantine it's lovely to join you guys today it's super helpful i don't mean to focus too much on the resumes but uh it's another resume question so if i'm a student non-cs major and i've had like some internships that are not really tech related does it is it more valuable to add those to kind of fill out my resume or should i really try to like do more personal projects and then add those into my resume instead so which one would be more valuable is my question yeah i would say the if i had to pick between those two i would say the latter so sharing having personal projects that are related to the roles that you are related you're applying to are really helpful so for instance if you're applying to a web development role showing some websites you've built is really helpful uh and i'd say you know even if you only have a few that's totally fine sort of fill out the rest of your space with your prior experience but an interviewer will definitely love to see something that's related to the role that you're applying to more than you know the past experience you do have so i'd say projects first then fill out the rest with the prior experience you do have and definitely include that as well and uh shoira if i'm saying that right would you like to say hello and your question my name is i'm from india i was my question was that is keeping a smile on your face while in the interview is not going that much well so does that affect any impact on the interviewer yeah i'd say whether you know sort of someone everyone sort of knows interviews can be really stressful and so i don't think uh i think i've ever expected anyone to sort of be like you know totally happy and not you know not stressed the whole time um so i would say you know the the best it sort of all comes down to communication i think as long as you're communicating clearly and you're having a good dialogue with your interviewer and you're you're able to share your ideas and and listen to feedback from your interviewer and sort of hear their hints um i think that's the most important thing but you know everybody is everybody's really nervous and i wouldn't uh i wouldn't recommend anyone trying to like fake how they're feeling or you know sort of like pretend to be feeling a certain way when the reality is that everybody knows that it's nerve-wracking and so interviewers don't expect you to be doing that anyway and it all just sort of comes down to communication as long as the communication is effective that's the most important thing let's go lastly to uh uh pawan kumar if i'm saying that right my apologies so um thank you so much for this opportunity so uh my question is more of on the system design level so yeah we have somehow we did so much hard work for for the billion years and somehow we were able to you know break the coding interviews but then we have another phase called system design where uh like someone with my experience i have a 10 years experience i live in united states and it's you know though i have experience when it comes to their questions on you know uh how do you how do you design a facebook how do you design a twitter yeah we design things in our site but it doesn't mean it's gonna be that level so can you please give me some idea of how do i prepare for the system design interviews yeah for sure i'll give some quick thoughts on systems design interviews um so generally speaking what we're looking for in a systems design interview is often something architectural so you know for example you mentioned sort of how do you build the facebook news feed for instance so we're not looking for precisely like you know i would use zero mq with the fan out architecture and a multi-layered redistribute for caching like you know if you could say that that that's great but we're more concerned about architectural things like you know here's what the schema of the database would be here's how rows are written to the database here's where the caching layers are what's being cached here's what's being read from those so it's almost like if you the goal of the system design interview is is kind of to have a diagram out on a whiteboard either verbally or literally that sort of explains all of the major components of the system and and how they interact and that's much more important than you know picking the individual library or the sort of implementation details within that diagram i think if you can speak to technologies you have used in the past and so you know in the past we use kafka for message passing and here's some things i liked about it but here are some ways we're kind of broke down and things like that that experience is really valuable um but for system interview we're very we're almost never looking for some like really precise answer the the other thing we're also not necessarily looking for is exactly what part of the system you design in many cases it's really intentionally ambiguous um like one that i've got in the past is just how did you make google maps end of question sort of like turn it over to me and that could mean anything right that could be the front end that could be like how do you implement all the the scrolling it could be like the how do you store all of the map like there's tiles of different elevation levels and and um resolutions how do you store that it could be how do you do like google maps includes routes like how do you do route planning and traffic and it was sort of intentionally ambiguous and the interview was like oh i don't know whatever you want to design like do it like you've got an hour let's just kind of like see what we can do um and so i'd keep that that in mind as well that a lot sometimes it might feel like the interviewer doesn't have anything in mind and it's because we don't we just sort of want to see where you gravitate to because you're naturally going to gravitate hopefully towards the thing where you have the most experience and where you can design the best thing so yeah so really focus on that architecture focus on what are the components of the system how do those components interact what are the abstraction barriers between those systems then if you can talk about implementation details like frameworks or libraries or patterns you've used in the past then you can do so but we're really most mostly interested in architectural decisions and tommy spunden's question was about what should you do when you get frustrated and stuck with coding yeah i think you know in an interview like i said it it happens to everybody you know it'll it'll happen to you it's happened to me i think you know just taking it taking a deep breath uh you know taking just a step back you know just 10 seconds take a step back and think and and calm yourself down as best as you can you know take a glass of water if they have one if they don't bring one so you have one um and then just sort of you know ask for a hint i think you know a lot of a lot of interviewees when they get frustrated they sort of get angry or sort of get mad and i think you know it certainly might happen just try to you know as best you can try to take us take a step back and sort of you know just ask for help in a way that's sort of keeping the conversation light and you know not not becoming overly angry but it certainly certainly can happen and has happened to me and people i've been interviewing in the past so um yeah just i would say if you get frustrated just sort of ask for a hint take a deep breath and just remind yourself that everybody fails these things it's not just you i hope folks who still have their hands up will forgive if we didn't get to all questions but in our remaining minutes here just wanted to give maria and connor and then tommy the final word with some final advice maria yeah i really would just say um don't be worried or scared when you mess up i have messed up so many interviews and i sometimes still think back to them and i kind of find them funny now thinking back because um i really just put so much pressure on myself that it even prevented me from doing well and showing what i knew well and actually thinking clearly in the moment um and we said this a lot but the best way to do that is to really just practice and put yourself in those high stress situations to get yourself more used to them um and um really believe in all of you uh especially like in coming to this i think you're taking like the best steps that you can um so it really is just about taking this and like these guidelines that we shared today and just practicing and really like mastering everything so thanks so much for spending uh the past few hours with us thank you maria and connor yeah i i definitely agree with that i i would say the biggest thing is to even though it's very difficult to try and be as relaxed as you can um try to have a good outlook on it one thing um that i have i think i've found out over the last couple of years that i had wished i had known going into it is that a lot of the interview process is a bit random um so there can be like like you might get a question that you feel really confident about or a question that you just have no idea what to do and there can also be interviews where you feel like you did really well and then you don't get into the next round or interviews that you feel like you bond and then you do get into the next round um so that i think that's kind of helpful to know because like even if you struggle with a question for a while um it's not a good idea to like kind of give up on that interview you want to keep trying like keep interacting with your interviewer and um and you never know what's going to happen thank you as well and thank you to all of the team here behind the scenes who've been making this possible and certainly tommy who prepared so much of today's materials along with maria and connor tommy final advice you'd like to leave folks with final advice i'll say don't don't give up i'll uh i'll never forget my first interview where i was interviewing at a big tech company and we're in a building with an elevator and the two two people from the interview my interviewer and someone else in the company were in the elevator and they were talking about how bad i did in the interview like this kid was such a joke and i walked into the elevator and then took the elevator down 10 floors with them as they just sort of like stared at me and everybody knew it was going up what was happening uh so i'll never forget that it happens to everybody definitely don't give up you can fail a ton of interviews before you eventually succeed and that's totally okay everybody goes through that so yeah you might feel like this is impossible who can possibly do this you can just don't give up and you'll get there thank you so much tommy thank you for joining us today we'll see you online for cs50 again soon

Channel: CS50

Views: 7,964

Keywords: cs50, harvard, computer, science, david, malan

Id: TzdajQHS7xA

Length: 152min 58sec (9178 seconds)

Published: Tue Oct 12 2021