Software Engineering Interviews – 5 Red Flags

Avoid these things and Increase your chances to crack Interviews

• Going to an interview unprepared – Preparation is the key to success and the most important part of your job search. But wait, preparation is more than you thought what it is. Preparation is not only about brushing up on your tech skills, but it is also about knowing about the company-> team -> specific interview expectations in the specific order. Every interview has a scope and you need to know that in detail. Do not get surprised when asked to code in a coding interview 😉 . You should know in advance if your interview is going to be on a whiteboard or a pair programming laptop interview with one of the team members, if you are expected to design api’s, draw some system architecture diagrams or just talk about them. Ask your recruiter all your doubts, prepare within that scope and you will find yourself in a much better position.

• Not Reviewing your Resume – Do Not write something in your resume only to attract the recruiters or to make your resume look cooler. Be sure about what you write in your resume and make it very point to point, relevant to your experience and use a good concise format. Understand, there is a big difference between writing a cool Technology X in your resume and knowing about it in depth. You must know the why’s/what’s/when’s/how’s of any technology, language or framework which you have mentioned yourself as an expert at. Writing cool stuff, buzz words are usually an invitation for the interviewer to grill more on those topics and if you are missing the basics it could lead to a bad experience.

• Talking too much Or too less – Basic human nature, either makes us “speak a lot” or “swallow our tongue down the stomach“, especially when we are nervous. Communication is one of the most important skills of Software Engineers and interview is all about conversation and an opportunity for you to drive it in the direction of your strength. Keeping a balance is very important otherwise it becomes annoying for the interviewer in both cases. If you speak a lot, you might not be listening properly to what the interviewer has to say. If you speak very little, interviewer might think you are nervous, uninterested or know nothing. You need to be a good listener and speak when required. Ask questions when in doubt but make them point to point and concise.

• Jumping on the solution – As an engineer you have to understand the problem statement, ask clarification questions, think about the edge cases, come up with a few approaches, finalise the approach and then solve it. If you do the last step first, then chances are your solution might be incorrect, partially correct, sub-optimal or works on some incorrect assumptions. Obviously any of these cases would result in a bad feedback from the interviewer. To avoid such cases, take one step at a time. Even if you have solved such problems before, there could be a catch and if you try to rush, you might fall right on your face on the floor made of bullshit. Some example questions to ask yourself and the interviewer could be :
  • Can the input be negative ?
  • Will my approach work for very large inputs?
  • What happens when the input is invalid ?
  • How much should the application scale?
  • How is the input given ?
  • Is it a multithreaded environment ?
  • Memory or speed? which is more important?
  • What is the user journey ?
  • For how much time we have to store the data ?
  • How about the security of the application ?

• Being on the Extreme sides – I have heard candidates saying “I hate Java script”, “Who uses SQL now? It is old and boring”, “Always use micro-services”, “Spring is the best”, “I do not write test case, we have a separate team for that”, “Are developers responsible for deploying the code? Who monitors the system ? I hope not developers” etc. Being a software engineer you have to understand features and limitations of the technologies you are working with. No technology is the best or the worst. There are always use cases and you have to make a decision based on that. For example, if a monolithic architecture works for you why go for micro-services pain? SQL is also very scalable but it has its own use cases. NOSQL is highly scalable but not meant for everything. Scala might be a choice for some use cases but if a team struggles with it, it is a wrong decision. Java works for many cases, but sometimes you might also need PHP (ok this is a joke :P) but I think you got my point. In short, you need to understand the pros and cons and then make decisions based on what works best for you.

At the end, an interviewer is looking for a co-worker who is a Good Software Engineer and can work with him to solve a complex engineering problem. Try to be that and you are almost there.

Software Engineering is a combination

Writing clean code

Designing scalable systems which are easier to maintain and understand

Writing Documentation

Communicating Well

Automating

Monitoring

Problem Solving

and Working as a Team…

Hope this helps all the candidates who are doing these mistakes and don’t even know these need to fixed. I have also done these mistakes at times and have seen hundreds of candidates doing this when I am on the other side.

Cheers,

Kaivalya Apte