Having participated in numerous interviews for various companies filling positions, I’ve seen some really great candidates come through, and some not so great. There have also been those candidates that appeared to be great, but made some classic mistakes.
With a good sampling of interviews under my belt I thought it would be helpful to list a few observations in the form of tips – mostly not to do – for interviewing. I hesitated to write this as a lot of what I’m listing feels like it should be obvious to most people, but from what I’ve seen, that’s not always the case.
Observations
- Know what’s on your resume
A big red flag goes up when a candidate cannot speak about technologies or projects they’ve listed on their resumes. If you list it, make sure you can talk about it. Better yet, list your role on the project. What? You don’t want to list that you had the merest of any participation or a limited role on the project. Probably a good indication it doesn’t belong on your resume.
Interviewers aren’t impressed or looking for buzzwords for every technology out there. We want to see projects you had a significant role or involvement in and we want to know in-depth what you did. If you didn’t have a hand in something other than having been on a team that performed some work in that area, or you didn’t actually do any of the work – don’t list it!
I’ve had interviews where I’ve paraphrased a question based on a statement on a candidates resume, asking them if they’ve done this before and the answer was “no”. Seriously? If you list it, make sure you have done it.
2. Read the job description and ensure you meet the basic qualifications
Not knowing exactly what technologies are being asked for in a position – both required and preferred/desired – leads us to believe you are mass emailing out resumes and applying to anything you can find. Normally a Human Resources or Recruiting department will screen candidates out if they don’t meet the job qualifications, but they shouldn’t have to – don’t apply for positions you don’t meet required qualifications for.
It’s disheartening when we hear someone say, “I didn’t know you were looking for that skill”, or “I’m not as strong in X” when the job positing clearly lists it in the context of “Proficient in X”. If you don’t know what “proficient” or “demonstrated ability” means, look it up.
Make sure you meet all of the basic requirements of the position before applying.
3. Don’t pretend to have experience in an area
This ties in with #1 above – if you list it or say you know something, make sure you know it.
We’ve had candidates list newer technologies like WPF or WCF on their resume which were requirements for some of the positions we’ve had and when asked to tell us what they’ve done with either technology the response is along the lines of “I’ve downloaded some of the samples and played around with them”. This is fine if the position only asked for familiarty, but isn’t normally going to suffice if it’s listed as “Demonstrable experience” or “Proficient in”.
It’s perfectly acceptable to talk about the fact that in your current position you haven’t yet used a technology and that you are immersing yourself in it on your own. This is great and shows that you can learn on your own and attempt to keep abreast of new technologies, but if the technology is a requirement of the position sample work will more than likely not be enough.
More egregious is the candidate who says they’ve spent some number of years working with a technology or had a substantial project they’ve worked on using a technology and then can’t answer basic questions about it.
Think about it this way – my job is to determine what your skill level is in any of the technologies that we might be using for our position. Given that objective, any attempt to pretend to know a technology will be exposed during the interview. It’s designed that way.
Just don’t do it. It’s embarrassing for you and us.
4. Know your skill level in different technologies
This is one of those self-reflection type of items. In preparation for the interviewing process you should have taken some time to assess your skill level in different areas. We all have stronger and weaker areas. Know what yours are – it helps.
In the interview process I will usually ask a candidate to rate themselves in a few of the skills we are focusing on in the interview. Scale of 1 to 10, 10 being an expert.
The answer to this question gives me some insight into (a) is how you rated yourself consistent with what I see on your resume, (b) is it aligned with the requirements of the position and (c) gives me a sense of what level of questions I should ask you.
(A) Rating yourself inconsistently with what’s on your resume leads me to ask you more
about your past experiences.If you rated yourself lower than your presented experience we may need to explore past project work. What was the role on the project? Did you use the skill on that project? To what level of depth?
If the rating is much higher than on the resume I want to know why. Was the role you had more substantial than you presented? Some resumes have so many projects listed that they all explanations are brief. This may indicate that your resume isn’t presenting yourself as well as it could for the position.
(B) If the position requirement lists “Proficient in writing SQL queries” and you rate yourself a 2 in SQL, we have a problem. In either case – rating yourself higher or lower than required for the position – means we need to explore further.
(C) Knowing where you think you’re at experience-wise with a technology gives me a good sense of where to start asking questions. Someone rating themselves a 5 or below will get more basic questions to start with, whereas someone rating themselves higher will start with more difficult questions. We will still circle back to some basics to ensure a good foundation but expect to be asked more detailed questions as to why/how things work.
We aren’t necessarily looking for syntax in these questions as opposed to knowledge of concepts and how things work, tradeoffs, etc. As a developer myself there are a ton of times I can’t remember the syntax for something and need to look it up or use Intellisense to help.
Reflect on your skills and “where you’re at”.
5. Don’t be afraid to say you don’t know
One common mistake during interviews is the failure to say “I don’t know”. It is perfectly valid to tell an interviewer that you aren’t familiar with a concept or technology. Constant change is a fact in our industry. There’s the possibility that given the breadth of technologies we employ and the depth of each, that there will likely be corners of a technology that you’ve used that you are unfamiliar with or even a full technology stack for that matter.
If the case occurs that the interview leads down one of these less traveled paths, it’s always preferable to an interviewer to hear “I don’t know”, rather than have a candidate try to guess, make things up or tell the interviewer what you think they want to hear. The former leaves the impression of honesty, while the latter leads to a perception of lack of knowledge or worse – of deception.
Most interviewers that attempt to be fair and find good candidates won’t immediately count an “I don’t know” against a candidate unless its in a core area that is going to be required of the position. Even then I try to weigh whether the item not understood is a conceptual issue or something that as a practitioner that you might use reference material (ie. Google, Books, etc) to normally accomplish.
When you don’t know, be honest. Don’t make things up, guess or try to give the interviewer what they want to hear.
6. Don’t talk badly about past people or positions
An obviously bad idea is to trash talk about people you’ve worked with or companies that have employed you. This immediately leaves an interviewer to believe that you are the type of person to tear people down rather than help lift the entire group.
I honestly believe most people know they shouldn’t talk badly about past employers and coworkers in an interview, but for some reason there is a subset of people that once they get in front of you can’t help but tear people down. I’m not sure if its due to nervousness, the question asked (e.g. tell me about a challenge…), or if they just really had a terrible experience with an employer.
But think about it from this perspective. You are interviewing for a position with a new company. If for some reason that company makes you an offer and further down the road things don’t work out, the interviewer is likely getting a good sense of how you are going to describe them or their company on your next interview. I can guarantee that the thought going through the interviewer’s mind is – PASS.
Keep it positive. Talk about challenges, not how much you can’t stand a company or coworker.
7. Don’t make assumptions
This is a very broad statement, but its applicable from the standpoint of, as soon as you start making assumptions there exists the possibility of error. Making assumptions can take many forms. Perhaps you think that for a certain line of questioning by the interviewer that they are looking for a certain answer. This might apply more often for a behavioral style of interview question, where you assume that the interviewer is trying to probe for whether a certain set of traits or behaviors from you. These type of assumptions can quickly lead you astray if you make the wrong assumption.
If in doubt it’s always better to ask for clarification. The interviewer won’t mind paraphrasing or explaining something a bit more clearly, and as a bonus you will appear more engaged than someone who makes an assumption.
Another assumption I’ve seen made is one of a candidate believing they are a perfect fit for the position and therefore not doing any “selling” of themselves. A candidate that feels that based on the experiences listed on their resume or previous positions held that they assume you that the interviewer will “obviously see” that they are a perfect fit, is assuming a few things.
The first thing that they assume is that the interviewer is valuing something on their resume or in their background the same way that they do. Maybe – maybe not.
Another assumption being made is that because of the “obviousness” of the assumption being made, that there is no need to sell themselves or their skills to the interviewer. Remember that the candidates main objective is to show the interviewer that they are qualified for the position and how they can add value to the organization. I can’t imagine someone failing worse than someone who is qualified and assumes that the interviewer see this and therefore doesn’t close the deal by explaining how they see themselves fitting into the position. Not to mention it gives a perception of overconfidence on the candidates part.
Assume nothing.
8. Be prepared to demonstrate your knowledge
There are several interviewing techniques that are employed, but when interviewing I usually insist on having the candidate demonstrate their ability in one way or another.
This can mean reading and discussing some code. Or it can be a whiteboard design problem that you are asked to work through. It can even be writing some code to demonstrate your ability to design something or solve a specific problem.
Now, unless you’ve really done your homework on a company and their hiring practices it may be difficult to determine what to be prepared for. The point is that if you are interviewing for a development position you should be able to demonstrate that you can develop something.
Many times the reason behind the exercise is not to determine if you read or write some code correctly or designed a system to a given requirement. Rather it’s usually tied to how you get to the result, and not the correctness of the result. It’s more helpful for me to see how you think – do you ask questions, do you make assumptions, what tradeoffs are being considered, etc – than whether you know how to solve a single specific problem.
Rather than tell me, show me.
9. Do share your non-work activities that are directly related to the position
Many candidates tend to try and avoid talking about non-work activities. In most cases I would agree. As an interviewer I don’t particularly care that you enjoy playing sports or sailing.
BUT, if the activity is related to the position you are applying for or technologies being used by all means let the interviewer know. In fact, its one of those “key indicators” that can be looked for to show some additional level of motivation or passion from the candidate. For a developer this might range from the Exchange server you run at home to learn with, or the game you wrote, or the books/clubs/organizations/usergroups you read and/or are a part of.
So if it relates to the job or technology bring it up. If it doesn’t don’t.
Good luck and I hope these tips help.
Steven Calise 