Stop Hiring Software Engineers

TIL that I am a product engineer. I identify very strongly with many of the points made in this article.<p>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.<p>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 consider myself to be one of these product oriented developers (not sure about being 10x though).<p>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.<p>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&#x27;t even mention leetcode :)

Yes, but, no. As in, I agree that you generally don&#x27;t want senior devs who don&#x27;t think at a level higher than the code level.<p>But I really hate trying to label this &quot;product engineer&quot;.<p>Stop trying to make &quot;fetch&quot; 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 &quot;because the business needs this thing for yesterday&quot;, but I think what the author is saying is: &quot;hire engineers who aren&#x27;t prone to thinking in a myopic way, but instead seek out the &#x27;why&#x27; before they think of the &#x27;how&#x27;&quot;.

&gt; if (text.trim().length() &lt;= 2) text = &quot;&quot;<p>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)<p>Maybe you do need a software engineer after all?

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

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

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.

Funnily enough, I came to similar conclusions and have been describing myself and some colleagues as Product Engineers for years now!<p>Software engineering is just a means to delivering product value.<p>In interviews I now primarily drill down on the company&#x27;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&#x27;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