054 How Do You Prepare For A Technical Interview?

How do I prepare for a technical interview? What should I study? How do I get the practice I need to be ready for a technical interview? How do I make sure I won't freeze up? These are the questions we will tackle in this episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_01 0:25

So, how do you prepare for a technical interview? This question comes up over and over again. So I want to take a minute to address this question. Step number one for preparing for a technical interview, relax. Okay? This is the best advice. This is the best thing you can do for succeeding in a technical interview. Not cramming for it, not Googling every potential question and trying to figure out the answers to it, not memorizing things. Relax. Breathe. Because here is the goal of a technical interview. The goal of a technical interview is to figure out where you are technically. To figure out what you know. Now, is this something that is ideally crammed for? No. Because that's not who you are. That's not what you know. It's what you crammed in your brain last minute. You probably don't even know how it works, you just know it does. That's actually a recipe for disaster. So I would say relax. Remember that you're just showing off who you are. And you know what? If they say, well, you know what, you're not gonna be a good fit for this role because you don't know enough to fill this role. That may be true. It may be that if you tricked your way into getting that job, that you'd be miserable because you're in over your head. Now, I am not gonna sit here and say the reason you failed your inner your technical interview is because you're not good enough. That's probably not the reason, but that's what they think the reason is, potentially. So the reason you fail your technical interview is because interviewing is hard. It's hard on the interviewee and it's hard on the interviewer. Both sides don't know what they're doing, really. Um, there's not a cut-and-dried way to interview a software developer. In fact, I have seen great evidence to prove that no matter how you interview a software developer, you're probably doing it wrong. The best way to interview a software developer is to have them do the job. And if they do the job well enough, then you hire them. And if they don't, then they didn't pass the interview, they didn't fit in. And that's that's okay. Not everyone's gonna fit every role or every um within every team dynamic. But so interviewing is hard, it's not gonna be great necessarily. When you walk in for a technical interview, they may ask you trick questions, they may ask you um just to design an app on a whiteboard, they may ask you to write actual code. Who knows? Because every company's technical interview is different. So if you try to you know learn up, but you try to really cram your brain full of stuff when you don't even know how they're gonna interview you, what you're gonna do is stress out your brain. And you're gonna be stressed out, you're gonna be, you know, tired, you're gonna be drained, and that's when you're gonna walk in and show off who you are. That's not a good look. That's not who you are. Who you are is hopefully not a stressed out, run-down, overworked, tired person. And if you show that off, what would you think? If you saw a person walk in the door and you realize this person's on the edge of being burned out, that's not who you want to hire for your role. That's not who you get excited about and go, yeah, that's a good fit. Instead, you find a person who comes in with a smile on their face, who looks relaxed, who looks confident, and who goes, I don't know the answer to that, but here's how I'd find out I have a ton more confidence in that person because they show off that they are a person who can answer a question when they don't know, and they show off that they can do so, the pleasant attitude, and that it sounds like they know what they're doing, that shows off a lot more. And then let's talk about that answer too, because if I ask a question in a technical interview, and I say, you know, um, how would you calculate the square root of 83 without a computer? Which is a stupid question. But let's just say I asked that question, and the person at the other end goes, Well, what I would do is I would write this, and you go, that ain't right. You know, so you're judging them, going, hmm, that's not gonna work. Or the person goes, I don't know. I don't know how I do that, but here's what I do know. I do know that I would start by asking Google this question. I would say, you know, uh, how to create, you know, how to um calculate square root first. I learn about the math of it, and then I'd learn about the C sharp side of things if I had a question. So, for example, if I learned about the square root and I realized that you can calculate it using this formula, um, but I don't know how to do that formula. What I would do is I'd I'd go to Stack Overflow and I'd ask the question Does anyone ever implemented this formula? And if so, I would look at the the suggested answers, all of them, and figure out which answer seems to best fit my scenario. And then I would put it together in this way. I'd probably put a class library and wrap it in a function, probably a static function, maybe, um, or either that, or I would use um a singleton in my dependency injection system so that we could, you know, not have a duplication of the instance because it's just a calculation that way it's faster and less memory intensive. And this is what I would you know write it up as. Okay, I have no clue how to answer that question, not just doing you know, math.sq R T, I think it is. Um, I don't know how to answer that question, but that's the way I approach it. And by saying I don't know, you actually raise a person's confidence. Now, if you don't raise a person's confidence with I don't know, then one of two things is the case. Either one, they're expecting you to know it all, and that's a big red warning flag, or they don't want to hear excuses and they think that's an excuse. And that's also a big red warning flag. So if they say that's not acceptable, say I don't know, then say this is probably not gonna be a good fit because you don't want to fight for a job, you don't want to claw your way into a job where that's the expectation, where you have to know everything, where you have to be on top of everything and never have a question, because that's not gonna work well. You're gonna have questions. And if you have questions and if those are bad, then you're gonna live in constant stress and you're gonna be miserable, even if you succeed in staying in the job, or more likely, you're gonna get fired or let go because you just don't cut it in that environment. So don't fight your way into a job that's not gonna be right anyway. But if you say, I don't know, it should raise your status in the minds of the interviewers. Because unless it's a required skill, if you said if they say, How do you um say you know hello world in a console app, and you go, I don't know, but okay, that's gonna show off a lack of technical skills. But if you say, I don't know, but here's how to find out, you are talking through what every developer does almost every day, which is I don't know, but I use Dapper a lot, a lot for my data access. I use SQL databases quite a bit, and Dapper is my go-to tool for accessing those SQL databases. At this point, I can probably write the syntax for a Dapper command without you know, without looking at a an example of it, but I don't bother. I look it up, I make sure I'm right, I copy and paste my previous my previous versions of it. I use a library where I just put in and use it. I don't have to remember it. I'm not gonna memorize the commands for making sure all the, you know, for doing Dapper. It may come naturally because I use it often enough, but I'm not going to worry about it. And so if you were to you know put me in front of a whiteboard and say, write out you know how to do a Dapper query to a SQL database, I might get it wrong. And that's okay. And if I approach it that way and say, you know what, I'm not sure I'm gonna have a perfect syntax, but roughly, here's what happens I open the connection string in a using statement so that we're gonna close it automatically down here, and then we're going to do a adapter.query probably, I believe it's query, um, unless it's the other one, which is execute, I think. Um, and I'd say that. I'd say, I think. Um, but that's the you know, the non um non-return value type. And um, and then I'd you know, I'd pass in my my SQL command, I'd pass in my parameters, and I'd pass in any other um conditional or other information. And they'd say, you know, what other information? Well, normally I don't have to. Uh oh, connection string. There's one. And you know, that if you talk it through and you're just yourself, if you talk it through and say, this is how I normally do it. I normally have an example I've already done because I've done this a lot. So I have an example I've already done, and I just take that code and make sure that my current code mirrors that, and then I just tweak it for whatever I need to in the new code. That shows off you know how to get the answers and you know how to go through a steps. So a technical interview doesn't have to mean that you know everything cold. And if you are a technical interviewer and you are asking people to know things cold, that's not a good technique. Don't do that because you will pass on great candidates who haven't memorized it. In fact, you'll probably pass on better candidates than you will get. Because the people who memorize are not usually the people who have used it. People who use it usually use it and then they forget it. They know how to do it again, or they do it once, dry, they do it once and don't repeat themselves. They put in a library somewhere and they just call it. So they never have to know how to do it again directly. And so those are the people you want to go after, the people who are doing things intelligently. When it comes to an interview, the closer it gets to a real-world environment, the better you will start to see who people are. So when you're walking into a technical interview, relax. Be yourself. Feel free to say I don't know. But don't just say I don't know and leave it there. Say I don't know, but here's how I would approach finding out. This is the term I would use in Google. You know what? I would look for the Stack Overflow results, even if I Googled it. I look for the Stack Overflow results to find out, you know, what other people have gone through the same problem. You know, I would I'd probably look at this and say, hey, is there any examples out there, not exact of this exact problem, but of this part of the problem? I'm sure that someone's done it before, and I want to see what their feedback is on it. You know, hey, I don't feel comfortable in this particular part of the answer, but here do I do to find that, and here for the rest of it is what I would do. By being honest, by being relaxed, by being feeling free to say, I don't know, but you will come across as a more competent, more with it developer who understands who they are as a developer and knows how to get help. With that, I'd probably share. You know what? I haven't gotten that to that in my training journey yet, but it's on my list at number three. Would you suggest I move to number one? Is that gonna be something we use a lot in this organization? Because I can move it to number one. We can I can work on training on that soon. And by the way, here's how I do that. So having a training list that you're working on and being willing to talk through how you do training is also a big bonus. If a person comes to me and says, Yeah, I don't know everything, but here's my plan for learning more, and here's how I do it. That's incredibly impressive. Because a person who is actively engaging in knowing more, a person who has taken control of their destiny when it comes to their experience and their skills is valuable. Not everybody does that. In fact, most people don't. In fact, if we had to do a poll the audience, I am guessing that most of you don't have a training plan written down somewhere. That might be something I would address. Create one and then maybe it makes it public. Not so that you everybody sees it, but so that when you go and interview, a technical interview, and you say, Hey, you know what? Can I show you my training list and have things crossed off and things that you know are on the list next? And you say, you know what, it looks like that's right down here. Or you know what? I just learned that two weeks ago. Be honest. So you're not saying, oh, I've got five years experience in you know, dot net five. Yeah, okay, sure you have. Um's not been out that long. So if you are honest about it and say, that was in my training regimen from three months ago. And since then I've done these things with it. Not only does that communicate that you have learned something and you're growing in it, but also that you are training actively and not just for a job. So lots of things you can do to prepare for a technical interview, but the number one thing is to relax. The number two thing is to be honest and say things like, I don't know but. And walk in there with a positive attitude. If you walk in there with a chip on your shoulder, if you walk in there saying, Tim Corey says this is stupid, don't do that because you're right away set yourself up for failure. Go in there, don't disparage the process. The process is hard. It's there's not a great solution. There's not the one size fits all interview process, but um just walk in there with a positive attitude, walk in there empathetic to their situation too. Man, I know that technical interviews are hard on you guys. Um, man, you know, this is this is hard on you, folks. What can we, you know, how can I communicate what I know? Um, and talk them through it. Be positive and proactive, be sociable, be kind, smile, present yourself in a positive manner. And part of that comes from not being burned out, frustrated, and just overworked trying to figure out a way to sneak your way through a technical interview. Okay, so that's my thoughts on the technical interview process. Great questions coming out of the um the community. I appreciate every one of your questions in this and other areas. If you have a question that you want to see answered, go to I am Tim Corey and look for the podcast page, fill out the form there, and I will try to get your question answered on this on an episode like this. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_00 17:53

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamTimcorey.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.