Python for a Coding Assessment
A refresher path through the Python graph for someone who has written Python before and has an assessment coming: run and read, rebuild the core, then work the way an assessment expects.
I can choose between a list, a dict, a set and a tuple for a given task, and say what each one costs to look up, insert and iterate.
The four built-ins a Python program is mostly made of, and the reasons to reach for each. Choosing well is most of what separates code that stays fast from code that quietly does not.
In scope: list, dict, set and tuple; what each costs; mutability and what it means for arguments and
keys. Out of scope: collections and the rest of the standard library, and formal complexity
analysis, which have their own nodes.
Ask what the code does most often. If it asks “is this in there?” or “what is the value for this?”, a list is the wrong answer: every question walks the whole list, so the work grows with both the number of questions and the size of the data. A dict or set answers in about the same time regardless of size.
This is the single most common cause of a script that runs fine on a sample and takes hours on the real file. The Python wiki’s complexity table is the reference: list membership is O(n), dict and set membership is O(1) on average.
A list passed into a function is the same object the caller holds: mutating it changes their copy too, which is a feature when intended and a bug when not. A tuple cannot be changed, which is why it can be hashed and used as a dict key, and why it is the safer way to return a fixed group of values.
Give learners a script that checks membership against a list of 100,000 items, have them time it, then change one line to a set and time it again. The number does the teaching.
Then ask the better question: “what does this code ask most often?” — and have them answer it before choosing a structure, for three different tasks.
| Resource | Kind | Cost | Provider |
|---|---|---|---|
| The Python Tutorial: data structures | reading | free | Python Software Foundation |
| Automate the Boring Stuff, chapter 4: lists | reading | free | Al Sweigart |
| Automate the Boring Stuff, chapter 5: dictionaries and structuring data | reading | free | Al Sweigart |
| Python wiki: time complexity of built-in operations | reference | free | Python Software Foundation |
A refresher path through the Python graph for someone who has written Python before and has an assessment coming: run and read, rebuild the core, then work the way an assessment expects.
A timed take-home in the shape real hiring uses: read messy data, compute a result, test it, and hand over a repository someone else can run.
The holder can take an unfamiliar problem, write a tested Python solution someone else can run, and explain what it costs.
Nothing to show yet. The publisher last published on 2026-09-20, and no aggregate for this outcome has reached the 50 learners a number needs. Open Degree does not track learners. About learner evidence.