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.
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.
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. :)
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
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...
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.
Product engineers generally pick mainstream languages and tools. They talk about users, strategy and product.
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.
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 and entrepreneurs get along so well because they're the same breed of people. Great entrepreneurs are often product engineers.
I don't like this sort of pigeon-holing; most developers I know straddle this divide.
"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.
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.
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?
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 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.
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.