Over the years, I’ve had several experiences of being on either side of the recruitment table. At different times, I’ve been the hiring manager looking to augment the team I’ve been leading with a skilled technical professional, and at other times I’ve been that external technical professional, with skills, experience and insights to offer the team I’d be joining. Those experiences on either end of the equation have led me to some conclusions about the best way to go about ensuring that each party to the process gets what they intend out of the deal. For the hiring manager, that’s a new and well-motivated team member that’s able to bring some desired skills into the team, and for the candidate it’s the opportunity to meaningfully demonstrate what they can do and determine what the opportunity has to offer them. Those goals aren’t in competition with one another; a “win, win” is what each party should be looking for when it comes to matching the right people to the right roles. It’s only when each party gets what they’re looking for that everyone involved (the hirer, the hired, and any intermediaries) can consider that the process has been truly successful. This article contains some thoughts on how each of the various parties to the process can help ensure a mutually-beneficial outcome.
One of the difficulties with recruiting technical professionals is that you will sometimes find yourself in the position of assessing people that have skills you don’t yet have. For intermediaries like recruitment consultancies, HR departments, and for non-technical hiring managers, you can substitute the “sometimes” in that last sentence for ‘always’, and the “do not yet have” for ‘will never be interested in personally acquiring’. That’s merely a fact of the different types of value those parties add to the process; similarly, you can be sure that most prospective technical hires will never be overly interested in finer details of employment legislation, employer branding, marketing, or abstract management theory. How, then, if you’re not a technical professional yourself, do you go about determining whether the person in front of you has what it is that you’re looking for? Before answering that question, here are some likely approaches that might seem reasonable at the time, but which, depending on how they’re carried out, may not provide the outcome you intended:
1) Sending an intermediary to do your first interview for you
Typically, what an agency will do when they receive a brief from a hiring manager is they’ll advertise for suitable candidates using the job spec you provide on several of the industry-specific online recruitment websites such as JobServe, etc. The agency will remove your company’s name and identifying details from their listing, so that any less-reputable candidates and competitor agencies wont attempt to contact you directly. The recruitment consultant will sift the CVs they receive in response to their advert, will discount any outright unsuitable applicants (e.g., you’re looking for a Java guru, and it turns out the candidate has made coffee once), and they will conduct a brief telephone screen with each short-listed candidate to make sure that their stated skills, salary aspirations (or daily rate, for a Contractor) match with what you’re looking for. A good HR professional or external recruiter will also be able to give you as hiring manager advice on the state of the skills market, average salaries that other organisations are paying for roles similar to the one you’re recruiting for, and will be skilled at extending and negotiating a mutually-beneficial package when it comes time to do that. Make no mistake about it, though: for all the value they can add, your recruitment consultant or HR professional isn’t in a position to conduct an in-depth technical interview or make a recruitment decision for you, and they’re not there to represent what you have to offer to the candidate – that’s your job.
Interviews are a two-way street, and if you make the mistake of letting your department be represented at a first interview by someone that doesn’t even work in your department, don’t be surprised if the most marketable candidates fail to be impressed by having to run a gauntlet of your intermediaries before even getting to meet an actual decision maker, and opt out of your process before you get a chance to assess them.
2) Getting the candidate to write some code using a pen and paper.
An analogy I use when highlighting why pen and paper is the wrong medium for assessing an ability to write useful code is the telephone. Up until the mid-nineties, most people were able to remember lots and lots of their friends’ telephone numbers off by heart. It wasn’t an uncommon nor an especially useful skill, it was just a somewhat abstract and unusual ability that everyone had spontaneously acquired because of the limitations of the way the telephone medium worked back then. These days, in the age of near-ubiquitous use of mobile phones, less and less people choose to remember such meaningless lists of numbers off by heart. Instead, everyone tends to use the standard address book function on their mobile phone to attach meaningful text labels to the people with whom they wish to communicate, and look up those labels whenever they need to make a call. You often find people looking up numbers on their mobiles these days, even when they’re using a desktop phone, because it’s become the modern paradigm of how to efficiently access that category of information. The essential skills of how to use a telephone and how to have a meaningful conversation with another person that you can only hear but not see are still the same today as they were in years gone past; it’s merely the tertiary skills surrounding the medium that have evolved.
With reference to the above sociological changes that have come about as a result of advances in telephony technology, asking a developer to write code with a pen and paper is a bit like attempting to assess a person’s ability to use a telephone by asking them to write down all of the telephone numbers they know off of the top of their heads. In much the same way as telephone handsets have evolved, development environments have changed a lot in the past 15 years too. Round about that same time in the mid-nineties that everyone in society possessed ubiquitous Rainman-esqe abilities to recall lists of essentially meaningless numbers in order to be able to communicate using the telephone, developers once had to remember most of the syntax of the languages they worked with in their heads. These days, in the age of smart Integrated Development Environments (IDEs), that’s not the case any more. With the advent of Intellisense, Code Snippets, Templates, and Keyboard Shortcuts, there are many more efficient ways of coding today than there were even five years ago, and new tools are becoming available all the time. These days, if developers want to insert a Constructor into a class they’re designing in C#, they don’t need to recall the exact format of such a code fragment from memory, they can just type ctor, hit tab, and all of the syntax for a parameterless Constructor that is meaningful within the context of the class they are creating is inserted for them. The real skill isn’t in remembering the syntax, it’s in knowing what a Constructor is, when to use one, and in understanding why a parameterless one can be overtly implemented in a class but not in a struct. When you can’t quite remember which namespace one of the 3,500-odd pre-defined .Net Framework classes resides within, the latest development environments will help you by suggesting ‘Imports / using’ directives that you may have missed. When you create a custom class in a project, provided you’ve been smart enough to structure your project logically using folders, the Visual Studio development environment will create meaningful namespaces for you. These cues, and many others, allow developers to concentrate on the important part of their job – creating innovative, robust and reliable solutions to well-defined problems – and relegates the non-cognitive and repetitive parts of the process to the place where they belong: the subconscious.
Asking a developer to undertake a pen-and-paper coding exercise never reveals any of that relevant knowledge, insight or craft. Instead, it obstructs many good developers from demonstrating the meaningful work they can do inside a real development environment that takes care of the repetitive, irrelevant and non-creative parts of the process, and lets them focus on the meaningful work they’re actually good at: producing useful, stable, innovative solutions.
3) Trivial Pursuit
Nearly as bad as using pen-and-paper coding, is having a list of trivia questions associated with the skill of interest, and asking the prospective developer a pre-set list of abstract multiple-choice questions. Generally speaking, interviewers do this when they don’t have an in-depth knowledge of the topic themselves, because it provides an easy way for them to understand whether the answers they receive are ‘right’ or ‘wrong’, without the interviewer having to understand why they may be right or wrong themselves. It’s not advisable to go down this route, for two reasons. Firstly, to be blunt, it’s pretty disrespectful to the interviewee; if you don’t understand the answers to the questions you’re asking yourself, how can you be certain that the questions and the way you’re framing them makes any sense to someone that is actually knowledgeable on the subject? Go down this route, and it’ll quickly become clear to an experienced candidate that you don’t know what you’re talking about, and are merely repeating what’s written on a piece of paper in front of you parrot-fashion. That in turn will ruin their confidence in your ability to assess them meaningfully, and even if they do ‘pass’ your test, you may very well find the best candidates will opt out of your process as a result. Secondly, even if the developer isn’t put off by being quizzed by someone that clearly doesn’t understand the subject themselves, a process based on the ability to recall abstract facts fails to address the fundamental difference between knowledge and intelligence. I’ll take an intelligent developer that has yet to acquire knowledge in a given area over one that has learned to recite stock answers to set questions but has not one iota of ingenuity and creativity about them any day of the week, and twice on Sunday.
In short, if you use set lists of coding trivia that you don’t really understand the answers to yourself in a misguided attempt to assess your candidates, whilst you may end up with someone that would do very well on a VB Pub Quiz Team, you’re just as likely to end up with an individual that couldn’t implement an IPissup interface within a Brewery class if their lives depended on it. You may find to your horror, after they come on board, that they are not after all the learned experts you supposed, but had merely read the same three articles on Wikipedia as you used when compiling your list of questions.
Finally, I would strongly advise against using ‘online tests’ to assess candidates. Such ‘tests’ tend to have all of the abstractness, lack of context, and general irrelevance of the in-person version of the Meaningless Trivia Test, but are even less personal than the in-person variety.
4) Getting the candidate to do some real work
Getting close to the way I recommend doing things now, but with caveats. The best developers, like any skilled professional, are happy to demonstrate that they can do the work you’re asking them to do. They welcome employers (or customers, in the case of contractors) exercising meaningful due diligence that allows them to demonstrate they’re the right person for the job. As I mentioned earlier, this is something that many of the best people actively look for in a recruitment process, because as well as giving them an opportunity to prove themselves, it also gives them confidence that their colleagues will be every bit as on their game as they are. Good people want to work with other good people, from whom they can learn and share knowledge, and alongside whom they can grow and develop as ever-more experienced professionals. The fly in the ointment is that there are a small number of less-reputable organisations out there, also advertising jobs, that are only too happy to ask for samples and free work, without ever intending to recruit. For such organisations, unfortunately, it’s a ‘creative’ way of saving on their training budget by getting an external professional to give some free demos under the auspices of an interview, or of getting small projects done for free. For this reason, you need to be careful; you don’t want to chase good people away by coming across as a freeloader.
One good way of avoiding your organisation’s honourable intentions being misconstrued, is to not make providing a sample of the candidate's work the very first stage in the process. Interview the person first, and invest some of your time to show them a little of what you have to offer them as an employer, before asking them to invest their time in providing free work for you. That approach immediately makes you stand out as an organisation that’s serious about recruiting. Organisations that are instead only looking for freebies, generally make it obvious by asking prospective candidates to invest their time in providing a demo solution after only a short telephone screen, and well before the organisation has demonstrated that it has anything of substance to offer the right candidate. Less reputable organisations will also have the cheek to ask for second and third samples of work, and changes to work submitted, never attempting to explain why earlier demos didn’t satisfy their ostensible purpose of demonstrating the candidate’s technical ability. I advise those on the hiring side of the recruitment table never to behave this way; not only will it be entirely obvious to people with marketable skills that you’re merely freeloading, but the best people can and will inform their equally-skilled professional colleagues about their experience with your process, and it’s very likely that you’ll be left with only sub-standard applicants should you become serious about recruiting at any point in the future. Reputations are hard to win, and easy to lose; for candidates, for employment brands and for internal and external recruiters of all flavours alike.
So much for the ‘wrong’ ways to go about finding the right people to join your fold. Now, the right way. As touched upon above, the best people will welcome you engaging in due diligence. There’s no better way to do this than by getting your existing technical staff to speak with the prospective new member of the team. Ideally, on your side of the interview table, as a minimum, you’ll have your lead developer or development manager (whatever nomenclature you use within your particular organisation, they should be the person your most senior management are most likely to go to when they want an opinion on how anything technical should be tackled within your organisation).
Invite your prospective new employee in to speak with you and your lead tech informally for a first interview (or a telephone screen, if distance is an issue), and don’t beat them up during that initial interview. The first interview should be to establish just two things: one, whether the person in front of you is manifestly unqualified for the work concerned, and two, to give them a taste of what you have to offer and to let them know what you expect in return. That’s it for the first meeting; those are the only goals. The aim isn’t to establish whether they’re exactly right for your organisation just yet, and it’s not to make any hasty decisions based on limited information. During your conversation, ask them to tell you about something particularly innovative that they’ve worked on recently, or better still their pet project; every developer has at least one on the go, and, whilst they’ll mostly be commercially irrelevant to your business, they’ll tell you a lot about how well your prospective new colleague is able to communicate the concepts they understand to others.
As mentioned earlier, I strongly advise against asking coding trivia questions from a set list, but it’s perfectly acceptable to have your internal technical expert ask the candidate to explain more about the nuts and bolts of the candidate’s pet project or most recent work. This is why you have your best existing internal technical resource on your side of the interview table; they should be able to probe and question during a discussion of the design, without coming across as needing to be the smartest person in the room. Your technical expert should avoid the temptation to ask the candidate any ‘trick questions’, that rely on obscure technical knowledge that they’ve only just encountered themselves, but it’s OK to probe a little to see how deep the candidate’s knowledge of underlying concepts is. It’s also OK to ask about newer technologies that the candidate may or may not have encountered; if they’ve not, you’re looking for them to tell you so rather than for them to waffle or bluff their way through – knowing what they don’t know is a good trait in a developer. Your internal technical expert may not know everything that the candidate does about the subject at hand, especially if the candidate is intended to add a skill to your team that it hasn’t yet mastered, but there should be enough common ground for your tech lead to determine whether the candidate outright doesn’t know their subject area.
After that first interview, ask suitable candidates to participate in a coding task. You can choose to allow your candidate to do this at home, or within your premises; it shouldn’t matter which to you, although bear in mind that some developers wont have access to all of the tools at home that they’re used to having in their workplace. The developer should have access to every resource they’ll have available on the actual job, including the internet, any reference books they want, MSDN, etc. They should also have a reasonably-powerful development machine, similar to the one they’d be using if they were to be recruited. Make sure that the problem you ask them to solve is realistic, and can be developed by someone with reasonable skill in the area you’re recruiting for within 3-4 hours max. Ideally, get one of your existing developers that wasn’t involved in designing the exercise to try out the problem first, to be sure it’s of a reasonable level of difficulty. Make it obvious to your candidate that you’re not asking them to do unpaid commercial work, by presenting them with an abstract problem that is clearly unrelated to your business (e.g., perhaps ask them design a Windows Service that writes an entry to the event log every time the sum of the minutes in the current time is a prime number, or something similar). It’s not usually possible to present candidates with a real commercial problem, because even if it’s something your team has actually tackled within a set time frame, chances are you brought existing knowledge to your understanding of the problem that brand new candidates wont be able to draw upon.
After your candidate has completed their solution, get them to talk through their design with you, and review it with them in the same open and non-critical way that you’d conduct internal code reviews on real, commercial pieces of work. Doing this will not only tell you a lot about how the candidate approaches technical tasks, it will additionally give you an insight into how well they work with others as part of a mutually respectful and co-operative team. If done properly, it’ll also give the candidate a good insight into your culture, and help you both to decide whether or not you’re a good fit for one another. What you should be looking for in an ideal candidate isn’t just a window onto their existing knowledge, but their ability to apply what they know to new problems, whether they have the honesty and self-awareness to recognise what they don’t yet know, and, of key importance, whether they have the initiative to find things out as and when the need arises. Those are all key traits that a set list of coding trivia questions or a faceless online test would never tell you.
After your ‘technical review’ with the candidate, discuss your findings internally amongst the recruitment team. Subsequently, if you decide to proceed, have one, final interview with the candidate, to review all that you’ve learned about one another in a post-mortem type setting. Ask them about their experience of your process, discuss any issues that you’d like to clarify with them, and be prepared to take any questions they’ll have of you. This meeting is about rounding out what you know about one another, and finalising any missing details.
Once you’ve completed the above process, your internal ‘recruitment team’ (consisting of the hiring manager, your internal technical expert, and any advisers from HR that you’ve consulted) should be in an excellent position to decide whether the person in front of you is a right fit for your needs or not. Don’t be tempted to conclude that just because you’ve come all the way through the process, you need to extend an offer; psychologists call that phenomenon ‘justification of effort’. Remember that your process is designed to give you the information you need to make an informed decision, and to give a favourable impression of your organisation to everyone that has taken the time to apply. It’s not merely about picking the last person standing.
Put any candidates that have made it to the end of your process into three categories: first choice, any second choices, and any unselected candidates. Contact unselected candidates right away, to thank them for their time, and to tell them they haven’t been selected. Keep any second choices in reserve whilst your external recruiter extends and negotiates a mutually-agreeable offer with your preferred candidate (hiring managers should never do this part themselves – negotiation is skill that most hiring managers don’t have, and, even when they do, this process is still at its most effective when conducted via an intermediary). If an offer can’t be agreed with the preferred candidate, approach any second preferences and try to come to an agreement with them.
At the end of the process, let every candidate that hasn’t been selected know the outcome, and, if they’d like to know, the reasons for your decision. The classiest way of doing this is for the hiring manager to call each individual personally, to thank them for their time, and to express regret that they weren’t the right person on this occasion, followed up by a letter to confirm the news. Many hiring managers shy away from doing this, perhaps through fear that the candidate will react badly. In my experience, though, most if not all professional candidates really appreciate it when the organisations in which they’ve invested their time and effort take the time to conclude the process properly. In years of informing people in person when they’ve not got a job, I’ve never once had the experience of a candidate reacting with anything other than courtesy and appreciation that I had enough respect to let them know the outcome myself, when I called to let them know the decision. If you’re unfortunate enough to experience a candidate being aggressive, or treating the call like a debate rather than a simple communication of your decision, feel free to end the call quickly – you’re not there to be their career counsellor, and you’re not there to justify yourself beyond respectfully communicating your decision, and your reasons for making that decision if the candidate is interested in hearing them. Conclude matters this way, and you’ll always have a steady stream of candidates for jobs that you may advertise in the future; word gets around about which organisations treat candidates well and which don’t, and it’s amazing how often that candidate that wasn’t quite right for you yesterday, has exactly the right skills for the position that comes up tomorrow, or knows someone that does. End things well, and you’ll always have the ability to open dialogue again if it becomes relevant to do so.
