Author: Peter

Peter is a former developer and CTO turned recruiter who wants to demystify the recruitment process so that developers can find jobs and get paid more.

Technical Interviews: Show Your Working

When I was in grade-school math class, the teachers would always implore us to show our working. When answering a question, you wouldn’t always get to the right answer, but if you could show you’d approach the problem in the right way then there were still marks to be awarded.

You should take exactly the same approach answering programming problems in interviews.

Interviews are limited opportunities to learn about someone

As we covered in Can you pretend to be normal for up to two hours?, there’s not really that much that can be found out about someone in a technical interview.

The list basically comes down to:

  • Can they answer questions about the skills they claim to have experience with?
  • Can they present some evidence of their experience with those same skills?
  • Are they capable of maintaining a façade of normality for at least a few hours?
  • Can they – when motivated to – have a technical discussion where they respectfully listen to the other person’s opinion?
  • Do you like them, basically?

Nowhere in the list is “have a dictionary knowledge of algorithms and perfectly solve all technical challenges”. Heck, three of our five bullet points deal entirely with just your inter-personal skills while answering technical questions. The other two deal with showing evidence that you know how to approach certain technologies.

The answer to any given technical question you ask is usually not that important. Getting to a right answer the wrong way — rote repetition of something you’ve memorized or just guessing around — is usually the wrong answer. Getting annoyed that you’ve being asked questions that you don’t think are appropriate is almost always the absolute worst answer.

Doing anything other than demonstrating how you think a programmer should approach unfamiliar technical challenges is the wrong answer. That’s what you’re really being tested on.

How to reverse a binary tree

Short interlude for one of my favourite tweets of all time:

Let’s say that unlike the author of that tweet, you actually want to get a job. And let’s say you’re asked in an interview, “How would you reverse a binary tree?”

I’ve got an MSc in Software Engineering from Oxford and reversing a binary tree is not something I’ve ever had to think about it before. So … let’s instead show off how a programmer approaches an unfamiliar technical problem (other than StackOverflow).

What don’t you know, and what are you assuming?

You’re better than this

Start by laying out what you know, what you don’t know, and what you’re assuming.

Let’s take a guess at what a binary tree is. Binary means a pair, and a tree is a data structure where objects link to other objects above or below them… So a binary tree is a tree where every object has two child objects?

Say this out loud and ask for clarification: “Is that what you had in mind?” Your interviewer probably wants you to succeed, and is likely to help you, so show your working.

What are the constraints?

What are the success criteria to think about here? Most technical problems can be solved in several ways, and the correct way to solve it depends on the constraints and practical applications of the question.

Start asking about those constraints: “Are we optimizing for anything in particular here? Memory usage or speed?” They may give you a constraint you hadn’t even thought of at this point, and that’s a useful hint.

Test your thinking with examples

Do you have a whiteboard? Great! Start sketching out an example binary tree. What does reversing it even mean? Try a three layer tree and draw out what you’re starting from and where you’re trying to go to. If you’re on the wrong path, you’ll give the interviewer a chance to make a subtle course correction for you at this point.

White-boarding is often a great way of solving technical problems in the real world, and is going to help your brain start to narrow down solutions. We’re trying to show off we know how to solve problems, remember?

What would you need to look up?

You’re not being employed as a walking encyclopedia, so if there are specific things you don’t know or can’t remember, highlight what those are rather than hiding the rest of your knowledge behind small ignorances.

Do you think your method will take an amount of time that’ll grow linearly with the number of elements but don’t remember the technical name for that relationship? That’s fine! Explain it in English.

Does your solution use recursion, and you know there’s a way that some languages optimize recursive operations, but you can’t remember what it’s called? Not a problem! Show your thinking, say what you’re thinking. It’s natural to forget things, but you’re not going to lose many points for having forgotten the term for “tail recursion” if you know it exists.

Say exactly where you’re getting stuck

Does your solution create circular references in a garbage-collected language? Admit it, and be honest that you don’t see the solution, rather than hoping they don’t notice. Is there a feature in that language that would help and you don’t remember what it’s called and how it works? Mention all of that. Your interviewer almost certainly wants you to succeed and will probably give you hints and help you get unstuck, but they’re not psychic. A problem shared is a problem halved.

What are the failure modes

What should you do if there’s a node “missing” in the binary tree? What should you do if you’re given a tree with a single node? Think about what unusual or erroneous input and starting conditions would look like, and reason through what you think reasonable solutions would be. Some interviewers won’t care what behaviour you choose but will be glad you’re thinking about it, and some will want it solved in a certain way.

Thinking about edge-cases is also a trait of an experienced developer, and you’re using this whole process to show that you’re an experienced developer!

Please show your working

Showing your willingness and ability to think is far more important generally than solving a specific problem you’ve been shown.

I will hire the person who had interesting insights in to the problem but got stuck on something because they were nervous, but a person who just sits, assumes, and writes code without discussing the problems they’re trying to solve is a red flag as a future colleague, and that’s assuming they produce a right answer the first time!

Minimum Viable Interview Research

The more you understand the process of an upcoming technical interview, the more you’ll be setting yourself up for success. The more you know what to expect, the more confident you’re likely to be in the interview itself.

What’s below is a list of things I’d recommend trying to find out before the interview. Some of it you might be told proactively, and some of it you may need to ask for. You may not be able to get answers for all of it, but it can’t hurt to try.

You should ask these questions to whomever is setting up the interview for you. That might be an external recruiter / headhunter, that might be an HR person at the company, or that might even be a technical employee at the company (see: Interview Gatekeepers).

Who Will You Be Meeting?

Find out who you’ll be talking to. Are they technical? Is it your future boss? Will you be meeting an HR person for soft-skills?

Try and find them on LinkedIn, either via job-title or name. Do you have any shared connections you could talk about with them? Have you worked at the same companies before? Maybe you went to the same University.

Are they on GitHub? Maybe they’re the only other INTERCAL developer in your city. Maybe it’s useful to know they’re a core-contributor to Magento before starting your customary rant about how PHP developers should be hunted down like dogs.

But … don’t contact them. It’s legitimate to try and find out a bit more about the people to whom you’ll be talking in an interview, but you should keep your actual communication with them inside of the interview context.

Technical Test?

Will there be a technical test at some point in the process? What form does it take? Is it a take-home, white-board, will they give you a computer and ask you to produce something? Is there anything they can do to prepare?

Some companies are happy to be upfront about which areas of your knowledge they’ll be poking into. You probably don’t have time to ingest an algorithms book, but making sure you’re not too rusty on any skills mentioned in the job-ads “REQUIRED SKILLS” section would be a good idea.

Structural Overview

Is this the first interview of several? Is it going to be a phone-screen followed by two days in-office? You might not want to talk salary in a first interview, but if the first interview is also your only interview, you probably don’t want to skip the conversation all together.

Knowing how the interview fits together can help you gauge how well you’re progressing through it too — if you appear to have skipped two interview stages, perhaps ask for more money? If you seem to have stalled after a phone-screen and nobody’s talking about a follow-up then perhaps it’s time to see what else is on the market.

Prior Preparation and Planning

If you’re working with an external recruiter, they should really have all this information at their finger-tips, although not every recruiter is diligent as we might prefer. It’s entirely within your rights to ask these questions, although bear in mind that they may not know exactly who you’re meeting — I’ve worked at no shortage of companies where this isn’t decided until 15 minutes before the meeting based on who’s free!

Understand the Process

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.

Prove, don’t say

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.

if thou gaze long into the Puppet documentation, the Puppet documentation will also gaze into thee — Friedrich Nietzsche

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

Interview Gatekeepers

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!

How a recruiter speed-reads your resume

Long before I was a recruiter, I was a programmer. One of the skill-sets I know pretty well is JavaScript, both back-end and front-end.

It takes me less than a minute to read and make a decision on whether I will send a JavaScript programmer CV / resume on to my clients, which incidentally is about the same amount of time it took me as a hiring manager to screen CVs / resumes recruiters sent me to decide if we’d schedule a phone interview.

If you think that’s bad news, what’s even worse is that I’m unusually diligent. Assume an unknown recruiter is reading your CV / resume even less carefully than me.

With that in mind, there are two things I’m trying to ascertain as quickly as possible about your CV / resume: your technical ability, and your hireability.

Technical Ability

The very basics

Does the CV / resume actually mention JavaScript at least once? I get a non-zero number of applications from waiters with no programming history at all for JavaScript jobs. If you’re a programmer, applying for a JavaScript job, I’m going to assume there is at least a mention of JavaScript on your CV / resume.

Mid-level

Are there previous job titles on the CV / resume that suggest JavaScript development has been a primary responsibility at a previous job? A DevOps person may well list JavaScript as a skill without any commercial experience beyond two line hacks.

Primarily I’m looking for something along the lines of “Full-Stack Developer”, “Front-End Developer”, or “Back-End Developer” + a mention of Node.js. If you’re lucky, I have your actual CV / resume document on hand, but if you’re unlucky, I have a preview of your profile that looks like this:

If you’re in the unlucky situation where you don’t have job titles that look anything like the role you’re applying for, how about writing a few lines at the top of your CV / resume saying explicitly:

“I am a Senior JavaScript developer with 7 years of commercial JavaScript experience.”

Help me know I’m in the right place, and you haven’t just applied to every job that’s even a vague match for your skills.

More advanced

Is there supporting evidence you’re an actual JavaScript dev? A link to your npm profile is pretty compelling even if you’re a DevOps person. Mostly though, I’m looking for auxiliary skills that I’d expect you to have if you’re really a JavaScript developer — build systems like Gulp or Grunt, use or experimentation with languages that build on JavaScript like Flow, TypeScript, or even CoffeeScript.

Do you describe a technical problem you’ve actually solved using JavaScript? “Helped develop the client-facing Widget Tooling” is weak evidence, because who knows what you were doing? “Introduced PhantomJS to allow automated testing” suggests you’ve probably got technical chops.

Testing is a huge opportunity to show you’ve done serious development. Solid developers working on non-trivial systems have generally done some automated unit testing. If you tell me the “Widget Tooling” that you helped developed was tested using QUnit or Jasmine, I’m a lot more convinced you were doing proper development rather than hacky one-liners.

For JavaScript, of course, ReactJS and Angular are also skills that show you’ve mentally tackled at least one large framework. But preferably bolster this by describing problems you’ve solved that show you’ve engaged with and built out the skill, or I may wonder if you’ve just made minor changes to an existing code-base that happened to make use of them.

If you’re going to link to GitHub, pull out projects that you’ve originated (rather than forked), and in the skill-set I’m interested in. I get a non-zero number of applications including a GitHub profile that’s either empty, or just has forked and unedited projects.

In general…

Digging in-depth into what you’ve written is a job for the people who end up actually interviewing you. My job is to decide — preferably as quickly as possible — if you’re the type of developer you say you are, and the approximate level of seniority you say you are. While I do sometimes follow up with people if it’s unclear from their CV / resume, assume I am reading your CV / resume while the fire alarm is going off and I’m evacuating a building. If I have to work too hard to pull the meat from your CV / resume, you’re severely handicapping your job search.

Hireability

Generally the person I’ll actually submit your profile to at an employer is a non-technical HR person. They will be attempting to judge from your CV / resume if you’ll be a good employee. As you can imagine, this is a little tricky from a 2 page document, but they have their own heuristics, and that largely boils down to looking for things that worry them on your CV / resume.

These red flags aren’t likely to be instant rejections, but they’re all going to concern the reader, and that reader gets to decide if your CV / resume will be forwarded on to a technical person who’ll actually understand all the long words on it. So it’s worth explicitly heading off any objections they might have.

Gaps

Do you have big gaps in your employment history that you’ve not even tried to explain?

If your last role was two years ago, because you’ve spent two years traveling the world and finding yourself, that’s fine. Heck, maybe that’s even good. Rather than leaving it mysterious, just explain in the middle of your work history:

Jan 2015 – Feb 2017 – Personal travel (Bali, Chiang Mai)”

Have you been dealing with family affairs? That’s also fine:

Feb 2016 – Feb 2017 – Dealing with now-concluded family affairs

I am happy to provide more details as need in interview

Have you been unemployed, job-seeking, and doing even occasional small bits of work for friends and family? I think it’s reasonable to say:

Jan 2012 – Aug 2012 – Freelancing

While between roles, I spent time picking up small pieces of interesting technical work and sharpening my skill-set. During this time I built a Blah Blah Blah system using AngularJS and blah blah blah

Simply: try and avoid giving the impression you’ve something to hide by not hiding anything. Real life gets in the way of all jobs and nobody’s perfect, but the unknown is scary so be explicit about employment gaps.

Very short roles

Between the exorbitant recruiter fees, provision of computer equipment, general HR process faff, and the time it takes for a developer to be brought up to speed with a new system, hiring someone new is expensive.

If you leave a job 7 months after you’ve started, having contributed very little, you may not represent value-for-money to the employer. Employers want employees who’ll stick around for 2-3 years.

An employment history that shows many short roles suggests you may be a problem employee, or have a very short attention span. It can also suggest you’ve just been unlucky.

Try and explain the reason roles were short:

  • “Company went out of business after 4 months”
  • “Family issues forced a relocation after 7 months”
  • “I enjoyed my time at XYZ Corp, but the career progression to management promised at interview was more ad-hoc than had been described in interview”

If the roles were freelance or contract, be explicit about that. In the UK there’s a culture of 3 to 12 month programming contract roles, and that’s fine, and something very different from leaving a series of roles that were meant to be permanent early. By the way: if you have a contracting background, and you’re looking to move into permanent employment, write this in bold letters at the top of your CV / resume. Otherwise HR will reject the CV / resume on the basis that you’re looking for a disguised contract.

Again, nobody’s perfect, and you can definitely get away with one or two short roles. But if you’ve got many many short roles, try and help me and the HR person understand why that is.

Existing right to work

50% of the applications we receive are for roles that are clear they don’t offer sponsorship, by people who would require sponsorship. They are almost all from India. I am desperately keen to hire Ahmed who lives in London with a Tier 2 dependency visa that lets him work in the UK without sponsorship. But I can do nothing useful for Mehmet who lives in Bangalore and requires sponsorship for a role that doesn’t offer sponsorship. And I get an order of magnitude more job applications from people like Mehmet than I do from people like Ahmed.

Put in big clear letters right at the top of your CV / resume your employment entitlement. Doubly so if there might be any question about it. If you have an address in Miami and have a cell that starts with +1, and you’re applying for a UK job, I will not that work that hard to double-check that you have an existing work right, because *most applicants do not*.

Conclusion

It’s a lovely idea that your CV / resume will be perused over at length by people with the time and energy to carefully decipher your strengths and weaknesses. It’s also fantasy.

I will go back to developers who send me ambiguous CVs / resumes for more information sometimes, or for a particularly hard-to-fill role, but again, assume something is on fire in my office when I’m reading your documents. However, I will always jump with enthusiasm on developers whose CV / resume presents me the information I am looking for quickly and in an easily digestible form.

Counter offers can be great, be wary of recruiters suggesting otherwise

Aims of recruiters are not always well aligned with the aims of the people they’re trying to find jobs for.

A particularly egregious example of this is recruiters writing opinion pieces on why you should never accept a counter-offer — that is, your original employer offering to match (or better) the salary somewhere else has offered you.

If you accept a counter-offer, you get more money for doing your existing job, and the recruiter doesn’t get paid anything.

Let’s talk this through…

How Happy are You already?

If you’re not currently happy where you are, then accepting more money for a role you don’t like requires careful consideration. But if your current role is bearable, and the new role doesn’t look amazing, then a counter offer gives you:

    • More money right now, in an environment that you are at least already familiar with
    • A chance to rebuild your relationship with your current employer having established that there are things you’d like to see change
    • Breathing room to find a role you’re sure you’ll love, and using an increased current salary as a bargaining chip for somewhere new

I was pretty happy when I worked for a large ecommerce site that sold very expensive women’s clothes online. I liked my team, the corporate bullshit was cope-able, my commute was bearable, and there weren’t hidden working conditions yet to discover that I didn’t already know about.

But a recruiter came calling and told me there was a role at a large investment bank paying almost 50% more than I was currently on. 50% more is hard to ignore, so I went and spoke to said investment bank, and got offered a job.

I was pleasantly surprised, having handed in my notice, to get a counter-offer — they’d pay me exactly what the investment bank was offering, no questions asked. Overnight 50% pay rise for doing the same job.

The recruiter in question, seeing his considerable commission slipping away, gave me the hard sell…

“If you’re worth 50% more, why aren’t you already being paid that?”

First of all, he wanted to know, didn’t it bother me I was being undervalued in my current role?

This is misleading. When my current company had hired me, they didn’t know what I could do, they didn’t know if I’d work out as an employee, they didn’t know how productive I’d be in practice. Developers bring wildly different levels of productivity to a business, both in personal output and in their effect on a team. Predicting how useful a potential employee will be compared to the rest of the team is virtually impossible.

But if someone you’ve hired is worth more money than you’re currently paying them, and seems pretty happy with working for you, simply giving them more money is no way to run a profitable business. When a business pays a salary, it’s trying to get a return on investment for that salary. Some developers will be a better return on investment, and some worse.

Handing out large ad hoc raises to your employees is a great way to reduce your return on investment for their salary, foster ill will with colleagues who overestimate their own skills and think they should also get pay rises, and as such is a hard sell to the people who control the purse strings.

Giving more money to developers who are threatening to leave and who you value is a great way of making sure money is allocated efficiently and avoiding the costs incurred by training someone new and recruiter costs for new hires.

So did it bother me at all that I was currently being “undervalued”? The opposite: the counter-offer showed me my current place was in fact well aware of my value, but also being run by people who understood how to stay profitable.

In another job as a development manager, any raise I wanted to give out had to get sign-off three or four management levels above me. Justifying this to the people above was hard if I just had a general feeling that a developer wasn’t being paid well enough for her time; there was no end of supporting evidence I had to come up with. But if that developer had come to me telling me she’d been offered $15,000 more elsewhere, I just had to tell my bosses I need to pay her more because she’d had a job offer elsewhere, and it’d get signed off in no time.

“Not being paid what you’re worth” is often just corporate inertia, and one great way to increase momentum there is to have a job offer — which you’re willing to take — offering more money elsewhere

“You’ll be seen as a flight risk, and the company will know you’re going to leave one day”

The next angle he had was: “now the company knows you’re looking to move, you’ll be slowly forced out or left behind”. It takes some chutzpah to suggest to an employee who’s just been offered massive bump in salary that the company offering the salary bump isn’t looking to invest in or retain that employee.

There’s also a mistake in his reasoning there: I wasn’t looking to move, I was looking to move for more money. I was pretty happy where I was, just not at the original salary I was being paid, a point I made clear to the current employer. My desire to move disappeared when I got offered more money. I was signaling that to my current employer by staying.

There are, of course, different situations to the one I was in. A candidate I was working with didn’t like his current role, and didn’t like the direction the company was going. He had been very open about this, and about his desire to move on. But when I found him a new job, he was offered a huge one-off bonus to stay put until a certain date. It was obvious to everyone involved that after that certain date, he’d start looking again with a view to leaving, and he’d have been insane to think that the company he was staying with were going to be working hard to promote and entice him.

But just as everyone dies eventually, everybody leaves their current employer at some point. Companies know this, and they don’t take it personally (although the occasional bad boss might). Businesses understand that employees want to be paid for their time, and that employment is a market, and it’s not going to be a black mark against anyone that they’re treating their job as a job, and not some kind of life-long commitment.

Everything else…

I was looking for a third point to end the article, and came across this gem of a list from the first Google result for “don’t accept a counter-offer”. Incredibly, the article is from the section called “Our Service to Candidates”…

“You have now made your employer aware that you are unhappy. From this day on your commitment will always be in question.”

If you work somewhere where your concerns are treated as a black mark against you, and there’s an expectation of unpaid “commitment”, then sure, move on. The vast majority of companies aren’t run by psychopaths though.

“When promotion time comes around, your employer will remember who is loyal and who isn’t.”

If “loyalty” is a big deal in your workplace, you may be working for the mob. Or a psychopath. If you work somewhere where seniority is determined by loyalty, rather than skill, you’re already working in the wrong place. The vast majority of companies don’t promote people based on loyalty.

“When times get tough, your employer will begin the cutbacks with you.”

Why would a company make redundant employees who they’re willing to pay money to retain? What kind of company doesn’t retain staff on the basis of their input? Most companies are not like this.

“When your employer replaces you after six months and ‘lets you go’, it’ll be harder to turn them around than it was for them to turn you around.”

If a company is paying you to stay on, it’s safe bet they want you to stay on.

“Accepting a counter offer is an insult to your intelligence. You didn’t know what was best for you.”

Money. It was money that was best for me. This list is an insult to my intelligence.

“Accepting a counter offer is a blow to your personal pride, knowing you were ‘bought’.”

If you wouldn’t do your job for free, aren’t you’re already being bought?

“Accepting a counter offer rarely changes the factors that drove you to look for a new job in the first place.”

Sure, unless that was money. And you’ve no guarantee a new workplace will be a better place to work.

“Where is the money for the counter offer coming from? Is it your next pay rise early?”

Usually not. That’s not how salaries and pay rises work. And if it does turn out to be the case, it’s not like there’s a shortage of jobs for developers…

“Statistics show that if you accept a counter offer, there is a ninety percent chance you will be out of the job within six months.”

The best statistics are those that are uncited and presented to you by a company that stands to lose a lot of money if they can’t persuade you. :eye-roll:

“What type of a company do you work for if you have to threaten to resign before they give you what you’re worth?
“Why didn’t they pay you that before? It was because they didn’t think you were worth it.
“Why are they paying it to you now? It’s because it’s easier and cheaper for them to keep you for the time being, while they sort the problem out.

As covered above.

And so…

I have a friend with a PhD in Financial Maths from Oxford (so technically a DPhil, but whatever) with a habit of putting complicated decisions in black and white terms. And back when I was thinking of making the jump I’ve used as an example above he asked me a very simple question:

“How much is the new role offering you to offset the risk that you’ll hate it at the new place, when you’re happy enough where you are?”

Once I got the counter-offer, the answer was “nothing”.

Be wary of recruiters giving you blanket advice to not accept counter-offers!

When two job titles are better than one

One of the very few things that can be fact-checked on your CV / resume is your employment history. That you “pioneered the use of continuous deployment” in your last role is just like, your opinion, man, but that you were employed by XYZ Corp from 17th of February to 9th of September as Senior Widget Wrangler is an objective fact.

And it’s an objective fact that companies can and will check, often as part of a box-ticking background check process prior to you coming on board. Someone in a Call Center far far away from Experian or Equifax will ring around the HR departments of your former employers and ask them to confirm the dates you worked and your job title.

If you’ve lied about how long you worked at a company, you’re going to have a very awkward conversation if the background check says otherwise to your new employer. If you’ve said you were CTO when your job title was “Developer Level 2”, you’ve also got a rocky ride ahead.

But even if your intention is to illuminate rather than obfuscate, the actual characters that make up the job titles in your work history may not be those best optimized for finding jobs for which you are in fact qualified.

A Real World Problem

There are a host of reasons that the exact characters which comprise your job title is so important, but most important here is the reductive approach that both recruiters and recruitment software take to reading your CV.

Here’s a screenshot from SEEK, Australia’s largest job-board, when searching for a Junior Sysadmin.

Note how each candidate has a single job title extracted from their CV. A career of working hard, a well-thought-out CV / resume, and it’s been distilled down to 64 characters. And unless I want to download and read all 600 results returned from searching SEEK, that’s all I’ve got to go on to decide if I want to invest more of my time in each candidate.

Lawrence Webb, the Murex Support consultant, is probably shit-out-of-luck, because I don’t know what a Murex Support consultant is. Murex has something to do with banks, I think, but I’ve got no idea what the relationship is with Sysadmin. The part where he explains how he lovingly uses Terraform to spin up AWS environments of Puppet-managed immutable infrastructure has been elided.

Even when a recruiter is doing their job properly, they’ll be likely skimming CVs, and one of the key metrics they’ll be doing is looking at previous job titles. If you’re applying for a DevOps role and your last job title was “Associate Web Engineer” then you’ll be tempting the lazy recruiter to pay even less attention than normal.

So there’s a problem here:

You can use your actual job title for each role, but then you might not turn up in searches. You might be discarded at the preview stage, and busy (and lazy) internal and external recruiters might not bother reading the descriptive part of your last job description if the job title isn’t an obvious match.

Alternatively, you could use the job title you think you should have, but you’re setting yourself up for difficult conversations a bit further into the interview process if and when a background check is run.

A Sneaky Trick

My sneaky trick for dealing this is to double-up the number of job titles on your CV. Lead with a descriptive job title, but also include your actual job title. Planning and executing a move of 100 servers from a data center into AWS, but stuck with the job title “Site Engineer”? Go with:

“AWS Cloud Architect / Site Engineer”

Managing a development team of 10 people but stuck with “Software Engineer Grade 2”? Let’s try:

“Technical Team Lead (Software Engineer Grade 2)”

It’s accurate, it doesn’t get flagged in a background check, and the real beauty of it is: if challenged on it you can be absolutely and totally honest about it, and about your reasons for doing it:

“The first describes the role I did, the second is the job title I oficially held, which I’ve included for accuracy”

It probably goes without saying that if you’re going to do this, make sure you can back it up: if you’re describing your last role as being “AWS Cloud Architect” and you can’t talk in depth about being an AWS cloud architect, you’re going to look like an idiot in a job interview.

Prefer a descriptive title rather than simply inflating your seniority, and don’t use titles that your current employer offers but you simply haven’t reached: if your company has Senior Developers, but you’re not one, calling yourself a Senior Developer when you’re just a Developer may well invite reasonable challenge.

Can you pretend to be normal for up to two hours?

Every company sucks at interviewing. Plenty of companies (and individuals at companies) think they’re really really good at interviewing, but mostly they’ve just gotten lucky.

You’re never going to learn in a 2 to 12 hour interview programme what it’ll be like to sit next to someone day to day, share large bodies of work with someone, or rely on someone in a professional context.

In fact, there’s very little you can learn about during an interview.

What you can learn about a candidate during an interview

Can they:

  • Maintain a façade of normality for at least a few hours?
  • Have a technical discussion – while on their absolute best behaviour – where they respectfully listen to the other person’s opinion?
  • Answer questions about the skills they claim to have experience with?
  • Present some evidence of their experience with those same skills?

and … do you like them, basically?

THAT’S IT.

And therefore, as a candidate, you have some very very simple and straightforward goals while being interviewed:

  • Provide evidence of having used those tools you claim experience with
  • Try and not be too weird for a few hours
  • Don’t shout at the interviewer
  • Make yourself appear likeable

Much of the content on this site is about providing evidence of your technical skills, and acing the technical part of an interview, so let’s quickly go over how to not appear to weird for a few hours.

Bad weird, good weird

I’ve been programming since I was 6, took time off from high school to speak at technical conferences, and have been commercially employed as a programmer since I was 18. Being a bit weird as a programmer goes with the territory, and everyone involved in the hiring process knows this. Weird is OK.

But there’s also bad weird, which is less OK. Bad weird is you cause messes that line management and HR need to clear up, and cause other people to do more work, less enjoyably, as a result of your being employed.

Wearing Vibram Toe Shoes and having a sub-dermal magnet are par-for-the-course weird, and may well endear you to future employers and coworkers. Turning up 40m late for the interview in shorts and a t-shirt and starting the interview with a small lecture about how you’re not going to accept payment in “unconstitutional fiat so-called money” is bad weird.

Signs that you might be bad weird

Unwillingness to put up with small amounts of corporate bullshit

The nature of companies includes small amounts of corporate bullshit. Sometimes large amounts of corporate bullshit, but generally small amounts. Examples of corporate bullshit at my last real job:

  • Marketing insisted on a photo of all employees on the website
  • HR insisted on using a terrible system for booking holidays
  • Finance insisted on a weekly timesheet for developers breaking down how many days were spent on each project

Some small companies do manage to do away with corporate bullshit entirely, and some larger companies try really hard to pretend they do (and then it leaks out in the form of structure-less management or unlimited holiday days that aren’t), but you’re going to face some degree of it almost everywhere.

And some employees will spend a lot of time and energy complaining to their immediate line manager — who’s usually empowered to do precisely nothing about it — about it. It’ll come up at every weekly review, it’ll come up in response to mandatory security training, it’ll come up at every team meeting. And it’s a huge waste of everyone’s time.

Side note: some things are absolutely worth shouting about over and over again to anyone who’ll listen: discrimination in the workplace, genuine health-and-safety issues, abusive relationships in the workplace / bullying. Notably not on that list is “the holiday booking system is cumbersome”

However technically gifted you are, it’s entirely possible to be a net negative to a team through constantly complaining and arguing about virtually everything. These people exist, and your interviewer does not want to hire them.

Employers won’t explicitly ask you if you recognize that there are rules in a workplace, and if you accept that you’ll have to put up with a small amount of corporate bullshit, but they will:

  • Make a note of if you’ve shown up to their interview looking like you’re going to a business meeting, rather than with baggy shorts and a ripped t-shirt
  • Be concerned if you’re late to the interview
  • Look unfavorably on your spending an hour complaining about how your last employer wouldn’t let you run a Tor relay in the data center

    Inability to avoid (technical) arguments even while on your best behaviour

    An interview is your opportunity to sell yourself to a potential employer. You’re expected to know this, and act accordingly. *Your behaviour in the interview is expected to be your best behaviour*. If you can’t last two hours without getting into a petty and pointless technical argument, being condescending to your interviewers or throwing your toys out the pram because you were asked an algorithms questions, that’s a bad sign that you’re going to be a real pain to work with and manage.

    I suspect the people who passed on this guy:

    … probably don’t regret it, having read the tweet.

    I’ve been asked some truly shockingly poor quality questions in interviews by some truly bizarre interviewers, but it’s a mistake to try and read too much into a company simply because one of the people the hiring manager picked to interview you has a favourite algorithms question he likes to ask to make himself feel intelligent.

    I was an interviewer once where a co-interviewer asked our candidate — in all seriousness — which the better band of The Beatles and The Rolling Stones was, and was expecting a serious answer. No deeply meaningful information about the company, work environment, or role, was passed on in that moment. It was a misguided rephrase of a (more interesting) product management question.

    Looking a little confused and asking follow-up questions makes you look like you at least know what being a compassionate, understanding, and thoughtful coworker looks like, and can pretend to be one when you need to be. Getting defensive and asking aggressively what relevance that question has to the job — while you’re meant to be on your best behaviour — just makes you look like an ass.

    A skillful technical interviewer will ask your questions that are a matter of opinion, and then challenge you politely on your opinion. The correct answer is explaining how you came to your answer, and to show an ability to understand that other opinions can exist, and that most technical decisions have trade-offs.

    You will almost certainly also meet bad interviewers with poor quality questions, but you’ll still be judged on your ability to keep your cool, make the best of the situation, and not berate your interviewer for wasting your time…

    Deep-seated and poorly hidden anger about previous coworkers and employers

    I’ve worked places I didn’t enjoy, and I’ve worked with people I hope I’ll never see again. I’ve interviewed places because I was desperate to get out of the toxic environment I was working in.

    And you’ll often get asked about these in interviews:

    “Why are you moving on from your current employer?”

    “Describe a difficult situation with a coworker, and how you recovered from it”

    These are a great opportunity to show how you’re like Rocky, and how you’re on a journey that included overcoming adversity with an open heart, rather than how you’re like the guy from Silence of the Lambs, and will carry your employment trauma with you forever to the detriment of those around you.

    This bit’s really important, so it’s in bold: under no circumstances make disparaging comments about your current company, as the interviewer has no way to know that you’re not the problem you are describing. Plus, if you can’t show you have the social skills not to trash the last company you worked for, that’s a big red flag, and you’ll look like an HR liability.

    Safer answers are specific things that you’d like to see in a new role, couched with an understanding for why things were how they were in the old role, eg:

    Is the codebase of your last company literally a festering sore that’s burned into your retinas? How about:

    “Much of my last employer’s codebase was built to try and satisfy customers and get the product to market as quickly as possible, and obviously corners had to be cut in order to achieve that. However, for me the trade-off was a little too far, and I’d like to work somewhere that considered code quality to be an important attribute in its own right”

    Was your last boss a control-freak who’d check your commits out of source-control if he didn’t like the indenting? How about:

    “In my last role there was a very strong technical hierarchy, and there wasn’t always an opportunity to engage in technical discussions about the right way to solve problems. I appreciate that you can’t always do everything the way you want to, but I believe I’d enjoy a workplace where I had more freedom to bring my skills to bear”

    …

    Your goals, in summary

    Interviews are not a good way to find out how good a coworker will be, but they can give you a pretty good read on some of the soft-skills. You are trying to not eliminate yourself by showing you at least understand those soft-skills exist, even if you’re not a master of them.

    In particular:

    • Try and not be too weird for a few hours
    • Don’t shout at the interviewer
    • Make yourself appear likeable

    Good luck with not being bad weird…

Who cares if developers want to get paid more?

Nobody cares as much as you do about your salary.

One reason I like to stress to developers that they should understand how the mechanics of interviews work is so that they understand the motivations of all the players, especially when it comes to salary — who doesn’t want to know how to get paid more?

Let’s say you’re applying for a role, and you want $10,000 more a year than the recruiter says they’re offering. We’re going to look at who cares, why they care, and what you can do about it.

You care how much developers get paid

Obviously you care, and you may well care a lot.

If we’re talking about $10,000 more money, and you’re a developer, you’re probably in one of the higher tax bandings. In Sunny England, where I’m from, you’re looking at 40% marginal tax, so let’s say $10,000 more a year is worth $6,000 more after tax.

$6,000 extra a year is $500 a month extra, which is a lot of Orange Mocha Frappucinos, or an upgrade from your Chevrolet Spark to a Tesla. It’s between 5% and 20% of an average developer salary.

There are also some compounding effects of a higher salary: many bonus schemes are expressed in terms of base salary, the starting point for your first salary review will be a percentage of your current salary, and your next job will probably ask what your current salary is, and tender an offer on that basis.

As a potential employee, that $10,000 extra for you is a big deal. You’re not going to be necessarily working any harder for it, but you’re certainly going to be benefiting significantly from it.

To you, that $10,000 extra a year is $500 extra a month, and unless you’re pulling in $300,000 in the Bay Area, that’s probably a big deal.

Who else cares?

External recruiters care how much developers get paid

If you’ve gone through an external recruiter — someone who doesn’t work for the company itself — he’ll get a one-off commission if you accept a job that he put you forward for. If the agency he works for is on a 15% commission then the agency will bill the employer $15,000 if they place you at $100,000, and $16,500 if they place you at $110,000 — your $10,000 extra salary is worth a one-off $1,500 extra to the agency.

However, the recruiter themselves won’t see that much — he’ll be on a commission scheme themselves with the agency. Let’s call it 25%, and apply a 40% marginal tax on that bonus.

For placing you at $100,000, the recruiter himself takes home $1,500. Not bad! If he places you at $110,000, the recruiter takes home $1,650. Your extra $10,000 a year is worth $150 after tax to the person doing the negotiating on your behalf, which will set him up for a pretty reasonable steak dinner.

There’s a huge caveat, though.

If the client hires someone else, who’s not working with this recruiter, because you were too expensive, then the recruiter gets $0.

He still did all the work, but he got precisely $0 commission. He gets an extra $150 if he gets you more money, but he loses the $1,500 commission if you get priced out of the role.

So his motivations are different from yours — you want to get paid as much as possible for the same work, but he just wants you to accept a job.

One of the few redeeming qualities of recruiters is that they’re gloriously, transparently, and cynically motivated by their commissions, and they’d love for you to get a job so that they get paid.

Recruiters will know the salary range of the role you’re applying for, they’ll often have a good picture of how you stack up against the competition, and they may well know how much other people at the company are already getting paid. And if you ask them, they’ll probably tell you; they’re not looking to save the hiring company any money.

Have a full and frank conversation with the external recruiter about salary upfront. Ask them what range the company has given them, ask them where they think you fit into that bracket, and ask them how often they’ve seen the company go above that range.

The Hiring Manager may not care how much you get paid

The Hiring Manager is your future boss — let’s say she’s a very Senior Developer who also line-manages a team.

Chances are that she doesn’t manage her own staffing budget; she’s just been given a salary range by the people who make the money decisions, and she’s allowed to make offers inside that range without seeking further authorization.

If she thinks you’re really really good, she can go to her manager and ask for a special case to be made for you to get paid more. And she’s a technical perfectionist who loves her codebase, so she really does want the best people, but…

The Widget Automation project that she’s responsible for is 6 months late, and her boss told her at her last performance review that more hands would help, and has she really not made progress on getting someone hired yet?

So her motivations are not purely financial. Her motivations come from wanting to deliver product and having a team in place to do that. She wants someone capable for her team, as soon as possible, but it’s not her money. So as long as the extra $10,000 you want is inside the salary banding she’s been given, she’s happy.

If you’re asking for more than that salary banding — even by $500 — you’ll cause her a day of work and hassle trying to get the extra money signed off.

One final consideration: if she pays you considerably more than similarly qualified people on her team, and they (inevitably) find out, she has a problem, because those other people will start asking for more money, and feel resentment if they don’t get it.

What to do?!

Unless you’re working for a tiny company, the people whose profits your extra $10,000 a year comes out of won’t meet you during the interview process, and may not even know you exist. You might meet the person whose budget is paying for you, but unless it’s a small company or a very senior role, you probably won’t.

The two people you will meet, and between whom most of the salary negotiations will occur, have motivations different from each other and different from yours.

While the recruiter wants as much commission as possible from placing you, he doesn’t want to push the boundary too much in case the employer goes with someone else.

The Hiring Manager probably doesn’t care how much she pays you, as long as it’s inside her budget, and she gets a vague feeling of value for money from you, and it doesn’t dwarf other developers on her team. If she can pay up to $99,999 without getting further sign-off, and you absolutely insist on $100,000, you’ll be causing her a lot of extra work that you may not see, and being only human, she may decide to go with an easier candidate.

It really can’t hurt to go into the process having shaken as much information as possible out of the external recruiter on the salary being offered, and where possible, looking on Glassdoor for the sort of salaries the company is paying to people who already work there…

By the way, the recruiter and the Hiring Manager are two of the Interview Gatekeepers, who are worth finding out more about!