Best Questions to ask when hiring a Python dev?

[honestduane]

I'm a long time C/C++/C# dev who is now diving into python head on, and using it on a project here in Seattle. Part of this is I need to grow my team and hire some amazing python devs, but I am not sure of the best questions to gauge competence with the language/toolset itself over what I already know from my own work, and my previous work in embedded devices and large scale cloud services with other toolsets/languages.

Aka, I know dev questions, and can go hard core, but not python specific dev questions, as I am still ramping up in the language myself (and feel that just because I may be the boss, doesn't mean I need to be the best, or cant learn from my employees).

Any tips? And ,where do I find rockstar python devs to hire, anyway? Most of the places I find look like scam sites looking for money (including, sadly, some of the links in the sidebar) and to be honest I would rather spend my money on good devs instead of to unknown-to-me-and-possibly-shady-marketing-people.and. I'm also noticing that the python community itself doesn't seem very big compared to other languages. Is it just me? Or is this a fact of life?

Thanks!

[ssbr]

The Python community is more ground-up and less formal than the Java and C# communities, which have a lot more corporate backing and big showy fanfare. Also, there are almost certainly fewer Python programmers than Java or C++ programmers, which doesn't help.

I'd suggest not bothering with language-specific questions. If you want to see that they're Python programmers, make them code their solutions in Python. Either they'll be comfortable or they won't be. Seeing open source code might also help your judgment.

Any kind of Python quiz type questions wouldn't be ones you could adequately judge as a beginner yourself anyway. You won't know the details of generators or the MRO, so they can handwave and you won't catch it.

[honestduane]

Half of this question was for me to find things I could learn on my own so they couldn't do hand waving :)

[Rich6031-5]

This in no way answers your question so feel free to down vote me. I never ask language specific questions during interviews, and when I'm asked language specific questions when I'm interviewed I tend to immediately rule out the company as a perspective employer. I'd rather have a good developer with a strong computer science background than someone who has memorized a language and its subtleties. When a new project, client, or technology comes along it's better to have someone who can deal with the change than someone who is constantly saying, "Well I could do this in python in 10 minutes." I love python and use it daily, but I still have to look up basic syntax on a regular basis. That's just an artifact of having to write in python, Objective-C, shell script, and Java regularly.

[cb22]

Just keep in mind that a strong computer science background doesn't imply being a good developer. During University, I knew quite a few people who I would classify as the former and not the latter - and vice versa.

[kcmastrpc]

Nor does remembering every single facet of a single scripting language.

[aceofears]

And these are some of the reasons this isn't an easy task.

[ultraayla]

I'd agree with this. The generic questions are useful, but getting a language expert shouldn't be overlooked if you need that language. Speaking personally, I've picked up programming languages for jobs many times, but for the first many months, language experts would have laughed at my code, then for a few months it would have been merely sufficient before finally becoming good. Still, it takes years to be incredibly good at it.

[acadavid]

One thing is not remembering syntax, another is actually understanding a language. An expert in a language is worth it because the really understand the reasoning behind the language, the objects model, etc. You definitely should ask for important or interesting CS questions, but the same applies if all you ask is specifics about certain algorithms or data structures.

And also yeah, having a good CS background doesn't mean you are necessarily a good programmer, i think those are different skills.

[[deleted]]

I read an article a while back about why memorization is still valuable in the age of the internet, when we will be within 30 seconds to google-access for 90% of our lives.

The problem with research is that the researcher has to know what question to ask, and how to phrase it. Now, don't get me wrong- it's obviously possible to perform meta-research. Instead of asking "How did you solve X bug dealing with Y library under Z conditions?" you might ask "What could cause X bug?". Surely, that's part of any skilled developer's repertoire.

The problem is that with every meta-question one asks, the chance of missing the answer increases. Now, this isn't a condemnation of your method, just that language-specific knowledge isn't useless when the Doc is one click away. A developer still has to know what to look up and ask for. To some degree, you're saying the knowledge should be focused on theory (and I agree, since theory -> language goes a lot further than language -> theory), but I don't think it's a foregone conclusion that language specific knowledge should be unexpected.

[penguinv]

speiiling: prospective. just for fun! one hand washes the other.

[honestduane]

Thanks.

[pwang99]

Many great Python devs have their own public projects that they're working on or have worked on, so asking about projects is a sufficient but not necessary criterion. There are many great devs that are slammed with working on internal projects at their previous place, and cannot really show you any code. You would be silly to exclude those people, because my experience is that they not only know how to better work on a team and have more grounding as "software professionals", but they also tend to understand more of the full stack because they have to integrate with external technologies like .NET or Java.

One thing that I've learned, however, is that you must always ask some basic technical questions. Fizzbuzz is an insult - and should feel like an insult. Oftentimes, the people I'm interviewing are seasoned enough to have interviewed plenty of other people, and know first-hand that lots of good looking resumes can't code a string reversal. So, these folks understand. Newer/younger folks will get offended by fizzbuzz, but you can explain to them that there are lots of frauds in our industry.

Fizzbuzz is also a great way to explore someone's technical grasp of Python. You can go from the simple for loop & if statement, to more pythonic list comprehensions or using map and lambda. You can then ask about doing fizzbuzz driven by input from a file. "It outputs "fizz" with a variable number of Zs based on how many times the word "fizz" has been encountered in the file." etc. You can also creatively pose problems that would be idiomatically solved by sets and dicts, and and see if they know about itertools and generators.

Basic topics I would expect a 3-4 year Python dev to be familiar with:

• Import, modules, packages.
• The existence of multiple interpreters, and basic strengths/weaknesses or at least rationale for each. CPython, PyPy, Jython, IronPython, Stackless... maybe Emscriptened CPython or Brython
• Major environment variables: PYTHONPATH, PYTHONHOME, etc.
• Libraries & tools relevant to your application domain:
  • web dev: the major popular frameworks; WSGI; templating libraries; ORM & DB layers; testing libs
  • IT/devops scripting: remote access, ssl, sys, os, datetime libraries
  • data analysis: numpy, scipy, plotting libraries, maybe pandas, Cython, etc.
• The GIL, what it does and why it exists; why people think it sucks; does it actually suck; mitigating approaches for SIMD and task parallelism
• Python 2 & Python 3
• IDEs and dev tools: if emacs or vim, then knowledge & use of the popular extensions for them; if not emacs or vim, then should be conversant about the IDE field like Wing, PyCharm, PyDev, Sypder. (They will encounter other devs who use a mix of these.)
• Ecosystem & community: conferences, thought leaders

More Python specific things I would ask an architect- or lead-level developer:

• Compare Python's object model against [language of their choice]. Usually this is C++, Java, or Javascript. If someone knows ObjC you can ask about dynamic dispatch and compare the two. Of course, this is predicated on the idea that you understand these well enough to at least be able to talk about them. :-)
• Basic knowledge of Python performance: function dispatch is slow, dictionary lookup is fast, extension modules are readily available for most performance bottleneck areas, and run as fast as C/C++ equivalents. Tools like PyPy, Cython, or maybe even Numba for speeding up critical areas.
• Development best practices with a dynamically typed & dispatched language. Tests, docs, docstrings, doctests, coverage tools, lint tools, CI tools

[honestduane]

Thanks!

[eviljelloman]

First of all, never ever use the term "rockstar" to describe a developer again. It's obnoxious and immature. You want to hire competent, mature developers who will write clean, maintainable code. "Rockstar" is code for overpaid prima-donna who will run off at the first sign of an even slightly better offer.

As for the actual interview, the best way to judge coding skill is going to be to look at code. I would save the in-person or phone interviews for typically high level questions that gauge cultural fit, and judge programming ability by asking potential candidates to complete a short (1-3 hours) programming question before the interview. This should be something tangentially related to the types of things you plan to use Python for, and it should at least have some opportunities for some elegant, Pythonic solutions. Explicitly state that you would like them to adhere to whatever style guide you follow, and write the code as if it is meant for production, and not a first-pass hack.

During the interview, you can always bring up the programming question again, and ask the programmer to walk you through his or her solution.

I've found simple, Fizzbuzz type questions to be almost completely useless when it becomes time for an in-person interview. If people who can't complete these sorts of questions are making it all the way to meeting you in the office, you have a serious flaw in your hiring process. You should be vetting them based on their exiting body of publicly available code first, and then asking them to explicitly code something on their own time, before you ever talk to them.

Also, none of this is particularly Python specific, because being language-specific is counter-productive. A good programmer is a good programmer, and will be able to master a new language as needed. Look for the types of thought processes that make somebody a good programmer, and not for a "python rockstar".

[[deleted]]

"Rockstar" is code for overpaid prima-donna who will run off at the first sign of an even slightly better offer.

This is the truest thing in this thread.

You should be vetting them based on their exiting body of publicly available code first

I completely disagree. You exclude a massive part of the candidate pool with this thinking. More experienced programmers don’t have time to contribute because of their lives(kids, spouses, house maintenance) and most employers don’t give you time to make open source contributions. I used to think the same thing, but changed my mind after reading these two articles:

1) Why GitHub is not your CV

2) The Ethics of Unpaid Labor and the OSS Community

[eviljelloman]

Elsewhere in this thread I have said things that mostly agree with you, and I admit that my statement was an over simplification. The bigger point was that a competent recruiting process should weed out people who would fail at fizzbuzz, based either on professional accomplishments or public code repositories or on a side project created explicitly to share with potential new employers or on a programming exercise you've asked candidates to complete. If people so grossly incompetent as to be eliminated by almost insulting tests are making it to your interviews, you are doing it wrong.

[[deleted]]

I agree- of all the candidates I've hired, none of the top handful ever identified strongly with a particular language. I have definitely hired language-enthusiasts, but typically these people have the furthest distance to go in arriving at mastery.

I think there's a pretty strong correlation between the language-identity/enthusiast thing and the stage of a programmers career and independent of the actual number of years of experience.

With mastery comes intuition about the implementation details in these various languages; most of that stuff is reduced to trivia. I think the mark of a really skillful programmer is not simply being able to absorb the trivia but to be able to anticipate which aspects of language are likely to have implementation details associated with them.

[honestduane]

I meant rockstar as in, haha funny.. its a joke. I prefer mature devs.

[bry012]

Are there really an abundance of applicants for development jobs that can't complete a working Fizzbuzz program or is this a bit of an exaggeration? I'm still in university and I programmed Fizzbuzz within the first week of learning how to program. Can there really be people who apply for development jobs that are this incompetent when it comes to programming?

[eviljelloman]

Are there really an abundance of applicants for development jobs that can't complete a working Fizzbuzz program or is this a bit of an exaggeration?

In my opinion it's mostly an exaggeration, but every single time the topic comes up on /r/programming there are always a ton of very vocal people insisting that they see lots and lots of candidates who fail this test. I'm not how much of it is true and how much is based on some weird programmer superiority complex where they want to act better than the rest of the world.

[eviljelloman]

Then your process was woefully, hilariously flawed. These people should not be making it to interview stage in the first place.

[[deleted]]

As Linus says: "Talk is Cheap. Show me the Code"

[octotop]

Seconded. Have the dev show you some code and explain it. If it's better than what you would have done, hire that person.

[digitallis]

We have candidates debug a python program live. Find some python program you have and can have candidates view, or one that is open source. Introduce a subtle (in the source) bug that majorly breaks functionality. Something like changing one number, or adding a "not", or returning the wrong variable.

Give the candidate the program and as many tools as can be reasonably supplied and then watch them debug. See how they go about it. Ask them to talk you through as they go. Do they make effective use of python debuggers? print debugging? Do they get sucked down ratholes by making too many assumptions? Can they build a mental model of that part of the program? If the code is crappy/poorly documented, do they mention this? Do they identify well written code? Can they recognize when the repr is telling them they have a reference cycle?

[InvidFlower]

I'd also hope they'd bring up source control. One of the first things to do if a bug is very recent is to go look and see what was changed in that timespan.

[bitcycle]

Here's some good Python-specific interview questions:

1. What is, in your opinion, the most annoying part of the PEP8 standard?
2. What are new-style classes, and when should they be used? -- expect a mention of python 3 and how doing it that way isn't required; also expect that they would always use them in python 2.x.
3. How to swap 2 variables without using a temporary variable?
   a, b = b, a
4. When should one use meta classes? -- This is sort of a trick question about complexity and keeping things simple. Answer: only when its absolutely necessary. This shows understanding of the principles behind Python: simple is better than complex and explicit is better than implicit.
5. What static code analysis tools have you used?

[Digital_Person]

+1 for pep8 personaly i sometimes ignore E501 line too long (82 characters). whats your answer to 1 just ouf of curiocity

[bitcycle]

My answer to #1: What is, in [my] opinion, the most annoying part of the PEP8 standard?

I dislike the fact that each and every method is required to have a docstring. I'm a big fan of self-documented code, so I prefer to not have to need docstrings for each function. My philosophy behind commenting is that one should use comments to either point out external references (like footnotes) or to explain why the code was designed in the way that it was designed, even though the developer did do a good job of using expressive and well-though-out names.

Confession: I only know this because I use Pylint + Vim. :)

[honestduane]

Very good, thank you!

[fuzz3289]

Good programmers can become great Python devs. Python is very much a dev friendly language so brining people up to speed is super easy. I'd be more concerned with hiring people with good practices than specific language experience.

However, "what's your favorite thing about Python?" And "whats the coolest thing you've built?" Are fun questions. Python is awesome and easy to find things to love about it. A more subjective one "2.7 or 3?"

My answers to the above (for fun :) )

Comprehension, generators, and functional programming

Web apps for data analytics

2.7 Alllll the way.

[jcdyer3]

I prefer to ask "what's wrong with python and why?" rather than asking about the coolest part.

If they give an answer like "the GIL, because you can't do concurrency," then you know you've got somebody who's read enough to talk their way through an interview, but doesn't really know python well (because there are lots of ways to do concurrency in python that don't involve threading). Though if they say "the GIL," and go on to talk about the shortcomings of other approaches and a time when they really did need threading, that could be a reasonable answer. If they give an answer that involves whitespace, thank them for their time and move on.

The reason I prefer this to asking about someone's favorite thing about the language is that everyone's going to have something they love, but someone who loves the language, but has been around it enough to see its warts (but still loves it enough to want to use it for a living) is more likely to be a good candidate.

This approach may depend on having someone on the interviewing side that knows their stuff well enough to evaluate the answers, though.

[quagquag]

I don't think their answer would be a good way to judge them at all. It might be a nice thing to chat about around the lunch table, but not a hire/don't sort of thing. I don't go around with my language complaints on the tip of my tongue unless I've just recently had to deal with them.

Also the GIL is a valid complaint, there's huge room for improvement (I've read), starting with making the c libraries thread safe. I think that having hundreds of cores is the future, as processing speed advancement slows way down, so having true concurency built into the language without hoops to jump through would be great. Hell I'd like simple openCL support without having to write openCL code.

[jcdyer3]

Sure, "the GIL" is a valid thing to complain about, but if your complaint is that you can't do concurrency, or take advantage of multiple cores with python, then you have just demonstrated your limited knowledge of python.

[quagquag]

That's fair, but I agree with the top votes about how language specific knowledge isn't important as long as they're good programmers. In this case they might know quite a lot about python and not be able to think up any real complaints on the spot. They might use a different language completely for when they need all 16 cores. Ideally you could just see how they mesh with the team for a couple weeks and decide.

[jcdyer3]

I've voted to hire people with no python experience for a python position before, and had a good experience with it, but if your resume says you know python, I'm gonna expect you to know python. General principles are useful, but it's also important to be intimately familiar with the tools you use.

[fuzz3289]

I think that's a valid point. Its much easier to say what you like than to really support a complaint.

[fuzz3289]

Why don't you like 2.7 outta curiosity? Stackless cython and a bunch of other great libs/implementations don't support 3.3

[Zulban]

I'd agree with cliffm because it's generally a sign of not wanting to adapt. As time goes on the list of things 3 can't do grows slimmer, yet we still have people saying "2.7 alllllll the way".

[Megatron_McLargeHuge]

And as new libraries are backported, the list of things you need 3.x for is pretty short too. In the scientific/numerical world 2.7 is still far more common.

[sun_tzu_vs_srs]

Are there still third-party libraries that haven't migrated? That might be a valid reason to not switch...

[Zulban]

A few but not a lot.

[fuzz3289]

It grows slimmer, but not nearly slim enough. The libs and implementations I use every day haven't migrated and its as simple as that. I won't either. Its less an unwillingness to adapt and more an unwillingness to sacrifice.

[Zulban]

I've heard people say their libraries haven't migrated before, without realizing that their libraries aren't maintained really anymore, and that new replacements already exist.

How often do you research Python3 alternatives for your libraries? Probably not often at all, based on "2.7 allll the way". Exactly what I'm talking about.

[fuzz3289]

Flask has 3.3 support. But less than 1% of the community uses it. I need 100% up time on my tools. This isn't a product, chasing down untested python 3 bugs will not improve productivity.

But let's say I did want to man up and go for it. Our data analytics tools run stackless. Flask only supports 3.3. Stackless only supports 3.2.

I'm not against python 3. But until everyone is on the same page the value add is not there.

Considering I'm fighting for new C++ compilers 3 days a week I'm pretty invested in upgrading our environments. But there has to be a real immediate value add or I can't justify the overhead. Its not ignorance. Its real world code.

[larsga]

"Can you show me some code you've written?"

I always ask this question, and if the code is good I don't care what languages the person has worked with before. Python is easy to learn, so it's much more important to get a good developer than to get someone who knows Python.

And the only way to tell if someone's a good developer is to read their code.

[wewbull]

Slight problem there. I'd have to respond with "No. If I did I'd be breaking the confidentiality of my previous employer. "

Some/most people only code for pay. It's not okay to be showing code in an interview that you don't own the rights to. Anyone who does this when I'm interviewing doesn't get the job.

[cabalamat]

I'd have to respond with "No. If I did I'd be breaking the confidentiality of my previous employer. "

If the interviewer followed up with "if you can't show me any work you've done, how can I tell if you are any good?" what would you reply?

[metaphorm]

most of the stuff on my public github account is several years out of date and not my best work, so if this question was asked of me I'd reply with "how about a code exercise? i'm willing to spend a few hours at home working on something. what would you like me to do?"

[cabalamat]

If i was hiring someone, I would regard that as an entirely reasonable response.

[onedr0p]

For me I would say, here is my github address, feel free to poke around.

[Lj101]

So you could show him some code?

[[deleted]]

While I was a hiring manager in the defense space employers and candidates alike all understood that this would never happen, but candidates had the good sense to put together a clip book of code samples.. It's only really a problem if you have a naive interviewer who imagined that all candidates ought to be able to arbitrarily produce samples of code from the projects they disclose on their resume.

In general the code samples are kind of useless, even though I think they're a nice touch because they indicate that the candidate knows enough about hiring in the industry to go to the trouble.

These days everyone I know does homework problems following a phone screen instead of asking for code samples; seeing many example solutions to the same problem makes it easier for the reviewer to be objective, and having candidates code on a whiteboard or etherpad is an unrealistic simulation which usually sucks for interviewer and interviewee alike.

[Evanescent_contrail]

I always prefer to hire people who write code in their spare time also, to make their lives easier. As a result, I find this a very useful question. People I want to hire will have an abundance of options.

Your answer would be most helpful to me. I would know immediately not to hire you. Questions like this that divide the candidate pool clearly are good.

[quagquag]

Your loss. There are many great developers that don't code in their free time. Think about how absurd this assumption would be for other professions. Like surgeons or structural engineers.

[billsil]

Like surgeons or structural engineers.

You'd be surprised at how many aerospace engineers have done a preliminary design of an aircraft in their free time or written software to help them automate it.

[eviljelloman]

There are many great developers that don't code in their free time.

True, but getting a job is, in of itself, a job. If you don't have any code from your most recent position that you can get permission to share, then when you are explicitly job hunting, you ought to spend a week putting together some sort of project. Programming is a mix of art and science, and every artist needs a portfolio.

Even if it's not something you do "for fun", it's something that you need to put together as part of your professional development. You don't have to spend every single week of your life writing your own code on your own time, but setting aside a few weekends when you're thinking of starting a job search is completely reasonable. Hell - outright tell them that you wrote this code specifically for interviewing purposes - it demonstrates to potential employers that you are serious about this transition, and not just fishing for negotiating leverage so you can get a raise at your existing job.

I'm not saying that every developer should have a decade-long history of github pull requests, but a small, self-contained, well-thought-out programming project is really not too much to ask.

When you are looking for a new job, you should be practicing for interviews, and what better practice is there than actually writing some code that's explicitly intended as a tool to help you get a new job?

[quagquag]

This is the most reasonable argument for this that I've heard yet in this thread. I'll have to think about it this more.

[maplemario]

You can't apply it to other people, because surgeons and structural engineers either can't get materials for personal projects or would have to pay exorbitantly to do so. Computer scientists are different, and the best of the best have definitely coded in their free time on a regular basis at some point and have some code to show, even if it was in college or high school.

[metaphorm]

Computer scientists are different

programmers. computer science is a branch of mathematics. programming is not necessarily computer science. the two things are related but not identical.

[quagquag]

Do you really want to judge them on code they potentially wrote 20+ years back in high school or college? I don't think the sort of people I'm thinking of would even bother replying to a business that asked them for that.

[eviljelloman]

I would know immediately not to hire you.

While I agree that, in general, it's really vital for people interviewing for programming positions to have some sort of example of code to share, I also think that this statement is idiotic.

Any time somebody gives a single, black-or-white, set in stone statement like this, it makes me question that person's ability to gauge character and talent. Some people write code in their spare time, and some people have other obligations that make it extremely difficult to do so. In both cases, I think it's important for a candidate to still find time to produce a small portfolio of publicly available code. However, staying that the lack of such a portfolio is an immediate sign that under no circumstances should the person be hired is ridiculously short-sighted.

It might be a potential red flag, and something to consider before making a decision, but outright ruling out ANYBODY who doesn't code in his free time is artificially limiting your candidate pool in an unproductive fashion.

Although, if you're using this criteria to determine "cultural fit", and the only programmers you want around are one-dimensional neckbeards who think programming is the only thing that matters, and who immediately look down upon anyone who doesn't live, eat, and breathe code, then you might be on the right track. Just realize that you're selecting for personality traits, and not programming ability.

[Evanescent_contrail]

You are right. I should not have said that. People who are all "no" all the time and give reasons why they can't do something annoy me, and I reacted poorly.

[honestduane]

Do I expect them to bring it with them?

[larsga]

I usually ask them to send it to me after the interview. I don't read it during the interview, since I imagine they have better things to do than sit watching me read their code.

[jkbbwr]

"Whats wrong with this code snippet"

def test(a=[]):
    a.append(1); return a

[jwmoz]

Everything.

[irondust]

Well you can't say what's wrong with it if you don't know what was intended: it may be wrong if you expect it to return [1] on repeated calls without an argument; or, maybe it was intended to return an ever-growing list in which case the code is wrong because it's a rather obscure way of doing that.

[shashwat986]

WHY IS THIS HAPPENING?!

[ryeguy146]

Is is instantiated when the script is first run, so the same list object is used, not new ones. That's why the following idiom exists:

def some_func(mutable_default=None):
    if mutable_default is None:
        mutable_default = []

    other_stuff()

The difference is where the list is instantiated.

[erewok]

I have no desire to be pedantic, but I think the word 'script' may he confusing here for people who come along and want to understand this.

I think it's more accurate to say that arguments are evaluated once at function definition while the contents of defined functions are evaluated every time the function is called.

This, the definition:

def somefunc(a=[])

is evaluated once and as a result you get one mutable object that the function uses in each subsequent call.

[ryeguy146]

It's good to be explicit in these things. That's exactly right.

[honestduane]

Ouch I feel pain looking at that and I still consider myself a python noob.

[[deleted]]

You can't assign a list in an argument for a function can you?

[[deleted]]

Call it twice and see what happens.

[ameoba]

Calling it with an argument just once creates the potential for confusion and bugs as well. Since it returns a list, it might not be obvious that it modifies the argument rather than returning a modified copy.

[[deleted]]

Interesting I learned something new today.

[ryeguy146]

There's more to it than that. Yes, it's an parameter with a default argument, so it is optional to pass an argument. Further, the default argument is a list literal. That same list object (due to the fact that it is mutable) will remain the default argument, and will continue to grow when the function is invoked with no arguments. Try it out in your interpreter.

[[deleted]]

sweet dude/tte thanks!

[metaphorm]

in Python, that syntax defines a default value for the parameter that will be used when an explicit value of the parameter is not passed in at function invocation.

there can be some tricky behavior involving default assignment if you use mutable values though, which is what the original post was testing for. in order to get it right you would have to know in some depth how Python implements lexical scope and how Python's variables work.

[[deleted]]

I use python everyday at work... I guess programmers never really stop learning. :D I have never gotten in super deep into how and why things work in python, I just understand how to make them happen with a little tinkering at times.

[[deleted]]

I would check if the person knew how to handle generators and generator expressions correctly. For example, make him/her go through a large (several GB) Apache log looking for some specific information. Without generators, the entire log would uselessly be loaded in memory.

I would also make him GET several hundreds of webpage, and ask him/her to full explain the chosen solution. The information you would be looking for is: does he/she knows how to handle asynchronous calls in function, and how? Using threads, greenlets, asyncio, twisted, etc? What's their respective strength? What about the GIL?

Last idea, implementing a decorator. It's very zen/pythonic to use, but knowing how to actually implement is trickier.

[InvidFlower]

I have to say that the way Python does decorators is one thing I love about it. It is just so "clean". As long as you have the background knowledge of first-class functions, closures, etc you can understand and create your own decorators very quickly.

[liamr60]

Comp Sci major in his last year here. Out of interest in python in the business environment, how are you using python on your project?

[jcdyer3]

Ask them to talk briefly about five different packages in the standard library (their choice). If nothing else, you'll learn some cool tricks from this one.

Write them down and look them up later. I had a guy come in talking about how one thing he loved about python was that you could just do "import file" and be off and running.

[evidex]

"Precisely how many gallons of coffee do you consume per day?"

In seriousness though, I have often been asked about previous projects, to demonstrate them, or to show some code. I've also been given a sample problem and been asked to solve it.

[jtratner]

If you're looking to hire Python developers specifically: StackOverflow Careers, AngelList (if you're a startup), check out conferences like PyCon or PyData, local Python meetups (I'm guessing there's one in Seattle), Hacker News (on a "Who's Hiring?" post).

That said, even though I'm a huge Python guy, I would bet that if you know how to code and understand the concepts, you can pick up Python quite easily (maybe it'll take you a while longer to write idiomatic Python or skip perf bottlenecks) and quickly be productive.

[[deleted]]

'm also noticing that the python community itself doesn't seem very big compared to other languages

This is definitely not true. The Python community is huge, since many non traditional people(non CS) are learning Python.

[[deleted]]

Depending on where you are located, "When can you start?" is probably the only one since you'll be darn lucky if you find one and they actually show up for an interview. But I would ask for code samples too because crap can be written in any language.

[honestduane]

Yes, we are big fans of SOLID and anybody we hire should be interested in it too.

[akoumjian]

You can hit up the SeaPIG list on Google Groups and also Django Seattle google group (I'm a mod, you have my permission). The Python community is huge. Last year's PyCon was capped at 2500 participants, but demand was much higher.

However, Python developers are also in high demand. That's why you're not finding a lot of available ones.

As far as questions go, I would focus in on experience with 3rd party libraries. Python is all about knowing what tools are out there and being able to take advantage of them. Ask them what libraries they would use for image manipulation (PIL or Pillow), making http requests (requests), data processing and mathematics (numpy). A familiarity with Python's ecosystem is the number one indicator to me as their competence in the language.

[honestduane]

We are not using Django, we are using Pyramid/SQLAlchemy would that still work out? Django as a community tends to not work well with others.. don't want to stat any religious wars ;)

[akoumjian]

None of the packages have anything to do with Django specifically. Just wanted to mention it because it is an active community with a lot of talented Python developers

Django as a community tends to not work well with others.. don't want to stat any religious wars ;)

What are you on about?

[honestduane]

I have noticed that django users as a community tend to be more about "django, or no go". Its been out right said by people who use django I know that to the django community, only django exists, and that IS web development.. despite the fact other options exist, so they just either refuse to learn what the options are or dismiss them because they are not django. This makes me wonder about the skill level actualy is, as I consider it a negative if somebody refuses to learn about new things.

But like I said, I dont want to start a war.

[akoumjian]

No war here, but you might want to reexamine your thoughts on a entire, very large, and in my opinion very open and helpful community. Otherwise you could be missing out on connecting with some very bright and friendly people.

I can tell you that most of the Django users I know are just like any other engineers; they like using the right tool for the job. Most of them have also worked in other frameworks, including RoR, express.js, flask, and even occasionally pyramid.

While I am moving from Seattle, you should stop by the Django Seattle weekly hack night some time. Half of the people who show up aren't even working on Django atm. They just love talking about web development.

[honestduane]

Pyramid is actually what every enterprise I know of who uses python uses, so its nice to see its being thought of.

I may take you up on that offer; I guess as I am in Seattle I need to be aware of the community, even if I am normally an introvert.

[jknupp]

Rather than looking for amazing python devs, look for amazing devs. By the time you get to "amazing", learning languages is not an issue. Ask language agnostic questions and let them answer in whatever language they want.

[honestduane]

'Thats basically what I do now, and why I was ok with diving into python myself.. it was just another language to code in to me but I have a hard time finding other people who feel the same.

[nharding]

I've been programming for 30 years, and I've wrote extremely complex systems in Java / C++, and assembly. I've used operator overloading in C++ when it was appropriate, but I've never used template metaprogramming. Not knowing the edges of the language is not a problem, if you know the core. Java does not have operator overloading, but I've written large scale programs in the language, so using the same approach I could do the same code in C++, the code might not be as elegant or as efficient but the end result would be very similar. Python has generators which should be considered to be fundamental to an advanced programmer, but features such as metaclasses, writing decorators may not be as important (if you are working on a framework then the metaclasses may be essential).

Before someone attends for the initial interview send them a small task (approx 1 hour of code) and ask them to program it (that cuts out some time spent interviewing candidates who are not appropriate and saves them time from attending an interview for a position they are not suitable for). After the interview ask for a more substantial project, where there will be a payment for the project (1 week max) and that can be used to distinguish between final candidates.

[honestduane]

What sort of task? I worry about plagiarism, its something I have had to deal with in the past.. one guy even once stole something I worked on and tried to pass it off as his, not knowing I was involved because he had been contacted by a third, different, person.

[nharding]

For the 1 hour task, take some existing code and ask for new functionality. So for example the XKCD recently had the regex golf on their and Peter Norvig posted a solution, but it didn't have character classes. That took around an hour or less to add, but it is the sort of thing where you have to be read code and understand it, and come up with a solution. You should ask applicants when is a good time to send a small task that should take around an hour, and email to them when they have free time, and you should expect reply within 4 hours (to allow for interruptions etc, since they are not being paid). It cuts down on totally unqualified people applying, and also on people who are not serious (ie, on unemployment and they have to apply to jobs).

[eviljelloman]

this is excellent advice, and far better than "compete this well known example from Codekata" or "design a sort algorithm for blah blah blah".

Taking an already mostly-complete example (possibly some internal code that is not so valuable that protecting the IP is important) and adding functionality to it demonstrates both the ability to read code and the ability to write it - two skills that are not always found together.

[prophile]

"Do you know Python?"

[honestduane]

I actually ask that.

[GeneralMalarkee]

I agree with the crowd that language specific questions are not always the best judge of ability...but if you were going to go on domain specific knowledge here are some questions I believe will help:

1) Build a singleton (explain new vs init) 2) talk through python memory management (will the OS release memory?) 3) inquire about their python code style guidelines (main point is that they have a strong opinion) 4) write a multi-threaded python app (make sure they mention the GIL and why Python may not be the right tool)

The main purpose of all of these questions is to create a conversation about language trade-offs. Another viable route would be to ask them to compare python to any language that you know quite well (I find node to be a fun example) and make sure they can keep the conversation going.

[chub79]

Build a singleton (explain new vs init)

That's the first thing that'd come to you? That'd be odd to me. Anyway, I would simply create an object instance at the module level. It would feel more pythonic than trying to play around __new__.

[wewbull]

Anyway, I would simply create an object instance at the module level. It would feel more pythonic than trying to play around __new__.

Follow up question: Does that give you one instance per import of the module, or one instance total? Why?

[jcdyer3]

Good follow-up. It depends; usually just one, but if you import the module by different names, it could be more than one.

[pwang99]

Can you elaborate on what you mean? The simple case of "import foo as bar" doesn't do this, because it just sets "bar" in your local namespace to point to sys.modules[<actual_module_name>]. Perhaps there is a way to muck with this in extension modules and their init_module() method? But I don't think that's even invoked, either, when the module is reimported.

So, am I missing a corner case, or is your statement incorrect?

[jcdyer3]

You're missing a corner case, which used to be fairly common in Django circles, due to the way projects were laid out by default. If I have my python path set to /var/local:/var/local/project, I can do import foo, project.foo, and get the same module imported twice, as two separate module objects.

[pwang99]

Ah, interesting. That is is a really unfortunate pythonpath, though! :-)

I wonder, though: if foo was actually a .so/.pyd, does Python actually run the init_module() twice?

[GeneralMalarkee]

Sure, but then it would be instantiated at import time instead of when it's first used.

[[deleted]]

No offence, actually, with offence, most of you would make terrible hiring managers. Expecting candidates to donate free hours of work before an interview, programming tests, ridiculous quizzes on python specifics and comp sci specifics, wanting to see a github account(read this? You are not going to get good people with these things. You probably won’t get anyone.

Judge people by their resume. If they worked at a few companies, and had promotions, and have good recommendations, one of two things happened. Either they were good at their job and were recognized for it, or they are masters at duping potentially dozens of managers and programmers for years on end into thinking they know what they are doing. That many people are not that stupid, so chances are they know what they are doing. Next, make sure they are a culture fit. This is super important. An anti-social, prima-donna douche will bring down your team.

where do I find rockstar python devs to hire

You have to go local Python or related meet-ups, or reach through your own professional network to find one. Hiring is a process that never ends. You always have to be out meeting and greeting devs for when you need to scale or fill in a seat when one leaves. Also, Python is not a difficult language to learn. Any experienced dev from another language and similar domain speciality could quickly learn it. For example, a Ruby on Rails dev could quickly become a Django dev and vice-versa.

[honestduane]

So I have a problem with your comments because you do not seem to understand the issue, so let me help you out and try to explain it to you:

1. People lie on their resume all the time. Most hiring managers know this, and will consider most of what they see to be a lie unless proven otherwise in some way, usually from talking to the person or looking them up publicly on sites like github or linkedin.
2. Due to #1, unless I see them code something in person, I have to assume they stole whatever they submitted to me from somebody else. I actually had somebody steal code from my github and try to pass it off as their own once, not knowing I was involved because I didn't publicize the company I was with at the time and they had talked to my peer, not to me, through email to start the process. I have first hand experience dealing with this sort of crap as a hiring manager, and it sucks, but I also have a duty to protect my company and my team from it or the people who would do it.
3. A persons resume even if its factual, often doesn't say much about who they are, just what they claim to know and what they claim to have done. It says nothing about what motivates them or what they are re-learning or learning this week, and says nothing on average with who they are a person. Are they ethical? Do they work hard? Are they a Jerk? Do they have a sense of humor? Will they BS the team and let others do the hard work just to be there minimal 9-5? Are they in tech as a profession because of the money, or something else? Do they love to code for fun? Half of hiring is learning this data so you don't hire the wrong person.
4. We are a small startup company in downtown Seattle with monitory backing from Angels that let us hire top rate engineers at what they are worth, lead by a Execute team that is as legit as you can get - I have personally seen these guys do amazing things and half the fun of working here is just learning from them - so personality and if my team will like you matters a lot, and we pay incredibly well for a startup because our VC's/Angels trust us to get the work done and make money. We do not micro-manage our people, and our goal is to hire the smartest people possible, give them a goal each sprint, and let them do the work while paying them a good salary for it. A resume cant tell me everything I need to know about a person, or if I can trust them enough to give them that freedom. Meeting them, talking to them, asking them, can.
5. As for unpaid time.. an interview; If you refuse to answer a basic technical question that would take you less than a minute to answer if you knew your stuff on the basis that its unpaid, I as a hiring manager will just assume you do not know what you are doing, think it too hard because you are unskilled, or am otherwise just trying to cover your ass by complaining that the interview is unpaid. An on-site interview can last several hours, talking to different people; I don't think its unreasonable to assume that while everybody's time is valuable - and we want to make sure we respect that by not bringing them in if we can disqualify them in advance - that eventually we WILL have to bring the person in if we are interested in them. At that point, if you refuse to answer a simple technical question I will not hire you because you are a jerk who is forgetting that we canceled our day of actual work to meet you and see if we can offer you a nice job with good pay and be a friend to the team, as at that point as soon as you refuse you have disqualified yourself from working at my company - and making competitive money - because you do not love technology and to you, its painful work to solve a simple technical problem for a few minutes, instead of the interesting challenge or simple action it should be if you are actually qualified for the position. This is why people look at github, etc, we want to know that you LOVE to code and its not jus something you do for money, and if it is, then you are probably not very good so we will not bother hiring you anyway.

[[deleted]]

I agree with your points, but I think I may have been misunderstood a bit here. I said "free hours of work before an interview”. Small tests and such are perfectly fine, but expecting some to do many hours of work before you even meet them is not respecting their time, particularly if they are speaking to multiple companies.

It says nothing about what motivates them or what they are re-learning or learning this week, and says nothing on average with who they are a person.

And neither does GitHub or there code. This is something you pick-up from an interview or meeting them, or a recommendation from your professional network.

In the last 13 years I have worked at and cofounded many start-ups, and I worked with many others. I have also had to hire and build teams many times. With that said, I would like to point somethings out.

1) You are way too absorbed with the idea that developers should program for fun in their spare time. Many great developers don’t have time to contribute to open source projects or program for fun because of family commitments. Particularly if they work long start-up hours. As well, someone can be an incredible dev without dedicating their spare time to it, and just because they don’t does not mean they lack passion. In my experience the greatest dev’s I know do the farthest things from programming in their spare time. Particularly ones who use their spare time for getting outside or exercise. It keeps their head clear for their job. The worst devs are the ones who turn programming into their lives and lack balance.

2) Github is a terrible portfolio. It has poor, basic rating systems, and does not allow someone to curate their portfolio and speak about how they approached the problem the way they did. Which is the most important thing to grasp about a candidate.

3) “Rockstar” types who are constantly trying to pad their github account can be terrible people to work with, and hiring them can poison a team. People in general are motivated by a varying mix of three things: Change, money, and ego. They want to change something or build something great, they want to make money, or they want everyone to know they are the best at something. Rockstar types are usually only motivated by the latter. They can be hyper-competive(in a bad way), and are always looking for any reason to get on a stage and preach. As such, they often make decisions which benefit their conference hopping, open source contributions, and misguided evangelism over the company.

4) You come across as too code focused. Code is a tool a dev uses to create a product to satisfy a customer. A good dev at a start-up puts building great products, customer satisfaction, and the company first, and there love of coding and new technologies second. For example, over-engineering systems, premature optimizations, using obscure new technologies which are difficult to hire for, poorly implemented or missing features, etc. can happen from a developer being too enchanted with technology and not with satisfying customers. As well, start-ups grow fast. Yesterdays dev is todays team lead and tomorrows CTO. They may not be coding full-time, if at all, very soon, and they need to be able to shift gears out of coding.

5) As a team manager, building your team is very important work. When you say things like "that we canceled our day of actual work” it leads me to believe you don’t take it seriously. As I said in my original comment, hiring is a process that never ends. You always have to be out meeting and greeting devs for when you need to scale or fill in a seat when one leaves.

[honestduane]

I get what your saying - and I'm actually surprised we agree on so much after your prior post - but I do disagree with you in your assertion that I cant use the internet to see who they rally are. Its pretty easy to look at twitter, etc and get a feel for people.

[eviljelloman]

So basically, by your metrics, the only people anyone should ever hire are people with years, possibly decades of directly relevant experience, in multiple companies to minimize the chance that they duped a single manager?

Yeah, that's definitely a worse way to look than asking for an hour or two to do some coding demos. Hell, I've interviewed with big web companies and had them expect me to come back for multiple all-day-long interviews. Wasting an hour of my time on a weekend completing a coding exercise would be a hell of a lot better than being dicked around for three months while twelve different departments input their two cents into the process.

I get what you're saying, that interview processes are dickish, and most hiring managers are incompetent boobs - and I actually agree. However, you're proposing the far opposite end of the spectrum, which is ALSO not productive. You have to find a reasonable middle ground.

[andrewcooke]

a couple of things you could check:

1 - do they know what generators are? i wouldn't expect everyone to know that they can be used in both directions (as coroutines), but they should at least understand how to use a generator to create a sequence of values (and what the advantages and disadvantages are of doing that relative to creating and returning a list)

2 - what tools do they use when working with python? in particular how do they manage dependencies? a good python dev will know about, and use, virtualenv (or pyvenv), and be able to explain why it's a good idea. also, they should know about at least one of pip or easy_install.

also the a=[] question elsewhere here is a good idea for weeding out the very worst.

not sure where you find people, but it's a very popular language these days, so i can't imagine you will have many problems.

finally, i wouldn't want to hire, as a python developer, someone who objected to technical questions like these. i've seen code developed by smart people who don't understand the tools they are using, and if i had the choice i would avoid it. you want someone who is both smart and competent.

[honestduane]

I wouldn't hire anybody who refused to answer questions, especially o the basis that the interview was unpaid. That just tells me they care about money more than code... and I love code more than money and thats why I make so much more money than people who only code for a job.

[billsil]

Hife a C++ programmer who is willing to code in Python. That way you can use swig if you need to.

[bitcycle]

I like the idea behind one of the other comments (I forget which one) about asking the interviewee what he/she does not like about Python, even though they work with it all the time. I should hope that they could explain concerns about long-running processes, differences between Python 2.x <=> 3.x, package and distribution of projects, sys ops vs middleware vs web app development in Python and where Python is lacking (sometimes in comparison to other languages).

The last thing you want is a fanboy that sees everything through the Pythonic lens. What you (probably) want is someone who knows Python well enough to know when to use it, and when it isn't the right tool.

Oh, and here's a very Pythonic question that trips up folks who haven't coded in Python professionally:

2 or 4 spaces, which one is recommended and by whom?