5 Coding Interview Tips From A Senior Engineer

What's up, everybody? Travis here from Travis Dot Media. Today, I'm going to look at an article that I think will be helpful for anyone planning their first interview, for a programming job. I'm always fascinated hearing what people who conduct these interviews on a regular basis expect from those interviewing, and what kind of mistakes people keep making. So that you and I can be sure not to make the same mistakes and stand out better. So in this video, I'll give you five lessons that you can take away from this information and better prepare yourself for that next interview. Let's start it. So I found this really good medium article, which can be really rare for me nowadays. And it's targeted towards senior engineers specifically. And it's actually called "This is Why I Didn't Accept You as a Senior Software Engineer." But I think it applies all the way down the chain to mid and even junior level engineers, even if this is your first interview. Because your existing behavior like a senior in your junior interview, it's a good thing. So let's take a look at this article. So here's what the author says: I've been interviewing engineers for different companies for the last few years, but lately I've been turning down candidates like never before. I'm still using the same questions, nothing changed. The problem is that people have no idea about what it means to be a senior engineer, and these professionals are scarcer than ever. Okay, that's good. Let's find out the skills we need to work on to make us some of the scarcer people. And that leads us to lesson one: general knowledge. I call it general knowledge. You call it development methodologies. So let me read this: development methodologies are organizational methods that are meant to make teams effective. These can be boring for us, but it's expected of you to have expertise in them. During my years of work, I've developed rejection not as a result of development methodologies, and more than that, I think this skill is not agile enough. It's also used in helping the ego of the project managers more than the programmers. I agree. Though I like scrum, but I like this more too. So here's the point: when I do an interview, I look for that capacity to criticism and developers knowing scrum is not enough, but you also have to know its disadvantages and propose solutions to them. So the lesson here is that you shouldn't be agreeing to everything. We go into the interview and we're like, yeah, yeah, I like that, yeah, I like this, but you should be forming opinions about things with reasons to back them up, not in a quarrelsome way. But no one really wants another developer that just does whatever he or she is told, without sometimes disagreeing or offering better or alternative solutions. As a developer, programming is only part of the job. Another very important part is meeting with experts on the task at hand. Maybe the feature that the project manager or the client wants is not an idea or will not go well with how things are currently built. You need to speak up, share your concern, and offer a better alternative. In the case of this interviewer, he's looking for someone that can offer their opinions of scrum, regardless of like or not. You can actually offer your opinion about it, not just agree to whatever he says about it, in the hopes that they give you the job because you are the same. The lesson here is to read up on things, form opinions yourself about industry-wide tools, development methodologies, and be able to be mind about it if asked. The point here is not that you need to learn scrum for this guy. The point is that if you're asked about scrum, you have an opinion about it. We want to carry on the conversation with the interviewer, and not just nod our heads at everything said. And I'll close lesson one with this quote here: I thought it was good. General knowledge will help you form better opinions and show your willingness to learn outside your field. General knowledge is important. Read up, form opinions. Lesson two: How well do you know your language? Here are some sections software design principles. The reason that rockstar engineers so much more valuable than the counterpart is unique programming. The great software engineers incredibly creative and can see conceptual patterns others can't. After finishing every interview, this is important. Listen to what this guy is saying. After finishing every interview, when writing feedback for the candidate, I swear I could copy and paste the same response every time. And it's this: I suggest you read more about Python design patterns. A good resource can be this guy. We'll get back to that guy in a minute. It's so easy to filter candidates with design principles. Only in really strange cases I've found people with answers to all of these questions. Any goes on to say that these design patterns are challenging, not always easy to apply, and recall them. But forcing yourself to do these checks while you're programming will put you a step ahead. Why do we use linked, array, and Python? While another language we can use, array, dot, link, is there any optimization behind it? How much do you know your language? So this lesson is two-fold. Number one: learn about your language design patterns, and two: know your language well. That's why I want to say: start out programming, learn one language, and learn it well. Like JavaScript, you can do everything with it, or Python. That's a popular one. Let's say that you learn Python first, and you decide to go all in with it. Learn it well. Learn its quirks. Find a book like one of those O'Reilly books. Go in depth with the language, be able to discuss things like why Python is using a linked function instead of a linked method. As this author mentions, sure, this may be more tailored to senior interviews, but it will help you stand out better as a junior, if at least familiar with the deeper parts of language such as you can carry on the conversation about. You don't have to be expert, just be able to carry on the conversation. Think about books like JavaScript: The Good Parts, a book that's old but really helps you see what's going on under the hood and learn about the quirks of the language. He says here, reading a book about the language you use is absolutely necessary when you're growing in senior engineering interviewing, including advanced questions that you will only know by reading, because books always go deeper than online courses. So do the online courses, learn the stuff, and then go deeper. Learn the language, build projects, get familiar, learn algorithms, but also here and there read new chapters too that take you a little bit deeper. Next, try to learn some design patterns for that language, or really design patterns in general with programming. Yeah, even as a junior, as you build apps, if it's Python, then do check out the linked library. It's really, really good resource. It's at Python Dash Patterns dot Guide, and here you have a handful of principles and patterns that you can learn if you're using the Python language, as the author suggests. Practically, be working through some of these in the Travis Media community when it reopens in January. I close for December because I'm doing a complete makeover in overhaul of the community. It's going to be awesome and real answers. If you want to be notified when it reopens, just go to Travis Dot Media slash community, put your email in the form here, and I'll email you when it reopens and work in your hobby projects or your portfolio projects. Your course don't have to memorize all of these and be able to implement them all, but if you're at least familiar with them, it can implement for you. That's enough to allow you into the conversation and thus have an opinion, which is part of lesson one that we just talked about. Lesson three is check your attitude. Look at this: working with the right person is immensely difficult. They make you feel bad all the time, and create bad vibes in the team. In the long term, the damage that such a person can do, the company can be very expensive. This has been an experience in every developer out there probably working with toxic developers. Companies are looking for great humans when they're offering humongous salaries, and part of that is being a good person. When doing an interview, we're not only evaluating the candidate's knowledge, but also his or her attitude. In a specific process I did months ago, the company asked specifically to look for good, honest persons, more than great programmers. He was told to look for good, honest people, more than great, great programmers. I can attest the companies doing this personally. The job I had in the past as a cyber liability engineer did just that. The CEO landed a new contract. They needed very people, local people. We had to go into the office, but he was only then, he found a wonderful, nice, me being one of them. He reached out, called me on the phone, told me the situation, told me the company philosophy, which was we look for good people who can easily learn the stuff. He said a lot of companies they want the best programmers, they don't care about the people themselves or their personality, they just want the best programmers. This company flipped all of that. It's looking for good people who love to learn or are easily teachable and don't have attitudes. So we talked things went really well. I still had the coding exam, but I got the job despite not really being qualified as an expert. I was a developer, but they were looking for good people who could learn and weren't toxic to be around. A bad attitude or lying could imply immediate elimination from selection process. Line two: I always recommend the book How to Win Friends and Influence People. It's one of those books that everybody should read to have better relationships in life. That happens to be a book we're just finishing up in the Travis Media community. It's a good one; should read it. Before we get lesson four: quick information. What should a junior mid read to become a senior? Here are some fantastic resources to grow as a senior developer. I'll put links to these below because this article is member only. Articles some of you may not be members, but they're really good. You use AI to simulate interviews. Here are some websites for programmers to visit. But these can be used even for maps. So really, just one dimension, real quick. If you need a roadmap for learning some technology, let's say you want to learn JavaScript, just go down here, click JavaScript roadmap, take you to a site called Roadmap dot S slash JavaScript, and you just start from the beginning. So introduction to JavaScript. What is JavaScript? History of JavaScript. Once you know that, you move on to all the variables. You learn about variable declarations, hosting, and you just continue to go down the line until you know everything about the language. Use this tool to go deeper with the language, as we mentioned in lesson two. Lesson four is what about my coding skills? So far, we've mainly been talking about communication skills, knowledge skills, being able to carry on a technical conversation. Well, often we just need to know all the algorithms and levels, but that isn't the case. It's both, and often we tip the scales more on the technical side for lack of the communication stuff. But we do need the coding skills. So this author recommends, "Leak Code." Everybody recommends leak code premium. I bought leak code premium some months ago. It was a great decision to land my current job on your way to discovering the magic here, all these patterns and optimizations for modules. Not a failure. I haven't done sin of the hell with this. That's just a recommendation. Simulating an interview from a big company can also be useful to understand how they're structured. Lesson five: the hard but understandable truths. This is very important. You simply may not be the right profile for the company. So now you with me, right? Now seriously, quit beating yourself up because you saw everyone saw said the coding interview. Actually, a really old video, but it's a bit crazy about when I really bombed an interview and passed up only two of them. Even after reading a lot of material, practicing every day, and having a lot of experience, you could be rejected because you're just not the right profile for the company. So lesson five is that you may do great at the interview, you may be expecting to land the job, and then you get bad news. But you have to remember that it may just be that you weren't a good fit for that role. Nothing to do with your skills. Nothing to do with your personality. But the company has a profile certain profile they want to fill, and maybe you just weren't that. The only things you can expect from yourself are resilience and persistence. Those are not only the skills necessary for the job in the future, but they also are the main skills we expect from a senior engineer. You found this video helpful? Give the thumbs up, consider subscribing to the channel, and I'll see you in the next video. Thanks for watching.