Ruby Developer interview questions

A lambda returns control to its caller, while a non-lambda Proc tries to return from the method that created it.

• A return inside -> { return 1 } ends that lambda, so the enclosing method can continue with its next line.
• A return inside Proc.new { return 1 } exits the defining method, even when the Proc is called by another helper.
• Calling that Proc after its defining method has already returned raises LocalJumpError, so I use lambdas for callbacks that may outlive the current call.

A lambda enforces method-like arity, while a regular Proc handles positional arguments leniently.

• ->(id, status) {} raises ArgumentError when called with one or three arguments.
• proc { |id, status| } assigns nil to a missing status and ignores extra positional arguments.
• I choose a lambda for a payment callback contract because an arity error exposes an integration mistake immediately.

A block or Proc closes over the surrounding local binding, not a frozen snapshot of each value.

• If rate is changed from 0.1 to 0.2 after discount = ->(price) { price * rate }, later calls use 0.2.
• State can intentionally persist, as in a counter lambda that increments a captured count on every call.
• Shared mutable captures are unsafe across threads, so I put cross-thread state behind a Mutex or Queue instead of closing over a Hash.

I use yield for a simple immediate callback, &block when I need a Proc object, and ... when a wrapper must forward the complete call unchanged.

• yield avoids materializing a Proc and pairs with block_given? for an optional block.
• &block is justified when passing the callback to records.each(&block) or storing it for later execution.
• def instrument(...); measure { target(...); }; end forwards positional arguments, Ruby 3 keyword arguments, and the block without rebuilding their signatures.

include places a module after the class in lookup, while prepend places it before the class.

• With include Auditable, Order#save wins over Auditable#save and can call super to reach the module only through its own implementation chain.
• With prepend Auditable, Auditable#save runs first and super reaches Order#save, which makes prepend useful for a narrow wrapper.
• Order.ancestors reveals the effective order, so I inspect it before assuming which concern or gem method wins.

super continues from the current method owner to the next matching method in the receiver's lookup chain.

• It does not simply call the superclass, because a prepended or included module may be the next owner in Account.ancestors.
• Bare super forwards the current positional arguments, keywords, and block, while super() forwards none.
• I use method(:charge).super_method to inspect a surprising chain instead of hard-coding BaseAccount.instance_method(:charge).bind_call(self).

A singleton method belongs to one object's singleton class and is searched before methods from its ordinary class.

• def gateway.timeout; 2; end changes only that gateway object, not every instance of Gateway.
• class << self defines class methods because the class object itself also has a singleton class.
• I avoid per-record singleton methods for domain behavior because they make serialization, reuse, and test setup harder than a normal collaborator.

public_send preserves the receiver's public API, while send can invoke private and protected methods.

• report.public_send(formatter_name) is appropriate only after formatter_name is mapped through an allowlist such as json or csv.
• user.send(:password_digest) bypasses visibility, so using send with request data can expose internals.
• I use send only for intentional framework-level metaprogramming where crossing the visibility boundary is explicit and tested.

define_method creates an instance method from a block and retains that block's lexical closure.

• A serializer builder can capture field in fields.each and define methods such as serialize_total without string evaluation.
• The generated method should still have a meaningful name and backtrace, so I prefer define_method(:serialize_total) over broad anonymous magic.
• I set public, protected, or private deliberately and test the generated API because a loop can otherwise publish many methods accidentally.

A dynamic proxy should handle only its recognized method shape, report the same capability through respond_to_missing?, and delegate everything else to super.

• A locale proxy may translate title_en into record.translations.fetch(:en).fetch(:title), but should reject unrelated names.
• respond_to_missing?(:title_en, false) makes respond_to?, method, serializers, and test doubles see a consistent interface.
• Calling super preserves NoMethodError details and prevents a typo such as titel_en from being silently swallowed.

A refinement is useful when a small extension must be activated lexically rather than changing the class process-wide.

• using MoneyFormatting can add Integer#to_money inside one report namespace without changing Integer for Rails or gems.
• Activation applies to code defined in that lexical scope, so callers do not gain the method merely because the refined method is reached dynamically.
• I still prefer a plain formatter object for public application behavior because refinement lookup can surprise maintainers and third-party code.

I would build a lazy pipeline over File.foreach and stream its final values to the destination with each.

• File.foreach(path).lazy.filter_map { |line| parse(line) }.map { |row| normalize(row) } retains one source line plus pipeline state instead of arrays for all million lines.
• The parsing and mapping blocks run only when a terminal operation such as each, first, take, or force requests another value; constructing the pipeline reads nothing.
• each can write results incrementally and stop early, while to_a or force realizes every retained result and can consume memory proportional to the output.

Enumerator::Lazy defers each stage and pulls only enough source values to satisfy the terminal operation.

• events.lazy.select(&:billable?).map(&:account_id).take(100).force avoids building intermediate arrays for every event.
• It can safely work with an unbounded generator when a terminal bound such as take(100) exists.
• Operations such as sort still require the complete input, so adding lazy does not make a globally ordered infinite stream possible.

I use case/in to describe the accepted structures and bind only values that match each shape.

• in {type: "card", card: {last4: String => last4}} requires the nested keys and a String before using last4.
• The pin operator, as in {account_id: ^expected_id}, compares against an existing variable instead of rebinding it.
• Domain objects can support the same API through deconstruct or deconstruct_keys, but I keep patterns small so a schema validator remains clearer for large external payloads.

Ruby 3 treats keyword arguments separately from a final positional Hash, so wrappers must forward them explicitly.

• create_user({admin: true}) passes one Hash, while create_user(admin: true) supplies a keyword and may target a different signature.
• A delegator uses *args, **kwargs, &block or the compact ... form rather than assuming *args preserves keywords.
• **options makes conversion intentional, and **nil can declare that a method accepts no keywords at all.

MRI allows only one thread at a time to execute Ruby bytecode, but threads still overlap when work waits on I/O.

• Puma threads can serve other requests while one thread waits for PostgreSQL or an HTTP response because those operations release the GVL.
• Two pure-Ruby image transforms do not run CPU work in parallel, so I use processes or a native extension that releases the GVL for that workload.
• More threads still consume database connections and memory, so I tune Puma thread count together with the ActiveRecord pool.

The GVL does not make a multi-step state change atomic, so a Mutex is needed for shared invariants and Queue is better for handing work between threads.

• balance = balances[id]; balances[id] = balance + amount can interleave with another thread even though each Ruby operation runs under the GVL.
• mutex.synchronize protects that read-modify-write sequence, but the critical section should not include a slow HTTP call.
• Queue provides synchronized push and pop, while SizedQueue also applies backpressure when producers outrun consumers.

A Fiber scheduler lets one thread cooperatively run other fibers while the current fiber waits on supported nonblocking operations.

• A server such as Falcon can handle many socket waits without assigning one native thread to every connection.
• Libraries must use scheduler-aware I/O paths, such as supported socket, sleep, or process-wait hooks, or a blocking native call can still stall the thread.
• Fibers do not make CPU-heavy Ruby code parallel, so calculating a large report still belongs in a process or background job.

Ractors can run Ruby code in parallel, but mutable objects cannot be shared freely between them.

• Deeply frozen shareable configuration can be read by several Ractors, while messages otherwise need copying or ownership transfer.
• Sending a moved object makes it inaccessible to the sender, which prevents ordinary shared-memory races by design.
• I would isolate a self-contained CPU task first, because Rails state and many gems assume the main Ractor and may not be Ractor-safe.

Ruby's generational GC collects short-lived young objects frequently and scans long-lived old objects less often.

• A request often creates temporary arrays and strings that die in a minor collection without requiring a full heap scan.
• References from old objects to young objects are tracked so a minor collection does not miss reachable young data.
• A growing old generation can raise major GC cost, so I inspect GC.stat and allocation sources before changing GC environment settings.