2025 EES Capital One: Nailing A Technical Interview: AMA

Hi everyone, I’m Dana with CodePath and we are excited to welcome you to our next breakout session. Before I introduce the session, just a few reminders to utilize the chat and keep your comments relevant to the session, please. And also take a minute at the end of the session to give us your feedback.

So with those reminders out of the way, I’m excited to introduce this session, interview prep 101: Tips and Tricks to nailing an interview with RNS. Hello everyone. Thank you Denia for the introduction.

Hello everyone. It’s good to see you. It’s good to be back at EES again.

I I I presented at ES last year, presented at ES New York. So, I’m really looking forward to doing this again with y’all to discussing going through interviews and and how to nail them. I know interviews is is what we’re kind of all here for and I know the technical interviews are really stressful and really terrifying.

So, I’m really looking forward to going through that with you guys and and getting started. So, Mario, can you bring up the slides? Perfect.

To read my mind. All right. So, let’s just let me just tell you a little bit about myself so that I’m not like a complete stranger danger up here and you’re like, who’s this guy presenting to me?

So, my name is Arya Nes. I’m a senior software engineer at Capital One. I’ve been here since 2021.

I have my career journey up on the slide because I know it’s a little unique. I actually started off there as a contractor before getting promoted to a to a software engineer a year later. And then a senior software engineer the year after that.

I put that up there because I know it’s it’s a bit of a unique and weird career journey. So, if you have any questions about that or anything else in this presentation as I go through it, we’ll be doing a Q&A at the end. Just make sure to ask your questions in the Q&A tab and then upote the questions that you think are the most relevant and then we’ll pull them up and we’ll go through them together at the end.

So, think of questions as you go and fire away at the end. I’ve also been volunteering with CodePath for for many years, pretty much ever since I started at Capital One. So, I’ve been doing resume reviews and mock interviews.

I was a TIP 102 coach for a few years as well. So, if you want to do any of those things, you can find me on LinkedIn by just my name. It’s just RJS.

Type it in, connect with me, and then if you want me to look over your resume, happy to do so. If you want to do a mock interview, I’ll try to schedule one of those with you. Anything you need, I’m really I’m really here to help offer some advice for you.

So, hit me up if if you want any of that kind of support or advice about jobs, job hunting, resumes, etc. And then before really before we really dive into the meat of this presentation, I have a quote up there from Michael Jordan, which is actually from a Nike ad which I only recently learned about about failure. And it’s about how all anyone who’s ever succeeded at anything before has failed at that thing more times than they can count. And I put that up here because I’ve bombed more technical interviews than I’ve succeeded in.

Everyone you’ve ever met has bombed more technical interviews than they’ve passed because you’ve all applied for more jobs than we’ve gotten. Failure is part of the learning process. And a crucial a crucial thing to keep in mind as you go through the technical interview process is as as things don’t go well because there will be moments when they don’t go well.

You will not you will not succeed on the first try. You may not even succeed until the 10th or 20th try. Failure is not the thing that defines you.

It defines how you learn, how you come back from it. And the things you take away from it. So, I I’ve put together this presentation to help minimize those chances of failure as as you’re going through a technical interview to really help you settle in and think of it as a step-by-step process you can get through.

But something I want you to keep in mind as you go through any technical interview or really anything in life is you’re going to fail and that’s okay. It’s just more about how you respond from it and how you learn and grow from it. So, don’t feel bad.

Don’t don’t think of yourself as a failure. That’s just part of the learning process. But before we actually get to technical interviews themselves, we have to get through how to get to one, right?

And and a crucial part of getting to one is is applying for jobs. And applying for jobs blindly is terrible. It’s terrifying.

You’re going through the automod filters of companies and they’re giant bots that are filtering for keywords and resumes. How did you get through them? And you can try to get through them by just applying for as many jobs as possible.

And that’s a Dallas strategy. There’s something better you can do. And I titled this the power of friendship.

It’s really about networking because if you can establish a really strong and supportive network, it’s going to make your entire job application process easier. I always like to think of my mother when I think of networking because my mother is is really high up in the financial services world and she hasn’t formally applied for a job in like 15 years. She’s always found her next job by networking through LinkedIn.

So what you’re going to do as part of this part of this, you know, entire summit is you’re going to meet a lot of new people and you’re all going to add each other on LinkedIn and then maybe never talk to each other again. And what I’m trying to tell you is not to do that. Because if you can keep up with the people that you meet here or at any single event that you have going on, that networking and that network you’ve built for you will come in handy.

And it might come in handy today, it might come in handy next week, it might come in handy in five years from now. You don’t know when that network is going to come and come out for you. But you want to keep it on tap so that you can use it whenever you need it.

So you might be helping someone now and they might help you in five years or vice versa. So referrals for jobs do a lot better than blind applications for them. So make sure any chance you get to actually build a network rather than just meeting people, connecting once on LinkedIn and then never speaking again.

And something a career coach at Codepath also pointed out to me before which I want to pass along to you guys as well is you can leverage your existing network for feedback. So something we’re going to talk about in the beginning of the interview is when you get asked that that very basic intro tell me about yourself. And having that answer prepped and ready to go is important, but you don’t want to practice it for the first time on an interviewer.

You want to practice it for the first time on a peer. So, if you have friends you trust either that you make in the session or just in general, leverage them for feedback on things like your elevator pitch or things on your interview skills, interview each other. You can make it kind of fun, kind of serious at the same time.

Any anytime you can leverage your network for either practice or for job connections, the better. Because getting getting your foot in the door is by far the hardest part of the interview process because once you’re in and you’ve made it past the automod filter part, you’re going to get to the next portion of it. And I want to clear up a common misconception I think I hear a lot about technical interviews and why we have them when the online assessments exist.

So let’s go through them. What’s actually the difference between an online assessment versus the technical interview itself. And the very key difference I like to think of it as an online assessment is just what do you know?

All right. It’s like taking an online multiple choice quiz for a class. It’s really just about can you regurgitate some information at me?

And spoilers, most people don’t do so well in coding assessments anyway. They’re really just meant to be a broad test of of information that you’re familiar with. But the interview itself is more like giving a presentation in class.

It’s it’s more of a test of how you solve problems, what is your critical thinking skills like? How do you approach solving a problem? How do you explain your answers?

And how do you how do you demonstrate to someone that you’ve just met not only interpersonal skills by being able to connect with them, which is something that we’ll talk about a lot on these slides as well, but also that you really understand everything you’re talking about. So when you’re getting into a technical interview, don’t just think of it as, oh, this is just an online assessment. Again, I can just sit here and silently code out an answer because that’s not the point.

If that was the point, we wouldn’t do them. And yes, I I work really hard on these memes. So, if you do like the memes, do let me know.

I’m really I I’ve worked really hard on these and I’m very proud of them. So, I’ll always take any fire actions to my memes. Thank you.

Thank you. So yeah, anytime you get the chance to distracted myself, anytime you get the chance to prove full understanding, you’re going to do it. And that’s why we do technical interviews as opposed to just doing online assessments.

So once you’ve made it through the networking and you’ve gotten your foot in the door and you’ve made it through the online assessment and now you’re just up to the interview itself, let’s get into how one nails an actual interview. And it’s going to start with things that happen before the interview itself even begins, which is the setting for your interview. So you look at my background right now, it’s clean.

My camera decent enough, my audio decent enough. Make sure that when you’re doing your interviews, it’s the exact same way. Don’t Don’t be I I once time did an interview with a candidate and they were doing it like in a cafe like a public cafe like a Starbucks kind of place and there was background noise and there were people walking in at a frame.

The whole thing was weird and confusing. Don’t do that. Like do your interview in a really in a nice quiet secluded room.

Both for me as the interviewer so I’m not like what on earth is happening in the background and I’m more interested in that than you as the candidate. But also because for you, you’re going to be more focused in a nice clean environment. So, good ca good lighting, good camera angle, clear audio.

I love my cat. Don’t want my cat on my keyboard in these at these moments. Don’t have your cat on your keyboard in these moments either.

Just remove all distractions possible and and make sure you’re in a really nice place to take your interview. Because once you have your setting established, we’re going to move on to actually joining the interview. And I don’t know about y’all, I’m a bit of an anxious person.

And when I know I have an interview coming up, I’m joining like 10 minutes early. And the problem when I join like 10 minutes early is I’m going to sit there and the nerves and anxiety are going to start to build, right? I’m just sitting.

I’m waiting. I’ve turned my phone off because I don’t want it buzzing and distracting me or anything or having it look suspicious. And I’m just sitting there like this and I’m waiting and I’m waiting and I’m waiting.

And it’s terrifying, right? My heart rate starts to build, my nerves start to build. And I know anxiety isn’t a one-izefits-all solution for everyone.

So, I’m not trying to pretend out here like it is. So, what I’ve put on these slides are are two things that work for me when I start to feel that anxiety and that heart rate build because you really want to begin the interview in the most calm state possible. And there’s two things I like to keep there’s two things I like to do.

One is keep in mind a mantra of self-belief. So, when you’re sitting in an interview, confidence really is is key. And you got to you got to walk in, they’re like, I own this.

I deserve this. I put in the work to for this job. I put in the work for this interview and I’m going to nail it.

You cannot walk in there was a cloud of self-doubt because it’s going to reflect in everything you say and everything you do. Be confident and believe in yourself because you should. Positive affirmations for yourself.

Really important, really powerful. And then two because heart rate is heart rate. My when I feel mine starting to build and I’m feeling short of breath.

I do I used to I used to Google a lot of like breathing techniques, calming exercises for me. Basically just doing meditation yoga things. I found that the Navy’s 478 technique really works for me.

So you breathe in for 4 seconds, you hold it for seven and then you exhale for eight. I do that a couple times and I really feel my heart rate start to settle, my nerves start to settle and that’s that really works for me. I’m not going to pretend both of these things together or either one in isolation works for everyone, but any techniques you can use yourself that you know work for you.

Whether it’s a pep talk from a friend, even like calling a friend five minutes before and you’re like, "Yo, I have five minutes. Talk to me. Prep me.

Hype me up." Whatever works for you, do it. So that when that interview starts, you walk in feeling like a million bucks and you walk in feeling calm while doing so. Because once the interview starts, you really, really have to be on it immediately because the first part of the interview is small talk.

And I know that absolutely nobody likes small talk. No one. But it’s going to happen because when the interview starts, it’s going to start with the interviewer guiding small talk with you and being like, "Hey, how are you doing?" And if you’re feeling nervous and you’re feeling you’re already feeling a little scared, that’s going to be hard to answer with anything other than good or okay.

Like, "No, no, no. You need to turn this part of the interview into a conversation as fast as possible." Because something I’m going to harp on a lot throughout this presentation is you really want to build a personal connection with your interviewer. It’s part of what I was mentioning about online assessments versus the actual technical interview. We’re testing interpersonal skills, too.

Even if you don’t think we are, because your ability to connect with someone that you just met within an hour is really important because you’re going to have to connect with people on the job really quickly all the time. So, the interviewer is going to ask you softball questions like, "How are you doing? How are you feeling?" Give an actual answer.

Give more like a, "Oh, you know, I’m I’m feeling a little nervous, but I’ve prepped as much as I can, so I’m as confident as I can be, and I’m looking forward to getting started." And then, this is really important. Don’t just leave it at that. So, it’s a one-way conversation.

Hit them back with a how are you? How’s your day been? How’s your week been?

Turn it into an actual conversation. It’s okay if the interview gets derailed for a couple of minutes because you guys are having an actual conversation and discussion. That’s totally valid because the quicker you can get the interviewer to view you as someone who’s friendly and an acquaintance rather than just some candidate that got booked at interview, the more likely they are to help you as the interview goes.

And odds are, unless you’re a savant, at some point in the interview, you’re going to need just a little bit of nudging and advice as to how to help the interview go along. So, make sure to hit them back with questions. Turn it into a conversation.

And this is something again I mentioned earlier with leveraging your network, but you might need to give that classic elevator pitch. They might just ask hit you with a so tell me about yourself, which is the most classic opening to an interview ever. Kind of like I did at the beginning of this presentation.

And when I your your elevator pitch and response should be like 35 seconds or less. And it really should be something as simple as here’s the things I already know, but here’s also how I’m humble and willing to learn more. So, for example, if I’m applying for a data engineering job, and I mentioned that that’s more along the lines of what I do, I’d mention, "Hi, my name is Arya Nes.

I’m a I don’t know, make up something. I’m a rising junior at X University, whatever it is." I I’ve I’ve worked on projects that use Python and SQL before and I’ve worked at integrating them together. So, I have some really strong background in those technologies, but I also know that your company uses them in ways that I haven’t been exposed to yet.

So, I’m really looking forward to growing and developing my skill set with those technologies and any new ones you can introduce me to. That’s an elevator pitch because it shows I have the skills that are needed to survive this job and and excel in it, but I’m also willing to learn more and grow as a candidate, as a person with your company. That growth mindset everyone likes to talk about.

That’s how your elevator pitch should work and that’s how you should kind of structure your your dynamic, I will say, as you come out with it. Show what you know. Also, show that you’re willing to learn more because this little small talk is the last little small talk you’re gonna get all the way up until the end.

And it’s really important to establish that that connection and that I’m I belong here attitude now right at the beginning because once you get through the small talk, the interview is going to stop things whatever conversation is happening and be like, "All right, let’s get into the interview." So, they’re going to read you off a question or maybe they’ll have to have you share your screen. The question will be on there, but they’ll probably read it in their own words anyway. This is something I really, really want to stress.

As they’re reading off the question to you, take notes of your understanding of the question in the IDE itself. And I put that in bold and italics for a reason. And you want to do that for two very, very crucial reasons.

One, you only get credit for the work that you put in the IDE. So, if you’re taking notes off to the slide in a notepad, that’s so great for you. But as the interviewer, I’m not going to remember that in however long later I’m looking back at these candidates and comparing interviews.

I’m going to look at the the screenshot of your saved code that I have. So, put notes in the ID itself so that you can get credit for the fact that when you’re asked to do a task, you take notes on that task immediately. And also, this is really important for the modern day and age we live in.

You don’t want to get accused of cheating. So, if you’re if you’re looking off to the side like this or you’re looking off at monitors, you’re scribbling off of something to the side, I want to believe that you’re not cheating and I want to believe that, you know, you’re just taking notes on a notepad to the side. But because I don’t know that and I know how the modern industry works for remote interviews, I can’t fully trust that.

And you don’t want to have me be suspicious like, "Hey, can you hold up what you’re writing on for a second so I can verify that it’s a notepad and not like a phone?" just avoid that altogether and take notes in the ID itself so that no one can even think that you’re cheating. And as you’re taking notes of the question, the interviewer is going to read what you’re writing down. And again, this is part of why you build that connection as quickly as possible in the small talk portion at the beginning.

You want them to correct you if you get anything wrong and they can only correct you on things they can see and things they can hear. So as you’re taking notes on the question, if you’re getting anything wrong, you want them to be able to correct you ASAP. You don’t want to start off with the wrong impression what the question is.

And we’re going to come back to that a lot throughout this presentation as well. So, let the interviewer intervene on your behalf because once they finish reading the question and and you’ve taken notes on it, they’re assuming that you understand the question and that you’re ready to start thinking about how you want to solve the problem because once you get through the reading of the question, we’re going to basically get into the ump portion of of the interview. And I really like the UMP method, the umpire method from Codecraft because I think it’s a really good structure for answering interviews.

So we’re going to get to the UMP portion, right? So, first you’re going to summarize the question out loud in your own words. Just verify your understanding.

Verify that your notes are accurate. Then you’re going to think through the approach you want to take out loud with your own words. But it can be a conversation and the interviewer can correct you if you’re thinking of the wrong algorithm or you’re thinking of the right algorithm, but there’s a better way to do it.

Whatever it is. Think through all of that out loud so it’s more of a conversation and not just an awkward they them sitting there silently and you sitting there silently while you think about things. And then once you once you’ve figured out the approach that you want to take and this is important and so I put in all of the formatting, you’re going to want to pseudo code out your answer.

And you’re going to want to do this for a multitude of reasons, but the the two main ones that I want to that I want to focus on here is that one, interviews, again, this comes back to the online assessment versus technical interview portion of things. Interviews are meant to be a test of how you think through problems and your critical thinking skills and your problem solving skills. And they’re not meant to be tests of do you know this random syntax?

Because I Google syntax all the time and I will for the rest of my career. That’s life. So what the only way you can demonstrate understanding whether you know syntax or don’t know syntax is by pseudo coding out your solution.

So even if you know absolutely none of the syntax because you’re stressed and you’re blanking, if you can at least pseudo code out that you know what the algorithmic approach is to take if you’re doing it correctly, then you have a lot more credit than someone who got nothing on the paper. And again, all in the IDE so that you get full credit for your work. So once you’ve chosen your solution, pseudo code it out.

Put everything you can in there. And it will also come in handy at the end if you’re in a time crunch because let’s say let’s say you’re, you know, you’re pseudo coding it out. You’re discussing the approach with the interviewer and you start running out of time at the end.

Even if you don’t get to fully finish implementing your solution, but you at least got the pseudo code version of it out, you’re doing a lot better than candidates who got nothing on the paper on the page. So this will come. So pseudo code out your solution as quickly as you can.

It will help you out for time crunch problems and it will help you out for for time crunch. Wow, my brain just blinked there for a second. I’m sorry.

It’ll help you out for time crunch problems and it will help you out in just in terms of scaffolding out your solution. That’s the word I was looking for. Because if your mind starts to blink as you’re going through it, it’s a lot easier to just reference back the things you’ve already thought through when thinking of your solution and just reference that back and be like, "All right, I did think of this already." and then you can just look back at it again and and figure it out from there because once you finish tuno coding out your solution, you’re going to have to actually implement the thing.

And then know this is the actual part of the interview that stresses people out the most. But if you’ve done everything we’ve talked about up until this point where you’ve taken notes on the question, summarized your approach, and pseudo coded out your approach, this part really shouldn’t be as bad. It’s just filling in fill in the blank of syntax.

So something I want to highlight here as well is that as you’re writing out that syntax, comment your code as you go because commenting is an industry standard and co candidates who commented their code do better than candidates who don’t. Very often in an interview if two candidates are really tight or even multiple candidates are really tight. We’ll go back and compare their answers to the interview question that we gave to say who did it better and the candidate who commented their code pseudo coded it everything I just said before does better than the candidate who doesn’t even sometimes if they haven’t actually finished their solution because a big part of the industry is readability and reproducibility in code and if your code is commented even if it’s not fully complete but I can look at it at a glance and fully understand everything you were doing and were trying to do versus someone who put together an algorithm that kind of made sense but isn’t intuitive to read and it’s not talented.

So I have to spend like 10 minutes just understanding what they did. That’s worse because in the job I want to be able to read code that works and is simple. It’s it’s easy to read and it’s understandable.

And part of doing that is commenting it and pseudo coding it and scaffolding it and everything we just talked about. So as you’re implementing out your solution, comment it as you go. It’s an industry standard and it will help you out with just thinking through your solution as you go.

And again, this builds back on the on the connection and conversation point that we’ve been discussing this whole time. If you’ve built the whole thing into a into a conversation at this point, even as you start to even if you start to struggle in the implementation because your mind is blanking on the syntax, if you built a good connection with your interviewer up until this point and if you and if you know you’ve done all the commenting and pseudo coding and scaffolding, then your interview is a lot more likely to jump in and help you with their mind of syntax because they know they’re not giving you the answer. They’re just guiding you towards an answer that you already know.

So comment it, verbalize out loud as you go. You never want those awkward moments of silence while the interview is sitting there and you’re sitting there while you think through a problem because not only can they not help you if you’re silent, it’s also just uncomfortable and weird. So constant stream of consciousness.

Just verbalize every thought you’ve ever had in your brain out loud. This is a slight a slight tangent from this point, but a way to practice this skill is when you’re practicing questions funniest coding you’ve ever seen. Stop.

But thank you. But something something you can do to practice the skill on your own time is as as you’re practicing lead code questions on your own because we all going to practice questions. No one just knows everything at the outset.

Practice doing this. I know it’s going to sound weird, but practice doing this with yourself as you’re answering questions. So, when you read elite code question and you start answering it on your practice IDE, practice summarizing the question in your own words.

Practice pseudo coding at and it’s going to sound weird, but practice just verbalizing every thought you’ve ever had out loud as you answer the question. It’s going to sound a little bizarre. You’re going to feel weird and silly doing it, but you want to do that in practice so that when you get to the actual interview, you’re not reminding yourself to do those things, right?

You’ve established such a clear habit of doing those on your own that you just do it. And you do it without having to think about it too hard. So practice, practice, practice all of the skills we mentioned up until this point, especially the speaking out loud because that’s going to sound weird, but it’s even weirder in interview when you’re kind of just sitting there awkwardly in silence while things try to happen.

I promise you because once you finish implementing the solution, and this is a really key part of this, don’t say, "I think I’m done." Because I know as an interviewer that when someone says, "I think I’m done," they’re not actually sure if they’re done. And they’re fishing at an answer out of me. And you don’t want to do that.

Kind of like we talked about the beginning with confidence being key. Tell me I’m done. Like just tell me my solution is done and then I’ll know that we can begin the next portion of the interview which is the walkthrough of your code.

So when you’re when some places when you get to do interviews, you’re not going to get to run your code at all. I think very famously Google does their interviews in Google Docs. And the reason they do that is for two reasons.

One, so you don’t get syntax help from an IDE. And two, because running the code isn’t actually the point. Kind of like we’ve been talking about this whole time.

Technical interviews are meant to be a problem solving check, like how do you think through solving things? And they’re not meant to be syntax checks. So that’s why they do them in Google Docs.

So, okay. Yeah, they still do. Okay.

So, when when you’re doing when you get to this portion of the interview, you’re not necessarily going to get to run your code, but they will be giving you sample inputs to run through your code. So, you’ll be given like, hey, I have XYZ input. Does it get to XYZ output?

And can you explain to me how it does? And the reason you’re want to do this, the reason you want to do this yourself is because it demonstrates full understanding of your solution. Something I’ll get to a little later again as well is we do know leak code exists and we have to try to find a way to test candidates in a way that shows who memorized leak code solutions and who actually understands what they’re talking about and what they’re doing.

So if you can walk your solution step by step when given a sample input and show how produces the correct output, you’re going to show that you actually understand what you did rather than just memorizing it off the internet. And if that doesn’t work because you find a bug as you’re stepping through it, then that’s great because debugging is a really important part of the job. Which directly brings me to my next point is that as you’re debugging, whether you get to run it or whether you don’t get to run it, you’re probably going to find a bug because no one’s code has ever worked on the first try ever.

Probably. So, we want to see how you debug. If you do get to run your code and it’s just chucking print statements everywhere or it’s just chucking like print x variable here or it’s just print printing I’m here, I’m here.

I’m here. Whatever it is, people want to see how you debug through your solutions. If you don’t get to run it, but you get to like comment, leave comments on your code like, okay, when I’m at this portion of my algorithm, the output looks like this and at this point it looks like this.

Whatever your debugging skills are, we want to see them and we want to see them shine in interviews. When I’m interviewing candidates, if I see there’s an edge case that they haven’t caught in their code and but it’s very small, I won’t tell them about their about their edge case problem. What I’ll do is I’ll wait till they get to the walkthrough portion of the code and then I’ll be like, "Hey, I think your solution mostly is correct, but for this input, you might have a problem.

Can you walk it through with me and show me where the problem is and how you would go about fixing it?" Because I want to see how they debug and how they and how they walk through problems as well. So, you’re probably going to have to debug at some point in your in your problem solving here, unless you’re like a savant and you’ve never had to struggle with anything in coding ever. But if you’re like me and you struggle all the time, you’re going to have to debug out your solution.

And seeing how you debug out your solution is really important to us as interviewers because debugging is something that you’re going to spend most of the time of your job doing. And then once you finish debugging and you finish, you know, the walkthrough of your code, the whole coding portion of the interview at this point generally is done. And now we’re going to get to the more of the wrap-up of the of the session.

So this is where the conversation flips back again from you just verbalizing out your thoughts and talking to the interviewer talking to you again directly. So they’re going to ask you questions about your code. This is why we asked about the run and spacetime complexity.

And this is why you’ll get asked follow-up questions like okay your solution works. Is there another algorithm that would have worked in the same amount of time? You’re not going to get asked to code that unless you have like a lot of extra bonus time for some reason.

But they’re going to ask those kind of things to show that you have such a good fundamental understanding of how to solve these kinds of problems that you can you can even think of alternate solutions that you didn’t even do. So you might get asked if there’s a faster way to do it. The answer that might even be no. You’re going to get asked the question anyway.

You’re going to get asked if there’s alternate algorithms that would have worked or they might even tell you about an alternate algorithm and be like, okay, you solved this with algorithm A. If you had used algorithm B, would that have been faster, slower, or what would the difference have been? You’re gonna get asked questions like this a lot.

And this goes back to what I mentioned earlier about leak code. We know leak code exists. So we’re going to test find ways to test you that show that you didn’t just memorize the leak code solution.

And this is the main way we do it is by asking you a lot of pointed questions about the solution that you chose so that we know that you fully understand the concept that we’re asking about and how you went about solving it. And this is also really important for everything we’ve mentioned up until this point. If you did everything we did I mentioned up until now.

So if you took notes on the question, notes on the solution you wanted to take, you sooner coded out the answer, you’ll have comments in the code you were able to write even if you weren’t able to fully finish implementing solution the solution. If you did all of the above, then you’re still able to answer this part of the question. You can still be asked why you chose the algorithm you chose because you were able to pseudo quit out that you know the right algorithm to pick.

You just couldn’t remember the syntax and the movement. You can still do this very important part of the interview that shows that you weren’t just trying to memorize code and spit it back at me. So that’s why we do everything we do earlier with the commenting and the pseudo code and all of that because no matter how that’s gone and what you’ve made it up to when the interview starts wrapping it up by asking you questions, you can still do this portion of the interview.

And this portion of the interview is really really important because you want to test full understanding rather than just who memorized what at a given time because once you once you’ve gone through the wrap-up of your code, you’re not even going to look at your code at all. Like we’re completely done with the coding portion of this interview and now we’re going to get to the wrap-up of the interview where you’re the question who’s asking questions is going to flip one more time and now you’re going to get to ask questions of the interviewer about the company that they work for. So, there’s a couple style of questions that you want to aim for when you’re doing this.

I always like to ask what’s a day on the job because it’s and the reason I think it’s a classic is for me work life balance is really important. I like working my 9 to5 and not working beyond my 9 to5. So, I like asking what’s a day on the job like so that I can know, you know, hey, what are the technologies I need to know?

Do I already know them? And what’s a day look like? But also that if they mention that they do products at 10 p.m.

Twice a week, that’s fantastic. It’s not the job for me. A really important thing to keep in mind as you get to this portion of the interview is that they’re not just the ones interviewing them.

I’m sorry. They’re not the ones interviewing you. You’re interviewing them in response.

And you want to see that you’re a good fit for this company and that they’re a good fit for you for the company at the same time. So, when you’re doing this this closing smell talk, you want to ask questions along that ilk. For example, if volunteering is really important to you for certain initiatives like climate activism, you can ask if the company does anything like climate activism, volunteerism, because maybe if they’re not a company like that, then then maybe it’s not the place you want to work for.

Whatever it is that you want to sus out about the company, this is your chance to do it. And then another another style of question you can ask, this one I really like, is questions that’ll pertain to the company with relevant current news. So, for example, I work for Capital One.

Recently we just acquired Discover Bank, a very big deal, one of the largest banking deals in the history of banking. If a candidate were to ask me, hey, I I know Kaplan recently acquired Discover Bank. Did you work on that and what was that like?

That’s a fantastic question because not only does it show that they’re keeping up with current news about the company that they’re that they’re interested in applying for it, but it also just shows me that they’re generally interested in the financial services industry, which is great if they’re applying for a job in that industry. So ask questions that are relevant to the company. Ask questions that are relevant to you.

The only thing I would say not to ask is don’t ask inflammatory questions. So if you’re applying for a job at Capital One or anywhere else and you’ve recently read some negative news about that company, don’t ask the interviewer questions about that company because they’re not going to know the answer. Okay?

They’re not going to know the answer to that question and you’re going to put them on the defensive and what’s meant to be a nice fun back and forth conversation. So don’t ask anything like that, but do ask questions that are that are guided towards you learning about the company and that are that show genuine interest in what the company’s doing and the the ways involved in the current news. And I also app very much so like the confidence asking what can I best what can I best do to prepare for the role because a guy who we talked about in the beginning confidence is key and a candidate who’s like I definitely got this so how do I best prepare for this when the time comes great 10 out of 10 definitely want to hear that because then we can go more technology side of things that they mentioned in their elevator pitch that they do know but things that they didn’t and I should tell them to brush up on those things ahead of time.

Because once this wrap-up portion of the interview is done, the interview is gonna log off. You’re gonna log off and you’re going to exhale for the first time in like 45 minutes and you’re gonna be like, "Wow, I’m done." And that’s great. So, one, the first thing you should mentally think is, "Wow, I survived.

That was awesome." because coding interviews are not easy. Our interviews are very unique for the industry we work in, right? Where they’re kind of just live exams and live presentations.

That’s stressful. So, the first thing you should do is congratulate yourself on just making through it. And then the next thing you should do once you’ve taken a moment to collect yourself and calm yourself just a little bit is take notes on everything that just happened.

Take notes on what went well. Take notes on what didn’t go well. Take notes on things you want to research later.

Take notes on on things that came up that you weren’t sure about, but you want to be prepared for for the next time. And you’re going to want to do this now immediately because if you think you’re going to remember all those things in an hour from now when you’re coming down from the high, the adrenaline stress, you’re just you’re not. So take notes on those things right away like the moment you’ve collected yourself and then don’t research any of them for like a week.

Like give give yourself time to decompress from the whole experience you just had, but take those notes right away so that you remember everything that just happened and you can research it later and review it later and make yourself even more prepped for the next one. Because just like we talked about in the beginning of this, nobody nails interviews on the first try. Again, I bombed all of my first interviews that I did coming out of college because I did not know what was flying.

Most interview most people you’ve ever met in your life have bombed more interviews than they pass. Not most, all of them. All of them have bombed more interviews than they pass.

That’s just like so for this learning part of the process, this self-learning for you that comes afterward is extraordinarily important and you want to maximize that as much as possible. And something I like to mention here right as well before we before we get to the Q&A coming up right after this is all of these things we talked about all these things you need to practice and notes you want to try out and do later. There’s one way you can make the job cycle and application cycle work for you and that’s by applying for as many jobs as humanly possible even for jobs that you don’t want.

And the reason you want to do that is because interviewing for jobs that you don’t want and bombing those interviews is a lot better than bombing the ones that you do. If you only apply for the jobs you really really super want and your first, you know, the first interview you ever get is with Google and their beginning interview, that’s rough. But if by the time you get there, you’ve already interviewed at like 10 places that you don’t really care about, but you’ve gotten to practice all of these skills, that’s a lot better.

Bomb the interviews you don’t want rather than for the jobs that you really, really do want. So I what whatever whatever you’re whatever job part of the job cycle that any of you are in right now, apply for as many many jobs as you can. Leverage your network to apply for as many jobs as you can, but also just blind apply for as many as possible.

So you can bomb the heck out of all the ones you don’t care about. So when you really get to the one that you really really want, you’ve practiced everything we talked about here and you nail it and you kill it. And that’s it.

Because once you’re finished with this decompression and this research, you finish a technical interview. So, I hope I hope you found this walkthrough of breaking down the technical interview with all my memes included into into a really helpful step-by-step guide. Yes, the session is recorded so you get to see it later.

And now it’s Q&A time with one last memes. So, you can ask me about my journey interviewing, what jobs are like, what the market’s like, what I think about AI. I don’t know, literally anything.

But anything at all. But I want to thank CodePath for bringing me on here. And I want to thank you all for your time.

I know it’s the end of the EES day, so I know you’re all probably a little tired and a little speakered out, but thank you all for being here. And now in the Q&A tab, up vote the questions that you want to see answer the most and then they’ll bring them on screen and I will answer them. But thank you.

All right. And we will start with this one. Okay.

What is the best way to maintain a connection post conferences, especially after a big event like EES where the recruiter meets multiple people? It’s an excellent question and the answer kind of goes back to the small talk we talked about in the beginning of the slides which is be a person right so if once you once you said hey great to connect with you and they said hey great to connect with you as well just start asking casual questions about the company be like hey so are there any openings in the company right now or is there anything I should be aware of or there any key dates I should be aware of and they’ll probably tell you some key dates that are coming up when recruiters are at these networking events it’s because they’re actively recruiting so they’ll give you those key dates and those key dates come up, you send the recruiter a message again that’s like, "Hey, I know this date’s coming up. I really want to apply for it.

What’s the best thing I can do to be as prepped for that opening day thing as possible? Is there any resources you could connect me with of people who can help me out with it possibly?" but something else I want to stress about with with an event like this, when I was talking about building your network, I actually wasn’t even specifically referring to a recruiter. It’s actually not what I was referring to mostly at all.

I was referring to your peers, y’all. Like you all need to leverage the fact that you’re all people in the same space in the same economy at the same moment at the same time and connect with each other, build your network with each other because you know maybe maybe let’s say you get you you and someone else get a job now but you guys keep in contact through LinkedIn congratulating each other on promotions on job switches whatever and then in five years from now you’re like you know what I really don’t like where I’m working now and then you see that you know one of the connections you’ve kept up with for the last couple years by congratulating each other just checking in on how they’re doing. They got a job at a company that you’re really interested in.

They got a job at Capital One and you want in. Congrats. Now you have an in because you maintain that connection for years rather than letting it fade.

So when I was referring to making connections with people at these conferences, I wasn’t even mainly referring to recruiters. I was referring to your peers. Like you don’t think it’s important now because the most important connections you make feel like recruiters.

But when you’re later on in your career, your peers are your most important network. That’s how you find your next job. Like finding peers and places that you really want to go to.

So, maintain those connections, but maintain them more with your peers and the recruiters is who I was referring to and we could bring up the next question. All right. All right.

Love the insights. What do you think about chasing referrals versus applying as soon as possible? Consider companies reach their head counts.

Yeah, companies do reach their headcounts pretty fast these days. I would still chase referrals over applying as soon as possible because referrals just get you through that auto filter and applying as soon as possible doesn’t. So, referrals always win even if it’s late in a company’s application process because at least a human being is probably going to see your resume.

If you really don’t think you’re going to get any referral anytime soon, then yeah, you just you just blind apply and shoot your shot as fast as possible. But you’re trying to weigh which of those options is is better and more important for you. Referrals always win out.

Like networking, networking really is like the the hidden secret sauce of of every technical or job you’ll ever get in in our space. So I would definitely chase referrals more than anything else. All right.

I had a small question. If two candidates both solve the same coding problem, the interview, what behaviors or qualities help us in the other? So everything I talked about is the answer to your question.

The candidate who turned the interview into a conversation rather than assaulted back and forth, they win because then when I get back to looking over their code later, I’m like, "Oh, yeah, I remember that person. They were nice. We had a good chat." Like that that already puts you more in the acquaintance bucket than the random stranger bucket and you’ve already won.

But also things like if I’m comparing their code and one person has pseudocoded out their code and one person hasn’t, one person’s commented and one person hasn’t, one person summarized the question in their own words in comments and the other person didn’t. Everything we talked about in this in this presentation was a way to stand out in the interview process so that when I’m thinking back on the ideal candidate that I interviewed from these decks is someone who engaged with me on a personal level is someone who wrote really clean and easy to read code. And because of those two things when I think back on them not only do I think back on them fondly but I’m looking back at the code I’m like oh this person was great and they wrote the best code I’ve ever seen sold.

I don’t have to think about it too hard. So the answer to that question is everything in this presentation. All right.

Does Capital One accept CPT F1 visa for internships? I actually don’t know the answer to that question. So I wish I wish I could answer that question, but I honestly I honestly do not.

Sorry. Do you recommend apply only for one position within a company? No. so at least for the way referrals for most companies work, if you’re going down the networking route is you can be referred for multiple positions at the same time and then you’ll get applied for those positions.

But even when you’re going for a specific company, I would not apply for only one position because you might be a better fit for position A with a different with one manager over another. Even if the job descriptions of those look almost identical, those job descriptions are generic boilerplate stuff generated by HR and they’re not specific to the job most of the time that you’re actually applying for. But the managers know the kind of skills they’re looking for.

So even if you apply for two different jobs in a company and they look basically identical, the actual skills they need probably aren’t, which is why you apply for both of them anyway because you want to give yourself maximum number of chances to get picked for any of those. How would you weigh two candidates against each other if one is slightly better cultural fit while the other is slightly more technically proficient? This is a really good question.

And I would give cultural fit very slightly the edge over a technically proficient. And the reason I do that is your technical skills can grow pretty easily, right? Most people can research, they can you can use YouTube, you can use whatever to grow in the ways that you’re technically lacking a little bit, but if someone’s abrasive and hard to work with, that’s probably not going to change.

And I don’t want to work with them. They may be the most brilliant software engineer I’ve ever met. But if they’re just a pain, then I don’t want to deal with it because then they’re just going to annoy me and annoy all of my co-workers for the rest of the time that they’re working there.

So cultural fit wins out, which is part of why the most crucial part of the interview is this building the connection point that I keep harping on because if you do that, then I know you’re a good cultural fit and you’ve checked that box for me. How much of a red flag is having your camera to the side, you having multiple monitors? Very big red flag.

So everyone knows that that that cheating is very proficient in online interviews. I know it’s a thing. You know it’s a thing.

It’s why you’ve been asking me the question to begin with. Your camera should be directly on you like this and you should be staring into it soul the entire time. If you’re looking up and down like this, like very very dramatically so that I know you’re not looking at a monitor or your phone, you’re just looking around because you’re thinking, that’s totally fine.

But if your camera is just pointed off to the side so that I can physically not see what you’re looking at, if you just glance your eyes left or right like this, I’m going to be suspicious the entire time. I’m going to assume that you might be cheating. Whether you are or not, you want to remove maximum suspectability of yourself that you’re possibly cheating at any capacity.

So, camera straight on like this, good lighting, good audio, and don’t look anywhere but your camera the entire time. You have resources to recommend for interview prep or le code and cracking the code interview. You practice plus you have practice you would recommend instead.

So Le code is a great tool for practicing pointed interview questions. So interview questions about link lists, sure le code is going to be great. Interview questions about random algorithms, sure le code is going to be great.

But if you want to practice and more about how the industry actually works. The biggest parts of our jobs are integrating different technologies. So you might be really good at writing Python code, but you can’t integrate it with a backend and a front end depending on the jobs you’re applying for.

And you’re probably not going to do so hot on the job. So, if you’re looking for practice outside of just surviving interview prep, part of what we do in interviews as well is we do case study interviews, which is really what I focused on here. But case study interviews are more about that technology integration stuff.

So, you might get asked, "How would you set up this kind of application for an example?" Or, "Here’s a piece of code that’s interfacing with a back end. You tell me why it doesn’t work." Those are a completely different interview style than the technical interview ones. But the reason we do them is integrating different technologies together is is what you’re going to spend a lot of your time doing.

And being able to practice that on your own ahead of time is really important. So any projects you can do of that ilk beforehand would be would be really helpful. Thank you so much Arya.

Please show Arya some love in the chat. Thank you so much for sharing those tips. Thank you for sharing the memes.

Remember that Capital One also has a company booth, so during any networking breaks this week, you can visit them. Again, thank you to our incredible speaker and we hope you enjoyed day one of EES. We’ll see you tomorrow at 9:00 a.m.

Pacific for our day two opening session. Thank you everyone.