Isabel presents us with a list of answers to avoid at all costs and ace your next interview!
Want to get hired? Avoid these answers at all costs!
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, but 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, hiring manager, and interviewer of more than 100 developers in the past two years alone, these are the things I have witnessed developers say in their interviews that make them less appealing — even if their resume looks good and they did well on technical and coding tests.
I’m sharing them with you here so you can avoid saying them and ace your next face-to-face or virtual interview.
Coding-Related
“That is a stupid framework/technology/language. Why would anyone still use it today?”
There is always a reason why certain things were done the way they were. 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 your opinion in a diplomatic way, but don’t be arrogant about it or make fun of 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.
“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 they exist. Code reviews are not there just to detect code smells. They are also for knowledge sharing and ensuring that coding standards and requirements are met.
“I would rather write new features from scratch than fix other people’s bugs.”
I have heard this statement way too many times. These candidates are often 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 the latest and greatest technology, but that does not mean they do a better job or are a better developer. You can learn a lot from fixing bugs (whether they are your own or of other developers’) as well as optimising and scaling existing systems.
Behaviour-Related
“I just get QA and testers to do the 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 from 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.
“I’ll go with whatever 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 that you have also used before. Because you said you have used both before, they expect you to know their pros and cons. They also want to know your opinion since you have used them before. When you answer the question by saying you will choose whatever, that is bad because it means you have no opinion or do not care. Even worse, you may have lied in your CV and you actually don’t know anything about those technologies, tools, or frameworks.
“I don’t have dedicated time for learning, I just learn something when I have to use it at work.”
In technology, you have to always be learning and be curious about all the changes that are happening every day. When you say you don’t have time to learn, that 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.
“I don’t ever want to use [software/technology/design pattern].”
When an interviewer asks you a question about a technology, an app, or a software or design pattern, it is usually because it is important to the role that you’re applying for.
Say you’re a frontend developer and your interviewer asks for your opinion on Internet Explorer. They probably already know most developers don’t like it, but they want to know what you think about using it, building for it, 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 ever want to use it, that means you are not going to be a good fit for the role.
Big Picture-Related
“I have not used your product(s) before.”
This is very important if you want to work for a technology or 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 applied for a job at an agency. However, it is such a disappointment if, say, you applied for a job at a company that offers a platform that is available for free (e.g. LinkedIn) and you say you have not used it 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.
“It’s in my CV. Have you seen it?”
Of course, the interviewer has seen your CV. It may have even been a perfect CV which was why you’ve gotten an interview. They may have read about your experience with a certain project or a technology and may want to know more about it. They may want to hear you explain it in more detail in person. Or perhaps they 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. Do not ask your interviewer to go and read your CV. By “consistently,” I don’t mean you have to memorise the exact words in your CV. What I mean is that if you said in your CV that you have used Spring MVC in one of your previous jobs and you are asked to explain where and how you have used it, you can’t say, “Oh, I actually have not used it.”
“I don’t have any questions. What’s the next step?”
This is actually one of the statements that give interviewers a bad impression of 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 questions 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 questions at all at the end of the session — or worse, you can’t wait to leave — it implies that you are no longer interested in the role or the company.
Yes, you can leave, and chances are you won’t be asked to come back either.
Conclusion
And with that, I hope you learned a thing or two about what not to say during interviews to 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.
