Python Type Hint Interview Questions: Protocols, Generics, and Runtime Validation

Python type hints describe the values your code expects and returns. A static type checker can use them to catch incompatible operations before execution, but Python does not automatically enforce ordinary annotations when a function runs. Runtime validation is a separate step, usually placed where untrusted data enters the application.

That distinction drives many Python type hint interview questions. You may be asked to design a small interface with a Protocol, preserve a relationship with a generic, or explain why a perfectly annotated function still accepts a bad JSON payload.

This guide uses a notification service and a data-import boundary as worked examples. For more coding exercises, browse the PracHub interview question bank, then practice explaining what each annotation proves and where additional checks are necessary.

Do type hints make Python statically typed at runtime?

Adding an annotation does not turn a function into a runtime gatekeeper. Consider:

def repeat(message: str, times: int) -> str:
    return message * times

repeat("hello", "three")

A configured static checker should flag the incompatible second argument in checked code. Python can still attempt the call, and the multiplication fails because the runtime operation does not support that pair of values. The annotation itself did not reject the argument.

Now imagine a body loaded from JSON. If its values reach your code through Any, a checker may permit operations that deserve runtime scrutiny. The key interview question is therefore not whether a function has annotations. It is whether the data path remains checked and whether external input is validated before the program relies on it.

Separate three claims: the source code passed a particular checker configuration; the incoming data passed a runtime schema; and the requested operation obeys business rules. Each needs different evidence.

When should you use a Protocol?

A Protocol describes the behavior an object must provide for static structural typing. A class can satisfy that contract without explicitly inheriting from the Protocol. This is useful when application code should depend on a small interface rather than a particular implementation.

from typing import Protocol

class Sender(Protocol):
    def send(self, destination: str, message: str) -> None: ...

def notify(sender: Sender, destination: str) -> None:
    sender.send(destination, "Your report is ready")

A mail sender, a test recorder, and a queue-backed sender can satisfy this interface if their method signatures are compatible. The consuming function does not need their constructors, storage details, or unrelated methods. That keeps the contract small enough to understand and test.

In an interview, explain why the interface has the chosen return type. Does send mean the message was delivered, accepted for delivery, or merely queued locally? A None return tells the checker little about that semantic distinction. Document the operation's meaning and error behavior alongside the type signature.

Protocols work particularly well for test doubles. A recording fake can collect attempted messages while meeting the same checked interface. A fake that accepts arbitrary arguments through *args and ignores everything may hide mistakes your real adapter would reject.

Is a runtime-checkable Protocol a full validator?

No. @runtime_checkable enables certain isinstance and issubclass checks, but those checks do not fully validate method signatures or prove semantic correctness. An attribute with the expected name is not evidence that it accepts the right arguments or behaves as promised.

For example, an object may expose send with an incompatible calling convention. A presence-oriented runtime check cannot replace a static check of the signature or a deliberate runtime adapter boundary. Python version details also affect these checks, so use the documented behavior for the deployed interpreter.

Ask what the caller actually needs to know. If plugin code comes from another team, a startup compatibility test might exercise the interface with representative values. If arbitrary external data arrives over HTTP, an object protocol is usually the wrong validation tool; validate the payload's schema instead.

The practical answer is concise: use Protocols to describe supported operations to the checker, and use explicit validation or tests for runtime claims. Do not label an object safe merely because a protocol membership check succeeds.

What problem do generics solve?

Generics preserve relationships between types. If a function accepts a sequence of values and returns one value from it, the return type should track the input element type.

from collections.abc import Sequence
from typing import TypeVar

T = TypeVar("T")

def first(values: Sequence[T]) -> T:
    if not values:
        raise ValueError("expected a nonempty sequence")
    return values[0]

Passing a sequence of strings gives a string result to the checker. Passing a sequence of orders gives an order result. Using Any for both arguments and results would lose this relationship and let incompatible operations travel farther through the code.

The example uses the older TypeVar spelling because it is familiar across several Python versions. Python 3.12 introduced type-parameter syntax such as def first[T](...); use syntax supported by the interview environment and tooling. The important idea is the relationship, not which spelling looks newer.

Notice the empty-sequence check. An element type annotation does not prove a collection is nonempty. You still need a runtime branch, a different contract, or a representation that encodes the stronger invariant.

Why can a list of a subtype be unsafe as a mutable list of a base type?

Suppose Cat and Dog both inherit from Animal. A function receiving a mutable list[Animal] may append a dog. If you pass a list[Cat] to that function, the caller's cat list could contain a dog afterward.

That is the reason mutable container variance matters. Treating the narrower list as an unrestricted wider list would permit an operation that breaks the original contract. A read-only interface such as Sequence[Animal] often fits a function that only iterates over animals, because it does not grant append permission.

Choose the smallest interface the implementation actually needs. Requiring a list when an iterable would work excludes useful inputs. Requiring an iterable when you index it later makes the annotation misleading.

How are Any, object, and a union different?

Any allows the checker to accept many operations without proving they are valid. It is useful at gradual-typing boundaries, but it can also hide uncertainty. object means a value exists without granting arbitrary operations; you must narrow or otherwise establish the capability you need.

A union such as str | None names specific alternatives. Before calling a string method, handle the None case. Returning an empty string automatically may be the wrong business decision, so explain whether absence means unknown, invalid, or intentionally omitted.

Consider a parser returning dict[str, object]. Before multiplying a value, verify it is the expected numeric type and decide whether booleans should count as integers in your domain. The type checker can help follow the branch, but it does not choose your policy about values such as True, negative quantities, or very large numbers.

In code review, trace where Any first enters a function. Fixing the boundary often provides more value than adding annotations downstream while leaving the input unchecked. Useful annotations describe real guarantees rather than creating a visual impression of safety.

How does Pydantic runtime validation differ from type checking?

Pydantic can validate data against a model when the program runs. That is useful for request bodies, configuration, and imported records. It can produce a structured error before the rest of the application relies on invalid input.

For Pydantic v2, a small example is:

from pydantic import BaseModel, ConfigDict, Field

class Purchase(BaseModel):
    model_config = ConfigDict(strict=True, extra="forbid")
    sku: str
    quantity: int = Field(gt=0)

purchase = Purchase.model_validate({"sku": "BOOK-7", "quantity": 2})

This declares a positive integer quantity and rejects extra fields under the shown configuration. Strictness is a deliberate choice: some APIs accept and convert numeric strings, while others reject them. Pydantic's exact conversion behavior also depends on the type and whether input comes from Python objects or JSON, so test the actual entry point.

Passing this model still does not prove the SKU exists, the caller can buy it, inventory is available, or the price is correct. Those checks depend on application state and authorization. A validation library cannot infer them from an integer annotation.

Where should validation happen in a real service?

Place validation where trust changes. Parse the external payload, validate its shape and basic constraints, then pass a meaningful internal representation into application logic. Keep the error path explicit so invalid data does not become an internal server failure later.

Imagine importing 10,000 purchase records. Decide whether one invalid record rejects the whole file or is quarantined while other records proceed. Record the original row identifier and a useful error category. Avoid writing sensitive full payloads into logs merely because a validation error occurred.

Once data crosses the boundary, keep the internal contract clear. Revalidating every field in every helper can duplicate work and scatter policy. Conversely, trusting a mutable object forever after its first validation can be wrong if later code changes it without enforcing the same constraints.

What do cast and assert actually prove?

typing.cast tells a static checker to treat a value as a type; it does not convert or validate that value at runtime. A cast can express knowledge established elsewhere, but it should not be used to silence an error you have not understood.

An assertion can narrow a type in checked code and raise at runtime, but assertions can be disabled with optimized execution. Use explicit error handling for required checks on external input. A customer request should not become acceptable merely because the process started with a different optimization flag.

When reviewing a suspicious cast, ask for the evidence: was the payload validated, was the branch exhaustive, or does the library's stub miss a fact the code already guarantees? If there is no answer, replace the claim with a real check or improve the type representation.

How should you prepare for Python typing exercises?

Implement the notification example with two adapters and one recording fake. Run the project's checker and deliberately change a method signature. Then implement first, call it with two element types, and explain why the empty case still needs handling.

Finally build the purchase boundary and test a missing SKU, a negative quantity, a numeric string, an extra property, and a valid purchase whose inventory check fails. For each case, state which layer should reject it. This turns Protocols, generics, and runtime validation into a connected design exercise.

A strong interview answer identifies the guarantee precisely: “The generic preserves the element type, the runtime model validates the incoming shape, and the service checks stock under the database's concurrency rules.” That is much more useful than claiming annotations make the whole program safe.

Sources and Further Reading

• Python typing module
• Typing documentation on generics
• Typing specification for Protocols
• Pydantic strict mode
• Pydantic models
• Python assert statement

Research checked September 24, 2026. Examples distinguish static checking from Python execution and use Pydantic v2 APIs where shown.