Job interviews can be nerve-wracking experiences, even for the more senior-skilled of us.
Having been on both sides of that table — with more than half of that time spent in the interviewer's chair — I have conducted or sat in on more interviews for developers than I can recall. Yes, junior, intermediate, and senior, I have seen them all.
In spite of the volume of interviews conducted, however, I continue to be surprised at the variety of candidates that grace my office. And irrespective of the skill level of the candidate, there almost seem to be de facto categories or types that most developers fall in to. So after years of exhaustive research and note-taking, I present to you, faithful reader, a listing of the types of developers you are most likely to run into as an interviewer. This listing will be delivered over the course of this series, so be sure to check back regularly for new types.
To those of you reading who will soon be on the other side of the interview table (i.e. the interviewee), have a read through yourself to identify both tips to incorporate and potential pitfalls to avoid during your interview.
To be clear, this series will focus more on technical interviews, and less on interviews with, say, the HR department.
We begin the series with an interview type that is more prolific than I would care it to be. The real danger of "scammers" is if they get past the hiring process, untold, undeterminable damage can be done to your organization and its work product, even with the best project practices and tools.
What can we learn from this slippery fish?
A mix of truth and unverifiable substantiations and answers. Note that "lying" is not necessarily in the preceding list, which is what makes the candidate particularly dangerous. Much like a con artist does, this candidate will reassure you with a few guaranteed answers and a whole lot of half-truths and plausible-sounding replies.
- Too few or too many references. This can be a warning sign that the candidate in question is either trying to hide something, or over-compensate. Also be on the look out for purely academic references, or references that are difficult to contact (e.g. all are from foreign countries).
- Answering slightly-modified versions of questions. We all have standard technical questions we like to ask. Be on the lookout for answers to questions that are actually slightly different, usually a bit easier or more difficult to verify (see above).
- Offering up too many details. A lot of candidates love to share the information and accomplishments they are the most knowledgable or proud of, and some candidates just get carried away. However, these diatribes typically are tightly focused around a particular thesis. The scammer will often meander through a labrynth of unrelated points in order to boost confidence.
This candidate type can be a difficult one to detect, but usually he/she will become obvious as the interview drags on.
What can we, as interviewers, do to help expose, weed out, or minimize the impact of this interviewee type?
Ask as many objective questions as possible that have well-defined, clear-cut answers. If more complex questions are necessary, make sure you are thoroughly well-versed in the concepts and methodologies that need to be applied in order to answer the question, and have them explain and show all work. For example, questions about data structures, algorithms, and their best-case, worst-case, and amortized runtimes. Avoid asking too many questions about how they might be used, as that leaves a lot of room for interpretation (though sometimes that sort of question is needed to gauge resourcefulness).
Do your best to contact all references and ask them specific questions about the candidate's role and achievements while at the company.
Call them on meandering answers. Just letting their answers go can sow more doubt in your mind, and convince the candidate the he/she is getting away with it. Instead, as the interview goes on, politely keep them on track; this will often allow the candidate to dig a deeper hole which is easier to catch out--the candidate will usually talk more, not less.
The occasional trick question can also keep candidates honest, but not too many.
What can we, as candidates, do to avoid being mistaken for a scammer?
Keep answers succinct and complete without being flowery or unnecessarily elaborate.
As a junior developer, if you do not know the answer to a question, be honest and say so. Replies like, "I'm sorry, I don't know the answer," and, "I can't actually remember right now," are perfectly acceptable. Augmenting those answers with genuine interest (e.g. "I don't know, but can you and I discuss it for a few minutes?") can often be music to an interviewer's ears, but you will likely have to play it by ear depending on the interview length and the personality of the interviewer.
As a more senior developer, if you do not know the answer to a question, be honest as well, but be prepared to offer up answers to similar/related questions if the interviewer will allow it.
Keep your resume/CV short and sweet. Only show the most relevant or recent positions you have held (a good limit is 3-5). Bullet-pointing the technologies and skills used for each position can go a long way to assuaging any doubts of the interviewer, so long as the skills listed are directly related to the positions and projects that appear on your resume.
Be confident, but don't be overconfident. Do not BS your way through the interview. Talking about "packeting your competitor's networks" likely won't fly.
The bottom line for interviewers: as aware of body language as you should be, go with your gut when it comes to the answers being presented. Keep your questions directed and objective whenever possible. Candidates will inevitably make mistakes, which is just fine, but when you notice an increasing pattern of what you view to be mistakes, follow the tips above.
The bottom line for interviewees: Be prepared, know your stuff, and be cordial. If you don't know something, don't make up answers and resist the temptation to discuss similar-sounding questions (unless you know they are related and the interviewer is ok with it).
As a prospective developer and likely an educated one, you will be expected to know some basics (can you talk about linked lists, heaps and BSTs confidently?). Do not expect to dance your way around it, and do not attempt to. If you say you have a Computer Science degree or similar, expect to be able to back it up during the interview.
For more senior personnel, understand that most (if not all) interviewers have baseline questions they will ask all prospective employees. Humor them and answer with grace; avoid the temptation to roll your eyes and sigh.
(Tip: When you finish answering such a question, politely offer up something more impressive that you have done or know about, beginning with something like, "You know, that actually reminds me of something I worked on that built upon those concepts...".)
Stay tuned as we explore other Developer Interview Types!