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.
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.
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.
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.
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.
This mismatch was part of what motivated me to build MakerSlate [1], a résumé optimized for just this type of creator.
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.
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.
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.
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.
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.
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?
Certainly startups are interested in hiring engineers motivated by product, but technical interviews obviously don't look for that.
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'
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.)
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.
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.
http://amasad.me/2016/01/03/overcoming-intuition-in-programm...
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.
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.
"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.
https://data.triplebyte.com/who-y-combinator-companies-want-...
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 tech company without a product is just some devs congratulating themselves on how smart they all are while they pour money out.
Go somewhere that does product well, especially if you're early in your career.
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.
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.
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.
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.
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.
