Why Work At Your Company?

Recruitment is all about relationships and trust, whichever way you look at it common recruitment practices support neither. While there are countless articles focusing on how hard it is to hire good developers little is said about how to find good companies. Trust work both ways and in order to ‘fix’ recruitment both sides of trust equation must be balanced. Examining each in turn:-

Employer-> Candidate trust

Employers have low trust in external recruiters, low trust in CVs, and low trust that candidates can complete a Fizz Buzz question. This means that it’s not possible to invest sufficient time in individual applications, which in turn makes it less likely they’ll ever attract really good people.

Services like LinkedIn and Stack Overflow have made some gains in solving the employer-> candidate trust problem. In LinkedIn’s case they have scaled the ability to ‘ask around’ for recommendations and Stack Overflow provides a feel for someone’s knowledge. Neither is perfect and in truth the best they can do is give me confidence that the candidate is not a total waste of time.

Candidate -> Employer trust

The Candidate -> Employer problem is more interesting not least because it’s generally ignored. Unless you happen to be Google or Facebook candidate->employer trust is a major stumbling block. How can a candidate be sure that they are dealing with a good company? They can’t trust their agent to have a clue (or care) and they themselves will not be aware of a host of interesting companies. As such applications tend towards the bland and generic since candidates cannot afford to spend days tailoring individual introductions, this in turn fuels the employer perception that passionate interested candidates do not exist.

As an example, I work for a small B2B Telecoms company, our work is on the public eye, but our brand is not. Most developers will not be aware of us. Once hired, developers tend to want to stay with us, with working environment and the freedom to ‘get things done’ playing a big part in that. However as a company I have no easy way to express this. It’s not even a case of saying ‘Isn’t my company great!’ it’s much more about about describing the trade offs. Not everyone will appreciate the chaos, pace and variety of working at a small company, some will prefer the promise of a well defined career path, security and greater opportunity to specialise typicallly afforded by a larger organisation. It’s down to personal opinion.

Individual companies can solve this problem by publishing an engineering blog, sponsoring community events, getting people speaking at conferences and generally exposing their culture and values. It could be argued that companies willing to go to these lengths clearly value recruitment more highly than others and deserve the rewards. However, if there was someway that candidates could pull that information rather than have it pushed then that would be hugely valuable.

The closest example I can see is the Joel Test. To me the Joel Test is starting to show it’s age and could benefit from an update, the best it can say is ‘this company is less likely to be a horrific place to work’. Glass Door also addresses this in part, though practically speaking companies must be a of certain size before it becomes useful.

I’m not sure what the solution might be. Perhaps a curated job board/job fair is the way to go, the curator finds a way to characterise companies and makes sure it only backs good companies. This builds trust with candidates, and should mean that it attracts the top people, especially those for whom money is not the top driver. Companies are happy to pay decent rates because they know how good the candidate pool is, further more there is prestige in being associated with the agency.

The Challenge

So, world, here is my challenge to you. How can I, as a company, express my culture and values in a meaningful and standard way so that candidates can approach me with confidence.

‘We only hire the best’ – I don’t believe you

Ask anyone about hiring developers and the advice is always the same ‘only hire the best’. The principle reasons being that

On the face the face of it this seems like great advice, who wouldn’t want to hire the best? It turns out pretty much everybody.

For instance, how long are you willing to wait to fill the position? What if you are really really stretched? What if you’re so stretched that you worry for existing staff? What if hiring a specific individual will mean huge disparities in pay between equally productive staff? What if not making the hire is difference between keeping a key client or losing them? At some point every company has to draw a line and elect to hire ‘the best we’ve seen so far’.

The difference between the great companies and the rest is how to deal with this problem. Great organisations place recruitment at the centre of what they do. If hiring is genuinely everyone’s number one priority then hiring the best becomes more achievable. For starters you might even have half a chance of getting ‘the best’ into your interview room in the first place.

Of the rhetorical questions posed above, in all cases the impact can minimised (though not eradicated) so long as management understands and anticipates the challenges in recruitment. For example “What if hiring them will mean huge disparities in pay between equally productive staff?” A company that intends to hire the best understands the value of keeping the best. So compensation of existing staff, especially longer serving staff relying on annual raises to ensure market parity, must be at an appropriate level. Doing so can be hugely expensive when multiplied over all employees and this cost comes directly from the bottom line. Companies that put recruitment at the core are willing to make the investment. Yishan Wong’s writing on this subject is brilliant.

If hiring really is everyone’s number one priority then there is a trade off to make, something has been deprioritised or sacrificed to make room. As a result hiring is much more than a partitionable activity, it is a statement of corporate identity. Proclamations like “we only hire the best” are meaningless without an understanding of the trade offs and sacrifices made.

Anatomy of a technical Interview

So you decided that you need to hire a new developer , advertised in the right way , vetted the CVs and even thought of some questions . Unless you’re in the 0.1% of people that think that a 90 minute chat is the best way to assess the skills of someone you may end up working with for the next 5 years you’re going to need to think really hard about how to give the candidate the best chance of showcasing their skills in a face to face interview.

This post won’t help with what questions to ask, but it will help with structure and maximising the chance of getting a good performance from a candidate.

Calm them down

First off let’s start right at the beginning, you’ve just met and are about to commence on some small talk, perhaps give an overview of the company – to be honest it really doesn’t matter what you say at this point, the candidate simply isn’t listening. Years of evolution are telling them to fight or flight  and it’s your job to calm them down sufficiently that you can move the interview forward.

Your end goal is to get to the point where you can ask them some really hard questions with a fighting chance of doing themselves justice, but first off there’s ground work to do.

Get them talking

Having helped them settle into their surroundings, it’s time to turn things up a notch and actually get them talking. A pretty good way is to go through their CV, their past work experience, university projects etc. This is stuff that they definitely know more about than you do, and should help them ease into the interview. The key point to remember here is that by asking very open questions and listening to what they consider to be most important or interesting, you can learn a lot about them. Good candidates will start explaining cool and interesting tech that they have used, while others will start talking about co-ordinating this and managaing that. Give people a chance and press them on the tech, but if they’re not confident or worse disinterested, then this is your first warning sign.

During this period you should be thinking about what sort of person you have in front of you, people handle stressful situations in different ways and if you don’t pick up on this you’re likely to miss some good candidates. e.g. if they are shy they’ll need some encouragement or if they are brash and perhaps little arrogant you need to be challenging them and forcing them to justify their assertions.

A final point, and one that I am most guilty of committing, is to make sure that you don’t go too far and overly relax the candidate. Doing so will make it harder for them focus once you start firing technical questions at them.

Getting technical

Before we get into asking any questions, I’d advise the following approach. Present the problem in a form that will probably be too difficult to answer, expect the candidate to need some help and judge their performance on quite how much help they need. This means that you’ll get an idea for how they think, smart candidates will have stretched themselves to solve the problem and poor candidate can at least solve the problem eventually, meaning that they won’t be so traumatised that they can’t concentrate on future questions.

As an initial technical question I’d recommend something pretty straight forward. Something like Fizz Buzz, I find candidates answer these sorts of questions in three different ways.

  • They write out the answer without even having to pause to think and you move on quickly.
  • They struggle a little bit, think things through and get the answer out. This isn’t necessarily a bad thing and might be down to inexperience, but it does mean that they are unlikely to hit the ground running.
  • They really can’t get the answer together and need a lot of leading. Alarm bells are ringing.

Next up I’d raise the difficulty, I’d suggest something wordy and open ended, perhaps some sort of systems level discussion. This means that the candidate can still push the discussion in a direction that they are comfortable with, but make sure that have at least of few things in mind that you will definitely discuss. Again judge them on the amount of leading they need before completing the question.

Now you’re ready to unleash the killer coding challenge, in many respects the whole interview has been leading up to this point, you’ve learnt a lot about them including how to get the best from them, but the next question will really set the best candidates apart. At this point in the interview you also need to consider whether it’s time to bail, if the candidate struggled with the toy programming question and couldn’t impress with your follow up question, then you really have to ask yourself whether it’s worth skipping the final challenge.

I would chose something that is initially tightly bounded but has the potential for significant extension should the candidate be up to it. Exactly what you go for is up to you, but if you don’t stretch the best candidate they won’t want to work for you.

Any questions?

Lastly it’s time to ask the candidate if they have questions, this in itself can be illuminating, though to be fair at this stage, the best they can do is reinforce a good performance. Questions about working attire and hours are generally a bad sign especially if not a final round, questions about version control, project management practices or something that came up as part of the interview are generally good things and provide an opportunity to sell the role.

After the interview

Once the interview is over, it’s time to come up with an decision. How you do is will be entirely down to your specific circumstances. For first rounds I tend to allocate a point for their programming, their systems and general technical common sense and finally a point for how well I think they’ll fit in. Anything over two and half, i.e. a strong performance in two out of the three and a good performance in the third is a thumbs up. For final rounds you can’t afford to let them leave the room if you still have any concerns unanswered. This is someone who you could end up working with for years so err on the side of caution.

Ultimately though, the only way to arrive at a good system is to have a lot of practice. Make sure technical staff are involved at the earliest possible stage and if you make a bad hire, don’t blame them, blame your process and learn from you mistakes.

How to do Nothing

Doing nothing is harder than it looks. As a developer I sometimes found it hard to understand what on earth my boss did all day. In fact the better the boss, the less they seemed to do.

Fast forward a few years and I found myself in charge of other developers, it quickly became apparent that doing nothing was actually quite a challenge. Try as I might something always came up, and I found myself doing something, which as previously mentioned was not a good sign. It turns out that doing nothing is pretty much a full time job, and I’ve put together some tips on how best to achieve it. Now bear with me, some of these activities do technically involve doing something, but if you are careful not to get caught no one will ever know.

  • Anticipate rather than react.

In some senses dashing in to save the day at the last minute is exciting, all the more so if your hair happens to be on fire at the time. However, there is no surer way to appear to be doing something than by intervening in this way. It is much better to notice that something will need to be done ahead of time and to act before anyone else notices that you are doing anything at all. This does mean that you will need to be constantly on the lookout for things that need doing before anyone else notices, however it is a small price to pay for doing nothing.

  • Maintain relationships outside of the team.

Occasionally, despite your best attempts at anticipating problems, your the team will get blocked and require some action on your part to resolve the matter. This is a dangerous situation since if they have nothing to do they are more likely to notice that you are in fact doing something. Therefore you need to act quickly. At this point it’s important to know the right person to talk to and what’s more have a pre-existing relationship with them. That way it will appear that you are just having a nice chat rather than actually doing something.

  • Big visible task boards.

A sure way to get caught doing something is by having your team ask you about what to do next, you can easily get around this by delegating the responsibility to a whiteboard. That’s right you can use an inanimate object to replace a previously essential function. To make this work, it does mean that you may need to do some planning ahead of time, it might even mean talking to more commercially minded folk on the other side of the office but nobody ever said that doing nothing would be easy.

  • Team collaboration

The more time the team spend working together, sharing ideas and learning form one another the less time they have for catching you doing something.

  • Small incremental changes

If you must be seen to make a change, at least be sure that it feels like a natural progression and sensible to all, that way your doing something won’t be as obvious. Once the change has been made, it is critical that you resist the temptation to tinker, not only will tinkering make it more likely that you will be spotted doing something, you’ll never learn what effect your change brought about, which means you might miss out on discovering new ways to do nothing.

  • Inspect and Adapt

Further to the previous section why not ask the team themselves to contribute ideas in order to refine their working practices, this way you can actively do nothing in their presence.

  • Hire great people

Unfortunately there is no getting around this one, while there are plenty of excellent guides available (1,2,3), sadly all of them advocate that you do something. However since it is likely that much of the process will occur in an interview room you can at least hide the fact that you are doing something. You may also find that you spend much of the time listening which can be easily be mistaken for doing nothing.

  • Commit to personal development

It’s much easier to do nothing when your team comprises of highly skilled geniuses. By working hard to consider the needs of all team members you can help them approach highly skilled genius status thereby reducing the need for you to do things. Over time you may even find that they appreciate taking on greater responsibility, further reducing instances where you will appear to be doing something.

Finally, having assembled and developed a great team, don’t blow it all by checking up on them every forty five minutes, just stand back and do nothing for a bit.