Hacker News new | past | comments | ask | show | jobs | submit login
The Product Engineer (davidchouinard.com)
166 points by patch45 on Jan 4, 2016 | hide | past | favorite | 82 comments



Was hoping this would be about hiring, because I've been thinking a lot recently about how shitty hiring is for these people.

I've been interviewed for a lot of these ostensibly "product" positions this year. A lot of it has to do with the company not even understanding what they're hiring for. Initial screeners would be all about product, product, product, but then they'd give me a new grad programming trivia test about rearranging chars in a string. Such a weird mismatch of aspirations vs. reality on the interviewer's part, and, most importantly, I've never come away from these interviews feeling the interviewer has a solid understanding of what I might bring to the table.

I'd push more for it before leaving the interview, but by that point the interview itself has soured me on the company overall.

I think this is exacerbated in the startup world in particular, because even "straight technological" roles in a sub-10 person team will inevitably include a ton of product decisions throughout the course of fast-paced development, and I worry too many startups focus on these type of algorithmic hiring tests being some sort of qualifier for these people when it's not.


This is a very strong feeling of mine and early reviewers of the essay railed at that frustration. It's striking how much the hiring dance feels full of misplaced energy.

There's no doubt hiring for product engineers is horribly broken, and in a way that holds back the entire ecosystem.

The essay is not about interviewing, because I don't have strong alternatives to suggest.

First we need vocabulary, then we'll need process. I'm in a quest to understand how to hire for this role: I'll write a new essay once I understand it.


When it comes to these things people are going to reinvent a vocabulary that already exists: Jung's psychological functions.

What Jung called extraverted intuition (Ne) is going to be the main "product" function in tech, with extraverted sensing not as common in the industry. Ne appears in Ti-Ne/Fi-Ne/Ne-Ti/Ne-Fi (what MBTI calls resp. INTP/INFP/ENTP/ENFP). In other words, the xxxP types are going to correlate with being product people. Steve Jobs was practically raw Ne.

The stereotyped "Silicon Valley Programmer" that every company wants to hire is introverted intuition primary and extraverted thinking secondary (Ni-Te, what MBTI calls INTJ). This archetype is quick-witted and naturally good at verbal/logic challenges.

To really, really, really simplify things, with xxxJ vs xxxP, you essentially have a dichotomy between speed on the one hand and (external) depth on the other. External depth being advantageous because the world itself is external. The current standard for interviews is essentially to judge speed, so of course this has the appropriate consequences. Which, by the nature of the particular elements involved, rapidly runaway.

Speed is quite easy to see and understand. Depth on the other hand is harder to pin down. But it is depth, and the vision that often carries it, that can render fine details onto a product. Those details can be so small that most people don't see them, so general appreciation of this power is rarer, and by its nature harder to test on top of it requiring a longer time horizon to work in.

Many people will think that you can get both qualities in a single person, but it doesn't work that way. Evolution would have done that long ago if it was possible. Instead, what we're dealing with are fundamentally different brain topologies/strategies, essentially characteristics that species can min-max in individuals because of the survivability allowances afforded by their ancestors having been social. Or who knows. Regardless, these are the same types of trade offs you have in data structures/algorithms.


I remember reading that stuff as a teenager -- and afterwards, I was able to make the MBTI tests say anything I want it to say.

My later experiences with vipassana/insight meditation showed me just how much hot air those personality indicators are. You can switch among them if you know how. These are not as hardwired as people would like to think they are.

Nice try, it's a good framework, but it is fairly limited when it comes to describing the spectrum of human consciousness. Jung is interesting in that, he was a scientist having mystical experiences that he tried to scientifically analyze. Was he successful? I don't know, but I doubt he was able to capture all that he experienced.


Personality factors aren't like IQ, in that they don't try to be measures of extent, but rather tendency. Saying someone is "Thinking-primary" doesn't mean they always think, or never feel; it doesn't even mean they enjoy thinking more than they enjoy feeling. It means they fall back on thinking; or, more precisely, they think of themselves as being the kind of person who falls back on thinking rather than feeling. (Which usually amounts to the same thing; the box you slot yourself into circumscribes the habits you'll form, and then things that become habitual feel more "natural.")

Everyone on HN is pretty familiar with the introvert/extrovert distinction, and also how carefully it has to be explained lest it be confused with "outgoing" vs. "shy." The real distinction, as the 'common wisdom' goes, is about how you "recharge."

I personally think it's clearer to phrase it in terms of the contrapositive: introversion/extroversion is about what you reject when you're out of willpower. Whatever comes more naturally to you—whatever's more habitual—will "cost" less to keep on with.

And, I would say, other "personality factors" can best be described similarly. They're not how people are on average; they're what people tend toward when not awake/aware/energized enough to be engaging both complementary faculties at 100% as needed (as mindfulness meditation, or a zeroed-out sleep debt, can allow.)

And do note that most of the MBTI factors do occur separately in other personality-trait assessments, that were not created by mystics. :)


>It means they fall back on thinking; or, more precisely, they think of themselves as being the kind of person who falls back on thinking rather than feeling.

Yes, and that tendency is mutable too.

> the box you slot yourself into circumscribes the habits you'll form, and then things that become habitual feel more "natural."

You mean they feel more comfortable, and sometimes that will be conflated with feeling "natural". Habits of the mind are just that: ruts and tracks that have deepened over time with repeated actions. They can be changed, like anything else in the phenomenal universe.

> Everyone on HN is pretty familiar with the introvert/extrovert distinction, and also how carefully it has to be explained lest it be confused with "outgoing" vs. "shy." The real distinction, as the 'common wisdom' goes, is about how you "recharge."

That might be the common wisdom, but that was not how Jung or even MBTI defines introversion and extroversion.

> I personally think it's clearer to phrase it in terms of the contrapositive: introversion/extroversion is about what you reject when you're out of willpower. Whatever comes more naturally to you—whatever's more habitual—will "cost" less to keep on with.

I've been talking with my meditation buddies about this on and off for the past year. Some of them are (or were) software engineers and some of them are not. Over the past year, I've been finding that idea of introversion and extroversion is BS, but I have not looked into it deeply enough to find any good insight.

It smells like BS to me because it seems like a truism that hasn't been thoroughly examined.

> And do note that most of the MBTI factors do occur separately in other personality-trait assessments, that were not created by mystics. :)

They appear in other personality-trait assessments because Jung and the mother-daughter team of Meyers and Briggs were credible enough scientists/speakers that people forgot where it came from. I didn't say Jung was a mystic. I said Jung had mystical experiences. He had been trained as a scientist, then out of the blue, he started having experiences for ten years. He went with it and started observing it, making theories about it, much like a cultural anthropologist would when they immerse themselves into a different culture. Where did you think Jung got his ideas of archetypes and collective unconscious from? He observed them directly and called them such. It's really funny to me how "mysticism" has become such a dirty word and used for name calling :-D


This is a really interesting analysis. Has it been expanded into more detail anywhere? Can you suggest references that map onto programmers, founders, product engineers, etc.?


Not to my knowledge. It's very easy to fall into twisted Escher boxes and ego traps when talking about these things so I try to only entertain them lightly (says my ego), and I don't know if this kind of thing is discussed in "official" psychology/sociology.

At its core it is about raw physical "existential modes" and not the more superficial label of "personalities", and it's very hard to appreciate what that means even in the case where you think you know what it means. Like if you're a trained psychologist. Certain drugs might be windows into our fellow humans' worlds. Other than that, strokes and other forms of brain damage are the only cases I know of people that have experienced multiple "existential modes". For example[1].

I think in terms of hiring, the broad strokes are useful but I wouldn't dilly dally with the specifics too much since they can be misused easily, nevermind all of the other variables in play. And as far as I know there isn't really a central place on the internet that describes the scheme as a whole. Dilly dallying through MBTI forums was one of my pastimes in ages long past and that might be the way to make sense of it today, keeping in mind how slippery things get when everyone's self is involved.

[1] https://www.ted.com/talks/jill_bolte_taylor_s_powerful_strok...


I interviewed at many of the large tech firms this fall, and I've found that Google's UX Engineer ladder did the best job of asking questions I should reasonably be expected to know without getting too hung up on an "algorithms" or "CS fundamentals" screening.


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 to see if they can ask the right questions.

I'm not looking for a UX expert but more someone who thinks about the process and end result as well as a nice way to implement the code side.

I'd ask programming related questions as well but if (when) I hire I want someone who thinks about the end user experience while they are developing, I don't live in a world where a job comes with a 400 page spec and neither would they.

I take the view that I'd rather have someone who can think about how the end system will work than someone who knows ever single API for whatever language I'm hiring for, one of those you can find on google in 30 seconds the other not so much.


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.


That's an interesting way to distinguish them, though I've seen people change from one to another. Motivations can change in a person.

I'm currently in the process of teaching one of the agency devs we hired on contract how to think with the end-user in mind. At the same time, I've tried to teach other how to reason through things from a purely technical perspective.

"Product engineers generally pick mainstream languages and tools." <-- going by that characterization, a "product engineer" will miss out some strategic advantages that comes from learning non-mainstream languages and tools. This is coming from the idea that, say, there are powerful abstractions and concepts that can be applied broadly, including UX.

For example: Promise Theory is a formal language for describing intentions and a powerful framework for creating cooperating agents in the context of uncertainty. It is typically applied to configuration management, infrastructure and microservices, but it can be applied broadly to human-to-human and human-to-machine interfaces -- literally, UX. For example, knowing that humans will typically assess trust in an iterative way, you can pick apart the entire user flow in terms of the perceived (implied or explicit) promises (user expectations) the product makes. It starts from the advertising (signaling), through user signup, through onboarding, and any useful impact that product makes. It extends through into support and infrastructure scaling, and back to the user signaling to other users that, hey, this is a useful too.

Another huge aspect that conception of the product engineer misses is strategic thinking. Strategic thinking is the art of making decisions in face of uncertainty. Engineers typically don't think strategically, usually thinking in terms of relative advantages instead of strategic advantages.


What differentiates a "product engineer" from an entrepreneur†? Lack of ambition?

Insofar as I fit all the criteria you're listing, those traits are all things that push me to want to work on a small, independent product where I can dictate the vision for it. If I'm willing to "learn programming somewhere along the way as a necessity" to express that vision, there's no reason I won't also decide to learn how to start and run a business "along the way, as a necessity."

To put it another way: in the games industry, the "product engineers" there are called "game designers." Game designers don't generally work as freelance consultants, or put themselves on the market as employees for companies like EA or Sony to snatch up. Instead, if you have the actual vision required to come up with a decent game, you'll make it—and sell it—yourself, either as a one-man show, or by starting your own small games company.

The only game designers working for the big games companies are the ones that grew into that role from whatever they got hired to do (usually either programming or art)—and, even then, only embraced their roles once the company decided to start letting them come up with products "from scratch" that they could basically run as their own little ventures, rather than just stewarding along some existing product of the company's.

---

† I say "entrepreneur", but not in the typical HN meaning of the term. Most "startup founders" I ever hear about seem to be either pure-engineering types who just think about cool tech all day, or pure-business types who think about what'll be profitable all day and follow trends. Entrepreneurialism seems to actually be much more common outside Silicon Valley in regular-old small businesses, where someone with a "product vision" like "feeding people really weird pizza" will get a loan and set up a pizza place to fulfill that vision.)


Product engineers are entrepreneurs in waiting who have yet to find product-market fit with an idea of their own. They've typically tried a few times, but haven't yet won at the startup roulette.

Product engineers and entrepreneurs get along so well because they're the same breed of people. Great entrepreneurs are often product engineers.


And what of those who are motivated by technical problems and by user needs and business strategy? Is it impossible to learn programming because of an interest in computer science or in the challenge of programming for its own sake, but learn product and strategy as a way to put those skills to impactful use?

I don't like this sort of pigeon-holing; most developers I know straddle this divide.


The definition for generalist engineers is relatively new. I consider myself a full stack engineer motivated by product problems.


I think of it like this, roughly:

"Full-stack engineer" describes a person's technical knowledge: comfortable doing front-end or server work, maybe comfortable designing whole things from scratch.

"Product engineer" describes a person's motivations: primarily interested in writing code as a means to making a product, or improving a product.

Lots of engineers are primarily motivated by writing high quality code, or very performant code, or prefer to write tools (libraries/frameworks) over writing products using those tools.


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


If the product engineer doesn't implement, why is engineer in their title? Is it just a rebranded UX Designer? Is it a glorified Software Architect?


She engineers the product, but doesn't lay the bricks. The product is not just the software.


You're begging the question. What does "engineering the product" mean? Software engineers are not civil engineers, there are not professional standards for what this means.


Fair point, there's no formal or widely accepted definition for Product Engineer.

In Roman languages, the word "engineer" derives from the word for "wit" (e.g. "Ingeniero" <- "Ingenio" in Spanish); hence there's a mental connection to identify an engineer as someone who uses her wit to solve problems. The Product Engineer hence uses her wit to solve Product issues, that could range from technical issues to manufacturing, materials, distribution or even marketing issues. She has to have a more holistic and less deep view of multiple areas, a la Project Manager.

Now you'll tell me that I'm talking about a Product Manager and I'll have to agree. In my opinion, a Product Engineer is a different name for a Product Manager. Product Management is a really broad area and I think some people more inclined to technical stuff and especially software development would feel more at home being called Product Engineer than Product Manager.


So here's my problem with this. There is no bricklaying in software. If something is really repetitive and mind-numbing it should be automated. That is the difference between software engineering and engineering/construction—the computer does all the rote work.

I get that there are amazing semi-technical managers and UX people who add outsize value even though they don't code—I don't subscribe to the SV worship of "hard skills". However, SV is also full of jackass wantrepreneurs who think they don't need to learn how to code because their singular vision is so valuable. These "idea guys" are the antithesis of what it takes to build a successful startup, and I worry that defining Product Engineer this way just gives them another place to hang their hat and further their own preciousness.

"Engineer" should be reserved for someone who codes or at least administers technical systems hands on. I'm well aware that traditional engineering disciplines look down their nose at programmers for declaring themselves engineers with such informal practices, but nevertheless software engineering is a thing with its own challenges (in many ways more difficult than physical engineering due to the breadth of scale and lack of constraints). Why do we need to water it down when we already have terms like Product Manager or UX Designer?


Wow. Just wow. This hiring process is so refreshing it actually makes me want to work for you, and I'm only half kidding. Are you hiring? ;)


Unfortunately not in the near-term but nice of you to say anyway :).


Well, nice of you to give me hope that some people appreciate and even seek what I think I'm good at. :) I am quite happy where I am now anyway. Wish you luck!


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 they might not be a glamorous interview question — will be much closer to what "real" work at the company will be.

Put another way: I've probably done a dozen or two product interviews this year, and have still never seen a full stack web request. I mean, I haven't seen a controller action, or a view, or even a model for that matter. And that's the area that's my entire job, really: I build screens and hook things together and make things work for users. As much as feasible, I'd like to be able to demonstrate those types of talents in the interview process.


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.


That fits -- it's difficult enough to recruit people, let alone people that you can work with, or building out a gelled team that can work through on a lot of challenging things (and not all those challenges are technical).


I had one of these "pair" things by a startup touting how different their process was. It consisted of two developers doing work while I solved a thinly-veiled CS101 interview question alone, on a setup I wasn't familiar with, in an editor I couldn't change. I tried to ask questions but the typical answer is "we really cant help you". I'll take the whiteboard, thanks.


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.


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 would do on a Google algorithms quiz.

This mismatch was part of what motivated me to build MakerSlate [1], a résumé optimized for just this type of creator.

1: https://makerslate.io


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 what it can't easily grow into, and set a vision that is well beyond what the masses point at. And you also have to know the industry enough to know how to build things that make sense to end users.

In maybe 80% of the jobs I've had, non-technical product managers have been probably the single most powerful force to get me to leave an organization, because I always get very invested in a product and want to see it do the right thing, and I want to work on and design the right things. Working on the wrong things - features nobody is going to use, features that won't work, features that don't take advantage of a great opportunity or make a product great to use - can be demoralizing. I want to work on the thing that will make the most difference -- and then be able to witness that difference in hearing those stories from userland.

And the second you take the design out of it (and reduce software down to implementation), for me, the fun parts are gone (unless there's some heavy C.S. or architecture parts, which in CRUD stuff is rare) and it's just implementation.

Also - I will say, having done it, product management is always one of the most misdefined and potentially most disliked positions from the outside. It's the easiest to please no one while still trying incredibly hard to do the right thing, and probably the most important make or break function - because a company is totally viewed by what it decides to create. Further, a good PM can be made powerless if he can't get engineering do anything, and frequently organizational lines are set up so that he cannot. It's a position that needs to be elevated because it's so important, but instead almost gets lumped in with project management and viewed as easily interchangeable; the result is bad PMs make it hard for good PMs to get any respect. There's a huge standard deviation.

Product management can also get in a bad spot when you give a few people absolute product control, and you ignore the ideas from developers and others throughout the company. So even if you are in this spot, and it's respected, you have to give voice to the entire company and try to focus sometimes hundreds of laser beams all pointed in different directions.

The C.S. I majored in was about designing things, a lot of software engineering is about implementing features out of canned components other people have already designed. I think there's a lot of lost possibility in that, and we should encourage everyone to be more creative and blur the lines more in how we define software positions.


> 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 what it can't easily grow into, and set a vision that is well beyond what the masses point at.

Customers tell you what their problems are but they're not trained in telling you the solution. The mistake that's often made is that customers tell you their problem in the form of a solution. The role of the PM is to then take the solution, reverse engineer the problem out of it and then work with the team to figure out the true solution.

Where the technical/non-technical split lies between the PM and the engineers can vary. Ideally, the PM is technical enough to come up with new possibilities on their own and understand the technical implications and tradeoffs of each possibility but not every PM has the background or inclination towards that. The next best thing is that the PM works closely with the engineers to communicate the user goals and trusts engineering to find clever solutions to those goals. But the worst is a PM who thinks they're technical enough to come up with features and then steamrolls over engineering objections over the implementation.


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.


Yep, definitely. As a really bad analogy, if you are in the ice cream business and ask a customer, they will recommend you changes in flavors, but if there was, say, a huge chance in a new kind of popsicle, they'd never tell you about that. There's also a dichotomy between the things they'll ask for and what you need to get them to stay with you, or get other users sold. You can make an existing user really really happy (which I approve of), but in doing so, you might not be expanding market. Just trying to retain them is not a good solution, but there's a balance there.

But yeah, the customer is not usually going to tell you the world takeover strategy.

I kinda wrote something about that here - http://michaeldehaan.net/post/118860078737/the-rockpaperscis...


Your article is spot on. I agreed with all the different product management strategies. I was going to make the argument that building what the users tell you they love is great when that thing is making you money. However you made the point much more eloquently in your article. That's a nice read. Thanks for the link.


I love this. What a great idea.


Product Engineering as a role is also critical in hardware companies, where discipline-focused engineers such as mechanical, electrical, firmware, etc. need to implement the features of the product. Many times, they fall into the trap of making an impressive feature set work and then thinking they can start selling the product.

What is missed are critical design elements such as:

- Cost of materials/assembly

- Power consumption and distribution

- Reliability of the system

- Durability of the system

- Supply chain integrity and robustness

- ...

It seems that a lot of the new robotics companies and many KickStarter projects fall into this trap: under-budget the product development, both in time and resourcing, and release their product prematurely.

This is all quite obvious to people who have participated in successful consumer or enterprise hardware companies, but young companies are still vulnerable. Advice would be to get it all working as a prototype, then, expect another major project of turning it into a Product before releasing.


Hardware teams have been explicit about this role for a long time. I wish I had first-hand experience of hardware product engineering, but it's certainly an inspiration for this essay.


I consider myself as a product engineer too and the traditional interview process is definitely broken for someone like me. I think @holman nailed the current interview process with this statement "I need to figure out hidden knowledge that the interviewer knows already". I'm glad to know there are others who share my frustrations.

Having said that, I think for my next interview I am going to go in telling them who I am. I will own the Product engineer title and let them know what a Product Engineer is and what we excel at. If that is something they are interested in then we can continue otherwise it will be a waste of time for everyone.

If I were to design an interview process for someone like me I would come up with a simple product. It can be something as simple as a List web app ala Trello. Then have them design the product for individual use, then layer on collaboration requirements and then layer on sharing requirements, if time permits. This will allow me to know how they think about the product. If they suggest collaboration when designing for individual use then that's awesome because it tells me they are already thinking about where the product can go.


Kudos on hitting the ethos behind product first engineers who build w/ code for the love of creating things rather than just the code. Code is the tool you wield to build great things, not the only source of beauty.


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.


Does anyone have any advice finding these roles? Most of my main projects have included me building products up from the ground up with successful releases. I've been cramming technical interview questions because its seems like the only foot in the door, but this kind of position is where I know I'll thrive.

Where do I look for Production Engineering positions? How does a new grad w/ a CS background move into one of these roles with relevant experience?


If you want to work at a startup, the earlier they are they more likely that every engineer is a product engineer. The bigger companies get, the less generalists are relied upon.


I'm in the throes of this right now, but I think product manager is close. Read the job description to see if it errors on the side of programming.


I recently wrote about the gap between product-motivated and technically-motivated engineers: https://medium.com/@ericwleong/the-product-technical-spectru...

Certainly startups are interested in hiring engineers motivated by product, but technical interviews obviously don't look for that.


I've had plenty of product based experience but found the person interviewing doesn't seem to realize that he should be pitching why I need to be there.

As an illustration of how clueless these recruiters are they start off by asking technical interview questions. I just say 'im sorry didn't know you relied on rote memorization to build your product'


> And the technical interview falls flat. The product engineer isn't intrisincally interested in software — programming is merely the tool for maximal leverage on the world.

Yes... but we can't let you off the hook too much. I consider myself a Product Engineer as well, but to be able to creatively evolve a product you need to have some serious professional tools under your belt and many of these are technical, I'm afraid.

To use his analogy: "Song designers are musicians first." I wouldn't trust a song designer that couldn't answer some of the relevant technical questions.

There is a very real question as to how to recruit and interview well. This self-proclaimed "Product Engineer" claims "I'm the test case you want to turn green," but the real question is: how can we tell he's the real deal from the next guy? (Hint: it isn't JUST take his word for it.)


The core point of the essay, that product design is a different skill to software development, is obviously true, but to me this feels a bit like the title "Software Architect" was 10 years ago; i.e. people who want to design software products without the pesky whole writing software part.

Like being a dev manager, defining the vision, design, etc requires a different set of skills from development. However, a person can do those jobs much better if they have spent time in the trenches. They understand costs and tradeoffs better, can better sell the ideas to the team, and so on.


Let me give you a counter-point. I was hired by my current employer as a software engineer. I love writing software. Unfortunately, in our team, we didn't have anybody who was good at managing product development. Features where thrown in willy-nilly, design often not well thought through because designers weren't given enough time and developers could just go develop.

I was/am the worst Software Engineer in the group (these guys are seriously awesome), so they had me take over product management and only spend part of my time coding.

I'm not an 'architect', I don't design the technical systems. I design the product systems, and implement features along with the rest of the engineers, but my time is split between managing the product and doing the development.

I fell into the role because I like considering the user/marketing/etc as well as doing the software development.

I've been putting "Product Manager/Software Engineer" on my email signature because I didn't know that "Product Engineer" existed..

As I work for a technical organization, I think they'll appreciate the product engineer label more.


I agree with you. A product manager doesn't need to be a great developer - they just need sufficient experience with development to assess the impact and complexity of changes, and to better understand where there might be opportunities. You have that plus passion for the role, which is a rare combination. Hopefully your employer recognizes the value of it!


The clearest way to see the difference is how natural the product engineering phenomena is — it's been happening and we just need a name.


As a candidate you might have better luck with companies that embrace Holacracy [0]. On the recruiting side, I have a hunch that the best way to get more Product Engineers is to have the Product Engineers in your org conduct interviews in addition to the pure technical ones. A requirement for this is that the Product Engineer's title is made explicit, otherwise "wtf, why is this person always doing the interviewing."

[0] http://www.holacracy.org/how-it-works/


A friend had sent this link. It dawned on me later, there is an interesting intersection between that article and this one about the Product Engineer:

http://amasad.me/2016/01/03/overcoming-intuition-in-programm...


Bingo. I'm a product engineer as well. I build products in 1/4 the time of an entire team, with unit/integration tests. It's also technically correct--that is, as technically correct as it needs to be to ship, scale, and see if it gains traction.

Waste my time white boarding a sorting algorithm and I'll turn down the job (well, unless the money is insane).

But designing the flow/architecture of a new product idea? That's my catnip. I'll white board THAT.


So... isn't that an architect, or UX guy (if front end)? Why do we have to invent a new job title?


Software Architect in general implies a high-level (in terms of abstraction) technical position within an engineering team. This person is usually in charge of the design of the software, as in "use a queue here instead of a database", "this data should not go to the UI, but instead be requested on demand", "here's what the API should be for these 2 components to interact". You wouldn't expect a software architect to be particularly knowledgeable about business needs and users.

UX positions are usually design centric (people in these positions usually hold HCI or Design degrees). These people usually lack the engineering knowledge to be able to quickly assess the viability and cost of the solutions they propose, and therefore work very frequently with people that have complementary skills.

I am one of those types with a mixed business/engineering skillset and work in Product Management these days.

The "Product Engineer" as described in the article seems like a great position for a small company, or for a small team within a company. It's what a founding CTO would usually do at the early stages of a company.

In my experience, as companies grow, it's hard to know both the customers, the users, and the technical details in intimate detail, so the position seems slightly doomed unless the product is very technical (say, mostly an API).

That being said, broad skillsets can be a blessing when things need to move rapidly.


It's a lot of things. "Product Developer" captures it quite well. You're going from 0 to ShipIt with minimal bottlenecks.

"Isn't that just an architect?" Except you're not a silo'd backseat driver–ahem! Architecture Review Committee Member–meddling with various teams.

"UX guy?" No, you're building the API, deploying the infrastructure, setting up the DB, and then consuming all of that on the front-end.

"A full-stack developer?" Except full-stack developers are usually weighted heavily to one side, or they get pigeon-holed on Day 1 wherever the team is lacking (usually Ops. Sigh).

But "Sr. Actually-Full-Stack Developer" would be an alternate job title to "Product Developer." You need a lot of discipline (and experience) to not over-engineer a new product to death.


Product engineers are sought after, and for companies that build flag-ship products they should be core to development. Product developers are often founders and should guide the vision as they have the product itself at heart and mind.

https://data.triplebyte.com/who-y-combinator-companies-want-...


This really hit home for me. I was recently looking for a job so these ideas are fresh on my mind.

What I have been trying to figure out, is it better to work for a company that has a good product strategy, or an other wise good company without a product strategy? At the time, my thoughts were to find a company that needs a product minded developer. A company that has everything else figured out but product.


A solid product with a sketchy tech team will result in a solid company that needs some internal work to truly take off.

A solid tech company without a product is just some devs congratulating themselves on how smart they all are while they pour money out.


A company that hasn't prioritized product strategy isn't going to suddenly start prioritizing it once you get there. You are more likely to be ignored.

Go somewhere that does product well, especially if you're early in your career.


There definitely exists organizations lead by smart non-product people who recognize their shortcoming and are enthralled to support it.


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.


UX is not about polish. UX is the product -- literally, from the user's perspective. I don't think there is a meaningful difference between Product Engineer and UX Engineer.


The X in UX is Experience so indeed a UX Engineer's role would be to improve the user's experience of the product not necessarily define what the product should be. It's unfortunate that UX is being confused with Product. Let me illustrate with an example: Consider a product with 20 features, 10 of which will be helpful to the user once they have been using the product for a while. The UX engineer's job is to identify this and provide a user flow of progressive disclosure of those 10 features based on user's actions. This improves the Experience for a user by not overwhelming them with all 20 features when they are just starting to use the product.

A Product Engineer's job is to identify the 20 features because they are useful for users.


In terms of conventional job titles, that's the job of the Product Manager.


True. And I mentioned in a comment above that a technical Product Manager would be a Product Engineer. However a non-technical Product Manager would not be.


But how much technical skills do most UX Engineers have? Seems from the general consensus Production Engineers touch software more.


Everyone that walks around with a touch screen computer in their pocket thinks they are a genius of product design. But if you actually want to design products the first step is to become an expert in the code. So stop day dreaming that you're the new Steve Jobs and get coding.


Everyone that has a car thinks they're a great race car driver. But if you actually want to be a great race car driver the first step is to become an expert in building the car. So stop day dreaming that you're the new Mario Andretti and grab a wrench.

That sounds as silly to me as your assertion. And yes I can code and have for a very long time.

I'll take the person that can figure out what will resonate with users and doesn't know a line of code over a guy that can code but isn't good with products. The skill sets are orthogonal in many products. Sometimes being able to code may give you important insights that a non-coding product person won't have, but I wouldn't count on it as a sustainable advantage for all but the most complex of products (e.g. enterprise/plumbing software), and even then a great product person will figure out what they need in order to arrive at the salient product decisions.

Sometimes having the ability to code is a hinderance to building a great product.


Yes, everyone, including coders, thinks they are the best product designers. The difference is that top-level coders actually have the influence to implement their ideas, whether they're good or bad. That's how you get your foot in the door. Walking in to a startup wanting to be the one that tells everybody else what ideas they should be implementing is not going to get you far. I'm not saying that product managers are not useful, but good product managers are data driven and their main job is to gather and summarize the available data and enable a conversation within the company about the product direction, not to be the grand visionary that hands down ideas from on top.


> if you actually want to design products the first step is to become an expert in the code

I'd say the first step in designing a good product is understanding what the client/customer actually wants. That is where a position like product engineer/product manager are invaluable. It doesn't matter how good you are at coding, if no one wants the thing you're working on.


Nice.

For me it always seemed as if there are consulting engineers and product engineers.

A few of my friends are devs at agencies, who worked at different projects for many clients, those were the consulting engineers to me.

I always worked for companies who sold software products, so I considered myself a product engineer.


This is me! Feels so good to be understood. I'm currently identifying myself with product management & user experience because I recently came to this conclusion.


I wholeheartedly feel product engineers are best suited to start their own companies. I literally do not know any company that can give them the kind of experience they seek.


Thanks for making this a 'thing' as I figure out how best to position myself.


I'm in a bit of a similar position as the author.

I've been interviewing for a while now, and have had the fortune of many companies approaching me for positions after coming across my profile on HN/AngelList/LinkedIn or discovering Toc Messenger (http://toc.im).

Without exception, the next steps in the interview process for all these companies included some kind of an hour long technical interview that grilled me on my ability to solve, under severe pressure (time and otherwise), abstract algorithms and data structure problems that had no relevance to the product engineering positions they contacted me for. I haven't spent nearly as much time as some of my new grad peers on solving these types of problems, as I generally prefer to spend my time actually building things and learning new technologies and approaches to help me build things in a better way, and the difference is really starting to show.

In my experience, any half-decent developer with a proper CS education can usually solve these problems (So far, I've never encountered a single problem I couldn't solve within an hour or two in the zero-pressure setting of my own dev environment at home, including the ones I had trouble finishing during actual technical interviews). Solving these problems quickly, however, is a skill that tends to come with practice. [1]

Practice is unfortunately something I sorely lack at the moment, but that's been improving lately due to the sheer number of these interviews I've done so far. However, I still don't plan on spending any time outside of actual interviews to begrudgingly improve a skill that I'll maybe get to use a handful of times throughout my career when I need to switch jobs.

Software development is a seller's market right now, and there is no shortage of companies that want to hire great developers. To those who want to interview me in the traditional way, I'll gladly play along with your flawed process, but please note that this process is very good at weeding out product-focused developers like me. And if you do weed me out this way, no hard feelings, because I'd at least gotten the extra practice I needed to beat this flawed system.

[1]

There are exceptions, of course. I have a few friends who seem to have a natural gift and interest for these types of problems, and most of them are working at Google/Facebook right now after acing all of their interviews and receiving multiple offers. But in the large majority of cases, the people who ace your traditional technical interviews are the ones who have spent countless hours reading books like "Cracking the Coding Interview" and practicing solving technical problems to the point that they can probably solve any problem you can throw at them in no time.

I don't mean to belittle the talent/efforts of these kinds of developers or their potential value to your company, especially if you really need someone to tackle the hard technical problems in your field of business. However, I do want to question the wisdom of assuming these same technical developers will be the ones who are best able to iterate on and improve your product.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: