Live data from Hacker News

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

voss.world

71–80 of 117 posts

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

#71

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

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.

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

#72

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…

It's always the last guy's fault. :)

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

#73
post #68

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?

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

tptacek - http://sockpuppet.org/blog/2015/03/06/the-hiring-post/

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

#74
post #32

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 have never in my life understood the word smart. Everyone is smart. No one is smart. It's a useless word, and seems overused to me (at least in American English).

You can't get people to stop sorting each other no matter what you do.

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

#75

Earlier quoted context omitted.

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.

"Gladiator, make no friends of gladiators" - roughly from "Spartacus".

Of course, intra-office competition at that level is highly destructive but that's what people are acculturated to.

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

#76

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…

> So, I am going to say NO to this article. Skills are important. In your anecdote though, I'm reading that the er, rockstar developer had enough skills to get things done, but not the personality to do things The Right Way. That is a personality thing, I think, with personality traits like attention to detail and quality and such. Those are not linked to skill level or technology; maybe with experience (i.e. being o…

There is nothing organically wrong with cowboy coding, especially if you're trying to find your footing with a new thing. But it's not sufficient, and probably not necessary.

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

#77
post #66

Earlier quoted context omitted.

> To the eyes of management he was a champ, the king of "shipping". So management also was bad at their jobs. They probably didn't get canned, though they deserved it as much as the King of Shipping. But, congratulations, you know the "What's Bad About Working Here". Maybe there's a way to train management what their implicit job responsibilities are. I've never seen it happen in the wild, but maybe it's possible.

This is my experience. It's a codependent relationship between management who is unable to determine the feasibility of what it's asking for (or, just as often, what it is asking for) on the one hand, and an eager-to-please yes-man of an engineer on the other. Management loves how fast things are delivered, and boyscout loves the pats on the head. The rest of us hate the countdown until the house of cards comes tumbl…

I love that tweet. Although it happens on the management side too. Manager comes in runs a team into ground(that the previous manager spent years building), pushes all kinds of work on other teams as well, takes credit for all of it and keeps getting promoted.

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

#78

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…

So this guy was working by himself, with no help, no review, and no one to discuss the implications of anything with. Sounds like a hero for managing it as long as he did.

good point.

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

#79
post #68

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?

Successful stories about good hiring usually involves most of/the whole team being part of the hiring process and less delegated to HR people.

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

#80

Earlier quoted context omitted.

I have one of these on my team right now, and he has caused me more sleepless nights than anyone I have ever met. Finding it very difficult to get mgmt to understand that most of his code needs to be re-written

This may sound paranoid, but I have seen it happen: make sure the person you are having problems with isn't sucking up to your managers and also making you look bad to them. [99% of the people I have worked with have never played those kind of political games but I have seen the utter chaos that can happen if a politically savvy operator is let loose in a trusting and politically naive environment.]

Frankly, if that works and you get fired, you didn't lose much to start with. Sorry, but keeping your job is a different skill set than doing your job.

I've had to opposite experience twice - I got drop-shipped into projects where somebody had gone rogue and I cleaned it up, and then they were let go. It's most unpleasant, and had they been more perceptive they'd have known that's what was going on. In both cases, I believe they were ready to go ( and I lost any trust in the management that used this gambit and left myself shortly).

Post reply on HN