100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

LISP Interview Questions

Common LISP interview topics—from car/cdr fundamentals to macros and tail recursion—explained with the reasoning an interviewer expects.

PracticeIntermediate11 min readJul 10, 2026
Analogies

LISP Interview Questions

LISP interviews, whether for a Common Lisp, Scheme, Clojure, or Emacs Lisp role, tend to probe a consistent set of fundamentals: list manipulation with car/cdr/cons, the difference between quoting and evaluation, recursion versus iteration, closures, and macros versus functions. Interviewers use these topics not just to test rote syntax knowledge but to see whether a candidate genuinely understands LISP's core model of code and data both being built from the same list structures.

🏏

Cricket analogy: LISP interview fundamentals are like a cricket academy trial testing a young batter on forward defense, footwork against spin, and running between wickets—not flashy shots, but the base skills that predict whether they can build a real career.

List Manipulation and Quoting

A near-universal opener is explaining car and cdr: given a list (1 2 3), car returns the first element (1) and cdr returns the rest of the list ((2 3)), and cons builds a new pair by prepending an element, so (cons 1 '(2 3)) reconstructs (1 2 3). Interviewers also probe quoting: 'x (or (quote x)) prevents evaluation and returns the symbol or list literally, whereas without the quote, LISP would try to evaluate x as a variable reference or, if it's a list, treat its first element as a function call—candidates who confuse (list 1 2) with '(1 2) usually haven't internalized this distinction yet.

🏏

Cricket analogy: car and cdr are like asking for the 'next batter in' versus 'the remaining batting order'—car gives you the single player up next, cdr gives you everyone still to come, both derived from the same team list.

lisp
;; car / cdr / cons fundamentals
(car '(1 2 3))       ;; => 1
(cdr '(1 2 3))       ;; => (2 3)
(cons 1 '(2 3))      ;; => (1 2 3)

;; Quoting prevents evaluation
(list 1 2)   ;; => (1 2)   -- evaluates 1 and 2, builds a new list
'(1 2)       ;; => (1 2)   -- returns the literal list unevaluated
'(+ 1 2)     ;; => (+ 1 2) -- NOT evaluated to 3, stays as a list of symbols
(+ 1 2)      ;; => 3       -- evaluated as a function call

Recursion, Closures, and Tail Calls

Interviewers frequently ask candidates to write a recursive function—reversing a list, computing Fibonacci numbers, or flattening a nested list—both to check correctness and to see if the candidate can identify and construct a tail-recursive version that avoids stack growth. A related staple is explaining closures: a function created inside another function that captures variables from its enclosing lexical scope, such as a counter-generator function that returns a new closure each time it's called, each with its own private captured state, which tests whether the candidate understands lexical scoping as distinct from dynamic scoping.

🏏

Cricket analogy: A closure is like a bowler who remembers exactly how many overs they've bowled today even after walking away from the umpire's table—the state (overs bowled) travels with the bowler, captured from that specific spell.

A classic follow-up question: 'Write a tail-recursive factorial.' The trick is introducing an accumulator parameter so the multiplication happens before the recursive call rather than after it returns: (defun fact-iter (n acc) (if (<= n 1) acc (fact-iter (- n 1) (* n acc)))). This lets Scheme (and Clojure via recur) execute the function in constant stack space.

Macros, Dynamic Scope, and Common Gotchas

A frequently asked conceptual question is 'what's the difference between a function and a macro?'—the expected answer is that a function's arguments are evaluated before the function body runs, while a macro receives its arguments as unevaluated code and returns new code to be evaluated in its place, which is why macros can implement control structures like a custom while loop that a function fundamentally cannot. Another common gotcha question involves dynamic versus lexical scope: Common Lisp's special variables (declared with defvar or defparameter) use dynamic scope, where a variable's value is looked up based on the current call stack rather than where the code was textually written, and candidates are expected to explain why this differs from the lexical scoping used by ordinary let-bound variables.

🏏

Cricket analogy: The function-vs-macro distinction is like the difference between a fielding drill that runs on the already-final scoreline (a function evaluating its finished arguments) versus a pre-match team talk that can rewrite the game plan itself before a ball is even bowled (a macro transforming code before it runs).

A common trap in interviews: candidates confuse dynamic scope (Common Lisp special variables) with the lexical closures used everywhere else in the language. Special variables declared with defvar are looked up dynamically at call time based on the current binding on the stack, which is unusual and specific to Common Lisp's special variables—most LISP dialects, including Scheme and Clojure by default, use lexical scoping throughout.

  • Know car, cdr, and cons cold, including how they compose to extract or build arbitrary parts of a list.
  • Be able to explain quoting ('x or (quote x)) and why it prevents evaluation of a symbol or list.
  • Be ready to write a recursive function and then convert it into a tail-recursive, accumulator-based version.
  • Understand closures as functions that capture variables from their enclosing lexical scope, each instance with independent captured state.
  • Clearly articulate the function-vs-macro distinction: evaluated arguments versus unevaluated code transformed at compile/expansion time.
  • Be able to explain dynamic scope for Common Lisp special variables (defvar) versus lexical scope for ordinary let bindings.
  • Practice explaining *why* behind each answer, not just reciting syntax, since interviewers probe for conceptual understanding.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#LISPStudyNotes#LISPInterviewQuestions#LISP#Interview#Questions#List#StudyNotes#SkillVeris#ExamPrep