5 ms·

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.
        dasil003 11y ago
        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?
  - DavidChouinard 11y ago
    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.
    - taurath 11y ago
      The definition for generalist engineers is relatively new. I consider myself a full stack engineer motivated by product problems.
    - sanderjd 11y ago
      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.
    - hosh 11y ago
      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.
  - 6a68 11y ago
    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.
- Drdrdrq 11y ago
  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? ;)
  - noir_lord 11y ago
    Unfortunately not in the near-term but nice of you to say anyway :).
    - Drdrdrq 11y ago
      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!
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

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.
        dasil003 11y ago
        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?
- DavidChouinard 11y ago
  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.
  - taurath 11y ago
    The definition for generalist engineers is relatively new. I consider myself a full stack engineer motivated by product problems.
  - sanderjd 11y ago
    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.
  - hosh 11y ago
    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.
- 6a68 11y ago
  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.
Drdrdrq 11y ago
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? ;)
- noir_lord 11y ago
  Unfortunately not in the near-term but nice of you to say anyway :).
  - Drdrdrq 11y ago
    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!

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