Get ready for a bit of a ramble about looking for a job as a software engineer in 2026.
No, it's not about AI changing the definition of software engineering in 2026. But there's obviously some truth in that.
It's about product engineering. Specifically, it's about the challenges engineers face when searching for new opportunities because of the massive shift toward product engineering.
I should preface what comes next with this: Searching for a software engineering job in 2026 is really hard. Scroll through LinkedIn or any software career blog and you'll see plenty of posts about how the recruitment system is broken, how good engineers are being ghosted, how CVs are being filtered out by AI screening for keywords. These frustrations are valid, but... you know what else is really hard in 2026? Being a software engineering recruiter. Being a software engineering hiring manager. And software engineering is about solving problems.
With that said, you can't solve a problem you don't define. So to lay the foundation, I want to address some challenges I've recognised before addressing what can be done about them.
First, the thing that's been haunting me for the last 6 months. Impact articulation.
I suspect this isn't a problem that's unique to product engineering, but it's certainly one I've faced as a product engineer. Earlier this year, I completed full interview processes with two separate companies. I felt confident about both. The roles were the type of engineering I'm great at: sitting close to users, working through ambiguity and owning product areas end to end. But neither resulted in a job offer.
The feedback I received was surprisingly consistent: I demonstrated strong technical execution, methodical problem-solving, clear communication and product judgement, and consistently sought to understand the "why" behind the "how". But also, I struggled to connect my product decisions to business or user outcomes. It was clear that I was a great engineer. But they were looking for more observable evidence of how my work "moved the needle", so to speak.
They weren't wrong. And since those interview processes, it's been a gatekeeping problem too. I suspect it's played a major part in me getting screened out before interview.
But there's irony here. Part of the reason I struggled to articulate my impact was that impact measurement wasn't a big part of the engineering culture I was working in. My product engineering practice was born out of necessity. I was part of a small team working on a complex product with a huge surface area. I owned product areas end to end because I had to, not because the company fostered a particular product engineering culture. And I thrived there because I like deep ownership, I like sitting close to users and building deep domain context. It came naturally to me.
But small teams that scale fast tend to be very reactive. A big part of our workload was building things that new clients needed for their onboarding. What was missing was a culture of defining the problem we were solving, and the metrics that would tell us if and how well we were solving it. How do you measure impact when you don't know what problem you're solving?
Impact articulation was a gap that I was aware of and was deliberately looking to address by searching for different roles. It felt a bit like being a teenager and searching for my first job all over again. How do you gain the work experience that companies are looking for until one of them hires you? Chicken and the egg.
This leads me to another challenge I've discovered: Product culture ambiguity.
Tell me if any of these buzz-phrases look familiar:
"comfortable operating in ambiguity"
"aren't just ticket-takers"
"own products end to end"
When I first started my current job search, I got excited by these phrases. These describe the environment I thrive in, right? My CV is full of descriptions about how I've owned problems end to end, fleshed out products from fuzzy requirements, worked closely with users to help define products, shipped fast and often to deliver value right away.
But job description after job description, I kept seeing these phrases. I thought "product engineering" was a bit of a niche engineering culture that was just starting to gain traction over the last couple years. Suddenly it started to feel like every company out there wanted product-minded engineers. And if that's the case, why were so many of my applications being passed up, or worse, ghosted?
Then I started asking, what do these companies mean by "operating in ambiguity"? Are they looking for engineer-magician hybrids who summon perfect software solutions into existence? And what do you give engineers instead of Jira tickets? If operating in ambiguity just means "less detailed tickets", and product engineering just means "figure it out", that's not really the environment I'm deliberately looking for, is it?
I'm being facetious, but there's some truth here. Many job descriptions give you vague expectations, without describing the environment that they provide to set you up for success. They don't describe what product engineering looks like in their organisation with much useful specificity. I very rarely see job descriptions that mention:
"product discovery"
"domain expertise"
"identifying rules and constraints"
"questioning assumptions"
"modelling the problem"
"comparing solutions"
That last one I find especially interesting. I often do see language like "explaining trade-offs". That's a completely valid expectation, and an important one. But it makes me wonder, trade-offs in what context? What's the point of explaining trade-offs if you haven't specified a problem to be solved and considered multiple solutions?
Finally, the challenge I find most dangerous: Speed ambiguity.
What does "we move fast" mean? Here are some possible interpretations:
We "move fast" and break things.
We cut corners.
We optimise for volume.
We foster a high-pressure environment.
We don't care about work-life balance.
To be clear, I don't think this is what most companies mean when they talk about speed. But there are very different reasonable ways to interpret speed:
We ship small. We scope requirements aggressively to deliver frequent incremental value that can be validated quickly.
We experiment often and learn fast. We optimise for knowledge and discovery to keep us moving forward.
Our codebase is optimised for well-defined boundaries and low cognitive load, reducing regression risk and allowing for safer agentic delegation.
I think the biggest issue is the inherent tension between ambiguous speed and product engineering itself. Product engineering requires more from engineers. Deeper domain understanding, more involvement in product discovery, more critical thinking, more observation and iteration. "We move fast" is meaningless without being clear about how.
I want to be clear that when I talk about "solutions", I'm not suggesting that I have all the answers. There are nuances to the problems, and I only have one perspective. So for me, a solution is an answer to the question:
"In the face of these challenges, how can I exercise my agency? What can I understand better, communicate better, select more carefully, or change about my own approach?"
Here's what I have done.
I (eventually) recognised that I was collapsing impact into a single concept, and as a result, I wasn't thinking critically about how to overcome the challenge. When I took a step back, I realised that there are actually three concepts.
I created impact with every decision I made that delivered product, user or business value. It certainly would have been helpful to have consistently defined the problem and decided how to observably measure the quantitative value of the solution in advance, but it's equally helpful to at least recognise that gap and take action to address it going forward. Regardless, the impact was still created.
As we've already covered, I did not measure impact very well. At least not quantitatively. I strongly believe that this is largely a symptom of the engineering culture I was part of, although I don't mean that as an excuse. I identified the limitation of my environment and took action. No point in dwelling.
Recognising the difference between the first two was the big unlock, because it helped me figure out how to articulate impact. Before, I felt like I had no meaningful way to describe the difference I made. But the reason I was able to deliver value without a more rigorous product discovery process was because I had built deep domain knowledge and understood the problems intuitively, which allowed me to reverse-engineer the impact retrospectively. That's no substitute for good product engineering practice, but it signals product thinking.
I think ambiguity is a more difficult challenge to overcome, and I wouldn't frame it as a solved problem. However, I think recognising the challenges can go a long way to mitigating them. Here are some questions I ask myself when I'm looking at roles to try and figure out if they're actually what I'm looking for:
"What evidence is there that engineers are expected to own or meaningfully participate in product discovery? What exactly do engineers own or influence?"
"How do engineers understand the domain? Is there evidence of deep domain learning, domain modelling, or working closely with users AND domain experts?"
"What is the team's definition of ready? Are engineers expected to define the problem, the outcome and what success looks like? Are outcomes measured quantitatively?"
"Does the role description consistently qualify its engineering expectations with evidence about how it supports engineers to achieve them?"
"If the team says they move fast, do they explain what fast means, what trade-offs they're making to achieve it, and how they mitigate any risks that the speed introduces?"
I think it's important to try and answer these questions, and in my experience, role descriptions don't cover them consistently. So it's probably worth reaching out to other engineers, the hiring manager or the recruiter. I have a theory that the less the recruitment materials answer these questions, the less well-defined the product engineering culture is.
If you're an engineer with significant experience within a mature product engineering culture, you may well be trained to recognise these signals already. But for engineers that are still navigating this transition, who have strong product instincts but haven't yet found the right environment, I think understanding the difference is crucial, and may go some way to explaining why applications don't get considered. I suspect that the teams who are still figuring out what product engineering looks like for them are explicitly looking for engineers who already have the experience to help them shape it. And maybe because of that, they bias toward quantitative impact over qualitative impact. I think there's value in being able to differentiate between the two, because role descriptions aren't usually transparent about where they need help, and knowing the difference might save you time and energy.
It's probably worth asking yourself one more question:
"Is this team looking for someone to participate in its product engineering culture, or to help create it?"
So back to chicken and the egg.
I think the first job metaphor summarises my thoughts about the massive shift toward product engineering cultures pretty well. Teams are moving toward product engineering. They want engineers with product engineering expertise. But how do you gain the product engineering experience they're looking for until one of them hires you?
Again, searching for software engineering jobs is hard right now. So is sourcing software engineering talent. So is deciding who to hire. But software engineering is about defining problems and then finding solutions. Maybe none of us can fix recruitment on our own, but we can each make small changes that have an outsized impact: candidates can be more thoughtful about the impact they can evidence and more selective about where they apply; recruiters can look beyond polished metrics for signs of real product thinking; hiring managers can be clearer about what product engineering actually looks like in their teams. None of that solves the whole problem. But it might make it a little easier for the right engineers and the right companies to find each other.
Which, for a bunch of people who claim to be good at solving problems, feels like a reasonable place to start.
P.S. One small thing I believe in strongly is offering a little guidance when an unsuccessful candidate asks for it. Detailed feedback isn't always practical, but a short note about what experience would make someone more credible for a future role can be genuinely useful. It helps candidates grow and companies build a stronger talent pool, while giving someone the chance to come back later having closed the gap — which probably tells you something useful about them too.