Unlike Michael Scott above I'm not a manager.

Yet I have worked as a Python/Django backend engineer for more than a decade. This puts me in a "senior" role in any team I usually join.

As a result, I get involved in the recruitment process. I.e. to look for someone who would then become a team mate.

This post is about questions I ask a prospective Python/Django backend engineer. A prospect with 2+ years of experience doing Python/Django backend development full-time.

The prospective engineer would be working in my team. With me. Not for me.

So the questions aim to help me to answer the fundamental "Would I want to work with this person?" question.

Below I go through what I look for in each question. Note that unlike a "hackerrank" style assessment, these questions look for qualitative attributes.

Answers do not have a completely correct/wrong answer. The way in which the candidate answers is more important than the answer itself.

Update 2021-06-06. These questions are Python/Django-specific. They intend to center discussion about Django-specific knowledge and experience. I have written another backend engineer interview script which is technology agnostic.

Self-intro

Allow the candidate to go over their career trajectory. Have them delve deep into some projects they are proud to have been part of. Allow them to expand on specific processes/tools used.

This will provide you with loose ends to relate the below questions with.

Q1. How do you use the _ character in Python?

Objective is to see how the candidate reacts.

Among the correct answers:

• Used in snake case (i.e. function names and variable names)
• Used to store a function return value which is going to go unused.
• Used to "show" that a function is meant to be used as a "private" function.

Q1 Follow-up: in case "private function" use case is brought up

The followup is a trick question:

How does Python enforce private properties/functions?

The answer is: It does not.

Probe the candidate to make sure she knows what she'd use it for, in Python.

Look for honesty in the candidate's answer. An "I don't know" is more than acceptable. Better than making stuff up.

Q2. Which test data generation toolkit have you used?

Usually the candidate will have mentioned tests in CV or during their own self-intro. It's hard to have good tests without proper management of test data.

This is an open ended question about how the candidate handled test data. Answer demonstrates whether the candidate has written tests or not. Look for familiarity with tools in the Python/Django testing landscape.

Q2 Follow-up: How to improve unit tests speed in Django?

A mature application is one that grows beyond that ideal “micro service” or “side project” size. Along size and complexity, one common aspect is tests taking longer to run.

Adam Johnson has written a whole Speed Up Your Django Tests book on topic. Which I fully recommend.

Do not look for that level of detail though. A couple “quick ways” to improve speed is fine. I.e. low-hanging fruit. Examples:

• Avoid using fixtures in tests.
• Avoid creating more test data than the test requires.
• Change the default Django password hasher. Etc.

The way the candidate answers this shows their “battle scars” in writing tests for Django applications.

Also look out for “quick hacks”. For example, changing the tests to run against sqlite rather than say Postgres or MariaDB. This should not be one of those “quick ways”.

Be ready, especially when it comes to allocated time, to discuss any disagreement. Not only in this question. If the candidate doesn't make it to the next round, they still would have learnt something.

Q3. Which packages you "carry around" in your Django projects?

Djangonauts tend to have some favourite frameworks that they end up using in all their Django projects.

Popular answers include DRF, django-extensions, anymail, allauth and the DJDT.

Q3 Follow-up: How do you decide whether to use a package or reinvent the wheel?

This again is an open ended question. Aim is to see the candidate's experience in making this sort of decision when building out a project. Good considerations include:

• Does this package actually fit the use case? Or at least, is it very close to the use case?
• Set up/installation complexity, especially given architecture of existing application. And other installed moving parts which might not play well with the package.
• Security concerns.
• Activity around package on Github, i.e. recent commits, contributors, responses to issues, etc.

Q4. Which code standards do you follow for a Django project? Tools?

Ideally any of these are mentioned: PEP 8, flake8, black, Django style guide, isort.

There is no correct answer. Just checking for "awareness".

Keeping in mind for example that black and Django's own style guide are not 100% compatible. The specifics are subjective.

Look for familiarity with a tool or a couple of them.

Q5. Which deployment tools have you used? To ship code to production?

Probe the candidate to know more whether they have been exposed to “ops” kind of work. Or at least gauge whether there’s an interest.

Feel free to discuss tools used at your current post, example AWS, Ansible, Python's Fabric library, Docker for local development, etc.

The motivation behind Q5 is that I work in environments where some “ops” skills alongside Python/Django skills are appreciated.

But you might be looking for a full-stack person. Then replace this question with another which shows the person's reaction about some FE-oriented work aspect.

On open-ended questions as these the candidate being opinionated is not a bad thing.

Discussing topics you do not have full agreement on is revealing. For both sides of the interview process. Which is what you want.

To conclude

Remember to encourage the candidate to ask questions throughout. This again enables the two-way information street we want.

I hope you find these useful.

Are there any other questions I should ask? Why? Feel free to add your suggestions as a comment.

This post was inspired by Jacob Kaplan-Moss's article: My interview kickoff script, annotated.

I suggest you give that article a look. Tread carefully. You might find yourself down in Jacob's interviewing series rabbit hole. Some excellent nuggets of knowledge shared down there.