Getting the Job: Developer Interview Types — The Self-Doubter
Zone Leader Duncan Brown continues his series on developer interview types and dealing with nerves in an interview, and how those little ticks can come across.
Join the DZone community and get the full member experience.Join For Free
Candidates for technical jobs come in different varieties. This series has been examining these varieties to see what we can learn from them, both as interviewers and interviewees! Feel free to have a quick look at the first two entries in the series, detailing "The Scammer" and "The Minimalist", located here and here, respectively.
In this article, we're going to dive in to someone who seems like they have the right answer — or maybe they don't; no, wait, they do! Or maybe...
As you, my observant readers, have likely determined (or maybe have just read the title of the article), the candidate type under the microscope in this post is...
Another one for our European readers.
Contrary to the label, this candidate type can and will often come across as being rather normal — even confident — during any non-technical portions of the an interview. It's when the interviewee is asked to answer technical questions, both verbal and written, that the nature of the Self-Doubter becomes evident.
With this specific candidate type, the interviewer can have trouble determining whether the potential employee doesn't actually know his/her stuff, is just suffering from a lack of confidence, or genuinely forgot one (or more) answers.
The kicker here is that, often times, the candidate has stated the correct answer to a question to begin with!
As usual, we will have a look at the hallmarks that usually accompany this type of candidate:
During verbal questions, the following hallmarks are often present:
Stammering. In an attempt to recall a proper answer, stammering while answering a question can be interpreted in several different ways.
Multiple pauses. One or two pauses while answering a question, especially prior to actually responding to the question, can be a sign of thoughtful discourse. Several pauses throughout an answer, particularly ones that preclude a change of direction in the answer, can be a warning sign of this candidate type.
The "question coda". After a response has been rendered, immediately adding on to it with, "Or is it X...?", or, "Actually, I think it's Y...", or even, "I don't know..." can seed doubt into an interviewer's mind, even if the original answer was correct!
This trait is rather common with junior developers: Their brains are working in overdrive to recall the answer as quickly as possible and, as a result, can end up stammering while their brains continue to work on formulating the answer.
It is important to recognize that sometimes it's a speech impediment, and other times the candidate does not actually know the answer; however, it can be the case that the potential hire is just inexperienced when it comes to answering technical questions in an interview, or, even more often the case, the person is simply nervous.
As noted above, the issue here is not one or two pauses at the beginning (or even throughout) the response to a technical question. The issue occurs typically when the person in the hot seat thinks he/she has the answer, but then changes his/her mind several times, even going as far as repeating the original answer.
In this case, not only are the seeds of doubt sown in the interviewer's mind, but those same seeds also flourish in the candidate's head, further sabotaging what might otherwise be an excellent interview.
The "Question Coda"
Adding on to an answer is sometimes necessary for clarification purposes. It is quite another thing, however, to attempt to change the direction of the answer and wind up making things worse by, say, contradicting the original response.
The question then becomes one of, "Does this person actually know how to apply his/her knowledge? Is this person just regurgitating information, or is this person just not very confident?" In any of those cases, it can be quite a hole to dig out of.
During written questions, the following hallmarks are also often present:
Correct, original answer crossed out. This is self-explanatory and raises very clear questions of confidence.
Too much code! For questions that involve writing out some code, scribbling down any and all possibilities that come to mind can show a lack of direction of thought.
Even if the candidate has the correct answer off the bat, that answer can still end up crossed out as the interviewee attempts a different answer, not convinced that the last answer was 100% correct or what was being asked.
There are parallels between this hallmark and the verbal Multiple Pauses hallmark described earlier, e.g. previous crossed-out answers may appear again and even be crossed out yet another time. Indeed, one can imagine the crossed-out answers as "pauses".
In this case, the interviewer will wonder whether the candidate is indecisive, unsure, or is just unable to understand the question (read: requirements).
Too Much Code
In an attempt to cover all possibilities, it is tempting to write down as much code as possible. This can seem like a viable option, especially for more junior developers who want to show their resourcefulness and depth of knowledge.
However, most employers want to know that the candidate can understand requirements and give them what they need. After all, businesses are built upon delivering what is required, on time and on budget (*cough*pick two*cough*). Extraneous code is symptomatic of protracted project lengths and possible confusion of product functionality. Worse, in the coding world, extraneous code can lead to code bloat, decreases performance and scalability, and — a personal favorite of mine — a maintenance nightmare.
Why would anyone want to upset this poor code cat?
Telling the candidate to take his/her time and/or to take a deep breath may seem obvious but it can go a long way in helping the person on the other side of the table collect his/her thoughts and relax just a little bit. Of course, you can only do so much by way of reassurance as if the candidate truly cannot make up his/her mind it could be a serious problem when placed on your team.
When the candidate completes a verbal answer to a question, try to avoid saying things like, "Are you sure?" or giving other prompts that may instill doubt in the candidate, unless you feel he/she can handle it. Now, sometimes it's necessary to see how candidates handle pressure like that, especially if the job is a client-facing one, so take that into account as well. Maybe the person being interviewed just isn't right for the job.
If you feel the candidate's answer is wrong and could be improved, ask more direct questions, such as, "No, that's not quite right, but I think you can get it. Do you want to try again?" You would be surprised at how often this can work, and the process can give insight into how the candidate is able to adapt.
With written technical questions, there is little that can be done here, other than following-up with the candidate and asking some more pointed questions to separate the nervous ones from those who are not suited for the job.
As always, know your stuff! School may or may not have been a long time ago, but if you're serious about the job, try to bone up on what you consider to be essential knowledge and questions that you may be asked. But this isn't like a college final: Get some decent sleep the night before and trust in yourself that everything will go just fine.
While being asked questions, if you find yourself committing any of the above behaviors above, take a deep breath, take a minute to think, and give it your best. If you genuinely do not know, then say so; trying to "BS" your way through a question will just make matters worse.
If an interviewer attempts to prompt you with an ambiguous question such as, "Are you sure?" take a moment to think if there is anything you missed, but don't overthink it. Reply with a "To the best of my knowledge, yes, I am," or a, "Actually, here's where I think I might make a change..." Don't waffle!
Above all, believe in yourself, even if it seems difficult. The expression, "fake it until you make it," is not necessarily bad advice. Learning to be confident in your skills is just as important as having them.
The bottom line for interviewers: Confidence is an important quality, although more leeway can (and likely should) be given to more junior positions. Given time to grow under the right leadership, these junior developers will turn into cornerstone members of any development team.
With respect to more senior positions — especially ones that have leadership and client-facing roles--confidence out of the gates is usually an important aspect of the prospective hire's disposition. Following the strategies outlined above can go a long way to ensuring you have the right candidate, but don't be afraid to augment it to your needs, including ratcheting up the pressure a little bit and not being quite as forgiving with the candidate's replies. The goal is not to be mean, but to examine how the interviewee reacts under pressure.
The bottom line for interviewees: Some of us are naturally more confident than others, but that doesn't mean confidence can't be developed. Being properly prepared for interviews can and will go a long way to helping to avoid any self-doubt that may creep in. A little is normal, but be prepared not to pay much credence to it. Take your time, remember to breathe, and believe in yourself. It may sound like trite advice, but it is amazing how many candidates forget such simple words of wisdom. Follow the simple strategies above and you can rest assured that you have put your best foot forward, which is really the only that can be asked of you.
That does it for this installment of "Getting the Job". Keep an eye out for more in this series, coming soon to a DZone.com near you!
Opinions expressed by DZone contributors are their own.