4 ms·

Stop Hiring Software Engineers

33 points by marcobambini 4y ago

rco8786 4y ago
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.
- kaiser81 4y ago
  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"
EdwardDiego 4y ago
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.
clarge1120 4y ago
I took the clickbait, and found an article that renamed Product Manager to Product Engineer.
- rco8786 4y ago
  I don’t think you read the article then. It’s definitely a little clickbaity but at no point did it describe a PM
  - clarge1120 4y ago
    PM has always meant Project Manager in my experience, which is an entirely different job.
- aloisdg 4y ago
  I would say that it is more about identifying product "quickwin": Small technical feature who solve huge fonctional problem.
  - kaiser81 4y ago
    I think the quick win in the example is just to highlight that the problem could have been solved by anyone with product passion
zcw100 4y ago
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!“
- deleted 4y ago
  [deleted]
lexx 4y ago
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
- danjoredd 4y ago
  So they can write a clickbait article
plaguepilled 4y ago
Now I might be out of the loop, but this -is- a software engineer if they're doing it right, right?
- wwilim 4y ago
  For me, this is the difference between senior and tech lead
- GoToRO 4y ago
  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.
RcouF1uZ4gsC 4y ago
> 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?
- GoToRO 4y ago
  The only thing missing in that code is a comment saying "temporary fix" that will still be there 10 years later.
- hbrn 4y ago
  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.
mikewarot 4y ago
PE in many US states means Professional Engineer, and if you use it in the wrong place, state licensing boards will come after you.
- hotpotamus 4y ago
  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.
- Matthias247 4y ago
  It would also be the Principal Engineer job title at various companies
wwilim 4y ago
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'".
haspok 4y ago
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 :)
- WorldMaker 4y ago
  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.
wfrew 4y ago
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.

33 points by marcobambini 4y ago

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.

kaiser81 4y ago
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"

EdwardDiego 4y ago

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.

clarge1120 4y ago

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

rco8786 4y ago
I don’t think you read the article then. It’s definitely a little clickbaity but at no point did it describe a PM
- clarge1120 4y ago
  PM has always meant Project Manager in my experience, which is an entirely different job.
aloisdg 4y ago
I would say that it is more about identifying product "quickwin": Small technical feature who solve huge fonctional problem.
- kaiser81 4y ago
  I think the quick win in the example is just to highlight that the problem could have been solved by anyone with product passion

zcw100 4y ago

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!“

deleted 4y ago
[deleted]

lexx 4y ago

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

danjoredd 4y ago
So they can write a clickbait article

plaguepilled 4y ago

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

wwilim 4y ago
For me, this is the difference between senior and tech lead
GoToRO 4y ago
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.

RcouF1uZ4gsC 4y ago

> 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?

GoToRO 4y ago
The only thing missing in that code is a comment saying "temporary fix" that will still be there 10 years later.
hbrn 4y ago
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.

mikewarot 4y ago

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

hotpotamus 4y ago
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.
Matthias247 4y ago
It would also be the Principal Engineer job title at various companies

wwilim 4y ago

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'".

haspok 4y ago

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 :)

WorldMaker 4y ago
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.

wfrew 4y ago

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.