#1. Saying too little
Especially to open ended questions like “tell me about yourself” or “describe a project that you were most proud of, and what were your contributions & accomplishments?”. Interviewers will be assessing how passionate you are about cutting code and solving technical & non technical problems. They will also be judging your experience, ability to communicate your thoughts, and get things done in a team environment. So, just answering with 2 or 3 sentences will not only fail to bring out your real interest for the profession, but also will make the whole interview very boring. If you are not enthusiastic about how you can add value to the organization from your past experience, accomplishments, and skills, your prospective employer will not be enthusiastic to offer you a the job. So, prepare well for the most common open ended Q&As, scenarios based Q&As and edge case Q&As. You need to sell yourself and no one else will do it for you. Good handle in the technical key areas like performance, memory management, scalability, security, concurrency, transaction management, SDLC process improvement, etc can go a very long way. They are my trump cards to impress my prospective employers.
#2. Talking too much
Going on and on about yourself without much substance. In other words, lots of fluff without any stuff. If you can’t concisely explain things, how are you going to get things done on the job? Ask the interviewer(s) if they want you to elaborate. It is an art to look at the big picture and drill down to the details when it is required. When talking to the business, look at things from the business perspective without any technical jargon. Learn to explain things in a simple and concise manner. You can do this when you have a good handle on the subject matter.
#3. Failing to answer must know fundamental technical questions
Interviews are not technical contests to see who gets the most number of questions right, but there are a number of “must know” core Java and web basics that you can’t afford to not know. These are the questions with the “♦” symbols in this site. For example
1) Not knowing the difference between “==” and equals().
2) Not knowing the contract between equals() and hashCode() methods and when they are implicitly invoked.
3) Not knowing the OO concepts and the design principles.
4) Not having a good handle on multi-threading.
5) Not knowing how to maintain states between an HTTP client and the server.
6) Not being able to explain the high level architecture of the application you had worked on.
7) Not knowing SQL.
#4. Failing to write simple code and not thinking out loud for more difficult problem solving
As a developer, depending on your level of experience you must be able to write code for a given problem or scenario. When you are given a more difficult coding or a problem solving question, you need to at least think out loud to let the interviewer know as to how you would go about solving the problem, even if you don’t arrive at a solution or the right result. It is quite natural to be nervous at the interviews and the time limitation can make things worse, but at least explain the approach as to how you would go about approaching the problem.
#5. Bad etiquette and attitude
arriving late, bad dress code, sloppy hand shakes, not making eye contacts, being too nervous, failing to ask questions, not showing real interest in the position, “I know it all” attitude, bad mouthing your current and past employers, getting irritated and frustrated during the technical grilling, giving excuses as opposed to accepting your mistakes, starting an argument, bad body language, being an “yes” person without having your own opinion, being too inflexible, lying, raising your voice, being a bad listener, etc.
Tip: Interviewers are not looking for rock star techies, but for well-rounded professionals with right technical skills, soft skills, attitude and real interest to add value and get things done for the organization being interviewed for. So, research the organization and thoroughly understand the job specification to be able to tailor your answers.
Treat each interview as a free training session , which leads to a win/win situation and reduced nervousness to perform better. Even if you don’t get the job, you will learn something out of it.
Latest posts by Arulkumaran Kumaraswamipillai (see all)
- 15: Spark joins with Dataframes & SQLContext - December 17, 2017
- 14: Spark joins with SQLContext & JavaPairRDD - December 16, 2017
- 13: Spark inner & outer joins in Java with JavaPairRDDs - December 16, 2017
- CAP theorem interview Q&As - December 16, 2017
- 00: ♦ Creating a Tree from a list & flattening it back to a list in Java - December 13, 2017