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

Lua Interview Questions

Common Lua interview questions and answers covering tables, metatables, scoping, closures, and coroutines.

PracticeIntermediate10 min readJul 10, 2026
Analogies

Preparing for a Lua Interview

Lua interviews for game-scripting, embedded-systems, or backend (e.g., OpenResty/Kong) roles tend to probe four areas repeatedly: how tables and metatables work (since Lua has no built-in classes), how closures capture variables (upvalues), how coroutines provide cooperative concurrency without threads, and a handful of well-known 'gotchas' like 1-based indexing, the behavior of # on tables with holes, and the difference between nil and false in conditionals. Being able to write a short, correct code snippet live -- not just describe the concept -- is usually what separates a strong answer from a shaky one.

🏏

Cricket analogy: A Lua interview probing four recurring areas is like a fast-bowling trial that always tests the same core skills -- yorkers, bouncers, seam position, and death-over composure -- because those four map directly onto what separates a genuinely capable quick from one who just looks fast in the nets.

Core Language Questions: Tables and Metatables

A frequent interview question is 'how does Lua implement object-oriented programming without classes?' -- the answer is metatables: every table can have an associated metatable, and setting the __index metamethod to another table (or a function) makes Lua fall back to looking up missing keys there, which is exactly how setmetatable(instance, {__index = Class}) simulates inheritance by chaining lookups from instance to class to (optionally) a parent class. A good answer distinguishes __index as a table (a static fallback lookup) from __index as a function (a dynamic computed fallback), since interviewers often follow up asking which one you'd use for computed/virtual properties.

🏏

Cricket analogy: The __index metamethod chaining lookups from instance to class is like a batting order's fallback plan -- if the designated opener is unavailable, the team looks to the next batsman down, and if he's also unavailable, further down still, chaining through the order until someone can bat.

lua
local Animal = {}
Animal.__index = Animal

function Animal.new(name, sound)
  return setmetatable({ name = name, sound = sound }, Animal)
end

function Animal:speak()
  print(self.name .. " says " .. self.sound)
end

local Dog = setmetatable({}, { __index = Animal })
Dog.__index = Dog

function Dog.new(name)
  local self = Animal.new(name, "Woof")
  return setmetatable(self, Dog)
end

function Dog:fetch()
  print(self.name .. " fetches the ball!")
end

local rex = Dog.new("Rex")
rex:speak()   --> "Rex says Woof" (found via Dog.__index -> Animal)
rex:fetch()   --> "Rex fetches the ball!"

Closures and Scoping Questions

Interviewers frequently ask candidates to write a counter-generator function and explain why it works: function makeCounter() local count = 0; return function() count = count + 1; return count end end returns a closure that captures count as an upvalue -- not a copy, but a reference to the same variable -- so each call to the returned function sees and mutates the same count that persists between calls even though makeCounter itself has already returned. A common follow-up is 'what happens if you create multiple counters?', and the correct answer is that each call to makeCounter() creates a fresh count local, so each returned closure has its own independent upvalue, not a shared one.

🏏

Cricket analogy: A closure capturing a local as an upvalue is like a player's personal net-run-rate tracker that persists across every match of the tournament -- each new team's tracker (each call to makeCounter) starts its own independent count, not sharing a single running total across teams.

lua
local function makeCounter()
  local count = 0
  return function()
    count = count + 1
    return count
  end
end

local counterA = makeCounter()
local counterB = makeCounter()

print(counterA())  --> 1
print(counterA())  --> 2
print(counterB())  --> 1  (independent upvalue, not shared with counterA)

Coroutines and Control Flow Questions

A classic Lua interview question is 'how do coroutines differ from OS threads?' -- the key answer is that Lua coroutines are cooperative, not preemptive: a coroutine only pauses when it explicitly calls coroutine.yield(), and only one coroutine (plus the main thread) ever executes at a time, so there's no need for locks or mutexes to protect shared state the way there is with true parallel OS threads. coroutine.create(fn) returns a coroutine object in the 'suspended' state, coroutine.resume(co, ...) starts or continues it (passing values in, receiving true, ...yieldedValues or false, errorMessage back), and inside the coroutine, coroutine.yield(...) pauses execution and returns control (plus any yielded values) to whoever called resume.

🏏

Cricket analogy: Cooperative coroutines are like a single bowler who only hands over the ball at the end of an over by choice, versus preemptive threads being like a captain who could rotate bowlers mid-over at any instant -- Lua's model requires the current 'bowler' (coroutine) to voluntarily yield the ball.

Because coroutines are cooperative and single-threaded, a coroutine that never calls yield (e.g., stuck in an infinite loop) will block the entire program the same way an unyielding while-true loop would -- coroutines give you structured pausing, not automatic parallelism or preemption.

Common Gotchas Interviewers Probe

Interviewers love a handful of well-known Lua traps: only nil and false are falsy in an if condition (so 0 and "" are both truthy, unlike many C-family languages), the # length operator gives an undefined/border result on a table with holes (a nil in the middle of a numeric sequence) rather than a reliable count, and functions can return multiple values (return a, b, c) which is how string.find, table.insert's companions, and pcall communicate several results at once -- a candidate should also know that extra return values are discarded when a function call isn't the last expression in an expression list, e.g. local x = f(), g() only keeps f()'s first return value.

🏏

Cricket analogy: The nil-vs-false truthiness gotcha is like a scorer's rule that only 'no result' and 'abandoned' officially count as a non-match, while a low score of zero runs still very much counts as a completed innings -- 0 isn't the same as 'nothing happened', just as 0 is truthy in Lua.

Watch for the classic trick question: what does #{1, 2, nil, 4} return? The honest answer is 'it's undefined behavior' -- Lua's manual explicitly states the length operator is only well-defined for sequences (tables with no nil holes between 1 and n), and it may return 2 or 4 depending on the internal table representation, which is exactly the kind of nuance interviewers use to separate memorized answers from real understanding.

  • Lua interviews commonly probe tables/metatables, closures/upvalues, coroutines, and a set of well-known gotchas.
  • Metatables implement OOP-style inheritance via the __index metamethod, chaining lookups from instance to class.
  • Closures capture locals as upvalues by reference; each call to the enclosing function creates a fresh, independent upvalue.
  • Coroutines are cooperative, not preemptive -- only coroutine.yield() hands control back, no locks are needed for shared state.
  • Only nil and false are falsy in Lua; 0 and empty string "" are both truthy.
  • The # length operator is only well-defined on sequences with no nil holes -- results on sparse tables are undefined.
  • Functions can return multiple values; extras are discarded when the call isn't the last item in an expression list.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#LuaStudyNotes#LuaInterviewQuestions#Lua#Interview#Questions#Preparing#StudyNotes#SkillVeris#ExamPrep