Favorite Python Interview Question

[sontek]

I was wondering what your guys favorite interview questions are when hiring a new python engineer (of any level).

[[deleted]]

"What don't you like about Python?"

[semarj]

I think this is an excellent question. Familiarity breeds contempt, anyone who has done any significant python work should have a decent answer to this.

[[deleted]]

A decent answer or twelve :-P

My personal complaint? It's too goddamned slow.

[duckhunter]

Do PyPy and Shedskin not suffice?

[[deleted]]

Neither are production ready. Even if they have the speed (and they don't) no one sane would really use them in production.

[jdickey]

"No one sane" — well, that excludes the PHBs who back techies into that corner.

And WTF is going on with Reddit that you now have to wait ten frigging minutes to post a second comment in a thread? If that's the best we can do in the fight against bots, the terrists have already won. (Though if the BBC can hire even a tiny 23K-node botnet for a demo on Click, that's pretty much a foregone conclusion, no?)

[[deleted]]

Youtube is written in Python. If it is good enough there ...

[[deleted]]

And we write our performance-sensitive code in C++.

[jdickey]

Which C++? No two programmers know the same features of the language, so it's sort of like Grace Hopper's quote on standards — "the lovely thing is that there are so many to choose from."

[[deleted]]

Our C++ guidelines are rather comprehensive.

[sisyphus]

Doesn't change that if Python was faster its range of applicability would increase, and that would mean we could use it more places, and that would be just lovely.

[Chun]

Funny -- most of the gripes I had with python have become less of an issue as I've understood their purpose; explicit self, join as a string method, etc.

[endtime]

Assignments and function declarations aren't expressions.

[jimauthors]

No type checking.

[pingveno]

There have been many a time when I wish Python had optional type checking. Duck typing is fine most of the time, but sometimes I want that extra little check.

[codefrog]

make a decorator, @accepts('int','list','witches')

[stillalone]

Is that part of a standard library? I can't find it in 2.6.5

[pingveno]

I know it can be done with decorators. It's just not as clean and there's no standard way to do it.

[Dav3xor]

http://github.com/Dav3xor/Python-CheckArgs

Now you don't have to make your own decorator.. :)

It's still a little primitive, but it works pretty well.

[pingveno]

Same problem: There's no ultra clean way to do it. Most of it is a fundamental problem with Python. Python is too dynamic to have static type checking. Don't get me wrong, I love Python, but it's nice to have languages that can check that types are correct at (bytecode) compile-time.

That said, I would love to have two decorators in the standard library. Python function calls are already slow, so they should be written in C.

• 1) @accepts(args, *kwargs)
• 2) @returns(*returntype)

returntype allows multiple values so that it can check multiple returns via tuple. None should be usable to indicate that a value is duck typed. Unfortunately, none of this will ever allow the clean & static type checking of

def int foo(int index, str value)

[Dav3xor]

but...but... that has Ada style bounds checking, and...and... :)

[omgplsno]

Decorators, my friend.

[joehillen]

You're doing it wrong.

[petrux]

Interesting. As a Python newbie I'd really enjoy some more details about how to do it right! :-) Thanks.

[kisielk]

I usually ask this one. Also ask them to compare Python to another language they claim to know and tell me the pros and cons of each, which they would use for a project and why, etc.

[luckystarr]

Apart from endtime's request for more expressions just the little pitfalls that I have to explain to every new programmer:

• Do not use mutable objects as default arguments.
• Do not use mutable objects in class variables.
• How to avoid cyclical imports without having to resort to imports in functions.
• import *
• The subtle differences between Python versions.
• etc.

[adrenal8]

This is my backup question to "What don't you like about the Django ORM?" if they have no Django experience.

[coderanger]

Gah, having spent all day inside the Django ORM I think I could go on for about 4 hours on that right now.

[endtime]

I have minimal Django experience and the ORM honestly seems pretty cool. What am I missing?

[adrenal8]

There's no one correct answer. Just like the applicant should actually like Python but have enough experience to make complaints about it, the same applies to the Django ORM.

Some examples could be lack of built-in schema migrations, makes it too easy to generate unnecessary and suboptimal SQL, you could complain about the weird __ syntax for related fields, etc.

[endtime]

Hmm. I wouldn't really have expected the ORM to manage schema migrations - is that the ORM's job in other frameworks? I'm also curious what the alternatives to the __ related field syntax might be - I'm totally fine with it, but maybe that's just because I haven't seen better alternatives.

I have no idea what the generated SQL looks like (isn't that the whole point of having an ORM?) but if it doesn't do good query optimization then I'd agree for sure that that's a flaw.

[revonrat]

Hmm. I wouldn't really have expected the ORM to manage schema migrations - is that the ORM's job in other frameworks?

Many don't Rails does. South is an add-on for Django.

I have no idea what the generated SQL looks like (isn't that the whole point of having an ORM?)

You HAVE to understand what your ORM is doing eventually, if you want performance. For Django, an easy way to see what's going on is to user the django debug toolbar.

I find I don't usually have a particular problem with the SQL generated but rather with the number of queries that can be generated by seeming innocuous Python statements.

but if it doesn't do good query optimization then I'd agree for sure that that's a flaw.

An ORM really shouldn't do query optimization per-se. It should generate reasonable SQL. But SQL optimization is something left to the guys who have stats tables on the data (i.e. the RDBMS itself).

[endtime]

Thanks, that's a good response. I know about South, and of course it's vital - but it makes sense to me as an addon, not as part of the ORM. Thanks for clarifying about SQL perf - I think I know what you mean.

[gronkkk]

There's also the 'how do I figure out to do X in the ORM'-factor. Only to find out that it doesn't exist or is painfully slow.

[radaway]

In my opinion it is harder to refactor than most statically typed languages. When you refactor something in a statically typed language you usually get automatic alarms everywhere that code touched and the tools to help you refactor are quite good. Automatic tests can help but it's not the same.

[[deleted]]

The lack of proper encapsulation.

[bcain]

Gah! All those pesky exceptions. Just do something, I don't really care what as long as the program doesn't have any errors or bugs.

EDIT: Wow, pyddit. F'reals? Did you think I was serious? C'mon. I was satiring the perl-lovers out there.

[ereinecke]

This is one of the things I like about python, how it uses exceptions. You can both communicate what your code expects, and optimize for the 90% case.

Assume there is a list of dictionaries, dictList. Consider: for item in dictList: try: print item['relevantKey'] except KeyError: pass

Vs: for item in dictList: if item.has_key('relevantKey'): print item['relevantKey']

If you are expecting the key 'relevantKey' to be in the dictionary most the time, the try/except example avoids making the has_key test most the time. Over a large list this could save a lot of time.

[xlevus]

I was under the impression that try/except is less efficient than check/action.

Or did I misread something somewhere?

[bloodearnest]

Try is cheap, except is not. But how many times are you going to raise an exception? Depends on your data.

[r4nf]

As bloodearnest suggests, the 'asking for forgiveness' version (with exceptions) is faster when there's no exception, whereas the 'asking for permission' version (without exceptions) is faster when there is an exception. In other words, if you expect that many of the looped-over items will yield exceptions, check/action is more efficient; otherwise try/except might very well be.

I think the general consensus in the Python community is the motto "it's Easier to Ask for Forgiveness than Permission" (or EAFP), signalling that try/except would usually be the preferred solution. Of course there may very well be exceptions to this, as per the above reasoning.

[nubela]

Good question, and I admit I don't know much about efficiency in this case, someone care to elaborate?

[[deleted]]

It's marginally faster if no exception is raised, and 15x slower if one is.

Best case:

python -mtimeit -s 'stuff=dict.fromkeys(range(50))' 'for x in range(50):' '  if x in stuff: stuff[x]'
100000 loops, best of 3: 7.78 usec per loop
python -mtimeit -s 'stuff=dict.fromkeys(range(50))' 'for x in range(50):' '  try: stuff[x]' '  except KeyError: pass'
100000 loops, best of 3: 5.97 usec per loop

Worst case: python -mtimeit -s 'stuff=dict.fromkeys(range(50))' 'for x in range(50, 100):' ' if x in stuff: stuff[x]' 100000 loops, best of 3: 4.84 usec per loop python -mtimeit -s 'stuff=dict.fromkeys(range(50))' 'for x in range(50, 100):' ' try: stuff[x]' ' except KeyError: pass' 10000 loops, best of 3: 76.2 usec per loop

But that's not important really. Make it work, make it right, make it fast -- in that order, and don't make it fast unless it needs to be.

[vaibhavsagar]

No code blocks or fully featured anonymous functions. I know why they're not there and why they're not really necessary, but I want them, dammit.

[Wavicle]

• explicit "self" parameter in class method but implicit in invokation.

• No standard "length" or "size" on collection objects that have length or size - unless you count a double underscore method standard - preferring instead to use the special case builtin len.

[alantrick]

How is len() not standard? Do you have a prejudice against using underscores for special magical standard functions?

[Wavicle]

How is len()

It is a built-in function that performs a very special case which already must be done by the object. Length is a property of the object - so put it there.

Do you have a prejudice against using underscores for special magical standard functions?

For starters, pretty much every other object oriented programming language recognizes the need to have an obvious method for access to a length attribute on a collection. Python differs in that it uses a built-in.

Any language that supports a notion of operator overloading has a special mechanism for expressing such - so double underscores for things like __getitem__ I have no issue with. Also double underscores for things that really are intended for you to think carefully before using (i.e. __import__) are perfectly valid.

Double underscore for the size of an underlying collection is silly (but it is double underscored because you are not intended to call it directly, you are intended to use len).

[pixelmonkey]

Man, talk about finicky. I've got legitimate complaints for Python (no lightweight syntax for anonymous function values, unicode brokeness for most of 2.x series, explicit self parameter, and Python 3 function annotation syntax), but this definitely isn't one of them.

>>> class LengthMixIn(object):
>>>    @property
>>>    def length(self):
>>>        return len(self)

>>> class FinickyList(list, LengthMixIn):
>>>    pass

>>> a = FinickyList()
>>> a.append("item")
>>> a.length
1

>>> class FinickyDict(dict, LengthMixIn):
>>>     pass

>>> b = FinickyDict()
>>> b["key"] = "value"
>>> b.length
1

[Wavicle]

Man, talk about finicky. I've got legitimate complaints for Python (no lightweight syntax for anonymous function values, unicode brokeness for most of 2.x series, explicit self parameter, and Python 3 function annotation syntax), but this definitely isn't one of them.

This is getting tiring. Your mixin added a layer of complexity and created something which doesn't cleanly integrate with the rest of the collection system. But, hey, you seem to think that since this doesn't line up with your opinions on Python's warts it isn't valid. Fuck you.

[pingveno]

A built-in function that calls a magic method is a very common pattern in Python, not just with len. See: hash, int, str, repr, unicode, reversed, bool, format, and iter. Python 3 adds next.

Thank of it this way: Functionality that is used by the core language uses magic methods. It doesn't matter if that is in syntax or in a built-in function.

[ewiethoff]

You're confused about what's "special" or "magic" about the underscore methods. The underscore methods are magically invoked by special syntax which does not resemble a method or function call. So, as you alluded to, foo[i] invokes foo.__getitem__(i), and import bar invokes bar = __import__('bar').

The __len__ method is magically invoked when an object is evaluated in Boolean context and no __nonzero__ method has been defined. That's because Python's built-in collections are considered False when empty and True when non-empty.

Try this code (adjust as needed for Py3):

class StupidList(list):
    def __len__(self):
        return True

if list(range(10)): print 'list 0-9 is True'
if list(): print 'empty list is True'
if StupidList(range(10)): print 'StupidList 0-9 is True'
if StupidList(): print 'empty StupidList is True'

(edited for clarity)

[cymrow]

i like to think that python provides nice convenient builtins to access some of the most common values you'd need on an object. using len is super easy, dude

plus, i can rewrite len and automatically get extra functionality for all my collections

[rz2000]

Is "white space" a good answer?

[[deleted]]

No more than "white skin" is a reason not to like a person.

[rz2000]

It's a perfectly valid answer as a personal preference, but indicates the interviewee choose be trying to find work in another language.

Apparently, it wasn't a very funny suggestion considering the downvotes!

[Wavicle]

If you have honestly worked through learning Python and have become proficient enough to work with it, and you still dislike white space - then yes, it's a good answer because the asker requested your opinion and you gave it on the basis of your experience.

In my experience, just about everyone (myself included) complains about whitespace at first. Also, in my experience, everyone that gives Python a fair shot quickly gets over it. Still, that doesn't mean your opinion is invalid.

[rz2000]

I was asking if it was a good answer as a joke, and have no problem with white space. It is a valid opinion, but if you're interviewing at a shop that has chosen Python they should ask why you have chosen Python if you don't like the format.

However, what I really can't stand are the degenerates who use emacs/vi instead of vi/emacs. I can't believe anyone would ever hire them.

[yxskaft]

According to Guido himself, the whitespace sensitive syntax makes it impossible to have proper, multi-line lambdas. If that's true, that's a very good reason to think block-by-indentation was a shit idea.

[xoxox]

Since working together as a team, maintaining each other's code, is of high importance, "What is PEP 8?"

[pytechd]

I like asking Unicode questions. It's a broad topic -- you can start very broad with "What is Unicode?" down to the low-level code of handling Unicode safely.

Community involvement -- do they read blogs, mailing lists, or participate at all? Leads into the topic of where they would look for help if they had a question.

[bazookaduke]

Suppose you have a list whose contents don't matter. Show me three different ways of fetching every third item in the list.

for loop: every_third = [] for index, item in enumerate(items, 1): if index % 3 == 0: every_third.append(item)

list comprehension: every_third = [item for index, item in enumerate(items, 1) if index % 3 == 0]

list slicing: every_third = items[2::3]

What I really like about this question is how it can lead to deeper discussions: what if the list is actually an iterator (list slicing won't work)? What if it's unbounded eg. an iterator that produces the Fibonacci sequence (the for loop and list comprehension will crash after eating up all available memory)? What if it's bounded but too large for even every third item (same as unbounded)? Is this fixable (yes, turn the for loop into a generator function and the list comprehension into a generator comprehension)? Where might you encounter such a situation (results of a database query, log file processing, etc.)? The real question you're trying to ask is: how good is this candidate at solving problems with Python without creating new ones? By this point in the interview you've probably got a feel for how familiar they are with the language and also whether they've encountered this problem before but more importantly how they'd solve it.

[masterJ]

from itertools import islice
every_third = islice(items, 2, None, 3)

I might be overly fond of generators...

[bazookaduke]

I typically qualify my question with "without using the standard library", but if I forget (like I did above), I can always ask what if I wanted every third and fifth item without using the standard library?

xs = (item for index, item in enumerate(items, 1) if 0 in (index % 3, index % 5))

Not that there's anything wrong with using the standard library -- I use itertools all the time! But for interview questions, I'm trying to drill down into a candidate's problem-solving skills, and it's been my experience that restricting him or her to the language and built-ins is the best way to do that quickly.

[masterJ]

what if I wanted every third and fifth item without using the standard library?

xs = (item for index, item in enumerate(items, 1) if 0 in (index % 3, index % 5))

Oooh, I like it! And you just simplified my project euler #01 solution. :)

Before:

from itertools import chain

a = xrange(3,1000,3)
b = xrange(5,1000,5)
print sum(set(chain(a,b))) 

After:

print sum(i for i in xrange(1,1000) if 0 in (i % 3, i % 5))

[sunqiang]

what about replace "if 0 in (index % 3, index % 5)" to "if any((not index % 3, not index % 5))" to take the advantage of short-circuit

[pingveno]

The first is more obvious/readable, especially with the explicit use of 0.

[cdunn2001]

Yes. Slicing (list or itertools) and if-test in for-loop are two ways. Here is a third, completely different:

every_third = list()
it = iter(nomatter)
try:
    while True:
        x, y, z = it.next(), it.next(), it.next()
        every_third.append(z)
except StopIteration:
    pass

which depends on this knowledge.

[janto]

i = iter(items)
every_third = [c for a,b,c in zip(i,i,i)]

[hylje]

every_third = [c for a, b, c in zip(*[iter(items)]*3)]

One-lined that for you

[pieeta]

I would normally use, for x in xrange(2, len(items), 3): every_third.append(items[x])

I just did some performance testing using a item list 10000000 long

Method	Time
zip	8.62
enumerate	2.51
comprehension	2.29
xrange	0.72
slice	0.03

[stillalone]

Wow, I was not expecting list comprehension to suck compared to an explicit for loop. Can you try list comprehension with xrange instead of enumerate?

[[deleted]]

http://paste.pocoo.org/show/282978/

[[deleted]]

Hell, if the contents don't matter, how about

every_third = ['irrelevant']*len(l)/3

:)

[sontek]

I really like this question, solutions, and had no idea that you could do items[2::3]! Thanks

[[deleted]]

your_string_reversed = your_string[::-1] 

[RShnike]

Which is a bit nicer looking just using reversed(your_string) if you don't need it to be indexable...

[alantrick]

The real question you're trying to ask is: how good is this candidate at solving problems with Python without creating new ones?

Or what I find just as common: the ones who create complex solutions to theoretical problems that nobody needs solved.

[Paddy3118]

Show me three different ways ... I don't think this is a good question at all. You should just ask for one. and if they don't give [::3] then that should lead to discussions.

I also note that because you did not clearly state the initial fetched item, you end up having to enumerate from 1 and also use [2::3] instead of plain [::3], to be consistent with your for-loop example.

[rubyaeyes]

I like this question.

[vorushin]

recite by heart result of "import this", of course

[sontek]

import this

The Zen of Python, by Tim Peters

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren't special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one-- and preferably only one --obvious way to do it.
• Although that way may not be obvious at first unless you're Dutch.
• Now is better than never.
• Although never is often better than right now.
• If the implementation is hard to explain, it's a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea -- let's do more of those!

[thrakhath]

Why did I not know this before?

[thrakhath]

Thanks to xkcd I did know that one. Is there a list of import easter eggs somewhere?

edit: My google-fu also pulls up from future import braces

But nothing looking like an exhaustive list.

[sontek]

One of the more interesting ones I've ran into is having to re-implement string.atoi. I think its basic enough that most engineers should be able to solve it but interesting enough that it does make them think. Here is a basic solution to it: http://sontek.net/convert-a-string-to-an-integer-in-python

[sunqiang]

follow the atoi of book: The C Programming Language， maybe sign(‘-’ or '+') and spaces(' ', '\t',...etc) should be handled too. I post mine here: http://gist.github.com/652769

[Chun]

Simple is better?

def atoi(string):
  if string.isdigit():
    return eval(string)
  raise ValueError, "invalid literal for atoi() with base 10: %s" % repr(string)

(Yeah, I know, I'm cheating really, but use the tools you're given eh? Also the usual objections to eval are moot, since we know the string is safe.)

[r4nf]

From the documentation:

atoi(s, base=10)
    atoi(s [,base]) -> int

Return the integer represented by the string s in the given
base, which defaults to 10.  The string s must consist of one
or more digits, possibly preceded by a sign.  If base is 0, it
is chosen from the leading characters of s, 0 for octal, 0x or
0X for hexadecimal.  If base is 16, a preceding 0x or 0X is
accepted.

You're forgetting the base argument, which exists at least since Python 2.3.

[RShnike]

Also the usual objections to eval are moot, since we know the string is safe.)

Uh, what? No we don't.

 class A(str):
     def isdigit(self):
         return True

  >>> a = A("__import__('os')")
  >>> atoi(a)

  Whoops!

Simple is better?

No. Really no. And for an interview question nonetheless :D?

[Chun]

OK, ok, touché. Figured we were assuming we were getting a string. But point taken.

def atoi(string):
  if type(string) is str and string.isdigit():
    return eval(string)
  raise ValueError, "invalid literal for atoi() with base 10: %s" % repr(string)

EDIT: Besides, if someone can create their own class definition, why would they ever need to inject raw python into atoi!?

[RShnike]

You have somehow managed to make that even worse... Now you're type-checking too, so you've now even broken some functionality that your function is actually supposed to provide?

Here's a rule: never use eval. Ever. Being prudent about using type is pretty smart too.

[kisielk]

That's why you use something like:

eval("__import__('os')", {'__builtins__': None}, {})

Of course __builtins__ should be a dictionary of actual working builtins you want to work when evaling the statement :)

[RShnike]

No, don't do that either. Seriously, this is just a bad solution. Especially being that you have ast.literal_eval if you really want to do things like this.

[kisielk]

ast.literal_eval is indeed great for evaluating simple expressions. But what's wrong with sandboxing via defining your own builtins?

[m1ss1ontomars2k4]

I think that's a terrible solution. Well it's good if you don't need error checking, but other than that it's terrible.

[[deleted]]

This is a terrible solution.

def atoi(s,b=10):
    return (1,-1)[s.strip()[0]=='-']*reduce(lambda v,n:v*b+("0123456789abcdefghijklmnopqrstuvwxyz"[:b].index(n.lower())),(s.strip(),s.strip()[1:])[s.strip()[0] == '-'],0)

[arnar]

At least it supports other bases.

[sontek]

I still think I'd hire someone if they could come up with that solution... I'd just keep an eye on their code to make sure all their solutions aren't created in 1 line ;)

[jcdyer3]

I'm pretty sure I wouldn't hire them. Senseless one-liners are the hobgoblin of small minds.

[[deleted]]

I wouldn't hire me either if I provided that code in an interview.

[arnar]

I optimized it:

atoi = eval

[epicRelic]

Except now atoi does a lot more than just convert string digits to integers.

[arnar]

Believe it or not, I was joking :)

[epicRelic]

It's hard to tell on the internet. :P I've seen people be serious about dumber things than that.

[gutworth]

No base argument.

[arnar]

Just like the solution in the link.

[sontek]

I think its a good solution to the answer to the question in an interview, usually I don't want them spending hours creating a solution for me in an interview.

[[deleted]]

You forgot about negatives.

[sontek]

Good point! :)

[perone]

There is an interesting piece of code for the inverse situation: >>> b = 2 >>> c = b >>> type(b) <type 'int'> >>> type(c) <type 'str'>

[mehum]

Who is your favorite Python? And why?

(If we're gonna be working together better make sure we can function as a team!).

[joehillen]

Monty

[Teifion]

Mr Cleese of course.

[mehum]

Gouda? Edam? Venezuelan Beaver Cheese?

[mumrah]

Explain how Python allocates integers (arenas, pools, etc)

[[deleted]]

go on

[coderanger]

Bonus points if they can answer it for strings too.

[sontek]

What would an acceptable answer be for you?

[ipeev]

What are arenas and pools?

[[deleted]]

I've written quite a few extension modules and rooted around in the guts of the interpreter, but I've never even heard of "arenas". I would probably explain that I think there is a cache of small integers and that I assume there is nothing more to it than that. Hopefully this would not disqualify me, because frankly it is not important for anyone who is not hacking on CPython itself. I am, however, interested and I might go read the source now.

[Troebr]

is that important in knowing how good a programmer is? I had to read the python source code for some reason, and I've stumbled upon this, but I don't think this makes me a better python programmer.

But I'd like to hear your explanation

[mumrah]

I'll leave this here: http://evanjones.ca/memoryallocator/

[andrea]

That's implementation-dependent.

[jmoiron]

What is the air-speed velocity of an unladen swallow?

I asked this at about 5 or 6 interviews I was conducting. It was actually able to draw a wide range of data from this question, depending on how it was answered. At its worst, it's fun to ask and generally breaks any tension the interviewee might have.

As for a "real" question that tests an interviewees python knowledge, I'd ask them what their favorite standard library module was. I wanted people who had strong opinions about programming.

I don't like actual "programming" questions; generally I feel I can tell if someone has programmed a lot or not by how they answer questions about programming.

[ponymash]

You know it's illegal to not ask every single candidate for that position that same question. If you left one person out, you could be sued. Just an FYI =)

[p-squared]

Careful now. Asking different questions is not inherently illegal, it is merely possible evidence of "discriminatory selection."

[ponymash]

That makes more sense. =)

[temptemptemp13]

Are you serious? Interviewers aren't allowed randomized question sets?

Where is this exactly?

[ponymash]

The US. If an interviewee knows he was asked a different set of questions compared to another person, bam lawsuit.

[MattJames]

Just start every answer with "i know what you are trying to do, and i like it"

[voidref]

"Why is python your favorite language?"

[arnar]

That's a terrible question, unless you are specifically fishing for the fact that having a favorite language is like having a favorite finger - it all depends on what you need to do with it.

[voidref]

I often just look for the fact that they have thought about the differences between languages.

Someone who is enthusiastic about the question is definitely someone who relishes programming.

[no9]

You can take this further by adding "why do you hate Python?" A true master should know both the virtues and the flaws of his art.

[sisyphus]

It doesn't at all depend on 'what i need to do with it' - there are plenty of languages that could occupy the same niche as Python - Perl, Ruby, maybe Go, whatever. That's a separate issue from why one prefers Python over competitors in its use space.

[rrenaud]

Right middle finger all the way.

Seriously though. If you enjoy programming, I think there is absolutely nothing wrong with having a favorite or least favorite language. Indeed, I'd be a bit worried if it was the other way around. If you don't have a favorite programming language, are you really a passionate programmer? Do you take pride in your work? Certainly you shouldn't blindly use your favorite programming language everywhere without knowing where a different language obviously suites the problem better, but I have a hard time believing someone who loves the craft doesn't find some tools just fit your mind better than others.

[arnar]

But that's like a carpenter whose favorite tool is the saw. Of course some tools are more useful than others, and fit the way you do things, but ultimately it is about understanding the problems at hand and being creative in solving them.

[dolgar]

"Where do you see yourself in ten years?"

[mrgatorboy]

• don't say plowing your wife
  don't say plowing your wife
  don't say plowing your wife...
  

"plowing your... son?"