Things you should never say when interviewing for a developer role

Being a developer these days is both good and bad. There are a lot of jobs available out there but there is a lot of competition too. If a company is known for looking after their developers well, a lot of developers naturally want to work for that company. So as a developer, you want to make sure you not only have the right skills, you also make a really good impression at every interview. And this includes not saying things that are arrogant, ignorant or inconsiderate. In my role as an engineering manager, a hiring manager and an interviewer for more than 100 developers in the past few years, these are the things that I have witnessed developers say in their interviews which make them less favorable, even if their resume looks good and they did well at technical test(s). I’m sharing them with you here so you can avoid saying them and ace your next face-to-face interview. Never say, “That is a stupid framework/technology/language — why would anyone still use it today.” There is always a reason why certain things were done in the way they were, especially in technology. Technology moves fast and things change very quickly. There is legacy code that hangs around for a long time especially in large organisations. You can voice out your opinion in a diplomatic way, but don’t be arrogant about it and don’t make fun or belittle those who are still using old technologies. Unless of course you are willing to rewrite and refactor that legacy code base in a week, then you can talk. Never say, “Code reviews are a waste of time. Everyone should just write good code.” Firstly, code reviews are a good thing. If you have never had a commercial experience with code reviews before because you have just graduated or your previous companies didn’t use it, it is ok to say so but as a technical person and a developer, you are expected to at least understand why it exists. Code reviews are not there just to detect code smells. It is also for knowledge sharing and for ensuring that coding standards and requirements are met. Never say, “I would rather write new features from scratch than fix other people’s bugs.” I have heard of this statement way too many times, and a lot of the times, these candidates are contractors who chase out greenfield projects and their contracts finish when those projects go live. I understand many developers want to work with a blank canvas and build things from scratch using latest and greatest technology but it does not mean they do a better job or they are a better developer. You can learn a lot from fixing bugs (whether they are your own or of other developers), optimising and scaling existing systems. Never say, “I just get testers to do testing for me.” When you are asked about your approach to testing, don’t think and imply that testing is not your job. You are a developer. You develop features and you build stuff. You have to test what you have built. Your approach to testing might be different to another developer’s approach, you might not use Test Driven Development (TDD), you might not know about the latest testing tool in the market, but you must have tested your code in your career as a developer. If not, then you are not really a developer, you are just someone who cuts code. Never say, “I’ll go with whatever what my development manager or tech lead chooses.” An interviewer asks you about when you would choose one technology, tool or framework that you have mentioned in your CV over another one that you have also used before. Because you said you have used both before, she expects you to know what the pros and cons are of one over the other. She also wants to know your opinion since you have used them before, things that you like and dislike. When you answer it by saying you will choose whatever, it is bad because it means you have no opinion or lack of care factor. Worse, you have lied in your CV and you actually don’t know anything about those technologies, tools or frameworks. Never say, “Sorry I can’t write code by hand; on a piece of paper or a whiteboard.” Writing code by hand, on a piece of paper or a whiteboard, requires practice but don’t refuse the request when you’re asked to do it. If you have never done it before, you can say so but don’t just decline to do it because you are scared of making a syntax error. Never say, “I don’t have dedicated time for learning, I just learn something when I have to use it at work.” Being in technology, you have to always be learning and be curious about all the changes that is happening every day. When you say you don’t have time for learning, it means you have little interest in what is going on around you and you don’t care about your craft. It implies to the interviewer that being a developer is just a job for you and not a career. Never say, “I don’t want to use [software/technology/design pattern] ever.” When an interviewer asks you a question about a technology or an app or a software or a pattern, it is usually because it is important to the role that you’re applying for. design Say you’re a front-end developer and your interviewer asks you an opinion on what you think about Internet Explorer. She probably already knew most developers don’t like it, but she wants to know what you think about using it, building for it and what are some of the quirks that you’ve learned and so on. Why? Probably because it is one of the browsers that the company supports and their customers use it. If you say you don’t want to use it ever, it means you are not going to be a good fit for the role. Never say, “I have not used your product(s) before.” This is very important if you want to work for a or a product company. When interviewing at those companies, interviewers usually like to ask you about what you think of their product and if you have any feedback or any experience with regards to using their product. You may be able to get away with not having used the company’s products before if you apply for a job at an agency but it is such a disappointment if say, you apply for a job at a company that offers a platform that is available for free like LinkedIn and you said you have not used LinkedIn before. Even if you have not used it regularly, it pays to do your research the day or night before your interview, try it out, read about it, understand what the product does, what sort of technologies it may be using and so on. technology Never say, “It’s in my CV. Have you seen it?” Of course, the interviewer has seen your CV. She may have read about your experience with a certain project or a technology and she may want to know more about it and she may want to hear you explain it in more details in person. Or she may have missed that particular detail while reading your CV. Regardless of what the situation is, it is your job to answer the question consistently as it appears in your CV and not ask your interviewer to go and read your CV herself. By consistently, I don’t mean you have to memorise the exact words in your CV. What I mean by consistency is that for example, if you said you have used Spring MVC in one of your previous jobs in your CV and when you are asked to explain where and how you have used it, you can’t say, oh actually, I have not used it. Never say, “I don’t have any question. Are we done now?” This is actually one of the statements that gives interviewers a bad impression on you just as you leave an interview room, regardless of how well the interview went earlier. Interviewers usually end an interview with, “Do you have any question regarding the role, the company, or anything else?” An interview is a two-way street, and you need to know as much about the company as they need to know you. When you don’t have any question at all at the end of the session and worse, you can’t wait to leave, it implies that you are no longer interested in the role or the company. So yes, you can leave, and chances are you won’t be asked to come back either. And with that, I hope you learned a thing or two about what not to say at interviews and increase your chances of being hired for that awesome developer role. Always remember that, What you say matters and what you don’t say speaks volumes. Thank you for reading! Subscribe to my newsletter to receive articles on Technology Career, Leadership & Life.