Prolog Interview Questions

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.

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.

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.

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.