5 ms·

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 o

by holman 11y ago

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.

BillinghamJ 11y ago
What should we be asking/looking for/testing?
- noir_lord 11y ago
  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.
  - lucaspiller 11y ago
    This is the first time I've come across 'product engineer'. How is this different from a 'full stack engineer'?
    - system_32 11y ago
      The product engineer wouldn't necessarily (or rather, shouldn't) implement the functionality. That would be left to the full stack engineer.
      - dasil003 11y ago
        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?
        NetStrikeForce 11y ago
        She engineers the product, but doesn't lay the bricks. The product is not just the software.
        dasil003 11y ago
        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.
        NetStrikeForce 11y ago
        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.
- holman 11y ago
  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.
  - ricardolopes 11y ago
    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.
  - DavidChouinard 11y ago
    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.
    - hosh 11y ago
      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).
  - vdnkh 11y ago
bsimpson 11y ago
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.
DavidChouinard 11y ago
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.
- tokipin 11y ago
  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.

by holman 11y ago

BillinghamJ 11y ago

What should we be asking/looking for/testing?

noir_lord 11y ago
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.
- lucaspiller 11y ago
  This is the first time I've come across 'product engineer'. How is this different from a 'full stack engineer'?
  - system_32 11y ago
    The product engineer wouldn't necessarily (or rather, shouldn't) implement the functionality. That would be left to the full stack engineer.
    - dasil003 11y ago
      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?
      - NetStrikeForce 11y ago
        She engineers the product, but doesn't lay the bricks. The product is not just the software.
        dasil003 11y ago
        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.
        NetStrikeForce 11y ago
        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.
holman 11y ago
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.
- ricardolopes 11y ago
  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.
- DavidChouinard 11y ago
  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.
  - hosh 11y ago
    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).
- vdnkh 11y ago

bsimpson 11y ago

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.

DavidChouinard 11y ago

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.

tokipin 11y ago
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.