Category: Core Concepts

Recruiting good people is hard.

Far too hard for the recruiters, HR people, and technical managers who are the people who actually do all the recruitment. To make life notionally easier for everyone, there are processes that are put in place and must be followed come hell or high water. Deviation from these processes causes everybody problems.

If you understand that these processes exist, and you understand the specific processes you’re working with, you can hack them. If you don’t understand them then you’ll keep running into constraints you didn’t know exist. Sometimes you won’t even know you ran into them, you’ll just not get a job or a promotion or a pay-rise you were expecting.

If you’re looking to get yourself a new job, or get paid more, or get an interview somewhere you’ve always wanted to work, then the more you understand about the processes involved behind the scenes the better equipped you’ll be. I’ll illustrate that with a short story involving you and $500.

The Hiring Manager’s Nightmare

You’ve just had your final interview at XYZ Corp with Angela, the Head of Product Engineering. She’s the Hiring Manager (meet the Interview Gatekeepers and what they do) for the role you’re applying for. She thinks you’ll be a good fit in her team, she thinks you’re qualified, and she wants to make you an offer.

The board have told Angela that she can hire a developer for $70-$90,000, based on some numbers they purchased about market salary in the region. If she finds a developer for anywhere in that range she can sign it off, and they can start on Monday. She doesn’t need to speak to anybody in Senior Management about it, it’s all ready to go.

Since the start of the process, you’ve been asking for $90,000. But shortly after the recruiter checks you’re still on board, you decide you want an extra $500 because the company’s Dental Scheme wasn’t quite what you thought it was. And it’s only like $500 more, and the company liked you, right? Asking for $500 more from a company that likes you really shouldn’t be a big deal, and you’ve got the idea in your head that if they’re too cheap to pay you $500 more a year then they might be penny pinchers, and you don’t think that’s a good thing either.

What you may not appreciate is the degree to which the level of bureaucracy explodes when you go try and go outside the process.

Forms, in triplicate

Cut-scene: XYZ Corp’s parking lot, two weeks ago.

Jake, the HR Guy, is chasing the VP of Finance to her car. He was sat outside the CEO’s office for 4 hours trying to get an Authorization To Recruit form signed off for your position, which he finally managed, but he needs one more exec’s signature to make it binding. Jake reaches the VP of F just before she starts her engine, knocks ferociously on her window, and manages to get the second signature on his form. It’s Friday afternoon, and the Board and Directors are off to Nepal for a 2 week “Offsite Management Realignment Camp”, whatever that means.

But for Jake, it’s a victory. When Angela makes an offer next week, he can start entering her new hire into the payroll system, generate an official offer letter, and perform all the magic needed for the company to employ a new human.

What Jake can’t do is use that Authorization to Recruit to hire someone for more money than is written on it.

Jake and Angela have a problem now, because while they liked you, that extra $500 will cause a lot of extra headaches for them right now. And they’ve both got full-time jobs to do. If they want to hire you, they’ll need to get the extra $500 signed off, and that process could literally take weeks if the right people are currently in Nepal.

They interviewed another candidate who they also liked, almost as much as you, who wanted $89,000. The money isn’t important to them, but the tornado of paperwork involved might be…

An aside: if at this point you’re thinking “I’d never want to work at a company with this much bureaucracy”, I understand. But in my experience you’ll often be shielded from HR bureaucracy after your first week and there’s little correlation between the labyrinth that HR and Finance have built and your experience coding day to day. All companies have some level of corporate bullshit and you’re better off understanding it and using it to your advantage than trying to find that one magical company that has none.

The External Recruiter’s Problem

Jake in HR and Angela in Engineering aren’t the only actors here. Ken the external recruiter really wants to hit his placement figures this month. If he does, he’ll get a $500 bonus that’ll pay for his holiday in Tijuana.

It’s the 31st, 4:45pm, and accounts close in 15 minutes.

He’d thought that you were a sure thing — you’d told him you wanted $90,000, Angela’s willing to sign off on $90,000, and he just needed to confirm that you were still interested before he had an official offer letter generated. But right now, you are seriously messing with his sun-bathing potential, and in his mind it’s because you weren’t sufficiently upfront about how much money you wanted at the start.

Even if Jake and Angela do get sign-off for the extra $500 you want, his cut of it is $50 tops, and it’ll be in next month’s accounting period, so he won’t get the rather larger bonus for hitting his numbers. And there’s another candidate who they seemed pretty keen on who wanted $89,000, which he knows they’re authorized to offer on without any more paperwork.

So Ken picks up the phone and…

If you’re lucky, Ken calls you and explains the situation. He explains the company isn’t penny-pinching, and that he can probably arrange a formal salary review after three months if you’ll accept the $90,000 you asked for to begin with. He may well mention that there’s another candidate who will.

But if you’re unlucky, Ken calls Angela and Jake and tells them he got a bad vibe off you, you made some noises about how you were only going to stay for 6 months, and that they should hire the guy who wanted $89,000. That way Ken goes to Tijuana, Angela and Jake get their employee, and everyone is happy. Except you.

Exegesis

XYZ Corp is definitely not the kind of company to quibble over hiring and retaining the best people! But individuals can be a bit funny, and if you’ve got three people who you’re about to seriously inconvenience because you didn’t understand the processes going on behind the scenes, you may just find that between themselves they talk into liking the other candidate just enough more to make them the offer instead.

These processes can be largely hidden from developers, but they can affect everything from the timing and sizes of pay rises, to how job titles and seniority work, to how the training budget it allocated, to who decides who gets to read (and potentially reject) your resume first.

On this blog we’ll cover all sorts of processes, how they work, and how you can make sure you’re well placed to benefit from them.

Consider the following excerpt from the skills section of a resume:

AWS (EC2, related services), Puppet, load balancing

What does that mean?

Does it mean…

“I’ve got a lot of personal experience of lovingly setting up a whole bunch of immutable infrastructure with auto-scaling instances in the cloud, and helping my team migrate to it?”

… or …

“I was on a team where the Devopsy people had setup the infrastructure, but I wrote scalable applications that were deployed across all of them and occasionally debugged issues?”

… or …

I was on a team where they’d just started experimenting with some degree of deployment on to AWS?

… or …

I read some of the Puppet tutorial, and spun up two machines myself in my free time, and wrote some PHP with Elastic Beanstalk on the front-end as a hobby project?

… or …

I have heard all of those words at least once, pretty much understand those words, and could take a stab at describing what they mean in an interview?

I’ve personally interviewed (many) candidates whose anemic skills section or minimalist approach to describing technologies used in the past looked just like our example, and it could mean any of the above. As a result, I’m likely to be skeptical and assume the worst.

Just mentioning the magical skills on your resume may get you past keyword-matching internal and external recruiters, but the two technical gatekeepers who’ll read your resume will be left guessing. If they under-estimate your skills based on a few words, you won’t get an interview, and if they over-estimate your skills, you’ll fall apart in the interview when they dive in to it.

We can do better than that.

Bitter experience and war stories

A pet theory I have is that technical experience is most valuable because when you come across problems to be solved, you’ll have solved similar problems in the past, and you’ve got some good ideas of what works and doesn’t work.

Whether that’s true or not, it’s absolutely true that when you’ve worked with a technology you’ve also probably been bitten by it. You’ve probably formed opinions on which bits you like about it and which bits you’re not so fond of. You’ve probably touched auxiliary tooling around that technology. You may have used more than one version and seen improvements and upgrade issues between versions.

As a Perl developer, I’m acutely aware that There’s More Than One Way To Do It in many situations. The more experienced with any given technology you’ve become, the more different approaches to using it you’ve likely seen. You’ll have formed opinions on the benefits and drawbacks of those different approaches, and you’ll probably have picked up a deep understanding of what problems each approach is trying to solve.

All of these things form a body of evidence that you have Real Actual Genuine Experience In Production of the technologies you’re mentioning, and presenting this evidence allows you to prove it, rather than just saying it. To paraphrase the utterly unreadable Nietzsche, “if thou gaze long into the Puppet documentation, the Puppet documentation will also gaze into thee”.

These things make great content for the work experience section of your resume, and in prose form when talking about your skills.

A quick example

This topic will get covered in great depth on this blog, so we’ll stick with a simple example, and we’ll go with EC2 + Puppet as that’s what we started with.

We’ll kick off with what we started with:

AWS (EC2, related services), Puppet, load balancing

But we’ll add a bullet point for each of our types of experiential evidence.

If you like a piece of technology, you’ve probably been bitten by it; for me, with EC2, that was losing control of costs and who owned what:

• Experienced using tagging schemes to accurately track costs and resource ownership

Opinions on which bits of the technology you’re fond of, and which you’re not so fond of; love my fine-grained access controls, but am yet to have an IAM role work first time…

• Many hours spent fine-tuning IAM controls in conjunction with the documentation to provide secure minimal functional access

Auxiliary tooling; gotta find a way to have the same environments in dev and production…

• Use of Hashicorp’s Packer to create both AMIs and Vagrant boxes to allow developers to code in an environment almost identical to production

Several versions and the differences between them…

• Encryption of server-side credentials initially with `hiera-gpg`, migrating to `hiera-eyaml` very shortly after it was released

Different approaches to problems, and their strengths and weaknesses…

• Decided where to draw the line between spinning up a new box for every service and consolidating machine usage to reduce costs

Putting it all together, we get:

AWS (EC2, related services), Puppet, load balancing

• Experienced using tagging schemes to accurately track costs and resource ownership
• Many hours spent fine-tuning IAM controls in conjunction with the documentation to provide secure minimal functional access
• Use of Hashicorp’s Packer to create both AMIs and Vagrant boxes to allow developers to code in an environment almost identical to production
• Encryption of server-side credentials initially with `hiera-gpg`, migrating to `hiera-eyaml` very shortly after it was released
• Decided where to draw the line between spinning up a new box for every service and consolidating machine usage to reduce costs

 

And we’re much closer to having proven, rather than just said, that we have the skill-set we’re claiming…

One final advantage

There’s another useful side-effect of writing out skills with observations about the skill:

Many of the technical people interviewing you will have very little structured idea of how they should conduct the interview, and will mostly be just scanning your resume for interesting things to talk about.

Rather than simply inviting ad hoc questions about Puppet, we’ve laid out five specific things we know we can talk about to show off our experience. We’ll no longer get such open-ended questions like “So, uh, tell me about Puppet” — we’ve now set ourselves up for questions that allow us to show off our knowledge and setup discussions such as “So where is the line between spinning up a new box per service, and running many service on one box?”.

Remember, on your resume: prove it, don’t just say it

Many of the articles on this site revolve around my theory of Interview Gatekeepers. This article outlines as briefly as possible what this means so that I can refer you back to it when it comes up.

What is an Interview Gatekeeper?

An interview gatekeeper is a person or persons who decide if you get to the next stage of an interview. Simple.

Each has a different set of skills, interests, and requirements and you need to make sure that your resume and performance in interview speaks to those different sets of skills, interests, and requirements.

Who are the Interview Gatekeepers?

There are three Interview Gatekeepers I like to talk about:

The first gatekeeper is the recruiter. He may work for the company you’re applying to (internal recruiter or HR person), or he may work for a 3rd party (external recruiter / agency). Most recruiters have no technical background, so when you write ReactJS they think it has something to do with chemistry.

The recruiter decides if they’ll send your CV on to:

The second gatekeeper, the Hiring Manager. She definitely works for the company you’re applying to, she’ll probably be your boss if you get employed there. She’s a senior technical person who’ll absolutely understand all the complicated words on your CV.

The Hiring Manager decides whether she’ll bring you in to an interview to meet:

The third gatekeepers, your future colleagues. Very often these are a randomly assigned group of programmers who the Hiring Manager scraped together and handed your CV to. Their job is programming, not interviewing, and they’re usually the people who perform the final in-person interview.

Let’s cover some high-level details about each Interview Gatekeeper, and strategies for dealing with them.

The Recruiter

The recruiter is the company’s first line of defense against candidates who’d be a waste of time to interview and who’d be a disaster if actually hired. As they’re usually non-technical, words like Jenkins and _git_ in your CV are like hieroglyphics carved on stone — they know they’re pretty important, but they’re not always entirely sure what they mean.

They make a decision about whether someone who will understand the words on your CV actually get to see that CV in the first place. This doesn’t always go to plan (here’s a terrifying example from Facebook).

They will do cursory keyword matching of your skills and look to see if your previous job titles look similar to job you’re applying for (see: When two job titles are better than one). They’ll also look for any red flags concerning employability, such as lack of an existing right to work for a position that doesn’t offer sponsorship (the article How a recruiter speed-reads your resume has a section on hireability red flags).

If it’s an internal recruiter, you may well meet them in person if you progress through the interview stage, and they’re normally the person who knows how much the salary range available for the role is — although it’ll be the Hiring Manager who decides where in that salary range your experience places you.

The recruiter has one simple question to answer about your CV:

If they’re an external recruiter, that question is: Should I send this CV on to the company?

If they’re an internal recruiter, that question is: Should I send this CV on to the Hiring Manager?

The Hiring Manager

The Hiring Manager is the company’s second line of defense. She will probably be technical, so she’ll understand that if you know Angular, you know JavaScript. If the company does an initial phone interview, it’ll often be with her.

She’ll be looking for proof (see: Prove Don’t Say) that you have the skills you’ve listed on your CV, she’ll probably read the whole thing at least once (as contrasted to the recruiter, who’ll just skim it), and she’ll also be looking to make a judgement on your seniority.

She knows which of the skills on the “REQUIRED SKILLS” section of the job ad are actually required. She knows under which conditions she’s happy to accept someone with Puppet experience when the company uses Ansible, and so she’s the person we’re targeting when we talk about how we’ve used our skills rather than just a long list of bare keywords.

The Hiring Manager actually appears twice in our process – she decides whether she wants you to meet her developers for an in-person interview, and she’s also likely to make the final choice about whether or not to hire you based on their feedback.

Future Colleagues

It would be nice to think that the people who’ll be interviewing you are the company’s hand-selected finest. The people who are most astute, best able to read character, able to asses technical skill, and sell the company to the job seeker.

The reality is that you’ll usually be interviewed by whichever members of the Hiring Manager’s team are free. Many people have pet theories about how to interview people, but mostly your future colleagues have absolutely no idea what they’re doing in an interview.

Their main goal is to stave off boredom during the interview and form an opinion on if they would enjoy working with you. They’ll do this by picking random parts of your CV that look interesting and asking you about them, asking you about technologies and problems they’ve been working on recently and are fresh in their mind, and occasionally by asking inane technical trivia.

However, the Hiring Manager will usually make the Hire / No Hire decision based largely on their feedback, so you’ll need to impress them.

What does it all mean?!

There are two important take-aways from all this. The first is to remember that the job application form is linear: usually you’ll need to pass the recruiter and the Hiring Manager in order to get the interview that really matters, the in-person interview.

The second take-away is that each person in the process has different goals and different things they’re looking for from their stage of the interview. At each stage of the interview you’ll stand a much better chance of progressing if you understand the goals and aims of the person at that stage.

These gatekeepers will come back over and over again in the content, as they’re generally looking for different things, and we’ll be exploring approaches to keeping them happy!