Functional Programming
Pure Functions
Understanding pure functions — deterministic outputs, no side effects, referential transparency, and their role in testable, predictable code.
Interview: Core functional programming concept — interviewers value candidates who understand side effects and write predictable code.
A pure function always returns the same output for the same input and has no side effects (no modifying global state, no I/O, no mutations). Pure functions are the foundation of functional programming — they're easy to test, reason about, and parallelize.
Properties of Pure Functions
- Deterministic: Same input always produces the same output
- No side effects: Doesn't modify global variables, files, databases, or external state
- Referential transparency: Can be replaced with its result without changing behavior
- No hidden inputs: Depends only on its explicit parameters
Impure vs Pure
- Impure:
datetime.now(),random.random(),print(), reading files - Pure:
len(),sorted(),map(), math operations - Push impure operations to the edges of your program (I/O boundary)
- Keep the core logic pure for testability and predictability
Interview Insight
Be able to identify pure vs impure functions. In system design, explain how separating pure logic from I/O makes code more testable. This is the "functional core, imperative shell" pattern.
Use Cases
Business logic — pricing, validation, calculations without I/O concerns
Data transformation — map, filter, reduce pipelines
Testing — pure functions need no mocks, fixtures, or test setup
Parallelization — pure functions are inherently thread-safe
Caching — memoization is safe for pure functions (same input = same output)
Common Mistakes
Modifying input arguments instead of returning new values
Reading global variables — makes functions depend on hidden state
Calling I/O inside business logic — push it to the program boundary
Not realizing datetime.now() and random.random() are impure
Over-purifying — some side effects are necessary; isolate them, don't eliminate them