“We only hire senior engineers.”

It’s a pretty good time to be an engineer, but it’s an even better time to be a senior engineer. In the economy of engineering jobs, there’s an increasing demand for senior talent, but no one is working to increase the supply because senior talent can’t be made, it takes time.

Companies will say things like:

“We’re only looking to hire senior developers right now.”

“We need to hire more senior talent to balance things out before we hire more junior developers.”

“Our code base/business logic is too complex for junior devs, we only hire at the senior level.”

But there’s a problem with this. Is it not immediately clear to you? Basically, replace the phrase “senior engineer” with “white men” in any conversation about hiring senior engineers you’ll see what I mean:

“We need to hire more white men to balance things out before we hire more women and minorities.”

This is, of course, a generalization. There is diversity at the senior level - it’s not great, though (it’s actually pretty bad). However, the thing about being a senior-level engineer is that you can work wherever you want. It’s a safe bet to make that women and minorities at the senior level aren’t going to want to spend their days being harassed while working at a company that claims it “doesn’t have a problem with diversity”, or one that is still trying to figure out the whole diversity thing. They’re going to work at a company where they don’t constantly feel alone, at a company that has diversity policies, employee resource groups, and a valuable, active HR team.

Companies don’t need to hire senior engineers, they want to because they think it’s easier to “just start coding” if you have more experience.

Beyond diversity, only seeking out senior talent is a problem because it reflects negatively on the company’s view of its employees.

Companies value profits over people. #

When a company is only willing to hire established, skilled, and senior-level talent, it’s an indicator that they value their profits over the people that help to generate them.

Hiring junior talent is an investment in their abilities and skills, something that, in the long run, is mutually beneficial for the company and the employee.

Companies hiring senior developers don’t have to worry about training employees or cultivating talent internally because they’re hired already trained, already cultivated people.

This is an alarm bell. It indicates a lack of value in employees on an individual level. If a company sees an employee as a profit-producing resource instead of a person to invest company resources in, you have a recipe for disaster.

Companies want to acquire senior devs, but they don’t want to train junior- or mid-level devs to become better. In an essence, companies are hoping to get something from nothing.

An alternative: create the supply. #

There is an alternative, though: companies can create the supply.

I know you’re probably thinking “ugh, Liz, I don’t want to start an apprenticeship program. I don’t have time for that, and I don’t have the money.”

But I’m not talking about an apprenticeship program, I am talking about extended onboarding.

Bring on a team of 5-10 junior or mid-level developers at the same time and assign them to the same manager (or - as some have suggested - 2-3 devs, which would be comparable salary-wise to hiring 1 senior). This manager should be someone who is great at developing people, teaching, and seeking out other talented engineers at your company for lunch time training talks.

Spend 3-6 months with this team, assigning them low-hanging fruit and bug tickets from the backlog. Every week, or every month, have one of your already existing engineers give a talk about your infrastructure, modeling, or other complex part of your code base. After 3-6 months of working with your team and getting to know your code base, they’ll be ready to transition onto a full blown team. (See below for clarification)

Will they be senior engineers? Probably not.

Will you have knocked out some annoying bugs from your backlog and made your customers happy? Yes.

Will you have trained a team of engineers that know your product? Will you have invested company resources into growing a valuable team that will reap long-term rewards? Absolutely yes.

Little note to clarify: I am not talking about hiring a squadron of junior devs to be janitors for all of your bugs (nobody should only be working on bugs - that’s misery-making). To be clear: I’m talking about having them work on some bugs to get to know your code base, while they tackle larger projects together, either individually, as a team, or in pairs. In retrospect I didn’t make that super clear when I originally wrote this, hence this little note.