Hacker News Reader

Comment by jowiar | Hacker News Reader

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 questions of their own, or to spot opportunities to redirect a tough question back to familiar territory." is a mistake, because some of them can't code. I know how to turn someone who can't code into someone who can. I don't know how to turn someone who fails at dealing with humans into someone who succeeds. And, at least in my job, engineers spend a whole lot more time dealing with people than with code.

View on HN

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.

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.

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

I disagree to a degree; I've met many people who were simply fantastic with figuring out problems but didn't know much software development and they ended up being awesome software developers.

It's certainly doable and I don't think it's so difficult that someone who can do it should be making an obscene amount of money but they are not cheap either; that's usually a really good development lead.

I think Thomas is saying that, if the process is repeatable, then the person who possesses a black box which ingests smart person on the left end and outputs a programmer can rent that box to industry and charge, well, billions of dollars for its use. (Fermi estimate; cost of college education to credential the number of engineers AppAmaGooBookSoft will hire this year was on the order of 10^5 * 10^4 = a billion dollars.)

I think you're more wrong than right, and it's selection bias that gives you confidence here.

There are people from all sorts of backgrounds that can become very good developers, but their common feature seems to be that they were already the sort of person who could become a good developer, not any methodology used to train them.

For example, I'm confident most talented physics Ph.Ds[1] can make decent developers of numerical code, but that says more about them than it does about my skill at training.

Given a random person, hell given a random person who is already decent developer in a different domain, my confidence in their ever becoming very good at that domain is much lower.

[1] the problem then being, that pool maybe smaller than the one you are trying to populate....

> Given a random person, hell given a random person who is already decent developer in a different domain, my confidence in their ever becoming very good at that domain is much lower.

I don't think anyone was saying a random person but someone wanting to get into the field or is already in the field but perhaps not in the right spot when you pick them up.

I can't imagine anyone would mean a random person here, that wouldn't make sense as development is a skilled position. not everyone can do it and OP was talking about interviewing developers not random people.

My wording was bad, but I meant a random developer who was not already highly skilled (in another domain)

>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?"

The idea that someone has no social skills because he doesn't ace in a highly contrived situation which has no correlation to the way he will communicate in his job later is pretty weird (Do you hire engineers/developers or high-stake, high-pressure negotiators, e.g. diplomats?). As is the idea that you should optimize your hiring process for what people do "most of the time". You want to optimize for what is MOST IMPORTANT about their job. If I need someone who goes to customers I wouldn't select for people that can drive Formula 1 cars efficient, even if it happens to be the case that they are driving most of their work time.

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

I'm not sure how you got from "less than half of engineers time spent on communication overhead" to "no communication whatsoever". Something is terribly broken if the people primarily responsible for execution take more time to communicate about a task than to actually do it.

Business depends on solving problems. Code is a medium for implementing solutions. I can count the number of times I've needed to put my CS degree to use on one hand, but knowing to whom, when, how to ask the right questions has been worth far more.

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

What kind of job do you have?

Depends how you measure. Writing documentation is dealing with people. And even most code is meant more for people to understand than for the benefit of the computer.

Reply on news.ycombinator.com