By December 13, 2018

Coding Interviews 101: Prepare For A Coding Interview

There are a lot of computer science graduates and programmers applying for programming, coding, and software development roles at startups like Uber and Netflix; big organizations like Amazon, Microsoft, and Google; and service-based companies like Infosys or Luxoft, but many of them have no idea of what kind of programming interview questions to expect when you're applying for a job with these companies.

“Coding Interviews” are an art… You can't just simply go to a coding interview without having, at least, a minimum idea of what a coding interview is like.

Said that one thing is clear: You need to prepare for a coding interview if you really want the job.

But… how do you actually prepare for a coding interview? What are the things you need to keep in mind when going for a coding interview?

We'll be doing a coding interview 101 series on this channel and this if the first video of the series.

Transcript of The Video

Jason Humphrey: This video is all about Coding Interviews 101. This is going to be the first of many videos I'm going to be delivering here. I wanted to set a really good baseline for people so that we're all on the same page of things I just assume we all know we need to do. Because in interviews I do on a daily basis, I feel like some of this stuff really is not apparent, and I want to make it extremely apparent to you.

My name is Jason Humphrey on behalf so Simple Programmer. Let's get started. First and foremost, your manners. Please, for goodness sakes, have some manners. Too far often, people come in and just do not have them, or they think they're right on everything. They don't open doors, they don't do the subtlest things that you would do on a regular basis, because nerves get in the way, or whatever it might be. So manners is the first key.

Listening is the second. Far too often will I give instructions that I see in an interview that people don't listen to. It's as simple as, say, taking some piece of data and putting it on a chart, or list laying it out, or console logging something, and they don't do it. It blows my mind when people don't listen to subtle requests that show you, as a candidate, don't actually listen very well. That is kind of a big problem, because I want someone on my team that can listen.

Third thing, being direct. Far too often, people are vague. When I mean direct, I mean I'm going to give you a question. If you do not know the answer, please tell me, because if you're going to start talk around in circles, you're going to end up becoming really vague in your answer. And then I might press you on something, and then you're going to be more vague. It's just going to look really, really bad. You will see, and maybe you do this yourself, people seem to think that the more they talk, the better it gets. Maybe something in there that I heard, I might like, but that's where the vagueness comes from. You talk around things so much and only 20% of what you're saying is actual content. Well, that's pretty damn vague to me. So, not vague, but be direct.

Next is confidence in how you talk about yourself. Far too often, people use the words, “I guess” and “I assume” and “Maybe if I'm right,” or they just do some self-deprecating talk, and not in a humorous way, but self-deprecating talk in the interview. It's like, wait, I want to hire a good candidate. This doesn't feel good, because you don't feel good about yourself. This actually feels really socially awkward, which I would rather you think about what you're going to talk about, talk about it more confidently.

Number five, do not lie. Please, for goodness sakes That's the second time I have to use that one, because you would think this is so obvious. It is not, I guess. Whether it might be on a resume, whether it might be about your technical skills, stories, if you lie about something, it's going to be found out more often than not, because if the story's too good to be true, which normally it is, we're going to press you on it. Then we're going to look into this and go, “Oh, so you have some AWF certificates? Tell me more. How'd you get them? What'd you do? Give me a little insight here.” Then when you don't have that insight, it becomes really apparent. I have had people lie to me before, and needless to say, the interview didn't go much longer. So, do not lie. Point number five here to 101.

Being prepared is my next point. Far too often, people come in and aren't necessarily prepared, not just on what we do, but what the company does, what the job might do, what I, the interviewer, if you know anything about the interviewer, prepare for the interviewer. It's easy to do a little research if you know who you're going to interview with. Being prepared also is in the sense of you know what you want to talk about today. You have your stories in a line. You have your resume read over. You know the job. You know all of this, and you don't come in asking really …

I normally say, there's no such thing as a dumb question. Well, there is in an interview. A dumb question is one that is one where you ask a question that you could easily Google the answer for, but instead you're asking me when I assumed you know about the research because you're excited about the job or something of that nature. With any given aspect, be prepared, because there's all different facets of being prepared. I was just kind of trying to talk about … I will talk more about that in another video here coming up soon. But point is, be prepared.

Next point, have your laptop in case you have any take home problems, or in case you're doing the next phone interview, but they said it's a technical one. Please bring your laptop home, if you're taking it from home, or wherever it is. Watch out for over and under talking. You do not want to do either/or, and this kind of goes to the point above of being direct and not vague. People will talk too much, as I talked about, and hoping they like something in there. Sometimes they'll just talk under, like, “What is AJAX?” “AJAX, Asynchronous JavaScript and XML.” Then, it's really short and they under talk it, and they don't give any context potentially, or any background to how they use it or anything of that nature, and it just becomes not a very good answer. Over and under talking is another point.

Know what you want in this role, like what do you want to get out of this? Is this the next step up for you to become a senior? Is this the next step towards management? What is this role? Because I would ask, “What are you here for? How can we help you at some point?” Far too often, people don't know what they want. It's like well how am I supposed to help you, or how do I know if this is a great fit for you if you don't even know what you want for yourself, right? Working at McDonald's could be a great fit for you as well, too, but if you don't know what you want, how are we supposed to know which one's better? I like that example.

Then the tech you want to use, make sure you know what you want to use, in the sense of right now, if you're a [inaudible 00:06:20] developer, you might like Xpress over some of these type script servers that are popping up. If you're a front end developer, you also might like angular over react. So, know what you want to use. Know what you like and know why you like it. Do you have a technical responsibility? What you know, if you say you're a front-end developer with good skills in Javascript, you must know Javascript well. You have a technical responsibility to be answering the pros and cons on it, answering why would you use it, how do you use it, where do you study, where do you learn things, how do you network with it, how do you find answers in the community, what open source projects do you follow, what styles and standards? There's a lot in technical responsibility you should know about what you're talking about or promoting yourself from your resume specifically.

Last point in the 101, that is know your audience. Please, learn and know your audience, because in every room, in every interview, it's different. Some people are really personable. Some people don't talk a lot. When I say know your audience, I'm saying the person on the other side from you. If you're telling jokes that they don't get, or you're trying to be personable towards them and they're just not picking up what you're putting down, know your audience. Know if they're not technical and you're just talking over their head, or know if they are technical and know you need to get into the depth of knowledge, not breadth. This where I'm getting with to know your audience, and I'll be doing some more on this. But know them. Pay attention to who you're talking to and make a point to make the conversation relevant and be really personable in that scenario.

That's it for Coding Interview 101. We talked a little bit here now about … I'm just going to point out a few that I really think you should focus on. Your manners, listening, the confidence, being prepared, and your technical responsibilities. Those are just a few. I'm going to be doing a lot more videos on this stuff, but this is the baseline of things I want you to know in the 101. So if you have any questions, feel free to leave a comment down below. I also will be leaving a one pager for you guys. If you have any questions, feel free to ask. I'll see you guys in the next video.

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."