Python Interview Questions: Mastering Technical Interviews

Topic 1: Why Python?

Like any tool, Python shines in some scenarios and falls short in others. When interviewing, be candid about whether Python is actually the best choice for the scenario provided. (And if it's not, don't hesitate to ask if you can switch languages!)

Here are Python's biggest strengths:

• Readability and Expressiveness: Python's clean, English-like syntax makes code incredibly readable. Its "one obvious way to do it" philosophy means different developers will write similar-looking code, making it ideal for collaborative teams and code review.
• Versatility: Python supports multiple programming paradigms. You can write procedural scripts, dive into functional programming with list comprehensions and lambda functions, or build complex object-oriented systems—whichever works best for the task at hand.
• Rich Ecosystem: Python's package ecosystem is vast and well-maintained. Need web development? Django and Flask are battle-tested. Machine learning? TensorFlow and PyTorch lead the industry. Data analysis? Pandas and NumPy are optimized number crunchers. This means you rarely need to "reinvent the wheel."

In practice, Python excels at:

• Rapid Prototyping: Python's simplicity makes it easy to get started and mock up a minimum viable product (MVP)
• Data Science and ML: The ecosystem of supporting libraries for these tasks is unmatched
• Web APIs and Services: Frameworks like FastAPI and Django REST make building robust APIs straightforward
• Automation and Scripting: More powerful than Bash, more readable than Perl, and more portable than PowerShell

However, you should probably look elsewhere when:

• Performance is critical: For real-time systems or performance-sensitive applications, consider C++ or Rust
• Resources are constrained: On embedded systems or memory-limited environments, C is usually better
• Building user interfaces: For web frontends, stick with JavaScript/TypeScript. For mobile apps, use Swift or Kotlin
• Handling Massive Concurrency: Go and Rust offer better built-in support for parallel processing
• Writing System-Level Code: For operating system components or drivers, C, C++, or Rust are more appropriate

Topic 3: Python's try, except, and finally: Exception Handling

Production code always runs into unexpected hiccups: a user claims they were born in 1792, a web server temporarily can't reach the internet, an expired API key makes a web request fail. Any of these edge cases can generate an exception which will terminate our program. In a production system, that's usually not what we want. Instead, we should handle the exception and continue running.

Basic Exception Handling

In Python, use a try block to isolate code that might raise an exception. After the try block, add a series of except blocks to catch and handle different kinds of errors. An optional finally block contains cleanup code that always runs—whether there were exceptions or not.

In production code, you'll probably want to do more than just print inside the except blocks. The specifics vary depending on the application, but some common exception handling actions are:

• Log the error in a structured log. Python's logging module shines here.
• Retry the action that failed, with some delay in between attempts.
• Fall back on sane behavior. In the example above, we might use a default configuration if we can't load the provided customized one.

Broad vs. Specific Exception Handling

You should only catch the exceptions that you're prepared to address. Each except statement should be tied to a specific Exception type to prevent it from accidentally catching more than expected. While the code below runs, it potentially masks a huge range of errors that might need more explicit handling.

Interviewers love considering corner cases and ways things can go wrong. During the interview, you should ask whether the interviewer wants your code to be robust to these kinds of failures or not. Some want to see you write careful exception handling code, and others prefer that you focus the limited interview time on other topics.

Topic 5: Function Decorators in Python

Decorators are one of Python's most powerful features, yet they often trip up developers. At their core, decorators are just functions that modify other functions. That's especially valuable because it lets you add functionality to existing code without changing a function's internal implementation. You should reach for decorators when you want to add extra logic either before or after every call to a function.

A Simple Decorator Example

Let's look at a common example: timing how long a function takes to run. Without decorators, you might write something like this:

This works, but it's tedious and messy to add these lines everywhere slow_method is called. Decorators to the rescue!

Now every call to slow_method automatically includes timing, no matter where it's called from. Pretty nifty, right?

Common Uses of Decorators:

• Monitoring function performance
• Caching and memoizing function results
• Validating input
• Rate limiting for API calls
• Access control and authentication
• Acquiring and releasing exclusive locks

Python's ecosystem includes several useful decorators. The functools module's @lru_cache decorator is a particular standout, caching function results to speed up repetitive computations:

Python's Class Decorators

A few built in decorators are particularly helpful when defining classes.

• The @property decorator makes it simple to control how object attributes are accessed and modified. As an example, if we were defining a Circle class, we could have an attribute for the circle's radius that had to be non-negative. Using decorators, it's easy to enforce that constraint.

  class Circle: def __init__(self, radius: float) -> None: self._radius = radius @property def radius(self) -> float: return self._radius @radius.setter def radius(self, value: float) -> None: if value < 0: raise ValueError('Radius must be >= 0!') self._radius = value my_circle = Circle(5.0) my_circle.radius = -2 # Calls radius.setter, raises ValueError

• Usually, the first argument to every method inside a class is self—the object instance involved in the call. That said, sometimes you'll want to write class methods that don't take in an instance. To do that, use the @staticmethod decorator.

  class Circle: # Snip @staticmethod def shape_string() -> str: return 'circle' print(Circle.shape_string()) # prints 'circle'

• Other times, you might want to write a class method that takes the class instead of a specific instance of the class. To do that, use the @classmethod decorator.

  from __future__ import annotations import math class Circle: # Snip @classmethod def initialize_from_area(cls, area: float) -> Circle: # area = pi * r^2 so r = sqrt(area / pi) radius = math.sqrt(area / math.pi) return cls(radius) unit_circle = Circle.initialize_from_area(math.pi) print(unit_circle.radius) # prints 1.0

During interviews, watch for opportunities where decorators could improve your solution. Common signs include repeated setup/cleanup code, need for timing or logging, or operations that could benefit from caching. When you spot these opportunities, flag them to your interviewer and ask if they'd like you to implement the decorator or focus elsewhere. This demonstrates both your knowledge of Python's features and your ability to prioritize during time-constrained situations.

Topic 7: Debugging Python Code—Beyond Printing

When an interviewer asks about debugging, they're often less interested in the specific tools you use and more interested in your systematic approach to problem-solving. That said, it's good to know about at least one debugging tool that's more robust than adding print statements. In Python, two common debugging options are the built-in debugger (pdb) and IDE visual debuggers.

Key Steps When Debugging

If asked to describe your debugging workflow, be sure to touch on each of the items below:

1. Reproduce the Issue
   • Create a minimal example that demonstrates the bug
   • Document the exact steps to trigger the problem
   • Note the environment details (Python version, OS, relevant package versions)
2. Quick Investigation
   • Add strategic print statements to trace program flow
   • Log variable values at key points
   • Check for obvious issues like None values or type mismatches
3. Deep Investigation. Use a debugger to find the specific point where behavior diverges from expectation.
   • Set breakpoints at suspicious locations
   • Inspect variable values and call stacks
   • Step through code execution
   • Evaluate expressions in the current context
4. Verify the Fix
   • Confirm the original test case now works
   • Add regression tests to prevent future occurrences
   • Check that the fix didn't introduce new problems
   • Document the solution for future reference

How to Use Python's pdb

During Step #3, it's often helpful to use a debugger. To trigger Python's built-in debugger, add a call to breakpoint at the point in your code where you want to debug. When that point runs, you'll be dropped into an interactive shell where you can inspect and modify the program state. You might:

• Show a stack trace (where)
• Print out the value of variables (print [variable name])
• Display source code around the current line (list)
• Execute until the next line, then stop (next)
• Add additional breakpoints (break [linenum | function])
• Continue until the next breakpoint (continue)
• Quit (quit)

Of course, it's unlikely you'll carry out extensive debugging sessions when coding on a whiteboard. Still, having fluency around using debuggers demonstrates programming maturity.

Heading Off Bugs During Development

Prevention is Better Than Cure: While debugging tools are invaluable, professional developers rely heavily on preventive measures to avoid digging out debuggers in most cases. Make sure to mention how your development cycle would incorporate:

• Logging: Structured logging provides insights into production issues
• Assert Statements: Catch invalid states early in development
• Unit Tests: Identify problems before they reach production
• Type Annotations: Catch type-related issues during development
• Code Reviews: Get another pair of eyes on complex logic

Topic 9: Generators and Lazy Evaluation in Python

Generators are one of Python's most powerful features, but they're often forgotten. Why? When working with small amounts of data, generators don't make that much of a difference. As data sizes grow though, using generators can be the difference between a program that runs quickly and one that runs out of memory and crashes. You should be comfortable recognizing where lazy evaluation would help make your code more efficient and scalable.

What are Generators in Python?

At their core, generators are functions that generate values on-demand rather than all at once. This "lazy evaluation" approach can dramatically reduce memory usage when working with large datasets or infinite sequences. Here's a simple example that illustrates the difference:

The generator version might look similar, but it's fundamentally different in how it uses resources. If n is 1 million, the list version creates a list with 1 million integers in memory all at once. The generator version? It holds just a single value in memory at any time.

When to use Python Generators?

Generators shine in real-world scenarios like:

• Processing large files: Read and process the file line by line instead of loading it all into memory
• API pagination: Fetch and yield results one page at a time
• Infinite sequences: Model potentially infinite sequences without running out of memory
• Data transformations: Chain operations together without creating intermediate lists

A More Complex Example: Parsing Logs With Generators

Here's another example that's a bit more realistic. Suppose we have gigabytes of logs from across our computing cluster. Using generators, we can efficiently parse through the logs and aggregate statistics.

Using generators is crucial when you're working with data that's too large to fit in memory. In an interview, showing that you know when and why to use generators demonstrates you know how to write code that scales to production workloads—a key trait for professional developers companies are trying to hire.

Topic 11: Python Linters: Code Quality and Style

Writing clean, maintainable code isn't just about making things work—it's about making them work well over time. Professional Python developers rely heavily on automated tools to maintain consistent code quality. Understanding these tools and Python's style conventions demonstrates that you think about code as a long-term investment, not just a one-off solution.

The Official Standard: PEP 8

PEP 8 is Python's official style guide. Some of the conventions it establishes include:

• Indentation uses 4 spaces—not tabs
• Maximum line length is 79 characters (though modern teams often use larger widths)
• Use snake_case for functions and variables, PascalCase for classes
• Spaces around operators: x = 1 + 2, not x=1+2
• One space after commas: func(x, y), not func(x,y)
• Two blank lines before top-level classes and functions

You should start writing PEP8 compliant code now so that it grows into a habit over time.

Helpful Tools for Python Styling

Python's ecosystem includes several tools that help maintain consistent code in larger projects. On production development teams, it's likely they'll already have one set up to enforce style conventions across the code base. It's a good idea to be familiar with at least one of the common tools:

• Pylint is the de facto standard for Python linting. It's comprehensive—highlighting style violations, logic bugs and code duplication. Well established, opinionated, and widely used across the community.
• Flake8 combines a few different Python linters into one tool to flag deviations from PEP8, overly complicated code, and other logic bugs. It's particularly good at catching syntax errors and style violations without being as strict as Pylint about code organization.
• Black, the "uncompromising code formatter," takes a different approach. Instead of just pointing out style issues, it automatically reformats your code to match a consistent style. This eliminates style discussions in code reviews—the team simply agrees to use Black, and formatting becomes automatic.

Regardless of whether you're coding on a whiteboard or inside an editor, make sure your code uses a consistent style, ideally one that's PEP8 compliant. Doing so shows the code you'll contribute will be consistent and follow standard conventions, making it easy for others to read and understand.

That last point is worth emphasising again. Above all, you should make sure your code is legible and coherent. It can be tempting to show off Python's features like complex list comprehensions or fancy one-liners. Don't. It's fun to write this code, but the result isn't fun to read or maintain. And in professional development environments, maintainability is crucial.

Topic 13: Profiling Python Code to Optimize Performance

Understanding how your code performs is crucial for production applications. Python's ecosystem includes several built-in and third-party tools for identifying performance bottlenecks and optimizing code execution.

Python's Built-In Profiler: cProfile

Python's standard library comes with a powerful profiling tool: cProfile. Give it a function or script to run and it'll break down how much time was spent in various subroutines, quickly identifying hot paths to focus on optimizing.

For instance, say we had this code, which counts the number of unique words in a file:

Let's run this with cProfile:

Oof. It takes a long time! We quickly see that we're spending a lot of time in count. That makes sense—list membership checking is . A faster option is to use a set, which has membership checking.

Other Python Profiling Tools

In addition to cProfile, Python's ecosystem also includes:

• line_profiler: Similar to cProfile, but profiles each source code line instead of each function call. Records how many times each line ran, the time per single run, and the total time.

  Here's the same slow example as above profiled with line_profiler. Again, the slow call to count jumps out as a performance bottleneck (99.8% of the runtime).

  $ kernprof -l -v unique_words.py /usr/share/dict/words Wrote profile results to unique_words.py.lprof Timer unit: 1e-06 s Total time: 203.646 s File: unique_words.py Function: unique_words at line 4 Line # Hits Time Per Hit % Time Line Contents ============================================================== 4 @profile 5 def unique_words(filepath): 6 1 0.0 0.0 0.0 unique = [] 7 2 1273.0 636.5 0.0 with open(filepath) as fd: 8 235977 85806.0 0.4 0.0 for line in fd: 9 471952 186702.0 0.4 0.1 for word in line.strip().split(): 10 235976 203255415.0 861.3 99.8 if unique.count(word) == 0: 11 235976 116381.0 0.5 0.1 unique.append(word) 12 1 0.0 0.0 0.0 return unique

• timeit: This package runs snippets of code repeatedly to determine how long they take. A quick demonstration shows how the built in pow function compares to manually calculating our own exponentiation.

  # File: timing_test.py import timeit def slow_power(base: float, exp: int) -> float: result = 1 for i in range(exp): result = result * base return result def fast_power(base: float, exp: int) -> float: return pow(base, exp) print(timeit.timeit(lambda: slow_power(5, 5000), number=1000)) print(timeit.timeit(lambda: fast_power(5, 5000), number=1000)) $ python3 timing_test.py 1.7985437081661075 0.026958625065162778

  A ~66x speed difference—wow!

• memory_profiler: This package tracks memory usage line-by-line as the program runs. It's helpful for finding lines that are using a lot of memory and perhaps could be optimized for space. Here's a small example showing the space overhead difference between making a generator vs. storing an entire list:

  from memory_profiler import profile @profile def list_vs_range(): a = range(1000000) b = list(range(1000000)) list_vs_range() $ python3 memory_test.py Filename: memory_test.py Line # Mem usage Increment Occurrences Line Contents ============================================================= 3 21.1 MiB 21.1 MiB 1 @profile 4 def list_vs_range(): 5 21.1 MiB 0.0 MiB 1 a = range(1000000) 6 59.3 MiB 38.2 MiB 1 b = list(range(1000000))

  One additional tidbit: some programmers like to use list comprehensions to shorten their code by a few lines. But there's a memory cost! When you use a list comprehension this way, the entire list gets assembled in memory only to be immediately thrown away. That's a bit silly, so it's best to avoid it.

  # Log all the users that are getting a notification. # Bad - makes a large list for no reason! [ logging.info(f'Sending a notification to {user.email}') for user in all_users if user.notifications_on ] # Better - no unnecessary memory overhead for user in all_users: if user.notifications_on: logging.info(f'Sending a notification to {user.email}')

  If you really do want to use a one-liner comprehension instead of a loop, you can avoid the memory overhead by using a generator comprehension instead of a list comprehension. But really, a simple loop works perfectly!

  # Less memory overhead; no unnecessary list ( logging.info(f'Sending a notification to {user.email}') for user in all_users if user.notifications_on )

Profiling and Optimization in Coding Interviews

When discussing performance in interviews, the goal is to write efficient code from the start:

• Choose Data Structures Wisely: When writing code, reason about the operations you'll be doing and picking data structures accordingly. In our example above, using a set instead of a list for uniqueness checking shows you understand both the problem requirements and data structure operations.
• Consider Complexity First: Before diving into profiling, analyze your algorithm's Big-O complexity. It's better to revise an algorithm to be than optimize an version.
• Know Your Tools: Being able to discuss profiling tools shows you're familiar with professional development practices. Even if you can't remember exact syntax, understanding what tools exist and when to use them is valuable.
• Follow the 80/20 Rule: Emphasize that in real-world scenarios, 80% of the runtime often comes from 20% of the code. Profiling helps identify that crucial 20% worth targeting for optimization.