Comment by nvarsj | Hacker News Reader

Comment by nvarsj | Hacker News Reader

Parent Full thread

> The single most effective way that I've found to interview for "interest" is to just get them talking about something they've done before and ask them to go deep into the details. You get everything you need from watching somebody talk, with a smile on their face, about how they solved some problem in a creative way that makes them show some pride.

Sorry, but you are being scammed. You are selecting for sales skills, not technical skills. Read what you've written. You're judging someone based on how they presents themselves - not anything about technical ability.

I have interviewed many people who are great at doing this impassioned sales speech, but are terrible at actual engineering. And in fact, many good engineers are not good at selling themselves in this way - they have spent most of their lives deep in code, not working on their social skills like normal people.

Why not actually test them similar to what they're going to be doing? If it's a sales or advocate role at your tech consultancy, well then sure, your approach works.

> Sorry, but you are being scammed. You are selecting for sales skills, not technical skills. Read what you've written.

You're asking the parent commenter to set aside eight years of personal hiring experience, over which time "every person I've ever hired who has passed that part has ended up in my 'great hire' category" (assuming, that is, that you've read what he/she's written).

Can a candidate lacking the technical skills go deep into details the way the parent commenter describes?

> Can a candidate lacking the technical skills go deep into details the way the parent commenter describes?

More often than you'd think, alas. I'm going by about fifteen years of personal hiring experience, for whatever that's worth.

I've seen this same thing frequently when evaluating security engineers. They often can talk the talk, but when given a simple task to perform more often than not will fail.

Coding exercises might not be a great measure, but as far as I have experienced, they are better than other items out there.

Do you mean that over your 15 years you've hired people more often than we'd think who later turned out to have been fooling you during the interview with their sales skills? That sounds terrible and I'm sorry to hear that.

On the other hand if you mean that you've discovered during your interviews that candidates more often that we'd think had been trying to fool you -- and that's why you didn't hire them -- well then that doesn't sound much different from the above person's eight years of experience.

I don't think anyone here would argue that there isn't a significant number of candidates for technical positions who BS about their technical skills.

I've hired, at several places, more than a few people who were fooling me with their sales skills. More often I work at a place where we do multiple interviews -- some "technical" in the sense that it's talking about tech, and some "technical" in the specific sense of asking a programming question with a verifiable answer (i.e. run the program, see if it works.)

Frequently people do well on the technical-not-actually-coding portions and very badly on the please-write-code portions. That is, if we didn't ask the specific coding questions, we'd be hiring people they disqualify.

At those places we less frequently hire people that just can't code -- though I've been around for that too, usually when we look at a resume and say, "oh, we don't need a coding test for him, he's been writing important code for years in a way where he couldn't hide lack of ability."

It would appear that a resume is a poor way to verify that.

Yup. I've seen candidates talk a deep technical game and turn out unable to write long term sustainable (well-organized) code.

Here's the fundamental asymmetry: what makes a good programmer great is their ability to build a cathedral brick by brick, alongside the architect, the other builders, despite the external circumstances, accounting for complications along the way. Ignoring the connotations of waterfall design that "cathedral" might invoke.

Building a complex system with many components takes weeks, even months, whether or not you're talking about MVP's, or service oriented architectures, and whether or not you're iterating rapidly.

A weak engineer will be fine for a few weeks, but the complexity will catch up to them. A strong engineer pushes that bar much, much further out. Possibly indefinitely.

Problem is, how do you tell that you're talking to that kind of person when you have only a few hours? It's an extremely difficult task because you must evaluate a person for a > 6 month job in under 6 hours. No matter what you do, you're going to have trouble.

> Can a candidate lacking the technical skills go deep into details the way the parent commenter describes?

That's what most bosses/salesmen excel at doing everyday.

That doesn't seem to correspond to the attitudes of salesmen vs engineers. I'm not sure what salesmen you're thinking of, but few of the people in sales I've talked to can have an in-depth discussion about how React.createClass vs Class ___ extends React.component will effect "this" context, and how super(props) pattern works in the latter. Furthermore, lots of engineers who work with any given language/framework can't explain it either, and many of them have basically been copy-pasting until stuff worked their whole career.

I've found that most people who have poor communication skills are not good engineers either* and the two might actually be related.

*Except for substack

> Can a candidate lacking the technical skills go deep into details the way the parent commenter describes?

I withdraw this somewhat rhetorical question. I should never have asked it because it's not the point (and it invites answers out of the original context that overlook "the way the parent commenter describes").

Here we have two ways of evaluating technical candidates, just two of perhaps many: One seems to be more arbitrary and unreliable than many have assumed, and the other is very time-consuming, doesn't reduce to graphable data and requires a really good interviewer.

Please just recognize that having candidates jump through technical hoops is not as solid and objective a method of evaluation as it might seem to you, and could even filter out certain kinds of great candidates. Where at all possible, please try to treat the human being under evaluation more like a human being and less like a horse.

It's not the exclusive criteria, just a part of the process that I've generally found to be associated with people who excel. We are still going to have them interview with some type of subject matter expert related to the position but all jobs are not created equal.

Positions for things like security, as another commenter mentioned, are very much experience driven. Java is another simply because it has a very high learning curve to become really adept with it. It's doable, but I'd extend the expected ramp up time to longer than 2 weeks.

There's nuance to everything. I didn't mean it to come across as if that was the only factor in hiring.

Actually it's pretty easy to sniff out "salesmanship" in the interview process. From either side, whatever the format.

Reply on news.ycombinator.com