by patch45 on 1/4/16, 5:01 PM with 82 comments
by holman on 1/4/16, 6:23 PM
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.
by danenania on 1/4/16, 6:40 PM
This mismatch was part of what motivated me to build MakerSlate [1], a résumé optimized for just this type of creator.
by 11thEarlOfMar on 1/4/16, 5:51 PM
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.
by palakchokshi on 1/4/16, 6:50 PM
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.
by jonathanpeterwu on 1/4/16, 6:16 PM
by tonystubblebine on 1/4/16, 7:05 PM
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.
by keepitsurreal on 1/4/16, 7:52 PM
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?
by t3hprogrammer on 1/4/16, 8:16 PM
Certainly startups are interested in hiring engineers motivated by product, but technical interviews obviously don't look for that.
by jorgecurio on 1/4/16, 8:36 PM
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'
by wellpast on 1/4/16, 8:18 PM
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.)
by matrix on 1/4/16, 8:38 PM
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.
by chejazi on 1/4/16, 7:02 PM
by hosh on 1/7/16, 8:57 PM
http://amasad.me/2016/01/03/overcoming-intuition-in-programm...
by gonyea on 1/4/16, 8:17 PM
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.
by jaunkst on 1/4/16, 8:10 PM
https://data.triplebyte.com/who-y-combinator-companies-want-...
by patch45 on 1/4/16, 5:06 PM
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.
by 10dpd on 1/4/16, 7:08 PM
by guelo on 1/4/16, 8:03 PM
by k__ on 1/4/16, 5:27 PM
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.
by pcunite on 1/4/16, 8:01 PM
by zeeshanm on 1/4/16, 8:36 PM
by pteredactyl on 1/4/16, 7:07 PM
by lewisl9029 on 1/4/16, 9:45 PM
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.