Again, oftentimes people give the advice to keep talking, keep talking at your interviews and what they really mean is this kind of stuff, right? Keep talking about your thinking not what's going on in the code and you realize there's three things that you've done. So take some time to talk about your approach. So if you say you know what? I'm going take a recursive approach and they look at you like excuse me? Then you know that you're probably on the wrong path right? So if you say well I'm going to take a recursive approach, I'm like okay, that makes sense, then you're playing the interviewer a little bit as well as playing the question. Are you going to look for a recursive solution, an iterative solution, a heuristic solution? Give the interviewer some insight into your logic and thought process and really help them understand kind of the track that you're going down so that you know you also get a little bit of read on if you're on the right path by how they respond to your questions. So start talking about the approaches you're going to take. Now the third step A, describe your approaches. This is another great way to keep the conversation flowing and make sure that you understand what the question is asking. How can you start understanding what's inside the black box before you know giving something into the black box, what comes out on the other side? So list out examples. One way to think about this is that this problem is a black box. ![]() This is another way to really understand what exactly the question is asking because you oftentimes will get a lot of understanding by just understanding input, output, input, output. So just create a little table, a two-column table and say given these parameters what output do you expect. So before you even write out any code write out, "hey here are the parameters that I'm going to pass into my function and what did I expect to get out," right? The second thing is to start writing out various examples. ![]() So the first thing you should do is really just repeat the question and that will oftentimes help A, help you understand it better and B, really make sure that the things that you don't understand you can work out with the interviewer as you're going through the repeating of the question. So you're going down the wrong path immediately and that immediately puts the whole interview onto a tough foot. So they already know all the paths that you can go down that are going to be incorrect. Now one secret is that when you're interviewing with somebody people like to use the questions they're comfortable with so very likely they've done this question 100 times and this is the first time they're seeing it. I can tell because the first step they say is makes me just know they're going to go down the wrong path. I say implement this thing and the first thing they do is they take the cap off the pen and they start writing on the whiteboard, before they even really understood the question. ![]() You wouldn't believe how many times I'm in the interview room with a candidate and I'm excited for the candidate and we're having a good chat and then we get to the programming question. R: Repeat the QuestionĪll right so let's start with R, repeat the question. So what does REACTO stand for? Repeat, give examples, describe your approach, implement the code, test the code, and then talk about optimization. So it's R-E-A-C-T-O, nothing to do with the REACT framework it's just something that as I was coming up with an acronym I wrote out kind of the exact steps and REACTO was the acronym that came out. So at Fullstack we've invented a method that we like to call the REACTO approach to solving interview questions. I wouldn't be upset that you're nervous about it, it's just something to practice for. It's one of those things where even to this day when I'm interviewing for technical jobs I still get nervous about it, even though I've done hundreds of them, I've been on both sides of the table and I've also, I've practiced a lot of coding problems throughout my lifetime, it still makes me nervous. So it's a pretty intimidating process for entry-level developers, actually to be honest it's intimidating for everyone. Usually you're working with people you know. And this is really one of the hazing processes of getting a job in tech is you got to get into a room with another developer, someone you've just met, they're going introduce you, introduce themselves to you and they're going to give you a problem and you're going have to solve it on a whiteboard which is totally unnatural, I get it. ![]() So one thing I want to talk about today is how to ace that technical interview.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |