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 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!“
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
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.
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)
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.
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'".
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.
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.
25 comments
[ 3.5 ms ] story [ 61.3 ms ] threadBut 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.
But I really hate trying to label this "product engineer".
Stop trying to make "fetch" happen.
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?
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.
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 :)
"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.
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.