Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Product Engineer

essays.davidchouinard.com

Post reply on HN
Print view View original

21–30 of 85 posts

Re: The Product Engineer

#21

Post by tonystubblebine »

Do people think the product engineer can be trained? One issue I run into is one of expectations. I think product engineers are treated like some sort of unicorn (a designer/coder).

I can see why that might have been true in 2000. But a lot has changed since then.

For one, being a product engineer could be considered a hack for picking up tech skills quickly. It's often much easier to learn by doing and product engineers define themselves by the product they're trying to build.

Plus, software got so much easier to build. What is your reaction to that? Do you go deeper and more esoteric than you used to be able to go? Or do you go broader?

Broader makes sense to me--that's the product engineer. But to what end? Do you go broader in order to save on team size? An engineer/designer means you can skip a design hire. Or do you go broader because you can have more autonomy?

To me, product engineers are the natural outcome of software getting easier (and design to some extent). People can have more autonomy because you can develop the skills to get more done on your own.

But I don't think management has caught up. There's still an assumption that these skill sets don't go together. Autonomy is killed when you have specialist designers and specialist engineers.

And that's why I led with the idea about training product engineers. I want to be able to create a culture at my company that assumes that you're a product engineer. Junior product engineers just work on smaller problems.

Re: The Product Engineer

#24

Post by ricardolopes »

holman wrote: post #13
BillinghamJ wrote: post #10

Earlier quoted context omitted.

What should we be asking/looking for/testing?

It depends on the company, but I'm a big fan of pairing with a developer on something they're working on for an hour or so. The dynamics of the interview completely changes from "I need to figure out hidden knowledge that the interviewer knows already" to "I need to work with this person to find out a solution together", which I think is quite a bit less stressful. You're also working on real problems that — though t…

Completely agree with pairing. If possible, with more than one developer, to avoid possible biases.

In addition to those reasons, I also like pairing because it also reveals what kind of team player you are, and going to be if you're hired (are you just redirecting blame, are you taking any initiative, what kind of questions do you ask...). Which is one of the most underrated skills when hiring, IMO.

Re: The Product Engineer

#25

Post by lucaspiller »

noir_lord wrote: post #11
BillinghamJ wrote: post #10

Earlier quoted context omitted.

What should we be asking/looking for/testing?

I'd hand them a piece of paper and ask them to sketch out a profile page that's user friendly. Then I'd ask them how they'd design the schema for that. Then I'd ask them to sketch out the admin interface for managing users and how they'd implement that. If they start asking questions about permissions and roles and such I'd be really impressed. Essentially I'd act like a client/end user who kinda knows what they want…

This is the first time I've come across 'product engineer'. How is this different from a 'full stack engineer'?

Re: The Product Engineer

#26

Post by DavidChouinard »

holman wrote: post #13
BillinghamJ wrote: post #10

Earlier quoted context omitted.

What should we be asking/looking for/testing?

It depends on the company, but I'm a big fan of pairing with a developer on something they're working on for an hour or so. The dynamics of the interview completely changes from "I need to figure out hidden knowledge that the interviewer knows already" to "I need to work with this person to find out a solution together", which I think is quite a bit less stressful. You're also working on real problems that — though t…

In general, anything that moves the interview from adversarial to collaborative is a big win. In many ways, interviewing is a lot less about assessing skill and a lot more about creating affection between two strangers.

Re: The Product Engineer

#27

Post by system_32 »

lucaspiller wrote: post #25
noir_lord wrote: post #11

Earlier quoted context omitted.

I'd hand them a piece of paper and ask them to sketch out a profile page that's user friendly. Then I'd ask them how they'd design the schema for that. Then I'd ask them to sketch out the admin interface for managing users and how they'd implement that. If they start asking questions about permissions and roles and such I'd be really impressed. Essentially I'd act like a client/end user who kinda knows what they want…

This is the first time I've come across 'product engineer'. How is this different from a 'full stack engineer'?

The product engineer wouldn't necessarily (or rather, shouldn't) implement the functionality. That would be left to the full stack engineer.

Re: The Product Engineer

#28

Post by palakchokshi »

10dpd wrote: post #23

Reading this I'm wondering what the difference is between a "Product engineer" and a "UX Engineer"?

I would differentiate them in the following way:

Product Engineer: Focused on creating something that fulfills users' need or want

UX Engineer: Focused on polishing the product to make sure the user's need or want is fulfilled with the least amount of friction.

Re: The Product Engineer

#29

Post by DavidChouinard »

lucaspiller wrote: post #25
noir_lord wrote: post #11

Earlier quoted context omitted.

I'd hand them a piece of paper and ask them to sketch out a profile page that's user friendly. Then I'd ask them how they'd design the schema for that. Then I'd ask them to sketch out the admin interface for managing users and how they'd implement that. If they start asking questions about permissions and roles and such I'd be really impressed. Essentially I'd act like a client/end user who kinda knows what they want…

This is the first time I've come across 'product engineer'. How is this different from a 'full stack engineer'?

Full stack engineers are generalist engineers who are motivated by technical problems. Product engineers are motivated by building impactful tools. They learnt programming somewhere along the way as a necessity to show the world their ideas.

Product engineers generally pick mainstream languages and tools. They talk about users, strategy and product.

Re: The Product Engineer

#30

Post by palakchokshi »

mpdehaan2 wrote: post #16
danenania wrote: post #15

This really resonates with me. There seems to be a trend of frowning on these types as 'generalists' who don't have sufficiently hard tech skills, but 'creates great products from the ground up' is a specialization in itself, and an extremely critical one. Someone who will do (and learn) whatever it takes to put out high quality work is someone who will be a top performer at almost any company, regardless of how they…

It's a good post and a good thought. Software is a giant LEGO set with no instructions, and it takes a good mixture of how to build things and knowing what you can build. A lot of times people want to reduce product management to "visit customers, ask what they want, make a spreadsheet", but I think it's more than that. To do it well, you have to know the possibilities the existing stack could grow into, and also wha…

A technical Product Manager would be a Product Engineer but the inverse might not be true. In my mind a good Product Manager is also responsible for guiding the product roadmap in the direction that addresses user's wants rather than features that are cool to implement but don't really address a user's wants or needs.
Post reply on HN