The Hiring Post • Hacker News Board

Re: The Hiring Post

#21

Post by tptacek » Fri, Mar 06, 2015, 9:54 PM UTC

jowiar wrote: post #18

This article seems to put forward a good theory on interviewing someone who you want to lock in room with a problem and have code come out the other end. Unfortunately, most of us work in the real world, where that's a very limited portion of the engineering job. When the author says selecting for: "people who have the social skills to actively listen to someone else’s technical points, to guide a discussion with que…

I know how to turn someone who can't code into someone who can.

If you can do that reliably, you should be making zillions of dollars.

My experience is the opposite: if someone is very impressive in an interview but a zero on the team, they're an intractable management problem.

In any case: there is a difference between being cripplingly antisocial and being able to deftly handle an interview. The social skills required to flip the script on an interview are distinctive, and they aren't the "team player" skills. In fact, as I re-edited that paragraph and came up with "controlling the conversation", it occurred to me that they might signal a candidate who has problems on teams.

Re: The Hiring Post

#22

Post by nvarsj » Fri, Mar 06, 2015, 9:58 PM UTC

jowiar wrote: post #18

This article seems to put forward a good theory on interviewing someone who you want to lock in room with a problem and have code come out the other end. Unfortunately, most of us work in the real world, where that's a very limited portion of the engineering job. When the author says selecting for: "people who have the social skills to actively listen to someone else’s technical points, to guide a discussion with que…

> And, at least in my job, engineers spend a whole lot more time dealing with people than with code.

I'd say something is wrong then. If your business depends on shipping code why are your developers talking to people most of the time?

Re: The Hiring Post

#23

Post by calcsam » Fri, Mar 06, 2015, 10:00 PM UTC

tptacek wrote: post #21

jowiar wrote: post #18

This article seems to put forward a good theory on interviewing someone who you want to lock in room with a problem and have code come out the other end. Unfortunately, most of us work in the real world, where that's a very limited portion of the engineering job. When the author says selecting for: "people who have the social skills to actively listen to someone else’s technical points, to guide a discussion with que…

I know how to turn someone who can't code into someone who can. If you can do that reliably, you should be making zillions of dollars. My experience is the opposite: if someone is very impressive in an interview but a zero on the team, they're an intractable management problem. In any case: there is a difference between being cripplingly antisocial and being able to deftly handle an interview. The social skills requi…

I'd suspect technical skills are more highly valued in crypto than in other programming domains. That may account for your differing perceptions.

Re: The Hiring Post

#24

Post by mtviewdave » Fri, Mar 06, 2015, 10:00 PM UTC

jowiar wrote: post #18

This article seems to put forward a good theory on interviewing someone who you want to lock in room with a problem and have code come out the other end. Unfortunately, most of us work in the real world, where that's a very limited portion of the engineering job. When the author says selecting for: "people who have the social skills to actively listen to someone else’s technical points, to guide a discussion with que…

>This article seems to put forward a good theory on interviewing someone who you want to lock in room with a problem and have code come out the other end. Unfortunately, most of us work in the real world, where that's a very limited portion of the engineering job.

It's a better representation of the job than writing code on a whiteboard.

The question shouldn't be "is it perfect?" The question should be "is it better than what we have now?"

Re: The Hiring Post

#25

Post by white-flame » Fri, Mar 06, 2015, 10:01 PM UTC

"Years from now, we’ll look back at the 2015 developer interview as an anachronism..."

People were saying similar things 20 years ago, too. Others will likely corroborate that from earlier.

Re: The Hiring Post

#26

Post by cipher0 » Fri, Mar 06, 2015, 10:01 PM UTC

nvarsj wrote: post #22

jowiar wrote: post #18

This article seems to put forward a good theory on interviewing someone who you want to lock in room with a problem and have code come out the other end. Unfortunately, most of us work in the real world, where that's a very limited portion of the engineering job. When the author says selecting for: "people who have the social skills to actively listen to someone else’s technical points, to guide a discussion with que…

> And, at least in my job, engineers spend a whole lot more time dealing with people than with code. I'd say something is wrong then. If your business depends on shipping code why are your developers talking to people most of the time?

How do you ship code when working with a team without communicating with them?

Re: The Hiring Post

#27

Post by tptacek » Fri, Mar 06, 2015, 10:01 PM UTC

Author.

I can talk in a pretty good amount of detail about how exactly our process worked, if anyone has any questions.

And, to head off a concern a reviewer gave me: from 1997-2005, I was a full-time software developer; I shipped shrink-wrap boxed software on Windows and Unix in the 1990s, then appliances deployed at tier 1 ISPs. I'm a "software person" more than a "security person".

Re: The Hiring Post

#28

Post by tptacek » Fri, Mar 06, 2015, 10:02 PM UTC

calcsam wrote: post #23

tptacek wrote: post #21

Earlier quoted context omitted.

I know how to turn someone who can't code into someone who can. If you can do that reliably, you should be making zillions of dollars. My experience is the opposite: if someone is very impressive in an interview but a zero on the team, they're an intractable management problem. In any case: there is a difference between being cripplingly antisocial and being able to deftly handle an interview. The social skills requi…

I'd suspect technical skills are more highly valued in crypto than in other programming domains. That may account for your differing perceptions.

I'm not sure I follow. But in any case, Matasano isn't a cryptography firm; it's a software consultancy. The set of things we did to boot up a specialty practice in cryptography are a different blog post.

Re: The Hiring Post

#29

Post by white-flame » Fri, Mar 06, 2015, 10:04 PM UTC

SamReidHughes wrote: post #3

As somebody who agrees in theory with tptacek's posts and now this blog post, what I find very funny is how I perceive typical technical hiring, with the interview gauntlet, to still be way better than what some other industries must do. How the hell does anybody hire a teacher?

A big difference is that the benefits of quality programmers manifest over long projects.

With many other industries, you can say "Do this" in a shorter, observable time frame and have it more aligned with what they'll be facing on the job. Contrast this to dumb interview coding challenges, for instance.

Re: The Hiring Post

#30

Post by BinaryIdiot » Fri, Mar 06, 2015, 10:12 PM UTC

joshdance wrote: post #16

I have a friend who is a good programmer, and likes learning, and is easy to work with, but he is terrible at technical interviews. He stresses about them to no end. This sounds like a much better process.

I know no end of people in the exact same bucket. I used to think I wasn't in the bucket at all as I've been through many difficult and time consuming interviews but I always got an offer until I interviewed at Microsoft and Google (though I still maintain my failure at those two companies were not entirely my fault but I digress).

After going through the march of those two big companies I found the process incredibly annoying and not useful at all; nothing of substance was really ever discussed it was almost always academic or some sort of trick question where I get to hear the interviewer talk for half an hour how they came up with a superior technique.

I've interviewed a lot of people. Interviewing software developers is such a pain in the ass.