Ruby Interview Questions
Ruby interviews tend to probe three areas: whether you understand the object model (everything is an object, including numbers and classes themselves), whether you can reason about blocks, procs, and lambdas, and whether you write idiomatic code rather than code that merely works. This topic collects frequently asked questions with answers that go beyond a one-liner, so you understand the reasoning an interviewer expects, not just the correct label.
Cricket analogy: A cricket trial doesn't just check if you can hit a ball — it probes technique, shot selection, and match awareness; similarly Ruby interviews probe the object model, blocks/procs/lambdas, and idiomatic style, not just whether code runs.
Language fundamentals
A classic opener is 'What is the difference between a symbol and a string?' Symbols (:name) are immutable and interned, meaning :name.object_id is identical every time it appears in a program, whereas each string literal "name" typically allocates a new object. This makes symbols cheaper for use as hash keys or identifiers that are compared frequently, while strings are the right choice when the value's content needs to change or be built dynamically. Another common question is 'What does nil mean, and how is it different from false?' — in Ruby, only nil and false are falsy; every other value, including 0 and "", is truthy, which trips up developers coming from languages like Python or JavaScript.
Cricket analogy: A player's fixed squad number (like a symbol's stable object_id) never changes across a season, while a scorecard's handwritten entry (like a string) gets rewritten fresh for every match — and just as 0 overs bowled is still meaningful, not falsy.
Blocks, procs, and lambdas
Interviewers frequently ask candidates to explain the difference between procs and lambdas, since it's a subtle but important distinction. Lambdas check the number of arguments strictly and a return inside a lambda only exits the lambda itself. Procs are lenient about arity (extra arguments are dropped, missing ones become nil) and a return inside a proc attempts to return from the enclosing method, which can raise a LocalJumpError if there is no enclosing method — a frequent source of confusing bugs when procs are passed around and invoked later.
Cricket analogy: A lambda is like a strict umpire who calls a no-ball for even one wrong step (argument count) and stops the over cleanly on return, while a proc is like a lenient net-session bowler who lets extra deliveries slide but can cause chaos leaving the ground unexpectedly.
# Symbols vs strings
puts :name.object_id == :name.object_id # true, same object
puts "name".object_id == "name".object_id # false, different objects
# Proc vs lambda arity and return behavior
adder_lambda = lambda { |a, b| a + b }
adder_proc = proc { |a, b| a.to_i + b.to_i }
adder_lambda.call(1, 2) # => 3
adder_lambda.call(1) # raises ArgumentError (strict arity)
adder_proc.call(1) # => 1, missing arg becomes nil -> 0
def find_first_even(numbers)
numbers.each do |n|
return n if n.even? # returns from find_first_even itself
end
nil
end
# method_missing example, often asked in senior interviews
class DynamicProxy
def initialize(target)
@target = target
end
def method_missing(name, *args, &block)
@target.respond_to?(name) ? @target.send(name, *args, &block) : super
end
def respond_to_missing?(name, include_private = false)
@target.respond_to?(name, include_private) || super
end
endObject orientation and idiomatic style
Expect questions like 'What is duck typing, and why does Ruby favor it over interface checking?' Ruby cares whether an object responds to a method, not what class it belongs to — respond_to?(:each) matters more than is_a?(Array). Interviewers also probe module usage: 'What's the difference between include and extend?' — include mixes a module's methods in as instance methods, while extend mixes them in as methods on the specific object (or, at the class level, as class methods). Finally, expect a question on attr_accessor versus writing getters/setters manually — it's shorthand for defining both a reader and writer method for an instance variable, saving boilerplate without hiding what's happening.
Cricket analogy: Duck typing is like a captain who cares whether a fielder can actually catch (respond_to?(:each)), not their official position title (is_a?(Array)); similarly include adds shared fielding drills to every player while extend gives one specific player a special role.
A good signal in interviews is discussing tradeoffs, not just definitions. For example, when asked 'why use a Struct instead of a full class?', a strong answer notes that Struct.new(:x, :y) is fast to write for simple data containers but becomes awkward once you need multiple methods or complex validation, at which point a real class is clearer.
A common interview trap: candidates say Ruby is 'purely interpreted.' In practice, MRI (the reference Ruby implementation) compiles source to YARV bytecode before execution — it is not directly interpreting text line by line, and knowing this distinguishes candidates with deeper implementation knowledge.
- Symbols are immutable and interned (same object_id for the same name); strings are mutable and allocate freely.
- Only
nilandfalseare falsy in Ruby —0and""are truthy, unlike some other languages. - Lambdas enforce strict arity and
returnonly exits the lambda; procs are lenient andreturnexits the enclosing method. - Duck typing means Ruby checks whether an object responds to a method, not its class.
includeadds instance methods from a module;extendadds methods to a single object or as class methods.- MRI compiles Ruby to YARV bytecode rather than interpreting source text directly.
Practice what you learned
1. Why are two identical symbol literals guaranteed to share the same object_id?
2. Which values are falsy in Ruby?
3. What happens when you call a lambda with the wrong number of arguments?
4. What is the core idea behind duck typing in Ruby?
5. What does `extend` do when called on a module inside an instance method context?
Was this page helpful?
You May Also Like
Blocks, Procs, and Lambdas
Explore Ruby's three flavors of closures -- blocks, Procs, and lambdas -- and how they differ in argument strictness, return semantics, and reusability.
Duck Typing in Ruby
Explore Ruby's duck typing philosophy — objects are defined by the methods they respond to, not by their class — and how it shapes idiomatic, flexible Ruby code.
method_missing and respond_to?
Explore Ruby's dynamic dispatch fallback: how method_missing intercepts unknown method calls, and why it must be paired with respond_to_missing? for correct, well-behaved objects.
Common Ruby Pitfalls
A tour of frequent Ruby mistakes — mutable defaults, frozen string surprises, nil handling, and block/proc return semantics — with fixes for each.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics