CodePath EES2024 CAPITAL ONE - Interview Prep 101: Tips and Tricks to Nailing An Interview

Hello everyone. Welcome to the breakout session, interview prep 101, tips and tricks to nailing an interview, hosted by one of our amazing CodePath volunteers, REA Ness from Capital One. I’m Emmanuela Stanislaws and I’m with CodePath and I will serve as your moderator for this session.

We are excited to have you join us today. First, I wanted to share a few reminders before we get started. Please utilize the chat to have conversations and share your thoughts during the session.

Please make sure that your messages are relevant to the topic of the session. And note that myself and the presenters and speakers can see the chat. Our team will be monitoring the chat and questions will be answered live during the session.

So be sure to use the Q&A feature to add your questions and definitely upvote questions that you want to be answered. Following the session, we will be asking you to complete a brief feedback survey. And we really want you to actually complete that because your feedback is very important to us.

With the reminders out of the way, I really want to take the time to introduce Arya Nes today who will be presenting again on the topic of interview prep 101. Ari is a graduate of Rutgers University. He graduated with his computer engineering degree in 2020.

He is now a senior software engineer at Cap Capital One. And recently completed their second time being a coach for CodePath TIP 101. He’s looking forward to meeting you all today and chatting with you.

So I will go ahead and turn the table over to Ari. Welcome. Thank you, Emanuela.

And hello everyone. I’m only slightly panicking that there’s 270 of you here. It’s fine.

It’s good to see some familiar faces in the chat. Jyn, I saw you. Noah, I saw you from my tip one or two courses.

So, fun to see some familiar faces and and and some new ones. And yeah, we can bring up the slides and get started. Thank you for the introduction.

All right, everyone can see the slides. That’s what you have to ask whenever you start presenting slides as is tradition. Okay, sweet.

All right, let’s let’s get started. Just a little bit about me for for those of you who I’m new to. My name is Arnes.

As Emanuela said, I’m a senior software engineer at Capital One. I’ve coached for TIP 102 twice now. I’ve done a lot of resume and technical reviews and and with with CodePath for a few years now.

I really like this place. So I’m happy that he can have me on here as a volunteer. My journey and I put on here I think is a little unique in that I started at Capital One as a contractor and then went through like a yearly promotion cycle to become a senior software engineer.

People tend to ask me a lot of questions about that because I know it’s not the normal path to becoming a senior software engineer. So if you have questions about that or anything else I’m going to mention while I go through the slides there’s a Q&A feature on the side. Just ask your questions there.

And I’ll go through the questions at the end, but I will be doing a Q&A once I’m finished presenting. So, ask any questions you have there and I’ll go through the most upvoted ones that I see I can answer. And with that, just to introduce what I’m going to be talking about.

You’re going to hear, I’m sure, a lot of a lot of speakers over the last over yesterday, today, and tomorrow that are discussing, you know, tips and tricks for interviews. I tried to I wanted to do my own take on that, but kind of breaking it down into a very peace meal, like step by step steps you can follow. And I hope you find the the steps I go through helpful.

And with that, I will get into my step minus one, the setting. If you see this meme and you’re like, did he put memes in a slideshow? You bet.

I grew up with memes. That’s that’s my life. Only I’m only 26 years old.

So, step minus one, the setting. Make sure that whatever environment you’re in for where you’re taking your interview, you create the greatest chance of success by making it a very easily workable environment. Remember to have good lighting, a good camera angle, clear audio, no distractions around.

Find a nice quiet area where you can really focus on your conversation with the interviewer and there’s nothing else happening around you. You don’t want what you see happening in this meme. You don’t want your cat on your keyboard.

You don’t want bad audio, bad lighting, a bad camera angle. Make sure that you’re presenting the best version of yourself to whoever you’re interviewing with. It’s really good for helping getting in the correct mind space.

And then step zero, again, all this is before the interview even begins. Being calm and believing in yourself I think is the most important aspect to success in an interview. When you’re waiting and you know when you’re sitting and you get there before the interviewer because you’ve joined the Zoom bridge or whatever it is five minutes early you’re going to start to get nervous your heart rate is going to rise.

And to what I like to remind myself when I’m sitting there waiting is is two things. One a mantra of self-belief. Remember that you deserve to be there.

You’ve earned the right to have the interview and you’ve earned the right to the job that comes after it. Believing in yourself is the most important skill I think to really have during the interview. And second is as much as you’re able to calm yourself.

That would be that would be great. I personally recommend the navies I didn’t come up with this 478 technique. What they teach their soldiers to do is to breathe in through their nose for four seconds, hold it for seven, and then exhale for eight, and do that about four to five times.

I I find that really helpful for calming my heart rate. I know anxiety isn’t a an easy slapball. Oh, just breathe for everyone.

But any steps you can take to try to to calm yourself as as you’re sitting there waiting, calm the nerves, focus yourself, the better. So that when the interviewer hops on, you’re at your best and you’re ready to go. And then we begin with small talk because the interview does not start right with just jumping into a coding question.

It starts with a discussion. And generally it’ll begin with some very very polite, very tiny small talk. The interviewer might ask you how you’re doing, give an honest answer.

Whenever I ask a a candidate how they’re doing, they’re like honestly pretty nervous. I kind of appreciate the honesty because the nerves are part of how it goes and and something I really want to highlight on also be engaging with the interviewer as well. Don’t just let them ask you questions.

Ask them questions in return. Ask them how their day is going, how their week is going. Treat them like a human person so that the interviewer can kind of turn from like a very formal stilted here’s a question, here’s an answer to more of a conversation.

The more friendly you can make it, the more you’ll stand out in the interviewer’s mind, especially post the interview, and the more it least to a conversation about the company as a whole, and you get sidetracked for five minutes first. That’s not a bad thing. It means that you’re forming a real connection with the interviewer.

And something else that might really come up is an elevator pitch. So, this is the classic tell me about yourself that you tend to hear in a lot of behavioral interviews. I’ve seen it and have asked it in technical interviews as well.

It’s a it’s a valid question. Have that pitch for yourself already on hand. And remember that that elevator pitch is a mix of being humble where you express that you’re willing and you want to learn more, but also you kind of got to be your biggest self- advocate and brag about the skills you already have to to justify, right, why you’re there and that you belong to be there.

So those are some things just to keep in mind before you get started. And then the question itself will begin. So when you’ll transition from your interview from like that small talk to the actual interview question being presented to you itself as the interviewer is reading out the question to you.

I cannot stress this enough which is why I put it in bold and italics. Take notes on the question as it’s being read in the IDE itself. And I say in the IDE itself because I know some people like to take notes on a notepad to the side.

I don’t recommend that for two reasons. One, for your work to count, it’s got to be visible, right? So, if you want the interviewer to see what you’re taking notes on and maybe make a correction on some of the things that you’re taking notes, if you’ve noticed something incorrectly, they have to see it to be able to to correct it.

And it’s something they can reference back afterwards if you’re typing it as a comment in the IDE after the interview is over. And I’ll I’ll hit I’ll I’ll go back to that more in a later section of this. And two, taking notes off to the side, and this is just the nature, especially of remote interviews, they can kind of look suspicious because when I see someone looking off to the side of their camera and looking down, I want to believe that they’re taking notes on a notepad, they might just be checking their phone for the question that I’m that I’m saying.

And because I can’t see, I don’t know, and I’m not going to interrupt myself to the, hey, can you hold up what you’re taking a note on? It just it just looks suspicious. So, avoid looking suspicious.

And make your work count by as the interviewer is reading out the question if it’s not a question that’s like copy and pasted sent to you take notes in the IDE itself so that you they can they can see that you’re demonstrating understanding of the question and this is part of what I said earlier about making it a conversation the more friendly you can become with your interviewer the more becomes more like a conversation this is a psychological hack I guess the more they’re going to want to help you answer the question correctly so if If you’ve had still small talk and then you note something incorrectly, they might let it go. But if you’ve had good small talk with them and you’ve established a rapport going into the question, when you note something incorrectly, they’re more likely to stop you and correct you then because now they’re on your side. It’s maybe a little bit psychologically manipulative, but I I think that the more the more you can establish that connection the better.

All right. And then we get to and this is this is going to go back to code house umpire method. I’m a big believer in it because I think that it works and it’s very accurate.

So once you’ve gotten past the understanding part of the umpire method let’s finish off ump by summarizing and planning what we want to do. So I like I always find it helpful and this is more helpful for you as the candidate but again it’s also helpful for the interviewer for you to summarize the question in your own words because by doing so they can make sure that you fully understand the question as it’s being asked with all of its edge cases. This is also the good time to ask questions.

So as part of ump you also are supposed to ask questions. This is the time to do it. And then once you pick out your path as part of you know the method you pick out the chosen path you want to go down.

Pseudo code it out and I put that in all of the formatting because pseudo code in my opinion might just be the most important part of a technical interview. Might be a little controversial. But something I liked as I point this out the end of the slide.

Comes in handy for correcting issues in a time crunch. Pseudo coding it out will do two things for you. One, when you have to pseudo code out your approach to the question, you’re going to spot issues in your own code a lot faster than if you just start coding it blind because when you have to create the scaffolding of your code, you’ll spot things that you miss, nobody gets it right on the first try.

Not no one’s expecting you to. And for a time crunch is because let’s fast forward through the interview and you’re in the last five minutes and you didn’t get to finish implementing everything that you wanted to implement, but you have the rest of it pseudo coded out. Having that pseudo coded out shows the interviewer that you understood the problem and you understood what the solution was supposed to be.

You just didn’t get the time to finish it. And that’s better than just typing your code out blind and then when the interview ends having nothing to show for the last third of the question, right? The more you can the more you can pseudo code it out beforehand and give the scaffolding for yourself to guide your approach to correct issues and to give yourself credit in case you don’t actually get to finish is a lot better than blindly coding it out.

So as this meme says if you can’t write basic pseudo code you’re going to have a bad time. Pseudo code is in my opinion the foundation of of a well ststructured technical interview. And yes I did do a meme on every slide because I did.

Okay. So, now we’re going to get to the actual all these steps we’ve taken in place. We’ve we’ve established a rapport.

We have a good setting. We understand the question. We’ve taken notes on it.

We pseudocoded it. Now, we’re going to get to the actual implementation of the actual question. And this is where I mentioned this on an earlier slide about a stream of consciousness and I really want to harp on it here.

As you’re implementing, I want you to do two very important things. One, leave comments because comments are an industry standard. And we and when you’re on the job, people expect you to leave comments on your code.

So, I definitely want to see it when I’m s watching someone implement a complicated algorithm or array question or whatever it is. And explain out loud as you go. Again, you only get credit in an interview for the for the things that the interviewer can see and can hear that you’re doing.

So, you comment your code so that they can see that you know how to properly document code. And if they ever want to go back after the interview and check your code later, because sometimes they do that if they’re trying to compare two very close candidates who both answered the question, the com the code with comments will do better than the code without it because the comments will explain everything the code is doing and the interviewer doesn’t have to re-remember and reassess why things were done a certain way. Comments make everyone’s lives better.

And for you don’t have to write everything out in comments like you don’t want to write like full paragraphs. So explain your comments as you go by explaining them out loud to explain your approach, explain why you’re doing what you’re doing. And again, all of this is so to help the interviewer help you.

So that if you make an error or you make a mistake in judgment, the interviewer can correct you a lot faster if they can hear and understand why you’re doing everything that you’re doing. And again, it helps establish that conversation with your interviewer where you’re having a constant back and forth. There’s there’s almost nothing that’s more awkward as an interviewer in a technical interview when there’s just four minutes of silence because the interviewee isn’t saying anything.

They’re not commenting and they’re just writing blank code. And because I don’t know why they’re doing what they’re doing, I can’t comment on what they’re doing to interrupt or to ask questions. I don’t know what’s happening.

So, never have like more than 20 seconds of silence. You can have 20 seconds of silence if you’re thinking, but if you’re actively doing something, you should always be explaining why you’re doing what you’re doing. So, you can just avoid that awkward silence.

And then step five, the walkth through. So, once you finish implementing, you’re going to get to the point in your code where you think it’s done. And I never want to hear an interviewee say, "I think this is done." Because don’t tell me that.

I I want you to have confidence in your solution that your solution is correct. And it’s accurate. So one be confident say this is done and then two to prove that you’re done take a sample input because every interview is going to have a sample input and pass it through your code and then demonstrate confidence in your solution by walking through that sample input that produces the expected output.

And again by doing this this will also help you find bugs before running the code. And I wrote if allowed to at all because some companies don’t actually let you run your code or they’re not asking you to. They just want you to write kind of a scaffolding of an algorithm that would work and they’re not looking for correct syntax.

So you don’t actually always get to run your code to spot issues. So if you don’t walk through your code with a specific input as an example, you’re never going to know if you’ve missed something logically in your solution because you don’t get, you know, like a like a leak code environment to run it in that tells if you passed every input case or not. And I put this meme here.

One, because you have to, and two, because being able to explain your code and how it handles sample inputs is a really important part of the job. Again, at some point in the job, you’re going to be completing a ticket. You’re going to get to a PR review and you’re going to have to explain to your tech lead and your seniors why you’ve done things the way that you’ve done so that they can explain it to downstream people, to clients.

And if you can’t explain it and they can’t explain it, no one’s having a good time. So being able to explain your code and demonstrate understanding is really important. And then I put step 5.5 here for debugging because our lives as programmers is literally non-stop debugging.

Nobody’s code has literally ever worked on the first try ever. Just it’s just not how that works. Especially when you’re implementing something important.

Something complicated I should say. It’s never going to work on try one. So debugging becomes a really really important part of the job.

And you want to show off how you debug to to the interviewer especially because that’s something you’re going to have to do in the job as well. So you want to show off how you debug whether it’s do print statements, example inputs, just putting five print statements in order that says I made it here. It doesn’t really matter what your technique is because I think most debugging techniques are valid.

But because it is such an important part of the job and your code’s probably not going to work on the first try, my recommendation would be to show off your debugging skills when you’re when your code does not work first try. And as part of that, if you don’t get the situation where you actually get to run your code because that sometimes happens. The interviewer will generally point something out to you that’s a gap in your code.

They’ll generally be like, "Okay, thank you for that walk through for that input that you did, but for this input, can you spot a reason why your code might not work?" And then you have to debug it anyway. Which is why having good understanding of why you’re doing what you’re doing really helps you with your debugging skills. All right.

And then assuming you’ve implemented correctly and you’ve walked through your code and you’ve debugged all the problems, you get to wrap it up. And a big part of the wrap-up is demonstrating understanding of your own code. So you’re most people are going to ask you for the runtime and space complexity of your solution.

A very common follow-up question also is this works but is there a way you can spot to optimize it further? Because 99% of the time there always is. And the key part I want to highlight is that last bullet point.

It shows we did not just memorize a leak code solution because interviewers know that leak code exists. We know that leak code covers most situations you’re going to be asked about in an interview. It’s how why the platform exists and why it’s successful.

So what we most of the questions we ask will be something similar to a leak code question unless we’re getting really creative on it. And because we know that students can just now memorize leak code solutions. If you can just spit it out the answer, that’s great.

But if you can’t explain why that’s the answer or if there’s a better way to do it and what the runtime and space complexity is, then me as the interviewer, I immediately know, oh, you’re good at memorizing code. You’re not good at explaining why your code does what it does, and that demonstrates a lack of understanding. So, you’re going to be asked questions, especially in this modern day and age, to explain your code.

So be ready for those. If you’re memorizing leak code solutions as a practice, that’s great, but don’t just memorize the solutions. Memorize why they work.

Like you’re studying for an exam basically. Otherwise, it will become very obvious very fast that you don’t actually know why this is doing what it’s doing. And then you’ll get to the wrap-up part of the interview.

So, at this point, the coding is done. And you’re going to have time for some last interaction with your the person interviewing you. And this time, you will have to do more small talk, but the key is that you you the interviewe are going to guide the small talk.

I always recommend that candidates prepare two to three questions in advance to ask the interviewer. A very common one is like what’s a day on the job like? One I always like to hear is you know how can I best prepare for this role because it shows confidence that you’ll get it and a humbleness to learn more which is a really good combination to have as a candidate.

We want people who are confident but also recognize that they have more to learn. But there’s a lot of different questions you can ask. You can ask about what the company is like.

If you if you and this is a big this is always a good win. If you’ve recently researched news about the company, you can ask something specific to that company. For example, I work for Capital One.

If a student asks if an interviewee I should say asks me about Capital 1’s acquisition of Discover Bank and how we’re preparing for that. That’s a really really good question because it shows that the interviewee has taken really impressive knowledge of the state of going on in the company that they’re interviewing for and then I can actually have a real discussion with them about oh that’s actually a really interesting question you bring up because that is something very relevant to my job. Let me discuss that with you as much as I obviously can legally.

So if you can do research on the company beforehand, if you can do research even on the person interviewing you beforehand and see if you have anything in common with them, like if I’m interviewing someone and they’re a Ruckers graduate and they’d be like, "Oh, I also graduated at Ruckers. How was that transition?" Like, great. We now have something in common.

And that that commonality goes a long way as well. So, this wrap-up time is really for you to guide a discussion based on topics that you find are most relevant for the job. And and I didn’t put this on the slide, but it’s something that’s also really important.

This time is really crucial for you as a candidate to in to determine if you want this job because we all are looking for jobs why all of us are here. But this you want to find out the job is a good fit for you, not just if the company is going to give you an offer. So you want to prepare a question that will that will let you ask something that determines whether you would actually like this job or if you’re not going to like this job.

A very common one to ask is like what is a day on the job like? And what you’re really asking is what’s my work life balance going to be like? If you’re someone who’s willing to work from 8:00 am to 8:00 p.m.

And that’s not a problem for you, great. If you’re someone like me and sticking to a very strict 9 to5 is a really important quality of life, then I’m going to ask what’s the day on the job like because I want to hear if the company has the expectation of me working outside of business hours. Make sure that the question you ask not only is about the company itself, but also gets into your personal preferences of the kind of company you’d like to work for.

You’re also interviewing them. They don’t have all the power. You get the power to say no to jobs that you don’t like.

Make sure to interview them as well as much as you’re obviously capable of doing. And then when that’s done, you’ll log off. You’re probably going to catch your breath because your heart is still beating out of your chest.

But congratulations because you’ve survived in a technical interview. And coding interviews are not easy. They’re never easy.

And even just surviving one to me is a really big achievement. Mentally take stock immediately because you’re going to forget very fast of the things you think you did well, the things you think that you struggled on, things you want to research. If they’ve asked you a question, like a specific technical question, and you just didn’t know it.

Note that down immediately before you forget. Don’t be like, "Oh, I’ll remember this later." Because you won’t. And make a note to research it later when you want to catch your breath, but take those notes right away.

And something I really want to highlight is in that last bullet point, nobody nails a technical interview on the first try. I bombed my first ones very hard. I graduated in 2020.

I graduated in the midst of in the midst of COVID. I did all my interviews remotely. And I I bombed those first few ones because I didn’t really know what I was getting into.

I did not know what the what the technical interviewing world was, I think, fully like in that environment. So don’t be stressed if you if you do your first ever one of these and you’re like, "Wow, that was terrible." Because that might just happen. And that’s okay.

Something I’m going to point out here also, and this again, this is how you can make the system also work for you. When you’re applying for your first jobs, especially, there is no bad job application. And what I mean by that is let’s say you get an interview offer from a company you have zero interest in working in.

I mean zero. It’s it’s not technology you’re particularly interested in. You don’t like the company.

Whatever it is, still do the interview because interview practice on companies you don’t want to work for is a lot better than interview practice on companies that you do want to work for. Let them be your guinea pigs. So when you’re going out and you’re applying for your first jobs, apply for anything and everything, honestly.

You might get surprised by a job offer that you get and you’re like, "Oh, wow. I actually do like this." But even if you don’t, practice on the companies you don’t want as opposed to practicing only on the three that you do. That will go, I think, a long way to being that when you get to the companies that you do want, you’ve gone through all these steps before, you know what to do and you know how to handle the stress.

And with that, Q&A time. So, does anyone have any question? I’ll start go start going through the Q&A chat.

You can ask questions about me, my journey, interviewing, what the job is like itself, literally anything and everything at all. But again, I want to thank you all for your time and and CodePath for having me on here. Awesome.

Great job. So, folks, definitely add your questions to the chat. There were a lot of aha moments for folks.

So thank you for sharing all of your amazing tips. So okay, let’s see. The first question that I have here is what mistakes have you seen when interviewing people and what would you recommend to avoid that?

So that’s a great question and I guess my answer to that question would be most of what I covered in the slides are the mistakes to avoid. So, people who don’t comment their code, they don’t say anything out loud, they don’t pseudocode it out, especially, again, I cannot stress how much I love seeing pseudo code in an interview because it’s such a good practice for when you’re working on the job as well. Those three things I think individually are probably the most bad that I’ve seen.

And what I recommend to avoid that is for all of those together is just to think out loud. Verbalize everything that you’re doing as you’re doing it. Write out the key parts as comments on your code.

Really just make sure that you turn the interview into a stream of consciousness and then the the minor mistake that I see is when the interview doesn’t turn into a conversation, it turns into a very stilted back and forth. The stream of consciousness will help alleviate that. But the you got when you’re in that first five minutes of the interview and you’re having just that that quick back and forth with the interviewer, it is so important to establish a good friendly rapport with them so that the rest of the interview feels like a team like a team effort and not just you versus them.

So those are the biggest mistakes I’ve seen. Really just not commenting, not saying anything out loud and and not turning the interview into a conversation, keeping it a very stilted, isolated experience, I think are the two biggest mistakes that I commonly see. That’s great point.

And those are definitely things that I’ve heard from employers like especially the piece about not talking out loud so they can learn about how you’re thinking about the problem. Yeah. All right, next upvoted question.

What is a habit you see successful interviewees do during their tech interview? And has an interviewee ever passed the technical interview without fully finishing their answer? Yeah.

So, the the the habits I see successful interviewees do are again kind of the things I just said. I might sound like a broken record here, so I apologize, but commented code, pseudo code, explaining everything they’re doing as they’re doing it. As Emanuela just said, the real thing that companies are testing you for on these interviews is how do you think?

These are not meant to be syntax exams because anyone can Google syntax. I’m a senior engineer. I still Google things all the time and I’m going to Google things for the rest of my career.

We all do it. It’s how the job goes. So, this is not supposed to be a syntax check.

It’s really a do you approach problems in the right way so that you can answer the questions in the way we want you to and you can actually explain what you’re doing. So the the the things that I see successful interviewers do is not just only be confident in their answer but also explain why they’re doing what they’re doing and again turning the interview really from a stilted back and forth into just a conversation between them and the and the interviewer to really establish a good rapport. And yes, I have I have past interviewees that have not finished fully finished with our technical answer.

And honestly, sometimes it’s my own fault. Sometimes I’ll have a really good rapport going with the candidate like in the first five minutes and we’re talking back and forth about the company about about tech news and then I actually cut into their technical time. So, I’m not going to hold that against them.

Especially if they pseudo coded out the rest of their answer, then I’ll be like, "This is my fault. You would have finished this. It’s all good." Sometimes I’ve also had candidates 95% finish an answer and they had like a bug in the last 5% of it.

I’m not holding that against them if I know that they understood what the problem was and how to answer it. So yes, I have I have definitely passed interviewees that have not fully finished their answer. Obviously, it’s best if you do.

Because a candidate that did everything I just said and fully finish it will do better. But I will not fail an interviewee because they did not fully finish an answer if they’ve given me reason to believe that they would have finished it with like five more minutes. So whether that’s pseudo code, comments, verbally explaining the answer, whatever it is, it all right.

Thanks for that. Okay, so next question I’m seeing is need tips for passing the online assessment and getting the first tech interview. So, any advice on passing the online assessment, in general?

So, honestly, the good thing about online assessments is that almost everything I just said goes out the window because the only thing online assessments are looking for is did you answer the question in the time in the time specified? That’s it. There’s no commenting, there’s no pseudo code, there’s no nothing.

So, the only tip I have for passing online assessments is practice, practice, practice. This is I think where leak code I think shines the most because here you can just regurgitate a leak code answer and that’s valid and it’s accurate. So that’s honestly the best tip I can give is really just to practice.

And then if you want to make that practice work better for you, and I give this recommendation to people all the time while you’re memorizing those leak code answers and you’re going through a bunch of leak code problems, when you start answering leak code questions on your own, explain to yourself out loud why you’re doing what you’re doing and comment that code so that you can build it as a habit so you don’t forget to do it in the real interview. I know that sounds weird. I know it might feel weird to do, but if you turn this into a habit, it will become second nature for you.

And then you’re not going to have to remember while you’re halfway through typing your code of, "Oh god, I forgot to comment everything. Let me go back and comment half my code." They’ll just do it by default. But the only tip I really have for online assessments is really just practice because the only thing they care about is did you answer this question accurately enough in the time given so you don’t get that person element to really work with.

So random kind of question. Would you say the reason why like folks or I shouldn’t say reason why is part of the way that the senior engineer or the panel that’s interviewing the candidate is looking for certain things is to see if they can fit into the whole engineering space because some of those things are required where you have to communicate why you’re doing what you’re doing. You have to document what you know why you made the the selections and choices that you made.

Would you say that that’s part of the assessment? I would say that’s honestly what the assessment is really meant to be. Like if you if you go I meant sorry the technical interview.

Yeah. No. So if you if you if you’re not us and you’re not crazy and your exam your interviews are not exams and you go through a regular interview, what they’re doing is they’re asking you questions to determine if you’re a fit for the job. Our interviews are supposed if you’re if you have a good interviewer because some people are weird about stuff.

Their interview goals should be the exact and I mean literally the exact same thing. Just the way we do it is by giving you a problem to walk through to demonstrate all of the things that are relevant for the job. So because commenting is relevant for the job.

You got to comment in your regular in your technical interview because explaining your thought process and explaining why you do what you do is relevant for the job. You got to explain it in the interview. It there are still elements of our interviews that are re that are that are what should I say global to all kinds of interviews and having the skills that are actually relevant for the job is definitely what it’s meant to be about and be for us those skills aren’t just can I code it’s can I do all the things that a business would require me to do like comment explain understand etc etc got it I appreciate that we have another question I feel like you might feel like this is kind of similar to some of the feedback that you shared before.

So we have someone that shared, I have never had a tech interview with a real person. What would you recommend me to do? Sorry.

What would you recommend me to get good at coding and interviewing? Okay, so two very different skill sets, but a question I’m always happy to answer. Get good at coding is practice.

So, like any skill that you’ve ever picked up or any hobby anyone’s ever picked up, you got to just you got to practice it. There is no there is no way around that. Leak code questions are great in for once lead code questions I would say are only good once you have a fundamental understanding of the topic they’re about.

Let’s say there’s a leak code question on arrays and you’re like, "Okay, I’m probably going to get asked an interview question on arrays at some point." You don’t just start going straight to leak code and memorizing array questions and answers because they’re not going to mean anything. First, you have to understand how arrays work in the language that you’re working with. Understand their syntax.

Not just their syntax, I should say, but understand how they work, how inserting and and and searching and how all of that works for an array and then only then do you attempt a leak code problem. So, build yourself a foundation first, then test your foundation against actual problems. And to get good at interviewing also, the best thing I can say is practice.

And there’s multiple avenues you can take for practice. Again, I’m going to clarify that I work for Capital One, but I really like CodePath. CodePath does mock technical interviews if you can get yourself signed up for those.

Would highly recommend because that’s a great way to practice literally doing an interview with a real person where there are zero stakes involved. So, that’s a free opportunity right there to practice interviewing. The other things I’d say is on your own time, like I was saying, when you’re answering a leak code problem, practice explaining your thought process out loud.

Practice commenting your code as you go. That way when you get to the real interview, it’s not like a skill you’re trying out for the first time. It’s second nature and it’s habit.

Because once honestly you can do those two very crucial key things. Most of the interview is just really being a person and interacting with your interviewer like you’re not afraid of them, but like they’re a person that you’re having a conversation with. So, a mix of social skills and technical skills, but you can practice interviewing both through CodePath because they do it and they recognize the value of doing so and also on your own by just practicing it on yourself on your own time.

And if you and your friends are bored even and you want to practice interviewing each other just to give yourself feedback on each other, that’s valid, too. I did that with some friends back in college and yes, it wasn’t totally serious. It was a little jokey, but we still did learn things from doing so.

Even if they roasted me when I got things wrong because they’re my friends and they have to. Gota love the friends. Great advice as well with the practice practice practice.

And then good plug for the technical interview weeks that we have here at so appreciate that. All right, the next question is hey Ari, what are the questions that software engineering interviewers don’t like to be asked? You have any insight?

Yeah, that’s a really interesting question because I’ve never really gotten asked a question that I was like, "No, that’s a terrible question." the only thing I’d say is don’t ask any questions that are accusatory or or aggressive. For example, if you’re interviewing with Amazon and I’ll pick on Amazon and you’re like, "Hey, Amazon, there’s been a lot of news recently about how your company is mistreating its workers. Do you have any thoughts on that?" That is a terrible question to ask because now you’ve put the interviewer on the defensive and they’re probably unrelated to all of Amazon’s scandals with their worker treatment rights anyway.

So, don’t ask any questions that are aggressive and and inflammatory, I should say, is probably the only thing I would say to avoid. I’ve never been asked a question that’s been bad. I’m getting a lot of laughs in the chat for that, but it’s the only thing I can think of for like a bad question to ask there.

It’s very hard to ask a bad question and I think I think most of you will avoid that pretty easily. Yeah, that’s a good one. Yeah, stay away from controversial stuff.

I think too I heard someone ask an employer the other day like, "Why should I come and work at your company?" and it threw them off, you know, like of course they’re going to go through whatever, but like that’s definitely not a a question. Nothing aggressive. Exactly.

Yeah. All right. Next question that I’m seeing.

Oh, let me Okay. What data structures should we focus on when it comes to preparing for Capital One’s online assessment? So, that one’s specifically for Capital One.

All right. I will I will do my best to answer that question. I can’t just give everything away because I like to help all of you out.

I understand what’s happening here. What I will say just to give you guys the correct answer that won’t get me in trouble is the stuff that CodePath goes through in their TIP 102 course will cover you for most any online assessment that you’ll ever do, unless it’s for somewhere crazy that wants you to do some ridiculous algorithm. I would love to really give a detailed answer on this, but I kind of can’t because that defeats the purpose.

That was a great shoot your shot moment. Thanks Jenn. No, I really I really respect that, Jenna.

Like, honestly, mad respect for trying to trying to get that out of me, but I I can’t really give that away. Love it. Okay, let’s see.

I’m looking at how we’re doing at time. Looks like we’re still good. If you’re you’re still good.

Yeah. All right. So, we have a question around what is the expected time to finish medium to hard level problem in technical interviews.

So any thoughts around the expected time around that? So generally any question you’ll be given an interview. They’re not giving you a difficulty along with it.

But they’ll generally give you about 30 minutes to answer the question. So if you have at least and this this I can speak about for capital and this isn’t like giving anything away. We generally break we do we do our technical interviews in a one hour slot.

Generally you have the first 10 to 15 minutes for introductions, highs, hellos. Then you have about 30 35 minutes for the coding and then you have the wrap-up after that. I think I don’t think I’m giving anything away with that because that’s how most companies do it.

An hour interview is very standard and that breakup of how that hour works is pretty normal for any place I’ve ever interviewed with and I’ve seen that a lot of places. So, you should expect to be able to finish your problem and in 30 to 35 minutes. And part of that 30 to 35 minutes is even if you’re able to code the solution in 10 minutes because you’re a wizard.

You still need to be able to comment, explain, pseudo code all the things I’ve been harping on for the last 40 minutes and I’m sure you’re tired of hearing. But yeah, you should be you should be able to finish all of the things I said the commenting and pseudo code etc in about 30 35 minutes. Great.

Awesome. Thank you for that. All right.

Next question I’m seeing is let’s see what is a core skill that an aspiring software engineer should have. Okay, this I’m going to I know I know this question is meant to be technical like what languages should I know? I’m going to give you an answer that you’re probably not expecting.

So Michael, thank you for the question. Social skills. So social and soft skills in my opinion and I will die on this hill are probably the most important skills that an aspiring software engineer should have because most software engineers don’t have them.

So the ability to be able to talk to people to be able to explain things that are technical to a non-technical person is huge because your managers are not technical people most of the time. So they need to be able to understand what’s happening and be able to explain, oh, I did this for this in in English and not just technical jargon is really important. Soft skills, I think underratedly are probably the most important part of any job.

And even just to go back to the interview, like the steps I was going through earlier, the first step I laid out of the actual interview is the small talk. And it is the most important step for laying the groundwork for a good interview. Because once you’ve established a good friendly rapport with your interview, even if you bomb the question, they’re going to remember you favorably.

It’s that’s just psychology. And then even for the job itself, being able to interact well with your peers because you’re going to be working with them on projects, being able to explain things to your managers, to your senior engineers, for PR reviews, and for performance reviews, and literally everything. Soft skills are incredibly important.

Something I did not mention in in the slides because I was trying to stick to the interview, but something I strongly believe in, and this is especially true of the kind of positions you guys are applying for, the interview does not end when you get the job. The interview ends if you’re doing an internship, when you get the internship return offer. And even if you have a full-time job, the interview ends after the first six months generally is the is the industry standard.

You get six months as a trial run. So you need to maintain all of those skills, especially those soft skills so you’re making a favorable impression into the job. So these soft skills are both important for the interview so that you can establish a good rapport with your interviewer.

But also on the job, you need to be able to work well in a team, be able to explain things to people that are technical and non-technical. Soft skills, in my opinion, are everything. And if you can make really good memes, make your co-workers laugh like I do, then that goes even better.

Gems. I love it. Okay.

Don’t let on your guard. You’re you’re still in interview mode even after you’ve gotten the opportunity. Absolutely.

Appreciate that there. All right. We have another question here.

Tips for staying confident during an interview when you don’t have anything in common with the interviewer and or when the interview does not seem collaborative. Okay. So, so yeah.

So, I guess my presentation assuming you’d have an interviewer that wants you to have the job because that’s why they should be there. Sometimes you will get standoffish interviewers, that is a thing. The best thing you can do is kind of just continue on like they are someone who’s collaborative because there isn’t really another option.

Commenting your code is never bad. Pseudo coding your code is never bad. And explaining why you’re doing what you’re doing out loud is never bad.

This will never work against you. At the worst, they’ll be neutral if your interviewer is just having a bad day and they’re taking it out on you. Because that can happen because they’re people.

Even if you have nothing in common with them and they’re not being collaborative and they’re not responding to what you’re saying, the best thing you can do is just continue on with what you’re doing anyway, which I know can be really hard to do if they’re not giving you any feedback because you might think, "Oh god, am I doing something wrong?" I promise you that if you’re explaining your code out loud and you’re commenting it and you’re pseudo coding it and you’re doing everything that I’ve said for the last 40 minutes non-stop, you will you’re doing the right thing whether your interviewer reacts positively to that or they’re staying neutral. The interview and this something I mentioned on that first slide, the self-belief I think really is everything on the job. If you don’t believe you can do the job you’re interviewing for, it’s going to show in the interview.

And that will also show in the job too when you’re not confident and you’re constantly asking your senior engineers questions that you’ve asked them five times already because you don’t believe in yourself. You’ve earned the right to be in the interview. You’ve passed the online assessments.

You’ve earned the right to the job. You need to believe that in your core going into the interview. And whatever the interviewer says, you need to maintain that that mantra in your head of I deserve to be here because you do.

And them not being responsive has nothing to do with that. Love that. Yay.

Okay, let’s see. Lots of questions coming in and lots of up votes for different things. I have no complaints about all the questions.

Leaving a lot of time for Q&A on purpose, so no worries. Love it. Okay, so this is just a plug for everyone.

Upvote your stuff if you really want a question to be pushed to the top. Okay. So, this question is how can I prepare for an interview in a week or two?

So, say they have an interview, how can they best prepare for it if it’s next week? I feel like this might be a very real question for for Islam. So, what I what the best thing I could say is just is practice as much as you can.

If you know you have an interview and you know the company it’s for, do the research on the company like I was saying earlier so you can ask pointed guided questions about the company in the wrap-up section. If you know who your interviewer is and you can look them up on LinkedIn so you can find that you guys have anything in common or that you’re just taking an interest in the company so you can ask them guided questions about themsel like about their specific role that works because outside of those things about the company and the interviewer all you can do is just practice and I would definitely recommend practicing in the style I was describing by commenting your code pseudo coding it and explaining it out loud to yourself as you’re practicing leak code or whatever you’re using as your as your question bank choice I would say because that’s that’s really all you can do. Great.

I think on that same vein Destiny has a question around how did you personally prepare for technical interviews? Did you practice leak code, watch YouTube videos, read tech textbooks? Or any other tips that you’ve done or strategies you’ve done personally?

That’s a that’s a great question, Destiny. Thank you. I kind of did I kind of did everything that I’m describing to do.

The only thing I can speak of is from my own experience and what worked for me. Part of my journey was unique though and that I went from contractor to full-time. And that transition meant that I did have an interview, but I it was not mo I it wasn’t as crazy as some of the other interviews you’ll see, but that’s that’s a whole separate discussion.

But I I practice the same way. I practice the code problems. I practice YouTube videos.

I didn’t read textbooks. I don’t find myself a very read and absorb how to do something learner. That’s just not who I am.

I need someone to demonstrate to me how to do something and then I can internalize it a lot better. So I watched a lot of YouTube videos. It’s probably the most common thing I did.

And then I practice leak code. So I would research a topic exactly. I say I was researching arrays in Python because I like picking on arrays.

They’re a very common interview topic for like entry-level interviews. I researched arrays really extensively in Python by watching YouTube videos. Just and they’re not long, they’re pretty short.

And then I then I watched people solve array problems on leak code on YouTube so that I could see what the questions were like and the common things that were being asked about on leak code problems for interviews. And then I did them myself by commenting my code. I’m not I’m not as good as as you know as I want to be.

Like when I was practicing, I didn’t comment my code out loud like I’m saying for you to do now because I’ve learned things now that I didn’t know then. So I did not practice everything that I’m preaching because this was years ago for me and I had not done an interview since granted. So I could have done better but I practice the code and I suggest you all practice the code in the way I’m describing or whatever question bank you choose to use.

Awesome. And then this may be our I don’t know. Well, we’ll we’ll see if we could do two more questions.

So, maybe our second to last question is from Christopher. Is it better kind of related to what you just answered to is it better to practice leak code problems in leak code IDE or practice in a more traditional IDE like format like PyCharm etc. and then so this this question can become really company specific. If anyone here is is has an interview with Google, you should know that they do their interviews in Google Docs.

You don’t get an IDE. You get nothing. Which is part of why I mentioned that sometimes you don’t even get to write your code.

You just have to give work with what they give you. So the less suggestive your your your IDE of choice you’re using is better, which to me makes leak code better than PyCharm or VS Code because you’re not going to get those autofills for some of the places that you that you interview for. They’re not going to generate things for you.

Oh yeah, Google Docs is rough. So because knowing that going into interviews that you’re not going to be necessarily be given things, I’d recommend the leak code IDE one just because of that because it doesn’t give you any any hints while you type. And more importantly too, it’s just a really easy way to to check your code like as you’re writing it by just running the leak code test.

You don’t have to import it back and forth to figure out if it works or not. So I find the the leak code ID works really well for for practice interviewing. Awesome.

Thank you for that. And then lastly, this question is around your career path. It looks like you climbed pretty fast to senior software engineering.

What do you think helped you reach senior so quickly? That’s a great question because I get to brag about myself. So, thank you for asking it.

So, my career path was was really unique, I would say. So, as I mentioned, I graduated during COVID height of COVID. I graduated, you know, May of 2020.

So, this is this is peak COVID time. There was no job market for me at that time. There was no job market for any of my friends.

So I couldn’t find anything for a while. And then I as I mentioned, I started off with Capital One as a contractor. So, I I went to I went I signed up with a company called Cognition.

They’re also called Collabor. What they do is that you sign on to their like six to eight week training course. They train you very intensively in very specific architecture and code yada yada yada.

And then they basically deploy you. I got deployed remotely because they deploy you to their clients and one of their biggest clients at the time was Capital One. And that’s how actually I started with Capital One.

I didn’t start as as an actual full-time associate. I started off as a contracted software engineer to assist with a with a project. But you’ll notice also in the in in my slide, I went from contracted to full-time in a year.

And the way I did that, which I think is really what this question is asking, is is I own something. So the best way I think to make an impression at a company especially a software development company when you’re brought on for whatever you’re being bought on to assist with the moment you can take ownership over something over a piece of the pie or the bigger piece of the pie you can get honestly the better the more indispensable you become and the better that will look for you. So I was brought on to assist with a project and this is this is deep in regulatory reporting because that’s what I work in.

So a lot of these terms won’t make sense. It’s fine. The project I was brought on to work with is called 2052A.

That’s a regulatory report that banks have to hit to report certain amounts of liquidity in assets to the government. Very boring work. But, at the time, Capital One had been outsourcing that to a third party.

And I was brought on to assist with not with importing that to be Capital One doing it in-house. They wanted to save a couple million dollars a year in that licensing fee. I was brought on to assist with that.

And I was brought on to assist with that. And within a couple months, I I had gone from assisting with that project to leading and owning that project to the point where I I started on that in in July. And by December, my boss had put me in charge of the project.

And the way I did that was I volunteered for stories as they came up relating to the project. I made myself the subject matter expert. You’ll hearme mentioned a lot.

Becoming anme is a really key skill to have because it makes you indispensable. Especially for me as a contractor, I was kind of fighting for my life because contractors don’t have workers protections that full-time engineers do. It’s just reality.

And because I because I became the subject matter expert on that project very quickly and I signed up for every story that was or every ticket that was created for that project. It got to the point people just relied on me to get it done and because I kept getting it done that kind of became a little bit of a cycle. And then my boss basically said to me in in January of 2022 of, "I don’t know what your contract situation is, but I’m working with Capital One to buy you out of it so that you can work for us." And I was like, "Great." And and that’s how I went from contractor to software engineer.

And then a year later, he made me a senior software engineer because I finished off that project. We got it done on time, and now Capital One saves like $4 million a year on on a on that licensing fee to a third party. So, what what I would say I know it’s a very long winded explanation, but what I would say is the way the best way to stand out and and and to secure that job at least for me was to own a piece of the pie.

And I really think that applies even to the rest of y’all who hopefully don’t have to go through the same experience I did. Don’t become a contractor. It’s not something I would recommend.

It’s you get you get paid less and and you don’t have workers protections because the company that you’re working for doesn’t actually have to protect you. You’re just a contractor to them. So my my recommendation would be find a piece of the pie, own it, and become the subject matter expert on it.

And then this is a really crucial part, share that knowledge with everyone around you because it’s not just enough to know it, it’s also enough to make sure that your teammates know it, too. So that if I’m out for a week, the project doesn’t collapse. So that was a lot of words, but I hope that made sense.

Yeah, you definitely dropped some gems for for folks, a lot of insight into you know your your journey and can definitely motivate and inspire other people as well. And so we have reached the end of this session. We just want to thank Ary for this engaging presentation and just for sharing your knowledge and insight with everyone.

Please give him a round of applause and share your appreciation in the chat. Definitely want to encourage you all to make sure that you fill out the feedback survey which should be linked shortly in the chat for you all to provide your feedback to us and to stop by the net networking breaks and making sure that you’re connecting with other folks. And then now to close us out, we will now do or transition to a brief video by our host Bobby D.

Thank you for joining us in this session. I got some information before you leave. It says, "Please take a moment to complete a brief survey to share your feedback.

Remember how valuable feedback is. I’m trying to come back three years in a row and it’s all based on feedback, right? To see what comes up next.

I want you to head back to the main stage and check out the schedule. See you soon in the next set of sessions.