Prolog Interview Questions

Analogy categoryAnalogies

Prolog rarely appears as a primary hiring-language interview the way Python or Java do, but it shows up in academic assessments, AI/logic-programming courses, and interviews for roles touching constraint solving, rule engines, or symbolic reasoning (compilers, expert systems, some legal-tech and configuration-management tooling). Interviewers use it specifically because it exposes whether a candidate actually understands unification, backtracking, and recursion at a conceptual level rather than having memorized syntax — the same three concepts resurface across almost every question, from simple 'reverse a list' prompts to trickier ones about cut behavior and negation.

🏏

Cricket analogy: Prolog interview questions probing unification and backtracking are like a fielding trial that doesn't just ask you to catch a ball, but tests whether you understand why you positioned yourself where you did — assessing the underlying principle, not memorized footwork.

Core Concepts Interviewers Probe: Unification, Backtracking, and Cut

The most frequent conceptual question is 'trace what happens when this query runs,' usually involving a predicate with multiple clauses and asking the candidate to walk through unification attempts, successful bindings, and backtracking when a later goal fails. A closely related favorite is explaining cut (!) behavior: given a predicate with a cut in one clause, interviewers ask what solutions are pruned and why, since misunderstanding the cut is one of the most common real-world sources of subtly wrong Prolog code. Candidates are also commonly asked to explain the difference between = (unification, which can bind variables) and == (structural equality, which does not bind), and between is/2 (arithmetic evaluation) and = (unification without evaluation) — mixing these up is a classic beginner mistake that interviewers specifically probe for.

🏏

Cricket analogy: Tracing a query's backtracking step by step is like a match referee replaying a run-out review frame by frame to determine exactly which frame the bail was dislodged, rather than just accepting the final 'out' call at face value.

prolog

% Cut example: max/3 picks the larger of two numbers
max(X, Y, X) :- X >= Y, !.
max(X, Y, Y).

?- max(3, 5, M).
M = 5.

% Without the cut, backtracking into the second clause
% could wrongly also report M = 3 as a second (invalid) solution
% once the first clause has already committed to the correct answer.

Classic Coding Prompts

A handful of exercises recur across nearly every Prolog assessment: reverse a list without using the built-in reverse/2 (testing whether the candidate reaches for an accumulator or writes a naive quadratic version), check whether a list is a palindrome, compute the length or sum of a list recursively, find the Nth element or the maximum of a list, and remove duplicates from a list. A step up in difficulty is writing a small family-tree or graph-traversal predicate (ancestor/2-style recursion) or implementing classic constraint puzzles like N-Queens or a Sudoku cell-checker using member/2 and permutation/2, which test whether a candidate can express a search problem declaratively instead of writing an explicit search loop.

🏏

Cricket analogy: The 'reverse a list without reverse/2' prompt is like asking a scorer to reconstruct the innings' ball order purely from the raw delivery log, testing whether they understand the underlying data structure rather than just calling a pre-built scorecard tool.

prolog

% Reverse a list with an accumulator (linear time)
my_reverse(List, Reversed) :-
    my_reverse(List, [], Reversed).
my_reverse([], Acc, Acc).
my_reverse([H|T], Acc, Reversed) :-
    my_reverse(T, [H|Acc], Reversed).

% Palindrome check
is_palindrome(List) :-
    my_reverse(List, List).

?- is_palindrome([r,a,c,e,c,a,r]).
true.

Common Mistakes Candidates Make

The single most common mistake is confusing = with is: writing X = 2 + 2 binds X to the unevaluated term +(2,2) rather than the integer 4, which only ?- X is 2 + 2. produces — candidates who don't catch this in a live coding round usually get stuck debugging a downstream comparison that mysteriously fails. Another frequent slip is writing a recursive predicate with no base case, or a base case that doesn't actually match how the recursive case eventually calls it (e.g., using an empty list [] in the base case while the recursive case never actually reduces to []), causing an infinite loop or stack overflow live in the interview. Candidates also frequently forget to handle the query-mode question interviewers love to ask — 'what if this predicate is called with the first argument unbound instead of bound' — revealing whether they designed the predicate with only one specific calling pattern in mind.

🏏

Cricket analogy: Confusing = with is is like a scorer recording 'four plus two' as a literal note in the scorebook instead of actually adding it to get six on the total — the raw expression sits there unevaluated until someone finally does the arithmetic.

In live coding, X = 2 + 2 followed by a downstream arithmetic comparison is one of the most common silent bugs — Prolog will happily unify X with the unevaluated term +(2,2), and only is/2 forces arithmetic evaluation. Always double check which one you actually need.

Prolog interview questions target conceptual understanding of unification, backtracking, and cut — not memorized syntax.
Be ready to trace a query step by step: which clauses unify, what gets bound, and when backtracking kicks in.
Know the difference between = (unification), == (structural equality), and is/2 (arithmetic evaluation) cold.
Classic coding prompts: reverse a list, check a palindrome, sum/length/max of a list, remove duplicates, N-Queens.
The most common live-coding bug is writing X = Expr where X is Expr was intended, leaving an unevaluated term.
A recursive predicate needs a base case that the recursive case will actually reach — mismatched base cases cause infinite loops.
Interviewers often ask how a predicate behaves with the first argument unbound, testing whether it was designed for one narrow use case.