Recently I have had the misfortune to be playing the interview circuit again; parading from one interrogation to the next like some prisoner of technical war. The experience has been both frustrating and humiliating - and unpleasant reminder of how appallingly most technical interviews are conducted.
So ignorant is the conduct of many interviewers, one could be forgiven for thinking they have undertaken the interview process with the deliberate intent of minimizing the chances of finding the right person for the job, and maximizing the opportunity for their own ego gratification. Such behavior is a common feature of the sociopathic personality.
Based on my recent interview experiences, I've assembled below a list of the techniques commonly practiced by the sociopathic interviewer.
The best way to ensure you don't accidentally get the right person for the job is to have no idea who you're looking for and what role they will be fulfilling in your organization. A meager and perfunctory PD (position description) helps to convey that "don't care" attitude right from the start of the hiring process. If you're working through a recruiting service, simply tell the recruiter that you don't have time to write out a decent PD. Rattle off a few buzzwords and acronyms and leave them to patch something together themselves.
If you are somehow compelled to write a PD, fill it out with the usual platitudes about "excellent communication skills", "ability to work well in a team", "delivering high quality code" ... and other such nonsense that 90% of programmer PDs include and which nobody can effectively appraise in an interview situation.
Phone interviews provide an excellent opportunity to explore the aural aspects of discourtesy. Always use a low quality speakerphone; even if you are the sole interviewer. Make the call from the largest, echo-filled room that you have access to, and sit a long way from the speakerphone. If there is more than one interviewer, make sure you constantly interrupt and talk over each other, making it impossible for the candidate to distinguish who they are currently talking to. The frustration of the constant struggle to understand and be understood will eventually wear down even the most ardent of candidates, often with comic effect.
Some candidates have the audacity to view the organization of an interview as being representative of the organizational capabilities of your company as a whole. They reason that finding someone to fill a role is effectively a mini-project in itself, and if you can't schedule and coordinate even a minor project like that, how could you manage a larger and more complex undertaking like a software project? These people are clearly thinking too hard and too critically. They are exactly the ones that you want to turn off. Therefore you should make every effort to have the interviewing process reflect the abysmal state of project management in your company as closely as possible.
Demonstrate your inability to estimate and track tasks by scheduling candidates' interviews too close together, booting one candidate out the door just as the next is about to give up hope that their own interview will ever commence. Having started the interview late, make it clear from the outset that you don't have much time to devote to each individual so you will have to rush. This will demonstrate your tendency to meet deadlines by making heroic efforts rather than rational adjustments of scope.
Then reveal that you have no questions prepared for the candidate. Just um and ah your way through a random series of queries that reveal no overall structure or intent, thereby conveying your inability to structure a work effort appropriately.
Technical interviews are a sociopath's utopia, for they provide you with infinite opportunity to humiliate a candidate while engendering feelings of supreme inadequacy. Even if a candidate has been using a particular technology for many years, chances are that they have only dealt with the most commonly used 80% or so of that technology's features. Therefore your questions relating to that technology should target the seldom encountered 20% at the periphery. Identify those aspects of the technology so infrequently used that most developers have either never been called upon to use them, or if they have, have not done so sufficiently to internalize the finer points of its operation. Drill the candidate mercilessly on these obscure and largely irrelevant details. When they fail to provide the correct answers, assume a facial expression that betrays your amazement that they have managed to survive in the industry without having immediate recall on every aspect of the technology they deal with.
The topic of "business value" should be avoided at all costs. Do not ask about the candidates' contributions to the businesses they have worked in, as this implies that all that boring business stuff is actually of concern to you. The sort of person you want is one who is solely focused upon decorating their CV with the latest buzzwords, and playing around with whatever "cool" technologies that vendors have most recently grunted out. You'll get such a person by ignoring the business aspect of software development, and assessing candidates solely on the amount of technical trivia they know. Clearly, those who take a "technology first" approach are motivated more by self-interest than professional responsibility, and are more likely to be suitable company for the sociopathic interviewer.
A favorite ploy of sociopathic interviewers everywhere is to ask questions that have no concrete answer. The standard defense of this technique is the claim that it verifies the candidates' ability to take a logical approach to problem solving. Of course, there is no empirical evidence correlating the ability to solve logic puzzles with the ability to develop software - but no matter.
The real reason for asking questions that permit no solution is to watch the candidate squirm "on the hook", and to experience that feeling of smug self-satisfaction that you get when you finally reveal that there is no solution to the problem - it's just an exercise.
Such questions include:
... which are all variants on the classic quandary "How long is a piece of string?", and equally deserving of serious consideration.
For some reason, it has become accepted in technical circles that all programming interviews must contain a question about the Model-View-Controller pattern. Every candidate expects it, every interviewer asks it - and there's no good reason for you to challenge the tradition. At least it chews up some interview time and spares you having to think of your own questions.
This technique is the staple of anti-social interviewers everywhere. It's particularly handy if you want to devote no cognitive energy whatsoever to the proceedings. Ask a question that is general enough to permit multiple answers, but badger the candidate until they provide the specific answer that you have in mind. Thus a technical query turns into a guessing game, which is great fun for everyone - providing you're not the one doing the guessing.
For the sociopath, the interview is mainly about them and only peripherally about the candidate. They view an interview as an opportunity to demonstrate their natural intellectual and technical superiority. That they control the questions and have had time to research the answers doesn't hurt either.
You should make frequent, derogatory references to the quality of the candidates you have previously interviewed, the implication being that the current candidate can expect to be discussed in similarly negative terms once they are absent.
Don't hesitate to mock the candidate if they answer a question incorrectly. If it looks like they are about to provide a correct answer, interrupt them and change or augment the original question with additional complexities, creating a moving target that they will eventually abandon hope of ever hitting.
A technique that will certainly annoy the candidate (and people react in so much more interesting ways once they're angry, don't they?) is to deliberately misinterpret the candidates answer, exaggerate or distort it, then throw it back to them as a challenge i.e. create a straw man from their answer. Here is an example from one of my recent interviews:
Interviewer: Have you participated in code reviews before? Ed: Yes - I've reviewed other team member's code on many occasions. Interviewer: So you don't trust your colleagues, then?
An attitude of willful antagonism will enable you to goad even the most dispassionate of candidates into an angry (and entertaining) response.
Companies intent upon creating the impression that they really care about the quality of their people will give potential candidates a hokey COMP101-level programming problem to solve prior to granting them an audience. The solution provided is then dissected carefully and assessed according to criteria that the candidate was not made aware of at the time the assignment was set. Ridiculous extrapolations and inferences about the author's general programming ability are then made based upon the given code sample.
The beauty of this technique is that because the problem has been offered context-free, the candidate has no idea what design forces should influence their solution. They don't know what importance to assign to non-functional criteria such as performance, extensibility, genericity and memory consumption. The weight of these factors might significantly influence the form of the solution. By withholding them, and because the factors are often in conflict with each other, it is impossible for the candidate to submit a solution that is correct. Simply change the criteria for evaluation to the opposite of whatever qualities their solution actually contains.
For example, if their solution is readily extensible, claim that it is too complex. If they have favored clarity over efficiency, criticize their solution for its verbosity and memory footprint. If they have provided you only with code, select documentation-level and handover-readiness as the critera-du-jour - question the absence of release notes.
Those who have been in the industry for a few decades will probably arrive at the interview expecting you to draw upon their extensive experience as a source of examples of problems you have solved, applications you have implemented and difficulties you have overcome. A sociopathic interviewer should demonstrate their contempt for the candidates' life's work by completing ignoring their work history. Make it clear that you don't care about the past by treating even the most senior of candidates like a fresh-faced rookie, demonstrating an appropriately condescending and patronizing attitude. After all, even the most worldly-wise candidate appears naïve when put alongside your own towering genius.
The most effective means of convey your disdain for the candidate that I have witnessed is to ask them to take an IQ test, thereby implying that it is not their professional qualifications which are in doubt, but their native intelligence.
There is a lot of folk wisdom surrounding the hiring process. One common misperception is that the more arduous the interview process (i.e. the more rounds it contains, the greater the size of the interview panel etc.) then the more worth the position actually has. In other words, the harder the journey the better the destination must be. Clearly, the logic is flawed - it is quite possible for a long and demanding journey to conclude in a cesspit.
In an organizational context, a protracted interview process may simply indicate that the company is disorganized, indecisive and have failed to gather the information they needed in an efficient manner. But the myth persists, so you can exploit it to maximum effect, creating ever greater hoops for the candidate to jump through, on the pretext that you are being thorough or somehow testing their commitment. Be careful not to let on that you are really only demonstrating your own ineptitude and disrespect for the candidate's time.
One of the biggest hiring mistakes you can make is to hire someone who is better than you, and whose subsequent performance makes you look bad by comparison. As soon as you've formed an impression of the candidate's ability, adjust your interview technique accordingly. If the candidate is too good, step up the difficulty and obscurity of the questions you ask until you reach the point where they are struggling, and thereby creating a bad impression with any other interviewers present. If you sense the candidate is just good enough to do the job but not so good that they could do your job, then ease up on the questions and let them shine.
Remember that there may also be some career advantage in simply not filling the position at all; concluding that you simply couldn't find a suitable candidate. You may be able to emphasize how lucky your company was to have hired the last decent software developer out there - you.
The senior ranks of the software development community seems to attract more than it's fair share of sociopaths. Such people undertake the interview process with the same intent as they approach all activities - to create advantage for themselves. Whether you are amongst the self-adoring community of psychopaths, or just anti-social with psychopathic ambitions, the technical interview is a professional construct designed with your particular needs in mind. Using the techniques described above, interviews can be both a means of self-gratification and a fulcrum for leveraging your own career advantage.