Ruby Interview Questions and Answers

Ruby resolves a call by walking the receiver's singleton class, then the class, then included modules and superclasses, in order. Module#ancestors prints the chain.

module A; def hi = "A"; end
module B; def hi = "B"; end

class C
  prepend A
  include B
end

C.ancestors # [A, C, B, Object, Kernel, BasicObject]
C.new.hi    # "A"

Key rules: prepend places a module before the class, while include places it after. Among included modules the last one included comes first. Singleton methods beat instance methods, and super continues the search from the next entry in the chain.

method_missing is the last resort before NoMethodError, and respond_to? should be kept consistent with it. Refinements can scope overrides lexically. This chain is why prepended modules and concerns are powerful, and why ordering matters when several mixins define the same method.

MRI, the standard Ruby implementation, has a Global VM Lock: only one thread executes Ruby bytecode at a time, so threads do not provide CPU parallelism for pure Ruby code. They do improve concurrency for I/O because the lock is released around blocking operations such as file, socket and database calls.

threads = urls.map do |url|
  Thread.new { fetch(url) }    # overlaps I/O, not CPU
end
results = threads.map(&:value)

For CPU-bound work you need process-level parallelism: fork, the Process API, multiple server workers under Puma or Unicorn, or a different implementation such as JRuby or TruffleRuby, which have no GVL.

Since Ruby 3.0 the lock is more granular, and Ractors offer actor-style parallelism in limited cases. Concurrency primitives include Mutex, ConditionVariable and Queue. Choose processes for parallelism and threads for overlapping I/O.