What Companies Failing at Engineer Hiring Are Missing
I have had the opportunity to go through various companies' hiring processes and also experienced being on the hiring side.
In recent times, the theme of "it's difficult to hire engineers" has become increasingly common.
From my personal experience, while I agree to some extent that "hiring engineers is difficult," I also strongly feel that "it's not really that hard."
So, in this article, I want to share my personal thoughts as an engineer about hiring engineers.
Since this might be a long read after a while, here’s the agenda first.
- Hiring should be the last resort
- Narrow and deep scope
- Are you truly committed to the product?
- Being in-house development doesn’t automatically mean it’s good
- Concrete approaches to challenges matter more than ideology
- Creativity and judgment are what engineers need in the AI era
- Scrum development is a given, but is it just a formality?
- IPO is a means, not an end
- Hiring is an act of being chosen
- Boasting about average tenure or unit price doesn’t impress
Hiring should be the last resort
I often get the impression that many workplaces easily choose the approach of "we need more people, so let's ramp up hiring."
As stated in the Scrum philosophy, increasing headcount should be the last resort, not the first step.
Especially in Japan, where regular employment often implies lifetime employment, this is a very risky choice compared to overseas.
That said, opting for contractors, side jobs, or interns brings long-term challenges such as smooth communication and company growth.
Hiring decisions should be made from a multifaceted perspective, considering the company's condition and phase.
Sometimes I see cases where teams try to solve performance issues by hiring more people.
In such cases, rather than adding (hiring), it’s often necessary to first subtract.
I won’t go into details about what "subtracting" means here, but if the state is poor, you need to identify the root causes, address those issues through subtraction, and then add.
Subtraction might involve painful improvements that cause some loss.
But why do we work? Why does a company exist?
It exists to quickly provide high value to end users; it’s important not to confuse means and ends.
Narrow and deep scope
Sometimes I see job postings shouting "Tech Lead Wanted!"
When you check the requirements, it says things like "Please handle team building, project management, development, training, everything!" which is intimidating.
On top of that, they write as if the role comes with huge discretion, which surprises me.
I believe mid-career hiring is about bringing in people to fill missing pieces that can’t be fixed by training.
If you’re recruiting with an extremely broad scope, it means your company lacks everything.
I personally strongly question what kind of winning strategy such a company has.
One person can only do so much; superhuman engineers are rare in the market.
Just like frontend and backend engineers have clearly defined scopes, smooth development happens because roles are well divided.
There are also many postings for full-stack or full-cycle engineers, but is that really what your company needs?
It’s important to post jobs that optimally fill the specific missing pieces.
Are you truly committed to the product?
I personally think it’s very important whether you are seriously committed to building the product.
A company is a place where you spend a significant part of your life.
Life is a one-time experience, so I have no intention of living it carelessly.
While I don’t consider myself a highly skilled engineer, I do believe I have strong passion for craftsmanship.
If you’re going to do it, do it properly; if you’re going to do it, do it seriously. Otherwise, it’s disrespectful to the company and ultimately the end users.
I think engineers who care about psychological safety, smooth communication, and maintainable project design tend to have strong inner passion.
Technical nerd types feel somewhat different to me, based on my experience.
I believe such passionate types are the ones who change companies for the better — I’ve witnessed this process several times.
While working as a frontend programmer, I have also served as a Scrum Master for team building and as an Engineering Manager focusing on company-wide improvements.
When I bring that passion, it’s disappointing when the company side pulls back or senior roles lose interest.
Being cool is fine, but do you really want to promote the product and make an impact?
Doing it seriously is a given, but it feels like a minority view, which is sad.
How clear and concrete is the company’s roadmap? How persuasive is it?
If the commitment is strong, many people will naturally follow.
Being in-house development doesn’t automatically mean it’s good
Compared to in-house development, SES (System Engineering Service) or contract development often feels a bit tougher.
Especially for engineers with high technical skills or strong communication abilities, lack of discretion is quite tough.
Engineers are creatures who want to argue "I want to do it this way!" or "It should be like this!" and dislike having their choices restricted.
If you create an environment where engineers can’t think that way, it becomes a top-down organization.
In that case, you might as well hire yes-men who have given up thinking — I don’t personally think that’s a bad thing.
But when hiring highly skilled engineers, that won’t work.
In venture-style in-house development, questions like "What is right?" and "How can things proceed smoothly?" are important.
With limited funds and stamina, bottom-up approaches are also vital.
Good engineers tend to seek such environments; it’s natural to find meaning there.
Therefore, you shouldn’t be complacent just because it’s in-house development.
Having discretion is not a bad thing; such engineers will deliver value beyond their salary.
Concrete approaches to challenges matter more than ideology
Recently, I’ve noticed many companies strongly emphasize their mission and values.
Personally, I think corporate philosophy emerges naturally from the roadmap and is only a result.
When a company says, "Our mission is this!" it’s not bad at all.
But empathy toward mission and values tends to be vague and somewhat risky as a direction.
What’s important is how concretely you are practicing that mission and whether you can agree with those actions.
Creativity and judgment are what engineers need in the AI era
Even in Japan, where AI adoption is slow, engineers are increasingly expected to be able to utilize AI.
AI improves development speed and product quality, and the demand for engineers themselves is gradually decreasing.
Yet companies still need engineers not for coding ability but for optimized craftsmanship and proper evidence-based decision-making.
In other words, product creativity and extensibility, project decision-making, and team building cannot be fully replaced by AI and likely never will.
As a result, engineers with broad but shallow knowledge are being phased out, while specialists with deep, narrow knowledge in specific scopes survive.
Conversely, companies will need only such engineers, and engineers themselves will want to chart their roadmap accordingly.
Whether you can provide such an environment and a future-oriented vision is becoming a requirement in hiring.
Scrum development is a given, but is it just a formality?
I feel that terms like Agile and Scrum are being used lightly these days.
Especially in hiring, HR people who don’t understand say things like "We do Agile development" as if it’s a magic word.
I have no intention to talk about Waterfall now, but there are too few engineers who truly understand Agile.
One major reason why development speed doesn’t improve is that no engineer understands the correct development system.
Disputes about engineers’ commuting or remote work also relate to this.
No engineer would join a fully on-site workplace these days.
With Scrum as a premise, two days a week in the office is the upper limit (actually even that is tough).
There is no need to come in more than that.
If team members properly follow Scrum principles, full remote work should be easy.
In fact, when I served as Scrum Master in a past project, it ran smoothly with no problems.
Despite technological innovations in recent years, full on-site worship is still common, which is incomprehensible to engineers focused on optimization.
What matters is not physical communication but creating a culture that flexibly adapts.
Re-understanding Agile and Scrum and embedding it in the team is essential — without that, progress in this era is just a dream.
IPO is a means, not an end
Sometimes when talking with startups, I hear "We’re aiming for IPO for now."
But IPO is a means, not a goal.
There’s nothing special about achieving IPO.
Most engineers probably don’t care whether the company goes public; I just think "Oh, okay" when I hear that.
What matters is what you want to achieve after IPO, how you use the funds, and how you leverage the position.
If a founder is serious about making an impact, IPO is just a milestone on the roadmap.
Talking about aiming for IPO as a selling point feels somewhat off to me.
Hiring is an act of being chosen
I hesitate to say this loudly, but it’s very important for those hiring to adopt the stance of being chosen.
For example, when sending scout messages on platforms like Wantedly, the recipient is the customer.
If you genuinely want them to join, your message won’t be generic.
When I’m asked technical questions in interviews, I have published my technical skills on OSS and my blog.
I also share my personality and way of thinking on my blog, and I always want to meet face-to-face after that.
Of course, I thoroughly research the company and profiles of people I might work with before interviews.
This is natural; it’s not about who’s superior or inferior.
It’s simply about whether you can become part of the company or not.
Hiring is a stage to present the company — nothing more, nothing less.
Misunderstanding this will clearly cause problems later.
Boasting about average tenure or unit price doesn’t impress
Rarely, I hear companies boast "Our average tenure is high!"
Personally, I wonder, "Why would you promote that as a positive?"
Long average tenure isn’t necessarily good — just look at GAFAM.
Average Tenure at GAFA and Semiconductor Companies
Skilled engineers always seek growth and change; they are creatures of constant thirst.
Because of that thirst, they move to the next project after completing one; they live for challenges.
What freshness can you get from a team with the same members for years? I seriously doubt it.
So this turned into a very long entry after a while.
I think it’s full of my personality, but there’s still a lot to talk about.
If you find any of my views or attitudes relatable, please feel free to contact me via the contact form.