Knowledge is power: Why are they hiring a new developer?

One of the core concepts on this site is the idea that the more you understand a process, the better equipped you’ll be to work with it. The more you understand the recruitment process, the more you’ll have a good idea of what questions to ask a potential employer and what to do with that knowledge.

In addition to the Minimum Viable Interview Research, one of the most important — but also most overlooked — questions to ask is:

“Why are you hiring a new developer?”

The Options

There are three common answers to why a company is hiring, and each opens up different opportunities to the developer interviewing for the job. Essentially:

Pssssst! Enjoying the article?

I'll email you once a fortnight with a summary of anything new I've written, and also send you the free How to write a developer resume that'll get you hired e-book.

  • Replacing an existing person who’s vacating the role
  • Staffing a new project or team
  • Incremental growth / expansion of their team


People leave jobs to go to different companies, or different roles within a company. What opportunities does this present to the person interviewing for the replacement role?

For one thing, the technical people interviewing you (meet the interview gatekeepers) will probably have opinions on the strengths and weaknesses of the person being replaced. You can ask about these in the interview itself to find out what skills they’re most interested in:

  • “Are you looking to exactly match the skill-set of the person who used to have the role?”
  • “Is there anything new that you’re looking for the replacement to bring to the table?”
  • “Are there specific skills you’re worried about leaving when they move on?”

The answers to these will give you a good idea of how to pitch yourself in the interview, and what skills you have to talk about. You probably don’t want an exchange where you simply parrot back to the interviewers all the things they said they’re looking for — it’ll look like you’re trying to over fit yourself to the role. But these are great for jumping off points for “proving, not saying” and “being technically interesting”.

It’s possible that an external recruiter you’re talking to about the role will also have a strong idea about the answers to these questions — we often get a lot of “liner notes” to go along the job description when we take on a job search. If so, you can use some of the ideas under “More Advanced” in How a Recruiter Speed-Reads Your Resume.

Startups or small businesses that became successful often have the “tech lady” or “tech guy” who did all the originally development — the one who wrote the horrible legacy code and runs SQL “fixes” against the live DB. The business generally has a love/hate relationship with this person or people — maybe they got the business a certain distance, but they lack the willingness to follow business and technical processes that make their work stable and predictable. If that’s the case, make sure you talk about professionalism and experience of “more appropriate methods for a more mature business” in the interview!

In general, if they’re doing a like-for-like replacement of someone, a company’s unlikely to want to massively change the seniority of the role or pay a dramatically different amount to the new hire than they did to the last person. They’re probably looking to re-use the same job title, and so there’s probably the least amount of negotiating flexibility about the remuneration and benefits package. But they’ve also probably got the clearest idea about what they need, and that can work to your advantage.

A Whole New World!

One of the most exciting times for a developer can be building something from scratch. And sometimes companies are hiring for a new project or a new team, and you’re interviewing to get in right at creation time. Awesome! Someone in the business got funding signed off to do something, and now they need to build the team to do it.

There’s probably a specific pot of money that’d been allocated and a rough guess on how much head count is needed. This means there’s probably the most associated flexibility in hiring — how that money is divided between different developers as salary, how that team will be structured, the mix of experience needed in the team. There’s potential to make one or two expensive hires, and who doesn’t want at least one superstar on their team?

Try and sound out the possibilities:

“Are there other related roles you’re looking to fill for the team?”

Maybe you’re a developer with some DevOps experience that you’d like to build on, and they’re looking for someone to fill that role and you’d be a good match. Maybe they’re also looking to hire an Architect or Team Lead, and you could suggest you’d like to be considered for that role too?

Internal or external recruiters certainly won’t mind if you end up with a slgihtly different role at the same company — they’ll get paid whichever role you take. And companies are often looking for people who want to develop and grow inside the company. There’s benefit in showing some ambition and initiative beyond simply finding out if there are more interesting or appropriate roles you’d like to do inside the team.

Incremental Growth

Somewhere between the like-for-like replacement and the building of a whole new team, we find incremental growth or expansion of a team. That’s a great sign! It usually means the business values the work that team’s doing sufficiently to invest more in it.

If they’re hiring quite a few new people, you have some of the advantages of a whole new team — there’s probably a head count and an amount of money assigned to it, so they can take a chance on you if you’re more junior, or pay a bit extra for your expertise if you’re senior.

You can also find out specifically which skills the team is looking to build upon with the questions from the like-for-like replacement. At worst, you’ll look like you’re genuinely interested in their company, and at best you’ll be able to sell your strengths directly against the things in which they’re most interested.

Knowledge is Power

Programmers are by and large intelligent people who like to solve problems and work with constraints, but for some reason many are reluctant to apply those skills to the more meta problems and constraints attached to interviewing for new roles. You wouldn’t try and design a new technical system without trying to find out what problem it’s meant to be solving. Likewise, the more you can find out what problem the company who’s hiring is trying to solve by hiring, the more you can pitch yourself as the appropriate solution to that problem!

All done?

I'll email you once a fortnight with a summary of anything new I've written, and also send you the free How to write a developer resume that'll get you hired e-book.

Published by


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.