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,

 

[sndive]

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,

assert() in the c functions extending python ends the interview rather
quickly.
or at least it did for me @IronPort ages ago.
To be honest they have massively multithreaded app
and the last thing they needed was an appliance down because
some programmer was not sure what to do when a certain condition
arises.

 

[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.

 

[Ben Finney]

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.

 

[Tim Chase]

Good luck with your interviewing and hope this helped,

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

 

[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]

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]

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.

 

[Paul Rubin]

+= 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.

 

[yeryomin.igor]

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

 

[Tim Chase]

yes, yes I did, almost 5 years ago.

You didn't include any questions/comments on my email, so it's a bit
hard to respond.

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. [snip]
Python History:
===============
- decorators added in which version?

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

I've long wanted to update my original post in this department to
include things like the "with" statement as well as my reasoning.
Some of our deployments were stuck on earlier versions (currently
our oldest is a 2.4 deployment that is merrily chugging along,
somewhat stuck due to an external binary dependency for which terms
changed between versions). At the time I wrote that, we had some
2.2 and 2.3 code in production that couldn't use decorators, and
sqlite wasn't officially added until 2.5 (IIRC). Now that
everything is at least 2.4, code can now use decorators freely.

I'd also likely include questions about integer division and other
stuff added in 3.x (such as the default new-class behavior).

So my main motivation was to make sure applicants knew that, in some
of our environments, certain features might not be available. Not
that I wanted to hire a Python historian.

Don't let the importance of these two escape. It's SOOOOOOO easy to
grab any of the freely available VCS tools and learn the ropes, or
to write some test code. Failure to do so just seems like
negligence these days.

-tkc

 

[Roy Smith]

You need to be careful when you ask questions like this. I would expect
somebody to be aware of those and have a high-level understanding of
what they do, but certainly not remember the details of the exact syntax
and argument order. Even with stuff I use everyday (like unittest and
datetime), I have a browser open to the reference manual most of the
time.

Heh. I would answer that with, "Python Debugger? I've never used it".

With the exception of the question about new-style classes, these are
silly questions. I was around when both decorators and sqlite3 were
added. I couldn't possible tell you when to any precision better than
"2 dot something". As for the zen of python, it's cute, and a piece of
python folklore, but hardly an essential part of being a good python p

 

[Tim Chase]

You need to be careful when you ask questions like this. I would expect
somebody to be aware of those and have a high-level understanding of
what they do, but certainly not remember the details of the exact syntax
and argument order. Even with stuff I use everyday (like unittest and
datetime), I have a browser open to the reference manual most of the
time.

Yeah, the aim isn't to grill them on the minutia, but to get a
feeling that they know the basics. The zipfile module offers a
ZipFile object for reading/writing zip files with or without
compression. The CSV file allows for reading/writing CSV files with
definable delimiters and quoting/escaping. Etc.

Heh. I would answer that with, "Python Debugger? I've never used it".

The ability to know off the top of your head that it's the "Python
Debugger" is more than enough That's just first-order
ignorance: you know what you don't know and can spend a few minutes
reading up on it if you need it. The second[or higher]-order
ignorance of not knowing what pdb is (or, if you need more powerful
debugging, how to do it) is sign the person hasn't been programming
in Python much.

With the exception of the question about new-style classes, these are
silly questions. I was around when both decorators and sqlite3 were
added. I couldn't possible tell you when to any precision better than
"2 dot something".

I'd even be satisfied if a person just knew that such features
weren't there all along and might need to be worked around for older
deployments.

As for the zen of python, it's cute, and a piece of python
folklore, but hardly an essential part of being a good python p

[Ed: something appears to have gotten truncated there] Yeah, it's
more about a person being sufficiently steeped in python to know
bits and pieces of the zen, and their ability to recognize/create
pythonic code. I've seen enough Java-written-in-Python to know what
I don't want

-tkc

 

[Rick Johnson]

 The second[or higher]-order
ignorance of not knowing what pdb is (or, if you need more powerful
debugging, how to do it) is sign the person hasn't been programming
in Python much.

So guru knowledge of pdb is prerequisite to being accepted as a
Pythonista? I find that ridiculous since *real* programmers don't use
debuggers anyway.

[Ed: something appears to have gotten truncated there]  Yeah, it's
more about a person being sufficiently steeped in python to know
bits and pieces of the zen, and their ability to recognize/create
pythonic code.  I've seen enough Java-written-in-Python to know what
I don't want

I know you are a member of the group who has an aversion to strict OOP
paradigm but is this a justified aversion, or just fear of OOP due to
static evolution? Look, i don't like java's strict approach either,
however, i do not have an aversion to OOP.

 

[Demian Brecht]

You need to be careful when you ask questions like this. I would expect
somebody to be aware of those and have a high-level understanding of
what they do, but certainly not remember the details of the exact syntax
and argument order. Even with stuff I use everyday (like unittest and
datetime), I have a browser open to the reference manual most of the
time.

Yeah, the aim isn't to grill them on the minutia, but to get a
feeling that they know the basics. The zipfile module offers a
ZipFile object for reading/writing zip files with or without
compression. The CSV file allows for reading/writing CSV files with
definable delimiters and quoting/escaping. Etc.

Heh. I would answer that with, "Python Debugger? I've never used it".

The ability to know off the top of your head that it's the "Python
Debugger" is more than enough That's just first-order
ignorance: you know what you don't know and can spend a few minutes
reading up on it if you need it. The second[or higher]-order
ignorance of not knowing what pdb is (or, if you need more powerful
debugging, how to do it) is sign the person hasn't been programming
in Python much.

With the exception of the question about new-style classes, these are
silly questions. I was around when both decorators and sqlite3 were
added. I couldn't possible tell you when to any precision better than
"2 dot something".

I'd even be satisfied if a person just knew that such features
weren't there all along and might need to be worked around for older
deployments.

As for the zen of python, it's cute, and a piece of python
folklore, but hardly an essential part of being a good python p

[Ed: something appears to have gotten truncated there] Yeah, it's
more about a person being sufficiently steeped in python to know
bits and pieces of the zen, and their ability to recognize/create
pythonic code. I've seen enough Java-written-in-Python to know what
I don't want

-tkc

Definitely appreciate your approach, I've asked similar questions when interviewing.

I also usually like to ask what a candidate likes and dislikes about Python, hoping for the GIL to creep up, along with an explanation as to what it is, implementations that don't have it along with methods of getting around the lock (although that would be a fairly advanced topic IMHO). If it doesn't come up, sometimes I'll pop it in depending on their level of experience..

 

[Demian Brecht]

You need to be careful when you ask questions like this. I would expect
somebody to be aware of those and have a high-level understanding of
what they do, but certainly not remember the details of the exact syntax
and argument order. Even with stuff I use everyday (like unittest and
datetime), I have a browser open to the reference manual most of the
time.

Yeah, the aim isn't to grill them on the minutia, but to get a
feeling that they know the basics. The zipfile module offers a
ZipFile object for reading/writing zip files with or without
compression. The CSV file allows for reading/writing CSV files with
definable delimiters and quoting/escaping. Etc.

Heh. I would answer that with, "Python Debugger? I've never used it".

The ability to know off the top of your head that it's the "Python
Debugger" is more than enough That's just first-order
ignorance: you know what you don't know and can spend a few minutes
reading up on it if you need it. The second[or higher]-order
ignorance of not knowing what pdb is (or, if you need more powerful
debugging, how to do it) is sign the person hasn't been programming
in Python much.

With the exception of the question about new-style classes, these are
silly questions. I was around when both decorators and sqlite3 were
added. I couldn't possible tell you when to any precision better than
"2 dot something".

I'd even be satisfied if a person just knew that such features
weren't there all along and might need to be worked around for older
deployments.

As for the zen of python, it's cute, and a piece of python
folklore, but hardly an essential part of being a good python p

[Ed: something appears to have gotten truncated there] Yeah, it's
more about a person being sufficiently steeped in python to know
bits and pieces of the zen, and their ability to recognize/create
pythonic code. I've seen enough Java-written-in-Python to know what
I don't want

-tkc

Definitely appreciate your approach, I've asked similar questions when interviewing.

I also usually like to ask what a candidate likes and dislikes about Python, hoping for the GIL to creep up, along with an explanation as to what it is, implementations that don't have it along with methods of getting around the lock (although that would be a fairly advanced topic IMHO). If it doesn't come up, sometimes I'll pop it in depending on their level of experience..

 

[Peter]

One of my favourite questions when interviewing - and it was 100% reliable - "what are your hobbies?"

If the answer included programming then they were hired, if not, then they went to the "B" list.

In my experience, anybody who is really interested in programming will haveit as a hobby (and is keen to learn even if they don't currently have the knowledge you require) - otherwise it is "just a job". Every job has a learning curve - whether it is just the particular domain or even a new language, the individual who sees programming as more "than a job" will come up tospeed much faster and be more productive in both the short and long term.

Every programmer I have ever hired using this criteria worked out well.

 

[Peter]

One of my favourite questions when interviewing - and it was 100% reliable - "what are your hobbies?"

If the answer included programming then they were hired, if not, then they went to the "B" list.

In my experience, anybody who is really interested in programming will haveit as a hobby (and is keen to learn even if they don't currently have the knowledge you require) - otherwise it is "just a job". Every job has a learning curve - whether it is just the particular domain or even a new language, the individual who sees programming as more "than a job" will come up tospeed much faster and be more productive in both the short and long term.

Every programmer I have ever hired using this criteria worked out well.

 

[Devin Jeanpierre]

One of my favourite questions when interviewing - and it was 100% reliable - "what are your hobbies?"
If the answer included programming then they were hired, if not, then they went to the "B" list.

Woe is the poor college grad, who wants to appear like a well-rounded
individual and lists capoeira and gardening, instead.

-- Devin