Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

voss.world

Post reply on HN
Print view View original

21–30 of 117 posts

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

#21

Post by quanticle »

lexicality wrote: post #8
heisnotanalien wrote: post #3

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.

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.

There is a difference between maintaining a cordial working relationship, and being friends. I certainly don't go out of my way to be rude to my colleagues. But I don't pretend to be their friends. To illustrate the difference, my friends and I often have rather vehement political discussions. But I would never try to have such a discussion with my colleagues. It would just get in the way of getting on with the work at hand, and would potentially lead to hard feelings that would lead to difficulties at work later on.

In some ways, I find it's more enjoyable to not be friends with my colleagues; to keep my personal life and work life as widely separated as is feasible.

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

#22

Post by pizza234 »

heisnotanalien wrote: post #3

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.

It's not about being friends in a strict sense.

I think the significant concept is that in the long term, there are very strong similarities between the mechanics of being a coworker, and those of being a friend.

So definitely it makes a lot of sense to "investigate" that way.

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

#23

Post by badminton1 »

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.

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

#24

Post by slgeorge »

InclinedPlane wrote: post #7

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…

> 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.

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

#25

Post by quanticle »

InclinedPlane wrote: post #7

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…

    Knowledge work is typically creative, the right model is an art studio, a
    movie set, or a band.

    Knowledge workers aren't cogs, they're part of a team.
And if you look at how bands, movie studios, art studios or professional teams hire, it bears little to no resemblance to the hiring process described in the OP's article. All of the professions you describe hire through some kind of auditioning process. No sports manager would hire a star player on the basis of, "Do I think this person is a cool person?" No movie director would hire an actor on that basis. No art studio would hire a painter based upon a description of their personality. All of those places would judge a person on their portfolio, or an audition.

And that's exactly what those "silly" whiteboard puzzle problems are. They're an audition. Just like actors who have to say silly phrases with emotional inflection, just like bands that require new members to play some random short pieces, and just like football players who have to post their times on 40-yard sprints. Now you can argue that the auditioning process should be improved; that right now the skills exercised with the audition aren't the same ones used by a working programmer and I'd agree with you. I do feel like the process of auditioning for a software development role can be improved. But the way to do that is not to abandon the process entirely and just go with some kind of ill-considered gut feeling about "how much do I like this person?" The way to do it is to make it such that the interview more closely resembles the job the person will be asked to perform.

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

#26

Post by wvh »

ewar-woowar wrote: post #13
quanticle wrote: post #5

Earlier quoted context omitted.

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.

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 employ…

I totally agree that the lack of diversity and geek monoculture are a problem. It's not easy to feel at home when people huddle around a rather limit set of topics, humour, music and whatnot, and you find yourself outside of that little sphere. It's the main reason I'm hoping/planning for an exit from the IT world in n years from now, even though I am a white male – even like beer – and so should fit many a stereotype.

Having worked in different countries and companies, I'm not so sure nationality or gender make that big a difference (at least in western/northern Europe). Other industries also have mono-culture problems, but I guess geek culture is highly specific – almost a world on its own – and IT has a lot of people who are not very interested in or are bad at social interaction.

A lot of managers hire with a very specific task in mind, because it's probably easier to logically match a person to a concrete function or problem. In the long run, it would be a much better idea to hire people who can actually come up with new ideas, solutions and products... But it's much riskier to predict creative output and the value of ideas.

Too many people are made manager "by default" because they've worked in the company for a long time or because of their age, and not because they are actually good with people or building diverse teams that can tackle complex problems in an original way.

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

#27

Post by nommm-nommm »

lexicality wrote: post #8
heisnotanalien wrote: post #3

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.

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.

I try not to be friends with my colleagues. Friendly? Absolutely. Friends? No.

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

#28

Post by pjc50 »

ajuc wrote: post #19

> 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.

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.

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

#30

Post by adnrw »

badminton1 wrote: post #23

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 repor…

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.

Post reply on HN