Python Interview Questions

[Krypto]

Hi,

I have used Python for a couple of projects last year and I found it
extremely useful. I could write two middle size projects in 2-3 months
(part time). Right now I am a bit rusty and trying to catch up again
with Python.

I am now appearing for Job Interviews these days and I am wondering if
anybody of you appeared for a Python Interview. Can you please share
the questions you were asked. That will be great help to me.

Thanks,

[Tim Chase]

I have used Python for a couple of projects last year and

I found it extremely useful. I could write two middle size
projects in 2-3 months (part time). Right now I am a bit
rusty and trying to catch up again with Python.

I am now appearing for Job Interviews these days and I am
wondering if anybody of you appeared for a Python
Interview. Can you please share the questions you were
asked. That will be great help to me.

While I haven't interviewed precisely for Python, I've been
on the other (interviewing) end and can offer a few of the
sorts of things I ask. I don't expect perfect answers to
all of them, but they show me a range of what the
interviewee knows. I try and give a scattershot of
questions from the following areas to try and narrow down
where they fall in terms of pythonability, and then grill
more deeply around the edges that I find.

Basic Python:
=============
- do they know a tuple/list/dict when they see it?

- when to use list vs. tuple vs. dict. vs. set

- can they use list comprehensions (and know when not to
abuse them? :)

- can they use tuple unpacking for assignment?

- string building...do they use "+=" or do they build a list
and use .join() to recombine them efficiently

- truth-value testing questions and observations (do they
write "if x == True" or do they just write "if x")

- basic file-processing (iterating over a file's lines)

- basic understanding of exception handling

Broader Basic Python:
=====================
- questions about the standard library ("do you know if
there's a standard library for doing X?", or "in which
library would you find [common functionality Y]?") Most
of these are related to the more common libraries such as
os/os.path/sys/re/itertools

- questions about iterators/generators

- questions about map/reduce/sum/etc family of functions

- questions about "special" methods (__<foo>__)

More Advanced Python:
=====================
- can they manipulate functions as first-class objects
(Python makes it easy, but do they know how)

- more detailed questions about the std. libraries (such as
datetime/email/csv/zipfile/networking/optparse/unittest)

- questions about testing (unittests/doctests)

- questions about docstrings vs. comments, and the "Why" of
them

- more detailed questions about regular expressions

- questions about mutability

- keyword/list parameters and unpacked kwd args

- questions about popular 3rd-party toolkits (BeautifulSoup,
pyparsing...mostly if they know about them and when to use
them, not so much about implementation details)

- questions about monkey-patching

- questions about PDB

- questions about properties vs. getters/setters

- questions about classmethods

- questions about scope/name-resolution

- use of lambda

Python History:
===============
- decorators added in which version?

- "batteries included" SQL-capible DB in which version?

- the difference between "class Foo" and "class Foo(object)"

- questions from "import this" about pythonic code

Python Resources:
=================
- what do they know about various Python web frameworks
(knowing a few names is usually good enough, though
knowledge about the frameworks is a nice plus) such as
Django, TurboGears, Zope, etc.

- what do they know about various Python GUI frameworks and
the pros/cons of them (tkinter, wx, pykde, etc)

- where do they go with Python related questions (c.l.p,
google, google-groups, etc)

Other Process-releated things:
==============================
- do they use revision control
(RCS/CVS/Subversion/Mercurial/Git...anything but VSS) and
know how to use it well

- do they write automated tests for their code

Touchy-feely things:
====================
- tabs vs. spaces, and their reasoning

- reason for choosing Python

- choice of editor/IDE

Good luck with your interviewing and hope this helped,

-tkc

[Krypto]

Good luck with your interviewing and hope this helped,

-tkc

Well, I was looking exactly for this. Many thanks to you Tim. After
going through your list I came to know that I know nothing in Python
and have to catch up a whole lot.

[Tim Chase]

>Good luck with your interviewing and hope this helped,

>>
-tkc

Well, I was looking exactly for this. Many thanks to you Tim. After
going through your list I came to know that I know nothing in Python
and have to catch up a whole lot.

It was certainly not an exhaustive list of "you must know
everything on this list or else you'd never get hired", or
conversely, it's also not a "if you don't know everything on this
list, you're not worthy to call yourself a Python programmer".

It's a way I've found to gauge what somebody means when they say
the program in Python. I've had the gamut of folks where that
phrase means anything from "I glanced at some Python code once"
to "I'm Guido" (okay, so that's a bit of hyperbole, but you get
the idea). My goal is to use as few questions as possible to
flush out just what an interviewee mean by "I program in Python".

Hanging out here on the c.l.p list will introduce you to a lot of
these ideas on the sly. For my "basic" categories,
lists/tuples/dicts/sets as well as list-comprehensions show up
here regularly; I've answered several on basic file processing in
the last day or two (iterate over a file object, doing something
with each line); you see truth-testing regularly (and
chastizement when folks do things like "if foo == True"); you see
basic exception handling...all the basic stuff is regularly
covered/used here.

Knowledge of the available system libraries comes with using them
and having need for them. I'm still learning it. I finally
tired of writing my own command-line parsers and investigated
what the std. lib had to offer, only to find that optparse did
everything I needed: cleanly, readably, and extensibly. So now I
use that instead. That sort of experience only comes from time
emersed in using Python to solve problems.

All that to say, don't sweat it too badly, and that fortunately
Python is an easy language to work with.

-tkc

[Ben Finney]

Krypto <kr***********@gmail.comwrites:

I am now appearing for Job Interviews these days and I am wondering
if anybody of you appeared for a Python Interview. Can you please
share the questions you were asked. That will be great help to me.

I've given some interviews for programming positions. I find it
worthless to ask questions about the language; instead, I ask the
applicant *what they've done* with the language.

Then, I ask them to write some code, usually something simple but
poorly-specified, and observe their approach to the task. That tells
me far more about their knowledge of the language than answers to quiz
questions; it also tells me far more about them as a programmer, which
is what I actually care about.

--
\ "Any intelligent fool can make things bigger and more |
`\ complex... It takes a touch of genius – and a lot of courage |
_o__) – to move in the opposite direction." —Albert Einstein |
Ben Finney

[konryd]

- string building...do they use "+=" or do they build a list
and use .join() to recombine them efficiently

I'm not dead sure about that, but I heard recently that python's been
optimized for that behaviour. That means: using += is almost as fast
as joining list. Besides, "+=" is more obvious than the other choice
and since performance is not a problem until it's a problem, I'd
rather use it. Anyway: I wouldn't pick it for an interview question.

regards
Konrad

[Steven Bethard]

konryd wrote:

>- string building...do they use "+=" or do they build a list
and use .join() to recombine them efficiently

I'm not dead sure about that, but I heard recently that python's been
optimized for that behaviour. That means: using += is almost as fast
as joining list.

For some simple cases, this is true. But it only works in CPython, not
say Jython. So it's a better practice to continue using .join().

STeVe

[Rhamphoryncus]

On Oct 31, 2:58 am, konryd <[e-mail]:

- string building...do they use "+=" or do they build a list
and use .join() to recombine them efficiently

I'm not dead sure about that, but I heard recently that python's been
optimized for that behaviour. That means: using += is almost as fast
as joining list. Besides, "+=" is more obvious than the other choice
and since performance is not a problem until it's a problem, I'd
rather use it. Anyway: I wouldn't pick it for an interview question.

Concatenating strings using += will often perform quadratically with
the number of concatenations. Your testing will likely use a small
number and not take a noticeable amount of time. Then it'll get
deployed and someone will plug in a much larger number, wondering why
the program is so slow. The recent optimizations just make it more
obscure.

+= shouldn't be an obvious choice for sequences. If it's mutable,
use .append(). If it's immutable, build up in a mutable sequence,
then convert.

--
Adam Olsen, aka Rhamphoryncus

[Paul Rubin]

Rhamphoryncus <rh****@gmail.comwrites:

+= shouldn't be an obvious choice for sequences. If it's mutable,
use .append(). If it's immutable, build up in a mutable sequence,
then convert.

I generally prefer to do this with generators rather than mutation.
I.e. instead of

blech = []
while some_condition():
yuck = some mess
blech.append(yuck)
result = ''.join(blech)

I like

def gen_blech():
while some_condition():
yield (some mess)
result = ''.join(gen_blech())

It just seems cleaner. YMMV. Of course when "some mess" is a single
expression instead of multiple statements, it may be possible to use
a genexp without the auxiliary function.