5 ms·

It's because lying on a Resume is extremely easy. I do interviews for a large software company about once a week. The relationship between what a candidate sa

It's because lying on a Resume is extremely easy. I do interviews for a large software company about once a week. The relationship between what a candidate says they did and actually doing simple programming problems is non-existent. > It's like many companies have given up trying to rank applicants based on actual job experience and skills. Yes. > "You've created and ran successful software for hundreds of thousands of paying customers?" They probably are taking credit for someone else's or their teams work. It's depressing to say aloud, but it's the norm rather than the exception.

newsbinator 8y ago
Ask them non-trivial questions about the problems they solved and how they solved them.
- kamalkishor1991 8y ago
  They are likely to know more about the project they were part of then you do. Even if they are really bad.
  - newsbinator 8y ago
    That's okay. The important thing is their knowledge of common problem patterns and solution patterns. Ask them how they identified a complex problem, what process they used to get to its root, what they thought was causing it but actually wasn't, which solutions they discarded and why, etc. You don't need to have a better understanding of their project than they have. You just need to determine whether they have the ability to solve complex technicals problems in competent ways, and at what level. For example a more junior person might talk more about solving the problem for today and less about solving the problem for tomorrow. Let them talk it out and see where their attention goes. A more senior person might talk about similar problems they've seen on other projects and how they leaned on past experience to discard non-optimal solutions faster. You don't need an algorithms test to determine if someone is likely to be able to "get stuff done" in their role. Talking through past problems and solutions might be a better predictor.
  - r_c_a_d 8y ago
    You don't need to know anything about a project to spot that the candidate is being very vague when quizzed about the details of something that they claimed but didn't actually work on. And it is surprisingly common.
EZ-E 8y ago
If you ask in-depth questions about their past projects, the challenges they faced, the decisions they had to take, I think it's very possible to find out whether they were major parts of it, or if just small code-pushers who just implemented things like they were told.
- denormalfloat 8y ago
  This would likely result in interviewer bias based on how familiar they are with the project the candidate was working on. How do I fairly compare 10 candidates based on their answer to that question? The interview questions need to be objective and have a clear right answer. If you interview regularly (and work directly with the people you hire), I think the problem with your approach will become obvious.
  - EZ-E 8y ago
    > The interview questions need to be objective and have a clear right answer Then it's a test, not an interview. I don't think interviews were ever supposed to be perfectly objective. If the interview is only based on CS textbook questions, they might as well replace the interviewer with an online test, which by the way increasingly happens for screening, but my point is that it filters out great engineers who worked and delivered solid products because the interviewers are just not interested in details of past work experience
    - denormalfloat 8y ago
      > but my point is that it filters out great engineers who worked and delivered solid products because the interviewers are just not interested in details of past work experience Again, yes. It is hard to fire a bad candidate in case the interview was misleading. Companies would prefer false negatives over false positives. What you see in interviews is a product of laws about hiring and firing.
      - wolfgke 8y ago
        > Companies would prefer false negatives over false positives. If this is the case (i.e. companies can afford this behavior), all the claims about skill shortage are a lie and should be called out.
markatkinson 8y ago
I recently went through an interview process at a few companies. One in NYC, London and Bermuda. The one in NYC required me to do a leetcode style algorithm question. I somehow worked myself into a nervous wreck and bombed out even though I had prepared a lot and could have answered the question in my own time. I ended up landing the London gig and having a fantastic interview experience with the Bermudian company. They all had VASTLY different interview processes but it really made me realise how stupid that whole algorithm/whiteboard process is. I think this perception that the big 3 use it as a filter is even a bit lame and lazy. I've heard they do it because it's more costly to hire a dummy than to miss a star, but I would love to see the data around that. Unless of course they aren't interested in hiring "stars" and just want leetcode monkeys to file in and churn out code with perfect asymptotic behaviour.
gaius 8y ago
It's because lying on a Resume is extremely easy. I do interviews for a large software company about once a week. The relationship between what a candidate says they did and actually doing simple programming problems is non-existent. My C++ interview is pretty easy. No whiteboarding, just a conversation. I want to know for example if this candidate uses templates judiciously or if they are a maniac. Either is fine btw, I’d just like to know. But more times than you’d perhaps think, the candidate has admitted that they don’t know C++ at all, and then the really awkward questions come, such as why did they write it down, then apply for this job, then show up for the interview...

newsbinator 8y ago

Ask them non-trivial questions about the problems they solved and how they solved them.

kamalkishor1991 8y ago
They are likely to know more about the project they were part of then you do. Even if they are really bad.
- newsbinator 8y ago
  That's okay. The important thing is their knowledge of common problem patterns and solution patterns. Ask them how they identified a complex problem, what process they used to get to its root, what they thought was causing it but actually wasn't, which solutions they discarded and why, etc. You don't need to have a better understanding of their project than they have. You just need to determine whether they have the ability to solve complex technicals problems in competent ways, and at what level. For example a more junior person might talk more about solving the problem for today and less about solving the problem for tomorrow. Let them talk it out and see where their attention goes. A more senior person might talk about similar problems they've seen on other projects and how they leaned on past experience to discard non-optimal solutions faster. You don't need an algorithms test to determine if someone is likely to be able to "get stuff done" in their role. Talking through past problems and solutions might be a better predictor.
- r_c_a_d 8y ago
  You don't need to know anything about a project to spot that the candidate is being very vague when quizzed about the details of something that they claimed but didn't actually work on. And it is surprisingly common.

EZ-E 8y ago

If you ask in-depth questions about their past projects, the challenges they faced, the decisions they had to take, I think it's very possible to find out whether they were major parts of it, or if just small code-pushers who just implemented things like they were told.

denormalfloat 8y ago
This would likely result in interviewer bias based on how familiar they are with the project the candidate was working on. How do I fairly compare 10 candidates based on their answer to that question? The interview questions need to be objective and have a clear right answer. If you interview regularly (and work directly with the people you hire), I think the problem with your approach will become obvious.
- EZ-E 8y ago
  > The interview questions need to be objective and have a clear right answer Then it's a test, not an interview. I don't think interviews were ever supposed to be perfectly objective. If the interview is only based on CS textbook questions, they might as well replace the interviewer with an online test, which by the way increasingly happens for screening, but my point is that it filters out great engineers who worked and delivered solid products because the interviewers are just not interested in details of past work experience
  - denormalfloat 8y ago
    > but my point is that it filters out great engineers who worked and delivered solid products because the interviewers are just not interested in details of past work experience Again, yes. It is hard to fire a bad candidate in case the interview was misleading. Companies would prefer false negatives over false positives. What you see in interviews is a product of laws about hiring and firing.
    - wolfgke 8y ago
      > Companies would prefer false negatives over false positives. If this is the case (i.e. companies can afford this behavior), all the claims about skill shortage are a lie and should be called out.

markatkinson 8y ago

I recently went through an interview process at a few companies. One in NYC, London and Bermuda. The one in NYC required me to do a leetcode style algorithm question. I somehow worked myself into a nervous wreck and bombed out even though I had prepared a lot and could have answered the question in my own time. I ended up landing the London gig and having a fantastic interview experience with the Bermudian company. They all had VASTLY different interview processes but it really made me realise how stupid that whole algorithm/whiteboard process is. I think this perception that the big 3 use it as a filter is even a bit lame and lazy. I've heard they do it because it's more costly to hire a dummy than to miss a star, but I would love to see the data around that. Unless of course they aren't interested in hiring "stars" and just want leetcode monkeys to file in and churn out code with perfect asymptotic behaviour.

gaius 8y ago

It's because lying on a Resume is extremely easy. I do interviews for a large software company about once a week. The relationship between what a candidate says they did and actually doing simple programming problems is non-existent. My C++ interview is pretty easy. No whiteboarding, just a conversation. I want to know for example if this candidate uses templates judiciously or if they are a maniac. Either is fine btw, I’d just like to know. But more times than you’d perhaps think, the candidate has admitted that they don’t know C++ at all, and then the really awkward questions come, such as why did they write it down, then apply for this job, then show up for the interview...