Or, do unto others as you would have them do unto you.

Interviewing is one of the riskiest activities a team lead or technical manager is involved with as a standard part of their responsibilities, the consequences of which has the potential to leave a lasting mark on a team. The gap between a dream hire and a nightmare hire is wide and stark.

As an activity however, recruitment tends to be sporadic and infrequent. If it’s something being performed day to day you quickly accumulate experience. If it’s once or twice a year, or every couple of years, it can take quite a while to start learning from our mistakes.

I also feel this is an area that because we may feel unsure attracts a lot of posturing and seeking of magic bullets. A desire for processes that will simply drop out good results from them regardless of our performance within them. This has I feel led to some odd practices toward recruitment in our industry that are I feel self defeating.

So I thought I’d share how I interview people, and why.

Determine the possible size and shape of the role

I try and keep requirements to the absolute essentials in order to do the immediate job. I don’t know what I will find, and I limit my options if I start artificially filtering candidates too stringently. I am prepared and hope to be surprised.

I avoid looking for any qualities that aren’t actually going to be exercised. This may sound like an odd thing to say, but I feel it to be very important. I seek those qualities that are actually going to be required, rather than because they sound good. It’s an artificial constraint to start filtering candidates on the basis of communication and presentation if those qualities aren’t going to be stretched.

I list instead the different ways a candidate may contribute to a team. If we have a couple of gaps, no really good tester or anybody with QA experience. Maybe we have too much bias toward the back-end and are finding friction working with the designers. Maybe an existing person could use support as we experience pain every time they’re on vacation. I talk with the existing team and other managers about this, and develop a view of the different kinds of person that may be attractive for us. This may be narrow or it may be quite broad especially if the hire is simply to add capacity.

Sifting CVs

I avoid doing this without another pair of eyes involved, even if only cursory. Invariably I rope in a senior dev to also go over CVs independently of me. There’s too much opportunity for one individual to skip over or sell short an aspect of a CV. Equally it’s easy to miss a warning sign. The senior dev can whip through the CVs quickly as they’re only looking to catch what they feel to be potential mistakes on my part.

I am looking for breadth and depth, with both depending on the seniority of the role. I look for different languages and platforms. A range of employer types. As much diversity of experience as possible, because ultimately I have begun the process of trying to find a developer that is able to learn and grow over the course of their career, engaged with a job they enjoy. While I am happy for a developers career to have points of focus and themes, I tend to steer away from CVs that express only experience with one of the currently dominant development stacks. All approaches have weaknesses, and they have no point of comparison or counter experience from which to compensate.

I find CVs that simply list every technology the developer has ever been sat in the same room as difficult to consume as they don’t relate to me the developers competencies. I don’t ignore such CVs entirely, but I don’t find them as useful as CVs were the developer has engaged in some critical thinking about what they feel is most important to present and give emphasis.

While it is a definite bonus to encounter CVs with some personality expressed in them, it is only a bonus, and I don’t regard badly those who don’t. Some people feel it inappropriate and potentially risky to inject personality into a CV, and not without reason. I feel it then unfair to expect it, but as I say it is a bonus when it’s there.

Those CVs that make available source code for review are the most useful CVs I can receive, but unfortunately are very rare. They allow me to from the very beginning of the process to determine whether or not the candidate is capable of programming in a way I find appropriate. Nothing else on a CV will provide me with this information. At this stage I don’t need to review the code, a quick scan of a repo will tell me if there is enough substance to the candidate to warrant speaking with them.

I don’t regard it as a black mark if a developer doesn’t cite source code, as it’s not the norm in my corner of the industry. I am however going to need to put eyes on some code the developer has produced at some point and if that’s right at the beginning, well early feedback is always good.

I make notes for each CV citing the reasons for either wanting to speak with the candidate or not. Whoever I’ve roped into also quickly giving the CVs a once-over can challenge any of my reasons.

From this I have a rolling list of candidates to speak with.

Phone screening

I prepare a series of open-ended questions to ask the candidate on the phone. I plan on the screening interview to take up to 20 minutes, but I’ll cut it short if there is no traction with the developer.

After exchanging pleasantries with the candidate, I confirm what they’ve been told about the position by any agent or HR, and clarify broad details.

I make it clear that this is a quick screening interview, that if we move forward they will be afforded an opportunity at the next stage to engage in a full interview process. It is explained to them that they’re going to be asked a series of mostly quite general questions that they’re probably going to have reasonable answers for, and that the emphasis is on what a thing represents to them, rather than trying to guess the answer I’m looking for.

The candidate is told that at this stage and any future stage, they are able to correct themselves if they feel with a couple of minutes hindsight they’ve just said something stupid, and that doing so will be seen as a strength not a weakness.

A chunk of the questions will be very general indeed and will tend to be along the lines of “what does XML mean to you?” There’s a huge range of possible answers to that question without getting into right or wrong. What answers the candidate gives will start to tell me about their background and the sort of work they have been doing. Do they talk about data-modeling, serialisation, interchange, schema, configuration? Do they mention the word “extensible”, and does it mean something to them? Maybe they talk about how and why they prefer JSON. They may similarly be asked “what does OO mean to you?”, again with the range of possible answers wide open and likely to tell me much about the candidates world view.

I avoid phrasing questions in a way that is likely to encourage the candidate to try and guess what the answer is that they think I want to hear.

Just a couple of questions will ensure basic awareness of what is going on around the developer on a particular platform. So, for a .NET position I may ask “what is a lambda, and how might you use it?” or “what is an extension method, and why might you use it?” These questions are intended primarily to see if the candidate is paying attention to basic developments on their platform. They afford the opportunity for the candidate to volunteer a view on injecting strategies, or perhaps to comment on their extensive usage in LINQ. Because the questions don’t focus tightly on right or wrong, they allow the candidate to give me an insight into their background.

I expect senior developers to be able to give succinct and while not necessarily complete answers considering the context of a quick phone screening, to some degree defining answers.

I expect junior developers to be able to kick the ball in the direction of the goal, and to hit the target on a couple of occasions.

I’m not overly interested at this stage whether or not I see eye-to-eye with the candidate in their answer to an open ended question. It doesn’t much matter to me if the candidate favours NoSQL over RDBMS, it is interesting to me if they have a reasoned view on the usage of the two. If I ask them what technical sites they use for news, I’m more interested to see that they do exercise an interest in the broader industry, if they happen to be looking at a different end of it than I, that’s not terribly important.

I value honesty, and I’m greatly encouraged if the developer is able to simply declare “I don’t know” when they don’t.

From this I have a rolling list of candidates that I feel warrant investing the time in a proper face-to-face interview.

The face-to-face interview

The face-to-face can take as little as 30 minutes for candidates that are obviously out of their depth, to as much as 3 1/2 hours where things are going well.

There are a couple of things I want to achieve in the face-to-face interview above and beyond the predictable exchange of information about company history, duties, roles, and work history, the order of which isn’t terribly important and will depend a lot on the candidate and how the interview progresses.

I need to eliminate as much of the candidates fear as possible

It’s beyond clichéd to say “fear is the mind killer”, but it really is. Very few people perform well at all while afraid, and those people that do I may or may not want working for me depending on other aspects of their character. Moreover many people start to exhibit odd or uncharacteristic behaviours when they experience pronounced fear without support.

This is where myself and any potential reader may diverge for legitimate reasons.

There are roles where it is legitimate to test if the candidate can deal well with highly stressful situations. Consultancies and agencies that parachute bodies behind potentially hostile enemy lines, on their own or with minimal support. In these cases the candidates ability to code while terrified may have some merit.

It is I feel crucially important to be extremely careful to consider what qualities we are scrutinising the candidate for, and whether the manner of our scrutiny will actually expose those qualities. To scrutinise for qualities that aren’t actually a requirement is simply to apply an artificial and erroneous filter upon prospective developers. While my team members will have stress as part of their working lives with me, and they will have bad days, they will never be facing these things without my full support and the full support of a team that they respect and trust. Asking candidates to jump through arbitrary hoops is a counter-productive and abusive practice, that speaks more to the insecurities of the interviewer. Dehumanising people is rarely a good solution to a problem especially so in people-centric processes.

I make it clear what it has been that has impressed me about them and why I have invited them to interview. I also make it clear that given the current market for developers, they’re going to get a job, the question is whether that is with us or another company.

The candidate is told I am not interested in testing their ability to perform well in interviews because their job will not entail sitting interviews… Again in a more consultancy oriented environment it may actually involve similar… If they experience a brain freeze, go blank, experience a mini-panic attack, it’s okay and not terribly important to me. They wont be judged if the circumstance of the interview causes a bad reaction in them. Interviews are tricky, and a bit weird. It’s okay if they are a bit weird as a result.

When candidates realise that you’re not going to torture them, and that coming in for interview today might actually end up an enjoyable experience, they often become very grateful. You can see the look come across their face the moment they think, “nobody is going to try and shame me here”. This needs to be reinforced throughout the interview.

In most cases, and invariably in every case where the candidate is successful they will relax at this point and change gear.

It is my belief that most of us share two common fears in an interview. The first is simply that we will experience shame. The prospect of shame bends nearly all of us out of shape. Those that it doesn’t tend to have quirks of personality that may not make them healthy members of a team, but that’s out of scope of this piece. The second fear is that we’ll be misunderstood. That we wont manage to show the interviewer the best of us. These fears can distort the person in front of you to the degree that you’re no longer getting useful information about how they will actually perform within your team.

Therefore the candidate is told, that if at any point of the interview they simply want to tell me something about their work history or a cool thing they’re proud of, that they should simply volunteer it. They are instructed that they should not find themselves walking away from the interview wishing “if only I had told him about X”.

The probation period

Early on in the interview I tell the candidate that we exercise a x month probation period, and that we take it seriously. There is nothing to be gained by the candidate misrepresenting themselves or being disingenuous in trying to “win” the position, it’s not in their interests or ours. They should relax, and just be open and honest with us.

Best and worst

I ask the candidate to tell me about about a project they were involved in that they feel proudest about and why. I ask them what are the things from that project they are most enthusiastic about carrying forward into future projects.

Then I ask the candidate about a project whose involvement with they are least proud of. What their mistakes were, and how this project has informed their practices since.

This is a crucial stage of the interview. It is vitally important to me that my developers at a simple level are able to cop to their own mistakes, hopefully correct them, and most importantly learn from them… I am tolerant of mistakes, but not their repetition… Developers who sweep their mistakes under the rug and hope nobody notices are a liability. Developers who do this are also likely to engage in disruptive behaviour in the team in order to cover for their failing.

Understanding our failings is also essential to the process of learning. If we are unable to reflect upon our mistakes we are unable to learn from them. If we are unable to share those mistakes with our peers, it becomes an obstacle to learning with them.

There are very few outright failure criteria in my interviews. The candidate who attempts to dress up a strength as a weakness… I try too hard… will be challenged gently but firmly on this point. If they pull off a convincing U-turn, I wont hold it against them as the conventional mode of the interview process encourages the candidate to misrepresent themselves. If they are unable to reflect upon past mistakes in a simple and honest way, the interview probably wont proceed its full course.

When did that work for you, when did it not work for you, becomes a recurring theme of the interview.

The code test

I don’t normally do on the spot code tests.

In ideal circumstances the candidate will have code available for me to review, and we’ll do that together. This hopefully is an example of their programming unconstrained, and an exposition of what they consider to be their best.

I am interested in seeing their best. Their worst code will look just like my worst code, which is terrible. I want to see their best as it’s their best I intend to get out of them. Seeing their worst code does not tell me anything at all about their best code, it is therefore next to useless to me.

I’ll underline that… I need to know what their best code looks like, not their worst.

Unfortunately most developers currently don’t have repos to show, and indeed this has tended to be why recruitment processes in the industry have gotten so bent out of shape. So bent out of shape that many companies wont look at source code when made available by developers focusing only on their own tests, which in turn demotivates developers from maintaining projects to present to prospective employers. It’s a vicious little circle we’ve established here.

If the developer doesn’t have code to show, I will negotiate with them a mini-project that looks something like what they’d be doing for us, but feels comfortable enough for them to feel confident about giving a good account of themselves. I’ll try and base this on what they’ve related to me in interview, so if they’ve raved about design pattern X, then we’ll find a project that allows them to demonstrate it. With senior devs we’ll negotiate a kink of some sort that will stretch them a bit.

The test is outlined in such a way that the solution is neutral and doesn’t tie it to our company, allowing the developer to reuse it as a demonstration of code with other companies if they’re not successful with us, meaning they get something out of this test process and aren’t just sinking time into us.

Given that the candidate represents well in other aspects of the interview, what they have available in terms of code to show, or what they produce in the code test will often be the deciding factor between them and other candidates.

They can do this test either in the our office or at home. I don’t much care how much time they want to spend on it, if they want to invest a lot of time in it, good. Why would I stop them? The more they do, the more I have to consider.

Ad hoc questioning

While having general discussions with the candidate about their work history and competencies, I will drop in ad hoc the sort of questions that would normally be given in the form of an oral or written test… “Tell me, what’s the difference between a value type and a reference type?”… While the developer is engaged in hopefully animated discussion about things they want you to know, they forget to be afraid of such casual questions as things are evidently going well.

Over the course of an interview I can ask all the questions I want of a candidate without them ever feeling interrogated if I simply ask the questions the same way I would to somebody I was having a friendly conversation with, because that’s what is happening.

Second interview

Often there will be second interviews, but not always. It’s really more a matter of revisiting candidates where there is perhaps a choice between two or three strong candidates.

Second interviews will invariably involve other managers and members of the team, focus on how the candidate may fit in with the company, and will tend to look like follow-up interviews in a lot of places. By this point the candidate is likely to have a good level of confidence, be enjoying the process, and have a strong sense that things are going well. Starting to dig robustly into the candidates practices, work history, or how they work with others, especially if it is a senior role, is quite possible at this stage without freaking the candidate out.

If after a second interview it’s not clear to me if a candidate is the right choice, then they’re evidently not, and the process needs to continue.

Avoid the expectation that good developers think like me

Many of the best people I have worked with are nothing like me at all.

When I look back at a younger version of myself, I am ashamed at the number of articles of knowledge which I would insist all “good programmers” should know, I had in fact only learned myself six to twelve months prior. Things that I encountered from candidates in interview that I didn’t know were invariably classified as pointless detail that distracted from the core tenants of a good programmer.

It is important that candidates remain current with trends in the industry, but I’m not aware of any current trend to have emerged in my corner of the industry that wasn’t an established element of development cannon in the broader industry at least a decade prior. In every case I can think of, when I have learned a new concept I have been coming to the party at least a decade later than a whole bunch of other developers in another corner somewhere.

Over time I have learned to be careful not to expect the candidate to coincidentally be learning the same things as me, in the same order, at the same time. It is an unreasonable expectation and is the execution of a bias that can filter out potentially suitable candidates.

This bias produces a broader impact on the industry in that it can artificially reinforce trends. In commercial development communities a concern with best practice can quickly become an unreasoning group-think.

Imagine a case where I have been spending the last six months reading material on CQRS. Over that period I share the ideas with my team, and they start reading material. Excited and enthusiastic material. We convince senior management this is the way forward, and for our next application CQRS will be one of it’s core pillars.

We happen to be recruiting into a position on the team and we’re presented with two promising candidates, both of whom have sufficient skill and experience to fulfill day-to-day duties and expectations.

Candidate A has read the same material, is as enthusiastic as us, thinks the idea of being able to roll back events and replay them is killer, and would love nothing else but for their next project to involve CQRS.

Candidate B has heard of CQRS but isn’t overly familiar with it. They seem to understand the core concepts as it’s explained to them, and are intrigued, but express the concern that it seems a little overly complicated for the baked goods ordering system we’re building next. The thing they’re excited about the past year seems to be the use of the actor model in Scala which they’ve been playing with.

Everything else being equal, which candidate is more useful to me and my team?

Unfortunately there isn’t a right or wrong answer to that. There are pros and cons which is to say risks to both candidates in terms of how they integrate with the team. Candidate A will likely integrate with the team more smoothly, but is likely to simply amplify what is already in the team. If we have full certitude we’re right, we’re likely to prefer this option. Candidate B however, if they possess a sufficiently flexible personality has the potential to add a perspective to the team that it doesn’t currently possess.

My personal value judgment is to seek out Candidate Bs with sufficiently flexible personalities. It is more important to me that a candidate is capable of appropriately challenging assumptions that are presented to them, than it is for them to echo back to me my own views, reassuring me that my choices are correct. If Candidate B has a perspective or experience in areas that are absent in the team, then they start to become really interesting.

It is also more important to consider what the candidate has been doing, rather than if they have been reading and agreeing with the same material as me. It’s remarkable the number of developers who have a strong opinion on things they’re not actually doing.

Give me somebody playing with actors in Scala over somebody talking about CQRS, even if the later is what I’m excited about (I’m not as it happens it really is just an example).

It’s time consuming

Tough. It’s my job, and if I don’t get it right it can cost my company dearly in a myriad of ways. We will live with our choice of candidate for years, there are few other jobs that a team lead or technical manager perform that are more important.

One might argue that a recruitment process such as this will not scale, to which I would suggest if each team has a team lead that takes point on recruitment for that team, whether you have 2 teams or 12 will make no difference as the activity is in parallel.

If what one means to say is that an organisation in the pursuit of more efficient allocation of resource has teams leads acting merely as line manager for 3 teams each, and they simply don’t have the time to do their job properly, then that is a problem of the organisations own making and has more to do with them overworking their team leads that it does the scaling of process.

If I am distracted with a recruitment process my senior devs pick up the slack, it’s good practice for them, and indeed what they are there for. If I have a senior dev interested in gaining more experience they can pick up some of the screening. Recruitment is a good time to carefully stretch your senior devs skills, and I see it as an opportunity for their personal development.

Want to know if a candidate will fit in with the team?

Take them for lunch with the team. If it’s a really important hire, take them all for dinner. My team gets a jolly, feel involved participants (because they actually are) and nothing will give me more information about how a candidate may fit in with my team than putting them all in the same place in a relaxed setting, shutting my mouth for a while, and watching how they all get on.

We can test for a thing, which is to say observe its simulation within an artificial context, or we can actually just observe the thing in a natural context.

The candidate that seems brilliant but gives me concern that they may be too shy and reserved, I may find at lunch outside an interview room is relaxed, outgoing, confident and expansive… People can act in very unnatural ways in interviews that do not correlate with their behaviour in other aspects of their life. Again, I need to be mindful of what the interview is actually testing.

The pitch and pay negotiations start upon first contact

My experience tells me that the majority of developers will balance two simple criteria in choosing their next position. The first being how much does it pay, and the second how much they feel they will enjoy the position. How those two factors are balanced will depend on the developer. Many developers will take less pay for a job they feel they will enjoy and grow in.

The candidates first impressions of me, my company, my team and our projects are every bit as important as my first impressions of them. The more weight I put on this side of the scales, the less money will need to be placed on the other side of the scales.

This isn’t to suggest a recipe for underpaying developers. Coming very closely after the priority of acquiring the best developers I can get my hands on, retaining them is my second highest priority, and salary most definitely plays a role in this. The issue is that if the candidate is any good and has any significant experience, one has to assume they are entertaining other offers. There is always going to be somebody paying more than me, and I have a duty to my company to get the most I can from budget.

Again experience tells me that most candidates will not reveal other offers they are considering. While some candidates will come back to negotiate a better pay offer, a large proportion will not, and with those you have effectively engaged in a sealed-bid. You’ll be notified of their decision. In these cases having treated the candidate like a human being from first point of contact up until they make what is a life impacting choice for them and potentially their whole family, can be a compelling factor.

With good candidates, you aren’t just interviewing them, they are also interviewing you. You want smart people, well expect them to be smart.

My job is two-fold, to ensure my company prospers from the activity of its developers, and to ensure my developers prosper within the company. This is a mutually beneficial relationship if it is to work well over time. If by the end of the recruitment process the hopefully smart candidate is to accept this as genuine and authentic it needs to start at first point of contact, and remain consistent.

I treat my team members as humans, which is to say individuals with their own motivations, hopes, fears, insecurities, and aspirations. I treat my candidates the same way. Just because I don’t know them very well, does not make them less human.

This isn’t a case of it’s nice to be nice, making good choices and encouraging the best from people rather than the worst has a direct and marked impact on productivity and staff churn which can be very costly and sometimes outright crippling to a businesses ability to achieve and maintain momentum.

Treating candidates as humans is smart and the effort involved pays dividends whether your contact with them is for minutes or years.