2 ms·
>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 as
by 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 agoEww, 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 agoWell 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 agoThat'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 agoNo, if someone claims he has experience with Python, and I've seen a few of the self proclaimed python gurus, that question will provide a quick filter. And you don't have to get it right, but when I show you the result I expect you to be able to backtrack and reason about what's happening on the spot. And there are other advanced things, for eg. meta-classes, multiple inheritance and dispatch order, etc. Not things that you need to know on the top of your head but should be able to reason about when provided the context. And this really isn't that esoteric, it's the sort of thing that separates newbies from experienced programmers, if you've written a decent amount of python code chances are you will know at least a few of the edge cases. And that question is only in response to jpdoctor saying that details can matter, I was saying I agree that some details can help but others are just useless trivia questions that make you look bad. Also the language was just the first thing that came to mind, you can use a common library/framework/tool quirk, etc. Anything that shows familiarity with the required tools.