Recently I was interviewing some Python developers for a job opening. And I thought I’d share my unorthodox methods for evaluating someone’s skill as a developer using Python.
That’s different from “how well do they know Python”. Because I really don’t care how well they can rattle off arcane details of the language.
Instead, I want to grasp whether they can balance getting-things-done with doing-things-right, in situations that are not completely unlike what I might actually be paying them to do.
So rather than having them sketch out bubble sort on a whiteboard or something, here’s a few things I might do:
1) Process CSV data
I tell them to bring their laptop to the interview, and make sure it’s set up for Python development.
I’ll give them a CSV file of some kind of interesting data. Nutrition info for different foods, for example – something like that. And I will ask them to write a program to ingest and answer questions on that data.
Starting with the simple: “What’s the average value of the “calories” column?”
So I know that they can at least open the file and slurp in the data.
Then something a little more interesting, like: “Sort the foods by their ratio of protein to calories”.
And so on.
I don’t care if they use Pandas, or the csv module, or some library I’ve never heard of. I don’t care whether they use PyCharm or Vim or Nano. Unless it’s something basic, I don’t even care if they search online during the interview to figure it out.
I just care that they CAN figure it out.
2) Speak JSON over HTTP
I wrote a little todo-list web service, which you can GET and PUT and POST to over the network. And I give them the address, and a short doc that fully specifies its API…
How to create new tasks; list incomplete tasks; mark tasks as done; et cetera.
And I lead them through writing some code that exercises it. Because in the modern world, we have to write glue code with web services like this a lot.
If they happen to have never done this kind of thing yet – maybe they’ve just had jobs so far where it was never required, for example – in a way, that’s even better.
Because I can give them a quick tutorial in using the “requests” module, and see if they can use it right away to create simple interactions with the API.
And this lets me evaluate their ability to quickly learn a library and use it in real code… ANOTHER important ability in the modern world.
3) Test-Driven Version Control
I’ll have them develop a simple library, using test-driven development.
Emphasis on “simple”. I’m not going to ask them to implement a JIT compiler for a C-like language.
More like: generating integer sequences. Something a little trivial, because I’m testing something else at this point. And we don’t have all day to do the interview.
So I tell them the first requirement. And tell them to write code that meets that requirement, using test-driven development, and version control.
(Again, I don’t care if they use unittest or pytest or nose; git or mercurial or fossil or whatever. If they can do it with one of these, they can quickly learn to do it in the one I want.)
Once they’ve done that, I give them the new requirement. And they have to write new unit tests, maybe modifying some of the tests they just wrote, and then implementing application code to make the tests pass.
And I repeat once or twice more.
This tells me a lot about how they develop software, their strengths and their weaknesses.
There’s more to the interview process than this. What I wrote above are just some pieces I might use in an interview.
And if you plan to go on an interview soon, consider practicing with these questions before. Just maybe, it will help prepare you to pass with flying colors.