l33tminion: (Default)
Sam ([personal profile] l33tminion) wrote2007-10-30 10:02 pm
Entry tags:

Python Interview Questions

The more I learn about programming, the more I learn that I have a lot to learn. Take this post to c.l.p about Python job interview questions for example. Ones I can handle easily are in bold, trouble-spots in italics:

Basic:
  • 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 (but I probably wouldn't have thought to use that idiom before now)
  • 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:
  • 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 (____)

More Advanced:
  • 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 (then again, I don't use these enough...)
  • 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? (method decorators are in as of 2.4, class decorators are planned for 2.6)
  • "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
ext_81047: (Default)

[identity profile] kihou.livejournal.com 2007-10-31 03:16 am (UTC)(link)
Random comments:

  • string building...do they use "+=": this came up on the OpenLayers mailing list recently; it's also a big timesaver in Javascript when joining more than half a dozen strings together, such as when serializing a JavaScript object hierarchy into some format.
  • questions about map/reduce/sum/etc: functional programming FTW! Though I've got a better handle on list comprehensions these days, these are still nice when using predefined functions, less verbose filtering, or reduce functionality.
  • "special" methods: these are one thing I don't like about Python; a lot of the common ones could be replaced by keyword+operator/keyword like in C++, and the __name__ == '__main__' idiom is dumb.
  • more detailed questions about the std. libraries: I always think that being able to figure out stuff quickly with the docs is more relevant than memorizing stuff, but that's partially because I don't actually know anything. It's also why I recently failed my EK rapier auth.
  • questions about monkey-patching: huh? *wikipedia* Oh, I do that, just call it a subclass of magic (or "sticking stuff places"); i.e., I love it but wouldn't feel terribly comfortable using it longterm.
  • Python History: knowing what version things happened in is useful but also annoying; in the past I would've said it was dumb, but it comes up a lot for me now with programming on boxen I don't have total control over (ducks have 2.4; athena has 2.3 and 2.5 easily available but /not/ 2.4, I think scripts.mit.edu has only 2.5?)
  • the difference between "class Foo" and "class Foo(object)": This one is actually important. The first one will be an old-style class (can't use super, type(x) != x.__class__, doesn't do multiple inheritance properly); the second one will be a new-style class and almost certainly what you want these days
  • import this: made of awesome
  • Python web frameworks: I'm in love with TurboGears, though OCTO likes Django these days
  • revision control: OCTO theoretically uses RCS for apache configs but no one ever uses it properly and so things get dumb.
  • automated tests: continuous testing is awesome, though Gigo's not always fast enough for me to want to use Eclipse


LiveJournal should totally have an easy-to-use "quote" feature like phpbb.
ext_81047: (Default)

[identity profile] kihou.livejournal.com 2007-10-31 05:16 am (UTC)(link)
Apparently, its good for things like wrapping classes for testing (especially ones that in standard operation would be following some communication protocol or other, where the thing it will be talking to isn't something you want to be disturbed by testing).

With a good design, you can generally accomplish the same thing with wrapper classes or subclasses, though I wouldn't feel bad monkeying in tests longterm, because if they break you learn something useful.

Really? How is that with things like form validation? Those bits were still rough around the edges when I was using it. Also, have you been using SQLObject or SQLAlchemy (or something else)?

I'm in the habit of doing manual form validation, especially since my validation tends to be quite complicated. I know that TurboGears can use decorators for form validation, but I haven't used them much. I've been using SQLObject, but I've really cooled on it now that I understand SQL more and I've run into more of SQLObject's limitations. SQLAlchemy looks cool, but I haven't used it.

Is continuous testing for Python in Eclipse any good? And which of the relevant plugins is best for Python development in Eclipse?

I use EasyEclipse for Python, since Eclipse gets complicated really fast. My current continuous testing is just a custom build process that runs my command-line testing suite, which is enough for what I'm doing but doesn't give you the full Eclipse red-mark experience. I know there are cooler continuous testing plugins for Java, but my Eclipse is pretty bare-bones. I'd actually probably be happier with a emacs setup with continuous testing, but I haven't looked into that. Shouldn't be too hard.

Hello

(Anonymous) 2008-08-20 07:22 pm (UTC)(link)
I'm new here, just wanted to say hello and introduce myself.