3 ms·

I don't think you're wrong. But could you define talent? That's something that bugs me endlessly. Talent gets thrown around recklessly everywhere. Is talent sma

I don't think you're wrong. But could you define talent? That's something that bugs me endlessly. Talent gets thrown around recklessly everywhere. Is talent smart and gets stuff done? Is it more than that? I feel pretty confident I can identify "talent" but the blog post you are responding to isn't written for me or you, it's written for people who are already doing things the wrong way and content with it. We say hire for talent as though talent is self explanatory. I don't think it is. Maybe we generally feel like we know talent when we see it but that's not satisfactory advice if what we aim for is to give advice to people who struggle to hire good people. If you are the kind of person who hires for X years of experience you probably aren't the kind of person who feels confident identifying talent outside of a solid definition.

bobwaycott 14y ago
> We say hire for talent as though talent is self explanatory. I don't think it is. Absolutely true. A sibling comment[1] mentions an approach that is a bit closer to what I'm getting at. I personally hate trivia-ish questions when I've been interviewed and have attempted to eschew them when I've interviewed/hired. I try to focus more on questions that give me an insight into how a person thinks. So, I tend to refrain from asking definitional questions, and instead, opt for questions that can't be answered with a parroted statement of "X is like Y for Z." > But could you define talent? Heh. That's so subjective, isn't it? I try to gauge talent in programmers by listening to how people reason through problems. Generally speaking, I look for the ability to confidently walk through how they'd approach identifying and resolving a bug in a software package they know nothing about (say, because they've just been brought into a product team with a 2-yr-old codebase), or how they'd tackle architecting a complicated data-heavy backend, or what kind of pitfalls they'd be mindful of in defining UI/X for a mobile application, etc. I am wary of developers who start talking about programming languages and frameworks as solutions to higher-level, abstract concerns. That is, given the problem of integrating systems X and Y, hearing Ruby, Python, Django, or Lift as part of the solution before it's appropriate to discuss a stack. I'm also very circumspect when new developers join a team and advocate for technology/language/framework X to solve problem Y, when X is the thing they used for n years before joining the team. I also try to tease out a person's decision-making abilities. This has been a much more difficult talent to assess. I've seen a lot of inability to assess a problem and summarily decide how to appropriately move forward--that is, the kind of person who gets too bogged down in talking through a problem, and is unable to make a decision on how to actually get started solving it. I've found a team is highly unproductive when there isn't at least one person who is able to codify the team's thoughts on a problem into a pragmatic approach to get work done--especially when they lack management figures who know enough to help make informed decisions. > If you are the kind of person who hires for X years of experience you probably aren't the kind of person who feels confident identifying talent outside of a solid definition. Certainly. Which is why I suggested a better approach is to focus efforts on those who are in hiring positions (be they HR professionals or otherwise) who could use the help and input of someone who is able to confidently identify talent. [1]: https://news.ycombinator.com/item?id=5441632 https://news.ycombinator.com/item?id=5441632
kyllo 14y ago
"Hire for talent, train for skill" means to screen for more general intelligence and problem-solving aptitude rather than specific buzzwords. You want smart people who will pick up anything you throw at them quickly, not just people who have hit all the keywords in their resume. It may sound squishy, but it's really not. You can tell smart people pretty quickly from talking through logical problems with them. Dumb people will ask irrelevant questions and want you to hold their hand and walk them through it. Smart people will ask smart questions and deduce a path to the solution.

bobwaycott 14y ago

> We say hire for talent as though talent is self explanatory. I don't think it is. Absolutely true. A sibling comment[1] mentions an approach that is a bit closer to what I'm getting at. I personally hate trivia-ish questions when I've been interviewed and have attempted to eschew them when I've interviewed/hired. I try to focus more on questions that give me an insight into how a person thinks. So, I tend to refrain from asking definitional questions, and instead, opt for questions that can't be answered with a parroted statement of "X is like Y for Z." > But could you define talent? Heh. That's so subjective, isn't it? I try to gauge talent in programmers by listening to how people reason through problems. Generally speaking, I look for the ability to confidently walk through how they'd approach identifying and resolving a bug in a software package they know nothing about (say, because they've just been brought into a product team with a 2-yr-old codebase), or how they'd tackle architecting a complicated data-heavy backend, or what kind of pitfalls they'd be mindful of in defining UI/X for a mobile application, etc. I am wary of developers who start talking about programming languages and frameworks as solutions to higher-level, abstract concerns. That is, given the problem of integrating systems X and Y, hearing Ruby, Python, Django, or Lift as part of the solution before it's appropriate to discuss a stack. I'm also very circumspect when new developers join a team and advocate for technology/language/framework X to solve problem Y, when X is the thing they used for n years before joining the team. I also try to tease out a person's decision-making abilities. This has been a much more difficult talent to assess. I've seen a lot of inability to assess a problem and summarily decide how to appropriately move forward--that is, the kind of person who gets too bogged down in talking through a problem, and is unable to make a decision on how to actually get started solving it. I've found a team is highly unproductive when there isn't at least one person who is able to codify the team's thoughts on a problem into a pragmatic approach to get work done--especially when they lack management figures who know enough to help make informed decisions. > If you are the kind of person who hires for X years of experience you probably aren't the kind of person who feels confident identifying talent outside of a solid definition. Certainly. Which is why I suggested a better approach is to focus efforts on those who are in hiring positions (be they HR professionals or otherwise) who could use the help and input of someone who is able to confidently identify talent. [1]: https://news.ycombinator.com/item?id=5441632 https://news.ycombinator.com/item?id=5441632

kyllo 14y ago

"Hire for talent, train for skill" means to screen for more general intelligence and problem-solving aptitude rather than specific buzzwords. You want smart people who will pick up anything you throw at them quickly, not just people who have hit all the keywords in their resume. It may sound squishy, but it's really not. You can tell smart people pretty quickly from talking through logical problems with them. Dumb people will ask irrelevant questions and want you to hold their hand and walk them through it. Smart people will ask smart questions and deduce a path to the solution.