5 ms·

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

by jccc 11y ago

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

angelbob 11y ago
> 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.
- intern4tional 11y ago
  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.
- jccc 11y ago
  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.
  - angelbob 11y ago
    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.
munchbunny 11y ago
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.
wott 11y ago
> 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.
- Dr_tldr 11y ago
  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
jccc 11y ago
> 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.

by jccc 11y ago

angelbob 11y ago

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

intern4tional 11y ago
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.
jccc 11y ago
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.
- angelbob 11y ago
  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.

munchbunny 11y ago

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.

wott 11y ago

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

Dr_tldr 11y ago
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

jccc 11y ago

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