4 ms·

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

> 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.
- underwater 15y ago
  That's ridiculous. There are so many things that determine whether a candidate is good outside of how deeply they know language X. There is only so much esoteric knowledge one person can know and you can't expect candidate's specializations to overlap yours. You are being lazy by looking for someone exactly like you (because you obviously know you're experienced) instead of trying to figure out if the candidate is knowledgable in their own right.

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.
underwater 15y ago
That's ridiculous. There are so many things that determine whether a candidate is good outside of how deeply they know language X. There is only so much esoteric knowledge one person can know and you can't expect candidate's specializations to overlap yours. You are being lazy by looking for someone exactly like you (because you obviously know you're experienced) instead of trying to figure out if the candidate is knowledgable in their own right.