12 ms·

Hire characters, not skill sets. My most important questions in interviews

101 points by _ak 10y ago

aegisxlii 10y ago
Agree 100%. Too much focus on happening to have encountered the particular skills you ask about in the technical grilling. Rather, hire smart people you'd like to work with (and who have demonstrated a capacity for learning).
- quanticle 10y ago
  The problem with that strategy is that all too often, "smart people you'd like to work with" equates to male, white, upper-middle-class, with a fondness for beer.
  - paulddraper 10y ago
    Probably depends on the interviewer.
  - soft_dev_person 10y ago
    So all interviewers are male, white upper-middle-class with a fondness for beer? Good to know.
    - dguaraglia 10y ago
      Not all, but the vast majority fit exactly that profile. It's not difficult to find evidence of that, just Google for <insert any of hundreds of studies and internal diversity reports by major Silicon Valley companies here>. So yes, they point about "hiring for character might bias the outcome" is still valid.
      - soft_dev_person 10y ago
        I guess, as a person not in the SV sphere, I don't really agree. Maybe I missed the implied SV context.
        Cthulhu_ 10y ago
        This is HN, a community consisting mostly of middle-upper-class white males orbiting around SV.
    - TheCoelacanth 10y ago
      If you replace "white" with "white, Indian or east Asian" then you are pretty darn close.
  - ewar-woowar 10y ago
    Or "plays golf/football, comes from a similar background to us", where gender doesn't play a role, not even in the much-reported IT industry where there is a paucity of women . As a Brit in central Europe I have come up against this, not to the same extent as someone who isn't white, or comes from a markedly different culture, but the differences in culture even between some European nations can be enough that employers do not perceive me as "one of them". What happened to hiring people who are not like us, because that's where the challenge lies and life is better when we are forced to evaluate our own misgivings? A lot of IT people are so similar in personality, skills, hobbies etc that they all fail in the same areas, not just succeed in those areas. My own work place could be better, and produce a better product, if everyone wasn't so like-minded, imo.
    - slgeorge 10y ago
      > What happened to hiring people who are not like us, because that's where the challenge lies and life is better when we are forced to evaluate our own misgivings? I think for many situations that comes down to three things: a. People who don't agree that hiring for diversity is good. While every manager knows that diversity is important (as demonstrated by their responses to HR and while on a training course) I don't believe it's as internalised as people say. Most people subconsciously have strong beliefs of how "people like us" will work together. b. Risk aversion amongst hiring managers Commonly teams have more work to be done than people available: ever known a hiring manager not in a hurry to get a new person in? Taking a perceived risk to hire someone different - whatever that difference is from skillset, gender or background - may not be rewarded when higher management want specific objectives achieved. While in principle it might be nice, pragmatism often dictates that managers go with what they know. c. Inability to measure hiring outcomes How do you measure whether more diverse teams, or occasions when you took a risk worked out? If an individual is successful is that down to good hiring, or is it just random as that particular team happens to be doing well at that moment. It's very difficult to be evidence based in hiring. Consequently, everyone has heuristics for what they think is useful, but there's not much backing it up except gut feel. For example, what evidence is there that people having a "passion" outside work and doing side-projects is inherently better ... none that I know of ... but something that lots of developers and technical managers ask about and a key reason candidates build-up profiles on Github.
  - retox 10y ago
    Why is that a problem?
  - janvoss 10y ago
    Hi! actually I am the author of the artile ;-) My team looks like this: 4 female one more to come 26 male among these 30 people i have 15+ nationalities. I am a meat lover and drink beer....I have at least 4 people that absolutely never drink and 3 of them are vegetarians. Just by following my principle "smart people that i like to work with" I created a very diverse team. I think the point is: I like to work with people who are different to me, who challenge me, who make me grow as a personality because I learn something new from them. So the key is hidden in the "that i like to work with" and in the definition of "liking someone" ;-)
- humanrebar 10y ago
  > Too much focus on happening to have encountered the particular skills you ask about in the technical grilling. I agree somewhat, but I've seen many people making mistakes, learning on the job what not to do, and making the entire team learn from their mistakes. So there definitely needs to be some technical experience at the helm of the team to make sure any technical mistakes can be corrected without undue effort. In other words, knowledge, intelligence, understanding, and wisdom are all different things. I'm very excited to hire smart, humble people, but only if my org has some defenses against well-meaning people that are trying out some new technology for the first time. And if a good chunk of the team is smart, inexperienced people, even diligent code review doesn't really cut it.
heisnotanalien 10y ago
I sort of like the sentiment but this sort of interview, at least for me, would feel a bit too personal. Look I'm not your friend so let's not pretend that's what this or you just really want to get to know me. No. You just want to know if I can do the job so just get me to do a task which meaningfully reflects what I'd be doing day-to-day then ask me questions about it.
- lexicality 10y ago
  Do you not try to be friends with your colleagues? You spend about a third of your life at work, it seems to me that you should try to make it as enjoyable as possible.
  - soft_dev_person 10y ago
    Being friends with colleagues can lead to less enjoyable work situations, not to mention less focused work. Being friendly should suffice, not all of us want to get too personal with the same people we might need to have professional arguments with. We're all different.
    - hvidgaard 10y ago
      I'll share a bit of wisdom my son shared when he was 4 or 5. In kindergarden they talked about what a friend is, and he said after some thinking: "A friend is a person you can disagree and fight with, and still play with later".
      - anjanb 10y ago
        your son is smart. he will a go way.
      - soft_dev_person 10y ago
        Getting that close to all my coworkers would be too daunting a task. Edit: Not to belittle your son's wisdom, of course. I totally agree.
reflexorozy 10y ago
This sounds like a cool idea, but I've seen where hiring for personality often leads towards hiring discrimination. I think it's more likely to reinforce the lack of diversity in tech than to combat it as people unlike the interviewer tend to be viewed less favorably and would be less likely to be viewed as a person who could pick up the specific knowledge he/she doesn't already know.
- hvidgaard 10y ago
  Maybe, but my mantra is a mix. I use standard technical questions ect. to weed out candidates that cannot do the job - I try to stay general such that I see problem solving, rather than certification. Then I'm left with a pool of people that are real potential hires. After that I'm looking for a learner with the right mindset, and THEN I'm looking for a fit - preferably someone who will complement the team, rather than reinforce what is already working. Hiring is not an exact science, and what works for me, is probably not working for others.
- slgeorge 10y ago
  Having read through it, I think he's trying to hire for fit with himself and his team. An inbuilt assumption is that the candidates are capable of doing the role - he mentions going through their CV, or perhaps he's already covered off skills. I don't think he's saying that skills to do the role aren't required: so he's not hiring graduates and then giving them the skills for the job, for example. It's a tough one, if you don't look at whether a candidate could fit within the team (in this case they care about 'passion') then you're storing up problems on the team dynamic front. On the other hand, as you point out, it's difficult to hire on personality without subconsciously hiring people you like which is often people like you: which means less diversity.
- takno 10y ago
  I feel like it's telling that he refers to the candidates as guys throughout
  - SeanCrawford 10y ago
    If you mean the article, then I disagree, for I read him as using this person, candidate, and even the gender neutral "them" in the singular. As for "guy," the word is like nation and nationalist: it must be read in context: nation can mean Kurds and Quebec, or Iraq and Canada. Yes, if you want Quebec to separate then you are a nationalist, and if you want Canada to stay whole then you are a nationalist. In talking to two women I can mention a gorgeous guy in my classroom and then ask, "Are you guys going to the concert?"
InclinedPlane 10y ago
So many people have these really bizarre and outdated (by not just years but centuries) notions about how knowledge work gets done. They want to squish it into the model of factory work, but it just doesn't work that way. Knowledge work is typically creative, the right model is an art studio, a movie set, or a band. This makes hiring very difficult, which is exacerbated by the fact that engineers are innately bad at hiring other engineers without a lot of training or carefully focused self-improvement. Knowledge workers aren't cogs, they're part of a team. You shouldn't expect that you can easily find replacement people with exactly the same skillset and propensity as someone else to make up the gap that an absence makes in a team. Nor should you expect that the proper way to grow a team is by cloning the skills of some other existing member of the team. A team works cooperatively, and their skills, talents, experience play off one another to gel together into some sort of mechanism that is capable of doing stuff. But if you change the parts, you get a different team that does different stuff, or maybe doesn't even work at all. One of the big factors here is that if you think you can replace one person with just another person you're often wrong. Best case scenario you end up with something else (maybe better), worst case scenario is you can't replace the unique factors that made the previous person successful in that role (and realistically you need a team with a different breakdown of skills, different mechanisms of interconnectedness, etc. in order to have something functional). The band analogy really helps here a lot. Realistically when you change members of a team you don't end up with something like Steve Perry stepping into the lead singer role of Journey. What you end up with is something more like Fleetwood Mac being transformed by merging with Buckingham Nicks or Genesis changing after Peter Gabriel left. You end up with a very different thing doing very different stuff. And the higher caliber the people the bigger the difference is. What knowledge workers actually do day to day and what it says on their job description they do are often very different things, and you ignore that at your peril. Hiring based on the idea that knowledge workers are automatons with certain functionality modules installed is one of the easiest and most common ways to completely sabotage productivity and execution.
- slgeorge 10y ago
  > Knowledge workers aren't cogs, they're part of a team. You shouldn't expect that you can easily find replacement people with exactly the same skillset and propensity as someone else to make up the gap that an absence makes in a team. Nor should you expect that the proper way to grow a team is by cloning the skills of some other existing member of the team. A team works cooperatively, and their skills, talents, experience play off one another to gel together into some sort of mechanism that is capable of doing stuff. Great comment, I totally agree that taking a wholly mechanistic view of how individuals and teams work is an error. You can't account for all the 'magic' that make some teams function in ways that are more than the individual parts. Of course, you're striking at an underlying fear for managers. Our jobs are to make things work immaterial of the individuals: positively a managers job is to make the system of people/process/systems work, and negatively to make sure that no individual should be so indispensable for the project/department/organisation. This mechanistic view generally works because most roles are 90% perspiration and 10% inspiration, as the saying goes. Perhaps a good mix is that when a hole is created in the team, to look at the situation holistically. As the short-list of candidates is drawn-up consider how they could fit into the mix, and how they would be additive - not the same as previously, but a new opportunity - like a new ingredient, rather than a replacement cog. It reinforces the idea of having more peers from the group involved in the hiring as this could open up a range of opinions on how the mix could change.
wimagguc 10y ago
There is always a good debate on HN about hiring, but it feels like we really are comparing apples to oranges here. Hiring tactics depend heavily on the size of the organisation. They have to: for a 3-people startup you want someone who will break walls and get stuff done, for a thousand-people-heavy dev team you need people who can do one job very precisely. Those tasks require very different personalities, so naturally, very different hiring questions.
- danieltillett 10y ago
  This applies to almost everything. The really hard problem is recognising when the heuristics that worked in the past are now broken.
ajuc 10y ago
> It surprised me that people define theirselves via their CV: “Who are you?” -> “Here is what I have done in my professional life!”. Anything weird about that? I wouldn't expect my potential employer to be interested in my family, hobbies or beliefs. So I would respond with job-related stuff as well.
- pjc50 10y ago
  Well, indeed. Traditionally those have been used to discriminate against people. To the point that any competent HR department will ban you from asking women interviewees about children.
  - mizaru 10y ago
    In some countries (e.g. Germany), asking such questions violates labor law.
    - TheCoelacanth 10y ago
      In the US, the questions are not per se a violation of the law, but you are treading on very thin ice because using the answers to such questions in a way that has a disparate impact on anyone because of their gender, age, family status, religion, etc is a violation of the law, even if you did not intend to discriminate against people on that basis.
    - pc86 10y ago
      Just out of curiosity, does it matter what the questions are actually about? Even in the US if you ask a woman if she plans on getting pregnant you're going to have issues. But I would imagine if a woman was answering a general "tell me about yourself" type question and mentioned her kids, the interviewer might ask a follow up, particularly if they have a similar interest or something (obviously staying away from "so are you going to have more?" or whatever). I'm a guy so I've never been asked about kids until after being hired, and even then just conversationally at lunch.
- tgb 10y ago
partycoder 10y ago
The problem is how to determine how someone is smart. In my company we had this very eloquent, outgoing person who implemented many features very fast. To the eyes of management he was a champ, the king of "shipping". But a little bit later things started to seem weird. Noone was productive except for this person. Only he could understand the code organization because the system wasn't well structured. Then bug reports started coming in, later on the customer complaints started coming in, and incidents were declared. The guy failed to fix the incidents and got fired. Later on, I got hired. By auditing the code base I identified multiple issues that suggested the person did not understand what he was doing. So the eloquent, passionate, cool, outgoing guy turned to be productive because he was only doing 20% of the job. All non-functional requirements were neglected. Non-functional requirements are often implicit and taken for granted. Nobody tells you "I want to not be hacked" or "I want our system to not slow down and go over capacity". Those are implicit requirements that you as an engineer need to identify, specify and implement. The non-technical leadership realized this only 2 years down the road when a huge damage was already done. So, I am going to say NO to this article. Skills are important.
- nucleardog 10y ago
  I got hired on at a job to replace a guy like that. He "got so much done" and "worked so hard" (was at the office late) until he up and left. Step 1 when I got hired on was to automate away half of what he was doing. I turned processes that were previously three hour projects into five minutes and a shell script. Not many late nights or 16 hour days for me. Step 2 was to finish all the work he'd left behind. It wasn't unusual to get a bug report coming in "Oh, in screen X when you try and do Y it doesn't work right." only to find that while he'd built an interface, there was no code behind any of it.
- adnrw 10y ago
  I think the bigger lesson is probably something along the lines of: First, make sure they can do the job technically, within some sort of parameters of what they can currently do and what can be learned on the job. That's your baseline. Then, try and suss out if they'd be good to work with. That will come naturally through the way they interact with you in the interview and how they answer questions (whether they are the questions in the article or completely different ones). If you reckon they tick the boxes for those two major attributes, it's then just a matter of weighing up how much of each attribute they bring to the table and if the balance is right.
pinaceae 10y ago
big grain of salt with this one. mr. voss has only ever worked for one company, maxed out as head of IT, team of 35. so his sample size is rather limited.
- janvoss 10y ago
  well, you are right. I built up and worked only for one company. Why exactly do I need a bigger sample size in order to write down how I recruit, how and what I learned about interviews and what has worked for me and what has not? I am not stating that I have a solution for every situation or every company on the planet. Take it as what it is meant to be: a possibility to reflect your own interviewing behaviour and perhaps taking one or two new ideas with you :-)
mingodad 10y ago
In my experience interviews are not the main place to evaluate technical skills, people get nervous and asking too specific technical questions is not good also, some people can be good at remembering then but can not do anything with then. I came to the idea that to interview/hire/select a software engineer he/she should show at least three bug fixes on any opensource project and if the fixes are way back the interview/job advert the better. So one can at least have a concrete idea of the candidate skills/interest when confronted with a third party code base and how she/he understood/solved the problem. This way the interview can be used to access other important aspects of the candidate. I interviewed several people that seem to have paid someone to write their C.V. very well but when in person was a lost of time.
- Cthulhu_ 10y ago
  Bug fixes and such don't really tell much either though. We do hiring via an assessment, where people need to implement (parts of) an application similar to a real-life thing; involves things like creating a REST / JSON api, etc. The trick is we don't tell them exactly how to implement it (language, environment, secondary requirements are all left up to the applicant). This really weeds out the candidates; better than fizzbuzz, better than live coding. Of course there's a chance that someone copies stuff off the internet, but that's what the actual interview(s) are for, just ask some questions about the implementations and the why and such. We've hired people that did it in python, node, ruby, even J2EE. Language doesn't matter, it's the thought and reasonings behind it that count.
Raesan 10y ago
Whenever I see posts about hiring, the comments here tend to land at the "this is bad advice" end of the spectrum. Does anyone have any resources that give good advice? Or is hiring such an unsolved problem that we don't even have generally applicable guidelines, however vague they may be?
- rndmize 10y ago
  Here's some of the better advice on hiring I've seen after bring on HN for a while. One of tokenadult's posts on hiring - https://news.ycombinator.com/item?id=8232963 https://news.ycombinator.com/item?id=8232963 tptacek - http://sockpuppet.org/blog/2015/03/06/the-hiring-post/ http://sockpuppet.org/blog/2015/03/06/the-hiring-post/
- tyurok 10y ago
  Successful stories about good hiring usually involves most of/the whole team being part of the hiring process and less delegated to HR people.
eric001 10y ago
Wow.. I feel super provoked by the question "What's cool about you?". I wonder why..
- clavalle 10y ago
  Probably because being 'cool' is highly subjective and of marginal, perhaps even negative, relevance to doing valuable work. It is presumptuous and pretentious: 'Are you good enough by my own arbitrary and vague standards to be around me' is the underlying question.
lazyant 10y ago
So candidates where preparing for "what's your biggest weakness" and now they have to prepare for a twist of the also common "tell me about yourself"? again this question filters for people who practiced the question and are enthusiastic (or fake it).
- pc86 10y ago
  I'm not sure what your complaint is. You will have a better time passing interviews if you are comfortable talking about yourself - strengths, weaknesses, experiences, goals, etc. Enthusiasm is good. Faking enthusiasm is still better than crossing your arms and demanding you be judged on your GitHub profile alone and not have to answer questions about yourself.
  - lazyant 10y ago
    Not complaining, only stating that common questions can be trained and faked, diluting their value. Of course letting you explain yourself about what you are good at etc is better than narrow tricky questions, at the end there's only so much you can learn from a person you just met in one hour. Asking a candidate about themselves is good, is just no silver bullet.
joyeuse6701 10y ago
Aptitude over skill set. Interview for that.

101 points by _ak 10y ago

Agree 100%. Too much focus on happening to have encountered the particular skills you ask about in the technical grilling. Rather, hire smart people you'd like to work with (and who have demonstrated a capacity for learning).

quanticle 10y ago
The problem with that strategy is that all too often, "smart people you'd like to work with" equates to male, white, upper-middle-class, with a fondness for beer.
- paulddraper 10y ago
  Probably depends on the interviewer.
- soft_dev_person 10y ago
  So all interviewers are male, white upper-middle-class with a fondness for beer? Good to know.
  - dguaraglia 10y ago
    Not all, but the vast majority fit exactly that profile. It's not difficult to find evidence of that, just Google for <insert any of hundreds of studies and internal diversity reports by major Silicon Valley companies here>. So yes, they point about "hiring for character might bias the outcome" is still valid.
    - soft_dev_person 10y ago
      I guess, as a person not in the SV sphere, I don't really agree. Maybe I missed the implied SV context.
      - Cthulhu_ 10y ago
        This is HN, a community consisting mostly of middle-upper-class white males orbiting around SV.
  - TheCoelacanth 10y ago
    If you replace "white" with "white, Indian or east Asian" then you are pretty darn close.
- ewar-woowar 10y ago
  Or "plays golf/football, comes from a similar background to us", where gender doesn't play a role, not even in the much-reported IT industry where there is a paucity of women . As a Brit in central Europe I have come up against this, not to the same extent as someone who isn't white, or comes from a markedly different culture, but the differences in culture even between some European nations can be enough that employers do not perceive me as "one of them". What happened to hiring people who are not like us, because that's where the challenge lies and life is better when we are forced to evaluate our own misgivings? A lot of IT people are so similar in personality, skills, hobbies etc that they all fail in the same areas, not just succeed in those areas. My own work place could be better, and produce a better product, if everyone wasn't so like-minded, imo.
  - slgeorge 10y ago
    > What happened to hiring people who are not like us, because that's where the challenge lies and life is better when we are forced to evaluate our own misgivings? I think for many situations that comes down to three things: a. People who don't agree that hiring for diversity is good. While every manager knows that diversity is important (as demonstrated by their responses to HR and while on a training course) I don't believe it's as internalised as people say. Most people subconsciously have strong beliefs of how "people like us" will work together. b. Risk aversion amongst hiring managers Commonly teams have more work to be done than people available: ever known a hiring manager not in a hurry to get a new person in? Taking a perceived risk to hire someone different - whatever that difference is from skillset, gender or background - may not be rewarded when higher management want specific objectives achieved. While in principle it might be nice, pragmatism often dictates that managers go with what they know. c. Inability to measure hiring outcomes How do you measure whether more diverse teams, or occasions when you took a risk worked out? If an individual is successful is that down to good hiring, or is it just random as that particular team happens to be doing well at that moment. It's very difficult to be evidence based in hiring. Consequently, everyone has heuristics for what they think is useful, but there's not much backing it up except gut feel. For example, what evidence is there that people having a "passion" outside work and doing side-projects is inherently better ... none that I know of ... but something that lots of developers and technical managers ask about and a key reason candidates build-up profiles on Github.
- retox 10y ago
  Why is that a problem?
- janvoss 10y ago
  Hi! actually I am the author of the artile ;-) My team looks like this: 4 female one more to come 26 male among these 30 people i have 15+ nationalities. I am a meat lover and drink beer....I have at least 4 people that absolutely never drink and 3 of them are vegetarians. Just by following my principle "smart people that i like to work with" I created a very diverse team. I think the point is: I like to work with people who are different to me, who challenge me, who make me grow as a personality because I learn something new from them. So the key is hidden in the "that i like to work with" and in the definition of "liking someone" ;-)
humanrebar 10y ago
> Too much focus on happening to have encountered the particular skills you ask about in the technical grilling. I agree somewhat, but I've seen many people making mistakes, learning on the job what not to do, and making the entire team learn from their mistakes. So there definitely needs to be some technical experience at the helm of the team to make sure any technical mistakes can be corrected without undue effort. In other words, knowledge, intelligence, understanding, and wisdom are all different things. I'm very excited to hire smart, humble people, but only if my org has some defenses against well-meaning people that are trying out some new technology for the first time. And if a good chunk of the team is smart, inexperienced people, even diligent code review doesn't really cut it.

heisnotanalien 10y ago

I sort of like the sentiment but this sort of interview, at least for me, would feel a bit too personal. Look I'm not your friend so let's not pretend that's what this or you just really want to get to know me. No. You just want to know if I can do the job so just get me to do a task which meaningfully reflects what I'd be doing day-to-day then ask me questions about it.

lexicality 10y ago
Do you not try to be friends with your colleagues? You spend about a third of your life at work, it seems to me that you should try to make it as enjoyable as possible.
- soft_dev_person 10y ago
  Being friends with colleagues can lead to less enjoyable work situations, not to mention less focused work. Being friendly should suffice, not all of us want to get too personal with the same people we might need to have professional arguments with. We're all different.
  - hvidgaard 10y ago
    I'll share a bit of wisdom my son shared when he was 4 or 5. In kindergarden they talked about what a friend is, and he said after some thinking: "A friend is a person you can disagree and fight with, and still play with later".
    - anjanb 10y ago
      your son is smart. he will a go way.
    - soft_dev_person 10y ago
      Getting that close to all my coworkers would be too daunting a task. Edit: Not to belittle your son's wisdom, of course. I totally agree.

reflexorozy 10y ago

This sounds like a cool idea, but I've seen where hiring for personality often leads towards hiring discrimination. I think it's more likely to reinforce the lack of diversity in tech than to combat it as people unlike the interviewer tend to be viewed less favorably and would be less likely to be viewed as a person who could pick up the specific knowledge he/she doesn't already know.

hvidgaard 10y ago
Maybe, but my mantra is a mix. I use standard technical questions ect. to weed out candidates that cannot do the job - I try to stay general such that I see problem solving, rather than certification. Then I'm left with a pool of people that are real potential hires. After that I'm looking for a learner with the right mindset, and THEN I'm looking for a fit - preferably someone who will complement the team, rather than reinforce what is already working. Hiring is not an exact science, and what works for me, is probably not working for others.
slgeorge 10y ago
Having read through it, I think he's trying to hire for fit with himself and his team. An inbuilt assumption is that the candidates are capable of doing the role - he mentions going through their CV, or perhaps he's already covered off skills. I don't think he's saying that skills to do the role aren't required: so he's not hiring graduates and then giving them the skills for the job, for example. It's a tough one, if you don't look at whether a candidate could fit within the team (in this case they care about 'passion') then you're storing up problems on the team dynamic front. On the other hand, as you point out, it's difficult to hire on personality without subconsciously hiring people you like which is often people like you: which means less diversity.
takno 10y ago
I feel like it's telling that he refers to the candidates as guys throughout
- SeanCrawford 10y ago
  If you mean the article, then I disagree, for I read him as using this person, candidate, and even the gender neutral "them" in the singular. As for "guy," the word is like nation and nationalist: it must be read in context: nation can mean Kurds and Quebec, or Iraq and Canada. Yes, if you want Quebec to separate then you are a nationalist, and if you want Canada to stay whole then you are a nationalist. In talking to two women I can mention a gorgeous guy in my classroom and then ask, "Are you guys going to the concert?"

InclinedPlane 10y ago

So many people have these really bizarre and outdated (by not just years but centuries) notions about how knowledge work gets done. They want to squish it into the model of factory work, but it just doesn't work that way. Knowledge work is typically creative, the right model is an art studio, a movie set, or a band. This makes hiring very difficult, which is exacerbated by the fact that engineers are innately bad at hiring other engineers without a lot of training or carefully focused self-improvement. Knowledge workers aren't cogs, they're part of a team. You shouldn't expect that you can easily find replacement people with exactly the same skillset and propensity as someone else to make up the gap that an absence makes in a team. Nor should you expect that the proper way to grow a team is by cloning the skills of some other existing member of the team. A team works cooperatively, and their skills, talents, experience play off one another to gel together into some sort of mechanism that is capable of doing stuff. But if you change the parts, you get a different team that does different stuff, or maybe doesn't even work at all. One of the big factors here is that if you think you can replace one person with just another person you're often wrong. Best case scenario you end up with something else (maybe better), worst case scenario is you can't replace the unique factors that made the previous person successful in that role (and realistically you need a team with a different breakdown of skills, different mechanisms of interconnectedness, etc. in order to have something functional). The band analogy really helps here a lot. Realistically when you change members of a team you don't end up with something like Steve Perry stepping into the lead singer role of Journey. What you end up with is something more like Fleetwood Mac being transformed by merging with Buckingham Nicks or Genesis changing after Peter Gabriel left. You end up with a very different thing doing very different stuff. And the higher caliber the people the bigger the difference is. What knowledge workers actually do day to day and what it says on their job description they do are often very different things, and you ignore that at your peril. Hiring based on the idea that knowledge workers are automatons with certain functionality modules installed is one of the easiest and most common ways to completely sabotage productivity and execution.

slgeorge 10y ago
> Knowledge workers aren't cogs, they're part of a team. You shouldn't expect that you can easily find replacement people with exactly the same skillset and propensity as someone else to make up the gap that an absence makes in a team. Nor should you expect that the proper way to grow a team is by cloning the skills of some other existing member of the team. A team works cooperatively, and their skills, talents, experience play off one another to gel together into some sort of mechanism that is capable of doing stuff. Great comment, I totally agree that taking a wholly mechanistic view of how individuals and teams work is an error. You can't account for all the 'magic' that make some teams function in ways that are more than the individual parts. Of course, you're striking at an underlying fear for managers. Our jobs are to make things work immaterial of the individuals: positively a managers job is to make the system of people/process/systems work, and negatively to make sure that no individual should be so indispensable for the project/department/organisation. This mechanistic view generally works because most roles are 90% perspiration and 10% inspiration, as the saying goes. Perhaps a good mix is that when a hole is created in the team, to look at the situation holistically. As the short-list of candidates is drawn-up consider how they could fit into the mix, and how they would be additive - not the same as previously, but a new opportunity - like a new ingredient, rather than a replacement cog. It reinforces the idea of having more peers from the group involved in the hiring as this could open up a range of opinions on how the mix could change.

wimagguc 10y ago

There is always a good debate on HN about hiring, but it feels like we really are comparing apples to oranges here. Hiring tactics depend heavily on the size of the organisation. They have to: for a 3-people startup you want someone who will break walls and get stuff done, for a thousand-people-heavy dev team you need people who can do one job very precisely. Those tasks require very different personalities, so naturally, very different hiring questions.

danieltillett 10y ago
This applies to almost everything. The really hard problem is recognising when the heuristics that worked in the past are now broken.

ajuc 10y ago

> It surprised me that people define theirselves via their CV: “Who are you?” -> “Here is what I have done in my professional life!”. Anything weird about that? I wouldn't expect my potential employer to be interested in my family, hobbies or beliefs. So I would respond with job-related stuff as well.

pjc50 10y ago
Well, indeed. Traditionally those have been used to discriminate against people. To the point that any competent HR department will ban you from asking women interviewees about children.
- mizaru 10y ago
  In some countries (e.g. Germany), asking such questions violates labor law.
  - TheCoelacanth 10y ago
    In the US, the questions are not per se a violation of the law, but you are treading on very thin ice because using the answers to such questions in a way that has a disparate impact on anyone because of their gender, age, family status, religion, etc is a violation of the law, even if you did not intend to discriminate against people on that basis.
  - pc86 10y ago
    Just out of curiosity, does it matter what the questions are actually about? Even in the US if you ask a woman if she plans on getting pregnant you're going to have issues. But I would imagine if a woman was answering a general "tell me about yourself" type question and mentioned her kids, the interviewer might ask a follow up, particularly if they have a similar interest or something (obviously staying away from "so are you going to have more?" or whatever). I'm a guy so I've never been asked about kids until after being hired, and even then just conversationally at lunch.
tgb 10y ago

partycoder 10y ago

The problem is how to determine how someone is smart. In my company we had this very eloquent, outgoing person who implemented many features very fast. To the eyes of management he was a champ, the king of "shipping". But a little bit later things started to seem weird. Noone was productive except for this person. Only he could understand the code organization because the system wasn't well structured. Then bug reports started coming in, later on the customer complaints started coming in, and incidents were declared. The guy failed to fix the incidents and got fired. Later on, I got hired. By auditing the code base I identified multiple issues that suggested the person did not understand what he was doing. So the eloquent, passionate, cool, outgoing guy turned to be productive because he was only doing 20% of the job. All non-functional requirements were neglected. Non-functional requirements are often implicit and taken for granted. Nobody tells you "I want to not be hacked" or "I want our system to not slow down and go over capacity". Those are implicit requirements that you as an engineer need to identify, specify and implement. The non-technical leadership realized this only 2 years down the road when a huge damage was already done. So, I am going to say NO to this article. Skills are important.

nucleardog 10y ago
I got hired on at a job to replace a guy like that. He "got so much done" and "worked so hard" (was at the office late) until he up and left. Step 1 when I got hired on was to automate away half of what he was doing. I turned processes that were previously three hour projects into five minutes and a shell script. Not many late nights or 16 hour days for me. Step 2 was to finish all the work he'd left behind. It wasn't unusual to get a bug report coming in "Oh, in screen X when you try and do Y it doesn't work right." only to find that while he'd built an interface, there was no code behind any of it.
adnrw 10y ago
I think the bigger lesson is probably something along the lines of: First, make sure they can do the job technically, within some sort of parameters of what they can currently do and what can be learned on the job. That's your baseline. Then, try and suss out if they'd be good to work with. That will come naturally through the way they interact with you in the interview and how they answer questions (whether they are the questions in the article or completely different ones). If you reckon they tick the boxes for those two major attributes, it's then just a matter of weighing up how much of each attribute they bring to the table and if the balance is right.

pinaceae 10y ago

big grain of salt with this one. mr. voss has only ever worked for one company, maxed out as head of IT, team of 35. so his sample size is rather limited.

janvoss 10y ago
well, you are right. I built up and worked only for one company. Why exactly do I need a bigger sample size in order to write down how I recruit, how and what I learned about interviews and what has worked for me and what has not? I am not stating that I have a solution for every situation or every company on the planet. Take it as what it is meant to be: a possibility to reflect your own interviewing behaviour and perhaps taking one or two new ideas with you :-)

mingodad 10y ago

In my experience interviews are not the main place to evaluate technical skills, people get nervous and asking too specific technical questions is not good also, some people can be good at remembering then but can not do anything with then. I came to the idea that to interview/hire/select a software engineer he/she should show at least three bug fixes on any opensource project and if the fixes are way back the interview/job advert the better. So one can at least have a concrete idea of the candidate skills/interest when confronted with a third party code base and how she/he understood/solved the problem. This way the interview can be used to access other important aspects of the candidate. I interviewed several people that seem to have paid someone to write their C.V. very well but when in person was a lost of time.

Cthulhu_ 10y ago
Bug fixes and such don't really tell much either though. We do hiring via an assessment, where people need to implement (parts of) an application similar to a real-life thing; involves things like creating a REST / JSON api, etc. The trick is we don't tell them exactly how to implement it (language, environment, secondary requirements are all left up to the applicant). This really weeds out the candidates; better than fizzbuzz, better than live coding. Of course there's a chance that someone copies stuff off the internet, but that's what the actual interview(s) are for, just ask some questions about the implementations and the why and such. We've hired people that did it in python, node, ruby, even J2EE. Language doesn't matter, it's the thought and reasonings behind it that count.

Raesan 10y ago

Whenever I see posts about hiring, the comments here tend to land at the "this is bad advice" end of the spectrum. Does anyone have any resources that give good advice? Or is hiring such an unsolved problem that we don't even have generally applicable guidelines, however vague they may be?

rndmize 10y ago
Here's some of the better advice on hiring I've seen after bring on HN for a while. One of tokenadult's posts on hiring - https://news.ycombinator.com/item?id=8232963 https://news.ycombinator.com/item?id=8232963 tptacek - http://sockpuppet.org/blog/2015/03/06/the-hiring-post/ http://sockpuppet.org/blog/2015/03/06/the-hiring-post/
tyurok 10y ago
Successful stories about good hiring usually involves most of/the whole team being part of the hiring process and less delegated to HR people.

eric001 10y ago

Wow.. I feel super provoked by the question "What's cool about you?". I wonder why..

clavalle 10y ago
Probably because being 'cool' is highly subjective and of marginal, perhaps even negative, relevance to doing valuable work. It is presumptuous and pretentious: 'Are you good enough by my own arbitrary and vague standards to be around me' is the underlying question.

lazyant 10y ago

So candidates where preparing for "what's your biggest weakness" and now they have to prepare for a twist of the also common "tell me about yourself"? again this question filters for people who practiced the question and are enthusiastic (or fake it).

pc86 10y ago
I'm not sure what your complaint is. You will have a better time passing interviews if you are comfortable talking about yourself - strengths, weaknesses, experiences, goals, etc. Enthusiasm is good. Faking enthusiasm is still better than crossing your arms and demanding you be judged on your GitHub profile alone and not have to answer questions about yourself.
- lazyant 10y ago
  Not complaining, only stating that common questions can be trained and faked, diluting their value. Of course letting you explain yourself about what you are good at etc is better than narrow tricky questions, at the end there's only so much you can learn from a person you just met in one hour. Asking a candidate about themselves is good, is just no silver bullet.

joyeuse6701 10y ago

Aptitude over skill set. Interview for that.