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.
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.
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.
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.
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.
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.
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.
Djangonauts tend to have some favourite frameworks that they end up using in all their Django projects.
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.
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.
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.
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.
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.