3 ms·

> If you needed someone to build your house, which method would you choose? Both. The first method provides better protection against talented bullshitters, t

> If you needed someone to build your house, which method would you choose? Both. The first method provides better protection against talented bullshitters, the second provides better insight into the candidate's work. There is nothing wrong with examining the level of details somebody has at their fingertips. If they don't have the specific detail immediately handy, watching (and perhaps collaborating) with the person to find detail-type info gives you insight into whether they have a suitable user-interface when you need information from them.

moonchrome 15y ago
>The first method provides better protection against talented bullshitters Assuming that your skill level is above that of a talented bullshitter it shouldn't be that hard to drill deeper in to the previous projects with specifics. You don't necessarily need to even know the field, if you're a competent programmer you should at least get a feeling of how skilled/technical the other person is. And I'm willing to bet that that information will be a lot more reliable than the "what package is Foo in ?". IMO using the first approach you concede that you aren't skilled enough to meaningfully evaluate the previous work/ skills, which is fine for contracting small work on your home, but you should consider third party evaluation/insurance service for anything big. In a interview scenario using this approach tells me I'm being interviewed by technically illiterate person that can't or won't use someone with more technical ability to do the evaluation, and both can't/won't options tell me that this company probably isn't for me.
- jpdoctor 15y ago
  > IMO using the first approach you concede that you aren't skilled enough to meaningfully evaluate the previous work/ skills Only to those who confuse a test on details with ignorance of a field. There is a wonderful scene in The Seven Samurai. The leader is testing the prospective candidates one-by-one as they walk into the "interview" room. There is a junior fighter hidden behind the doorway who attacks each prospective samurai as he walks through the door. Most of the fighters dispatch the junior fighter without much ado, and forgive the "interviewer" understanding that he must test each one of them. There is one candidate who stands outside the door before walking in and says (paraphrased): Please, skip the attack that I know you have planned; It is a waste of energy. He does this in such a way that it is clear he will dispatch the junior fighter even before fighting. Then there is one candidate who is unaware and gets whacked over the head. The scene is a wonderful summary of interviewing candidates. (And a great movie too, fwiw.)
  - moonchrome 15y ago
    >Only to those who confuse a test on details with ignorance of a field. There are insightful details that you only catch by working with something, eg. If I ask you what will the following python code print : def default(): print("using default arguments [1, 3]") return [1, 3] def append_five(a=default()): a.append(5) return a print(append_five()) print(append_five([1, 3])) print(append_five()) print(append_five([9, 7])) I expect you to know the "detail" of python handling default arguments, even tough it's non obvious anyone with decent amount of experience in python has probably been bitten by that behavior, you'd have to be a master bullshitter to guess that one. Similarly there are many such nuggets that could be used to determine if someone has actual experience/skill with the language/tools vs. reading the brochure before the interview and did his homework in college. But this is not the same as asking what package contains what class, and similar petty details that you think are good questions because you looked them up in the documentation before the interview. I would expect many good programmers to miss that and bad ones get it right. Knowing the answer to the above question vs. knowing the name of the Java clusterfuck naming convention IMO gives a very different level of insight in to the experience of a programmer.
    - ekidd 15y ago
      Eww, that's a nasty bug, though Python certainly isn't the first language to have it. IIRC, Dylan's "init-value" for class slots did much the same thing. But really, this question only tells you whether a candidate is lying about Python experience on their résumé. If the candidate answers, "I have no idea. But I have 5 years of Ruby experience, and many years of Perl before that, and I can be competent in Python within a month or so," this question tells you nothing either way. I've always been delighted to hire a really good programmer. I'm usually not too picky about which languages they're really good at.
      - moonchrome 15y ago
        Well technically it's not a bug - it's by design :) But I agree completely, which is why I said you should be able to evaluate the previous work trough the interview, even if you don't know the specific technology (eg. If I was interviewing someone for a Django/Python gig and he has RoR experience ~10-15 minutes of interviewing about a previous project that he thinks is representative would be enough to figure out if he's winging it or he knows what he's talking about, it's cool if someone misses something but he should be able to reason about things on the fly, eg. in the above gotcha I expect you to figure out what's happening when I tell you the result if you didn't get it right away). I'm just saying - some details can be useful, eg. if I knew Ruby or Rails I could ask about a few similar details that separate the men from the boys - but asking what namespace is foo located in isn't going to provide useful information and puts you in the PHB class of people who don't realize that their lack of skill is preventing them from creating good evaluation tools and can't delegate the responsibility to someone skilled - the kind of environment I would want avoid at all costs.

moonchrome 15y ago

>The first method provides better protection against talented bullshitters Assuming that your skill level is above that of a talented bullshitter it shouldn't be that hard to drill deeper in to the previous projects with specifics. You don't necessarily need to even know the field, if you're a competent programmer you should at least get a feeling of how skilled/technical the other person is. And I'm willing to bet that that information will be a lot more reliable than the "what package is Foo in ?". IMO using the first approach you concede that you aren't skilled enough to meaningfully evaluate the previous work/ skills, which is fine for contracting small work on your home, but you should consider third party evaluation/insurance service for anything big. In a interview scenario using this approach tells me I'm being interviewed by technically illiterate person that can't or won't use someone with more technical ability to do the evaluation, and both can't/won't options tell me that this company probably isn't for me.

jpdoctor 15y ago
> IMO using the first approach you concede that you aren't skilled enough to meaningfully evaluate the previous work/ skills Only to those who confuse a test on details with ignorance of a field. There is a wonderful scene in The Seven Samurai. The leader is testing the prospective candidates one-by-one as they walk into the "interview" room. There is a junior fighter hidden behind the doorway who attacks each prospective samurai as he walks through the door. Most of the fighters dispatch the junior fighter without much ado, and forgive the "interviewer" understanding that he must test each one of them. There is one candidate who stands outside the door before walking in and says (paraphrased): Please, skip the attack that I know you have planned; It is a waste of energy. He does this in such a way that it is clear he will dispatch the junior fighter even before fighting. Then there is one candidate who is unaware and gets whacked over the head. The scene is a wonderful summary of interviewing candidates. (And a great movie too, fwiw.)
- moonchrome 15y ago
  >Only to those who confuse a test on details with ignorance of a field. There are insightful details that you only catch by working with something, eg. If I ask you what will the following python code print : def default(): print("using default arguments [1, 3]") return [1, 3] def append_five(a=default()): a.append(5) return a print(append_five()) print(append_five([1, 3])) print(append_five()) print(append_five([9, 7])) I expect you to know the "detail" of python handling default arguments, even tough it's non obvious anyone with decent amount of experience in python has probably been bitten by that behavior, you'd have to be a master bullshitter to guess that one. Similarly there are many such nuggets that could be used to determine if someone has actual experience/skill with the language/tools vs. reading the brochure before the interview and did his homework in college. But this is not the same as asking what package contains what class, and similar petty details that you think are good questions because you looked them up in the documentation before the interview. I would expect many good programmers to miss that and bad ones get it right. Knowing the answer to the above question vs. knowing the name of the Java clusterfuck naming convention IMO gives a very different level of insight in to the experience of a programmer.
  - ekidd 15y ago
    Eww, that's a nasty bug, though Python certainly isn't the first language to have it. IIRC, Dylan's "init-value" for class slots did much the same thing. But really, this question only tells you whether a candidate is lying about Python experience on their résumé. If the candidate answers, "I have no idea. But I have 5 years of Ruby experience, and many years of Perl before that, and I can be competent in Python within a month or so," this question tells you nothing either way. I've always been delighted to hire a really good programmer. I'm usually not too picky about which languages they're really good at.
    - moonchrome 15y ago
      Well technically it's not a bug - it's by design :) But I agree completely, which is why I said you should be able to evaluate the previous work trough the interview, even if you don't know the specific technology (eg. If I was interviewing someone for a Django/Python gig and he has RoR experience ~10-15 minutes of interviewing about a previous project that he thinks is representative would be enough to figure out if he's winging it or he knows what he's talking about, it's cool if someone misses something but he should be able to reason about things on the fly, eg. in the above gotcha I expect you to figure out what's happening when I tell you the result if you didn't get it right away). I'm just saying - some details can be useful, eg. if I knew Ruby or Rails I could ask about a few similar details that separate the men from the boys - but asking what namespace is foo located in isn't going to provide useful information and puts you in the PHB class of people who don't realize that their lack of skill is preventing them from creating good evaluation tools and can't delegate the responsibility to someone skilled - the kind of environment I would want avoid at all costs.