TIL that I am a product engineer. I identify very strongly with many of the points made in this article.

But I have to say I’m disappointed in the conclusion about hiring. Early in the article it teases that PEs are “easily identifiable” in the interview process. But the final conclusion is to just ask general problem solving questions and not require specific language expertise, which I’d argue most companies are already doing. Consider the classic FAANG interview - general problem solving, interviewee picks the language.

Would have loved to see this part fleshed out more because I agree with the general premise of the article and also think there are real ways to identify PEs at the interview stage.

I think the chapter named "deliver value" + the question asking is where he describes the qualities to look for in the hiring. The last part I read it as "if you keep filtering through technical stack you reduce your possibility to find these people because you will look only in a subset of the market"

I consider myself to be one of these product oriented developers (not sure about being 10x though).

Interestingly, while interviewing this has always been my bane, as the typical interviewing process goes along the tech stack and tech-related trivia (probably because it is easier to assess), and almost never towards the product side of things.

And with the tech stack questions those are always in favour who are interested in the latest version of framework X, as opposed to real world problem solving. And don't even mention leetcode :)

I've felt this a lot myself. So many interviewers hate being asked "why?"

"Why this problem?" "What is the reasoning behind this problem?"

I've learned some fascinating things about company attitudes in asking these "why?" questions. It turns out that Not-Invented-Here syndrome really can be deep enough in corporate culture you can hear it in interview questions if you ask follow up questions. ("That's just what we do, we don't trust the library solution at our scale." Cool, rewriting platform libraries orthogonal to your business delivers real value to your consumers I'm sure.~)

So I'm probably still going to ask a lot of "why" questions in interviews, because it yields useful information. But I'm painfully aware from rejections how much interviewers seem to hate it.

Yes, but, no. As in, I agree that you generally don't want senior devs who don't think at a level higher than the code level.

But I really hate trying to label this "product engineer".

Stop trying to make "fetch" happen.

I think what the article describes is something like a cousin of the X-Y problem and Five Times Why. The example given comes off like encouraging layering duct tape "because the business needs this thing for yesterday", but I think what the author is saying is: "hire engineers who aren't prone to thinking in a myopic way, but instead seek out the 'why' before they think of the 'how'".

> if (text.trim().length() <= 2) text = ""

And then they released the product in Japan and got complaints that there were a whole lot of special requests that were being ignored (because you can encode far more information in those two characters)

Maybe you do need a software engineer after all?

If those two lines remove 100 of complaints per day but add 10, it's still a net positive change that creates value. Especially since special requests were never supposed to be a guarantee in the first place.

The fact that one type of complaints get converted into another type is an unforeseen consequence. But shipping the change is still worthwhile because it's the only way to expand your domain knowledge and learn about those consequences.

The only thing missing in that code is a comment saying "temporary fix" that will still be there 10 years later.

PE in many US states means Professional Engineer, and if you use it in the wrong place, state licensing boards will come after you.

It would also be the Principal Engineer job title at various companies

In my mind it means Private Equity or Premature Ejaculater. I deal with many acronyms in my life so they tend to get a bit overloaded.

Now I might be out of the loop, but this -is- a software engineer if they're doing it right, right?

For you and me, yes. Corporations, however, decided to never promote people that can code and to create new positions, like product owner, scrum master, all kinds of managers, that will be filled with cheaper, unable to code people. My experience is that a lot of very important questions never get asked until it is too late: until a developer has to write the code.

For me, this is the difference between senior and tech lead

I couldn’t help slipping into reading this in the voice of David Attenborough. “If you look in under the jungle canopy you just might catch a glimpse of the elusive product engineer. Festooned with their hoodie and mechanical keyboard. What a rare and magnificent find!“

I took the clickbait, and found an article that renamed Product Manager to Product Engineer.

I don’t think you read the article then. It’s definitely a little clickbaity but at no point did it describe a PM

PM has always meant Project Manager in my experience, which is an entirely different job.

I would say that it is more about identifying product "quickwin": Small technical feature who solve huge fonctional problem.

I think the quick win in the example is just to highlight that the problem could have been solved by anyone with product passion

Funnily enough, I came to similar conclusions and have been describing myself and some colleagues as Product Engineers for years now!

Software engineering is just a means to delivering product value.

In interviews I now primarily drill down on the company's business model, target customers and wider organisational structures outside of the engineering team. I have found these have the biggest impact on your ability to deliver product value. Everything within the engineering team (technologies, architecture etc.) is well within your realm of influence but you're going to face a massive uphill battle if the core business model is amiss.

So, the author suggests to look out for a specific trait in programmers. To care about the essence of what they actually work on. I agree but why the need for the terminology

So they can write a clickbait article