Master Python reverse dict interview answers: give the unique-values one-liner, name the duplicate-values caveat, and explain the group-by follow-up.
Most candidates who stumble on a python reverse dict interview question don't stumble on the syntax. They stumble on the framing. They hear "reverse the dictionary," immediately reach for the cleanest one-liner they know, and type it out before they've asked themselves whether the values are unique — which is the only question that determines whether their answer is correct.
That silence before the code is the tell. A mid-level engineer who treats this as a syntax exercise is showing the interviewer something they didn't intend to show: that they solve problems by pattern-matching to familiar code rather than by reading the actual constraints. The question isn't hard. But it is a trap for candidates who optimize for looking fluent over being right.
The answer interviewers want is not the most elegant one-liner. It's the one that starts simple, immediately names the caveat, and then shows what changes when the caveat applies. This guide gives you that answer in the order you should say it.
What Interviewers Mean by Reversing a Python Dict
They Are Not Asking for a Magic Trick
When an interviewer asks you to reverse a Python dictionary, they are checking whether you understand the structural constraints of a dictionary, not whether you've memorized a comprehension shortcut. A Python dict maps keys to values where keys must be unique and hashable. When you reverse it, you're trying to make the values into keys — and that only works cleanly when the values are themselves unique and hashable.
The real test is whether you can distinguish two fundamentally different problems: a one-to-one inversion, where every value maps back to exactly one key, and a grouped reverse lookup, where multiple keys share a value and you need to collect them. These are not the same data model. An interviewer who asks this question has almost certainly seen candidates answer the wrong one with complete confidence, which is why naming the distinction before you write a single line of code is the move that separates strong candidates from average ones.
The mistake pattern that shows up most often: the candidate answers with code before they restate the problem. They produce a syntactically correct dict comprehension, the interviewer says "what if two keys have the same value," and the candidate has to backtrack. That backtrack costs more than the original hesitation would have.
What This Looks Like in Practice
Consider two dictionaries that look almost identical:
In Case 1, reversing the dict produces `{1: 'a', 2: 'b'}` — a clean, valid dictionary. In Case 2, both `'a'` and `'b'` map to `1`. There is no single key `1` that can point to both of them in a standard dict. The problem has changed from "invert this mapping" to "group these keys by their shared value," and the output structure needs to change with it: `{1: ['a', 'b']}`.
The Python documentation on dictionaries is explicit that keys must be unique — and the moment you make values into keys, that constraint applies to them too.
Start With the Shortest Answer: Invert Unique Values With a Dict Comprehension
The One-Liner That Is Actually Correct
When values are unique and hashable, the correct answer to invert a Python dict is a dict comprehension:
This is the right answer for the simple case — and you should say so explicitly. "Assuming values are unique and hashable, I'd use a dict comprehension over `.items()`." That qualifier does two things: it shows you understand the constraint, and it signals to the interviewer that you're about to address what happens when the constraint doesn't hold.
The comprehension works because `.items()` returns key-value pairs as tuples, and swapping `k` and `v` in the comprehension produces a new dict where the original values become keys. If any value is unhashable — say, a list — Python will raise a `TypeError` at runtime, which is another reason to state the assumption upfront rather than let it surface as a bug.
What This Looks Like in Practice
In Python 3, `.items()` returns a view object — a live, memory-efficient window into the dictionary rather than a copied list. This is relevant if you're inverting a large dictionary, because the view doesn't materialize a full copy of the data before iterating. In Python 2, `.items()` returned a list of tuples, and `.iteritems()` was the memory-efficient equivalent. In a modern interview context, assume Python 3 unless told otherwise, but knowing the distinction shows range.
From a code-review perspective: a dict comprehension that silently overwrites duplicate values is not just suboptimal — it's semantically wrong. It produces a dict that looks correct and passes a basic test, but loses data. That's the category of bug that's hardest to catch and most damaging in production. An answer that acknowledges this before writing the code is categorically better than one that discovers it afterward.
Say the Awkward Part Out Loud: Duplicate Values Change the Job
Why the One-Liner Breaks the Second Values Repeat
The comprehension approach is genuinely good for what it does. When values are unique, it's readable, idiomatic, and fast. The problem is that most real-world dictionaries are not guaranteed to have unique values, and the comprehension fails silently when they don't — it doesn't raise an error, it just quietly discards data.
When two keys share a value, the comprehension processes them in iteration order and the later key overwrites the earlier one. You end up with a dictionary that has fewer entries than the original, with no warning. That's not a reverse — it's a lossy transformation, and in an interview context, presenting it as a complete answer is the kind of thing that makes an interviewer write "missed edge case" in their notes.
What This Looks Like in Practice
The key `'a'` is gone. The correct output when you want to group keys by value is:
This is a different data structure — a dict mapping each original value to a list of keys — and it's the only structure that preserves all the information. The moment you have duplicate values, a true one-to-one inverse no longer exists. The right answer is to say that out loud: "If values can repeat, there's no single-key inverse, so the correct approach is to group keys into a list under each value."
Teaching this concept in practice, the exact moment students internalize the distinction is when they see the silent overwrite happen. Before that, "reverse" sounds like one operation. After it, they understand there are two different data models hiding behind the same word — and that choosing between them is the actual problem.
The Python data model documentation confirms that dictionary keys must be unique, which is precisely why making values into keys requires checking for collisions first.
Use defaultdict(list) When You Want the Clean Grouped Answer
The Version That Reads Like You Know What You're Doing
When values can repeat, `defaultdict(list)` from the `collections` module is the cleanest solution. It handles the "first insert" problem automatically: you don't need to check whether a key already exists before appending to it, because `defaultdict` creates an empty list the first time a key is accessed. This makes the intent of the code immediately obvious — you're accumulating keys into groups, and the data structure says so.
The `dict(result)` at the end converts the `defaultdict` back to a plain dict for cleaner output, which is a small but professional touch worth mentioning in an interview. It signals that you're thinking about the interface the function exposes, not just the internal mechanics.
What This Looks Like in Practice
Every key is preserved. Every value maps to the complete list of keys that produced it. This is what "reversing a dictionary with duplicate values" actually means — and stating that framing before writing the loop is the answer that earns the follow-up question rather than the correction.
When setdefault Is Fine and When It Is Not
`setdefault()` is a perfectly acceptable alternative that doesn't require importing anything:
It's explicit about the default creation step, which some interviewers prefer because it makes the initialization visible. The tradeoff is readability: `defaultdict(list)` announces its intent at the top, while `setdefault` buries the initialization logic inside the loop. For most interview contexts, `defaultdict(list)` is easier to read and explain. Use `setdefault` if you want to avoid the import or if the interviewer has specifically asked you to stay with built-in types.
From a code-review standpoint, the readability difference matters more than the performance difference. Both approaches are O(n) in time and space. The question is which one a reader can understand in three seconds. `defaultdict(list)` wins that test. The collections module documentation covers `defaultdict` in detail and is worth reading before any Python interview.
Know the Alternate Inversion Patterns, but Don't Pretend They Are the Headline Answer
zip, map(reversed, my_dict.items()), and the Iterator Tricks
There are other ways to accomplish dict inversion that you'll encounter in code or in interviews as style checks. Two common ones:
Both produce the same result as the dict comprehension for the unique-values case. Neither is the answer you should lead with, because neither makes the logic as readable as the comprehension, and both carry their own caveats that you'd need to explain.
What This Looks Like in Practice
The `zip` approach pairs values with keys in order and wraps them in a dict. It's compact, but the intent is less obvious than a comprehension — someone reading it has to mentally trace the pairing to understand what it produces.
The `map(reversed, ...)` trick works because each item from `.items()` is a two-element tuple, and `reversed()` on a tuple returns an iterator. Wrapping in `dict()` collects the pairs. It's clever, but "clever" is not what you want an interviewer to think. It's also worth noting that in Python 2, `.items()` returned a list of lists, and `reversed()` on a list returns an iterator — the behavior is consistent across versions, but `.items()` behavior differs between Python 2 and Python 3 in ways that matter for memory usage.
From an interviewer's perspective: neat one-liners are fine, but only if the candidate can explain exactly what they return and why. If you use `map(reversed, my_dict.items())` and the interviewer asks "what does `reversed()` return on a tuple," you need a real answer. If you can give it, the trick becomes a demonstration of range. If you can't, it becomes a liability. The Python 3 migration guide covers the `.items()` and iterator changes in detail.
Explain the Complexity Before They Ask You to Defend It
Big-O Is Easy; Saying It Cleanly Is the Real Test
Every common approach to dict inversion — comprehension, `defaultdict`, `setdefault`, `zip`, `map` — is O(n) in time, where n is the number of key-value pairs. You make one pass through the dictionary. Each pair produces one write operation to the output structure. There's no nested iteration, no sorting, no recursive call.
Space complexity is also O(n). The output dictionary grows linearly with the input. For the grouped case with duplicate values, the total number of entries across all lists equals the total number of keys in the original dict — so it's still O(n), but the distribution across lists varies.
What This Looks Like in Practice
The mental model is simple: one pass, one container. For the unique-values case, the output has at most n entries. For the grouped case, the output has at most n entries distributed across the lists — the total item count across all lists is exactly n, because each key appears in exactly one list. Duplicate values increase the size of individual lists, but they don't increase the total item count.
A useful rubric for evaluating whether a candidate actually understands complexity versus reciting it: ask them to explain what "n" refers to. A candidate who says "O(n) where n is the number of items" understands the analysis. A candidate who says "O(n) time" and stops has memorized the label without the reasoning. Stating your n explicitly — "one pass through all key-value pairs, so O(n) where n is the number of pairs" — is the sentence that earns the check mark.
Separate Inversion from Reverse Lookup Before You Talk Yourself Into the Wrong Answer
These Sound Similar and They Are Not the Same Thing
Inverting a dictionary means producing a new dictionary with keys and values swapped across the entire structure. Reverse lookup means finding the key (or keys) that correspond to a known value — without necessarily building a new dictionary at all.
These are different operations with different use cases, and candidates who don't draw the line often overbuild. If the interviewer asks "how would you find which key maps to value 2 in this dict," the correct answer might be a single generator expression:
That's O(n) in the worst case, but it short-circuits as soon as it finds the match and doesn't build a new data structure. Building a full inverted dict just to do one lookup is wasteful — and saying so is the kind of nuance that distinguishes a mid-level engineer from a junior one.
What This Looks Like in Practice
Here's a quick decision tree for the interview moment:
- Unique values, need the full inverse: use a dict comprehension. O(n) time and space.
- Duplicate values, need the full grouped inverse: use `defaultdict(list)` over `.items()`. O(n) time and space.
- Unhashable or nested values: you can't make them keys at all. State this and ask for clarification on the expected output.
- Just need to find keys by a known value, once: use a generator expression with `next()`. O(n) time, O(1) space. Don't build the full inverse.
- Need to find keys by value repeatedly: build the inverted dict once upfront, then use it as a lookup table. Amortizes the O(n) build cost across multiple queries.
The most common mistake strong candidates make in this category: they hear "reverse lookup" and immediately build a full inversion, when the question only needed a single-pass search. Overbuilding isn't wrong — it's just not the best answer, and interviewers notice.
FAQ
Q: What is the simplest correct way to invert a Python dictionary with unique values?
A dict comprehension: `{v: k for k, v in my_dict.items()}`. It's readable, idiomatic Python 3, and O(n) in time and space. The qualifier "unique values" is load-bearing — state it before you write the code, not after.
Q: What should you do if multiple keys share the same value?
Use `defaultdict(list)` from the `collections` module. Loop over `.items()` and append each key to the list under its value. The result is a grouped dict like `{1: ['a', 'b'], 2: ['c']}` — the only structure that preserves all the information when a true one-to-one inverse doesn't exist.
Q: Which solution is most interview-friendly to explain out loud?
The two-step answer: start with the dict comprehension for unique values, immediately name the duplicate-value caveat, then show the `defaultdict(list)` version for the grouped case. This sequence is easy to say, easy to follow, and demonstrates that you understand the problem before you solve it.
Q: Why does a one-line comprehension fail when values are duplicated?
Because dictionary keys must be unique. When two original keys share the same value, that value becomes a key in the inverted dict — and the second assignment silently overwrites the first. No error is raised. Data is lost. The comprehension produces a structurally valid dict that is semantically wrong.
Q: What is the time and space complexity of the common inversion approaches?
All of them — comprehension, `defaultdict`, `setdefault`, `zip`, `map` — are O(n) time and O(n) space, where n is the number of key-value pairs. One pass through the input, one output container that grows linearly. For the grouped case, the total item count across all lists is still n, because each key appears in exactly one list.
Q: When should you use defaultdict(list) versus setdefault()?
Use `defaultdict(list)` when readability matters and an import is acceptable — the intent is clearer at a glance. Use `setdefault` when you want to avoid the import or need to stay with built-in types only. Performance is equivalent. The choice is almost entirely about code style and what you can explain clearly under pressure.
Q: How do you explain the difference between inversion and reverse lookup?
Inversion produces a new dictionary with keys and values swapped across the whole structure. Reverse lookup finds the key (or keys) that correspond to a known value, often without building a new dictionary at all. If you only need to find one value's key once, a generator expression is more efficient. If you need to look up by value repeatedly, build the full inverse once and reuse it.
How Verve AI Can Help You Ace Your Coding Interview With Python Dict Reversal
The structural problem this article just walked through — knowing the right answer but fumbling the explanation under pressure — is exactly what practice is supposed to fix. The catch is that most practice environments can't tell you when your explanation missed the caveat, or when you said "O(n)" without defining what n refers to. They just wait for you to finish.
Verve AI Coding Copilot is built for the gap between knowing the answer and saying it well. It reads your screen during live coding rounds and mock sessions, tracks what you're writing in real time, and surfaces the kind of follow-up prompts an interviewer would actually ask — "what happens if values repeat?" "what's the space complexity?" "why not use setdefault here?" — so you practice the full conversation, not just the code block.
The Secondary Copilot feature keeps you focused on one problem at a time across LeetCode, HackerRank, CodeSignal, and live technical rounds, without context-switching between tabs. Verve AI Coding Copilot suggests answers live when you're stuck on the explanation, not just the implementation — which is where most Python dict interview questions are actually won or lost. If you've got the syntax down but want to practice the 30-second verbal version until it sounds calm, that's the exact workflow Verve AI Coding Copilot is designed for.
Conclusion
The best answer to a Python reverse dict interview question is still the short one first. Write the comprehension, say "this works when values are unique and hashable," and then immediately show what changes when they're not. That sequence — simple case, caveat, grouped solution — is what the question is actually testing. Not the one-liner. Not the cleverest iterator trick. The ability to name the edge case before the interviewer has to extract it from you.
The 30-second spoken version of this answer is worth practicing until it sounds like something you've thought about, not something you memorized. "I'd start with a dict comprehension for the unique-values case, but if values can repeat, there's no true inverse — so I'd use `defaultdict(list)` to group keys by value. Both are O(n)." That's it. Say it until it sounds calm.
James Miller
Career Coach
