Ruby interview questions

What a strong answer covers

• Define string interpolation as embedding expressions within a string literal using `#{}`.
• Define string concatenation as joining two or more strings using `+` or `<<`.
• Explain that interpolation is generally preferred for readability and performance when building complex strings.
• Mention that concatenation can be useful for simple, fixed string additions or when building strings incrementally in a loop (using `<<` for efficiency).

Where people lose the point

• ×Not knowing that `+` creates new string objects, potentially impacting performance in loops.
• ×Failing to mention that `<<` modifies the string in place, which is more efficient for incremental building.
• ×Incorrectly stating that interpolation is always slower or faster without context.

What a strong answer covers

• Explain Arrays as ordered, integer-indexed collections of objects, suitable for lists where order matters.
• Provide an example of an Array storing a list of items, e.g., `['apple', 'banana', 'cherry']`.
• Explain Hashes as unordered (or insertion-ordered in modern Ruby), key-value pair collections, suitable for mapping unique keys to values.
• Provide an example of a Hash storing associated data, e.g., `{ name: 'Alice', age: 30 }`.

Where people lose the point

• ×Confusing the ordered nature of Arrays with the key-value nature of Hashes.
• ×Incorrectly stating that Hashes are completely unordered in modern Ruby versions (they are insertion-ordered since 1.9).
• ×Providing examples that don't clearly illustrate the primary use case for each data structure.

What a strong answer covers

• Define truthiness as the concept of values evaluating to `true` or `false` in a boolean context (e.g., `if` statements).
• State that in Ruby, only `false` and `nil` are falsy.
• Explain that all other values, including `0`, empty strings `''`, and empty arrays `[]`, are considered truthy.
• Provide clear examples demonstrating both truthy and falsy values in an `if` condition.

Where people lose the point

• ×Incorrectly identifying `0`, empty strings, or empty arrays as falsy.
• ×Confusing Ruby's truthiness rules with those of other languages (e.g., JavaScript).
• ×Failing to explicitly state that `false` and `nil` are the *only* falsy values.

What a strong answer covers

• Describe `each` as an iterator that executes a block for each element in a collection and returns the original collection.
• Explain that `each` is primarily used for side effects, such as printing or modifying external state.
• Describe `map` (or `collect`) as an iterator that executes a block for each element and returns a *new* array containing the results of the block for each element.
• Explain that `map` is used when you want to transform a collection into a new collection of the same size.

Where people lose the point

• ×Incorrectly stating that `each` returns a new array of transformed elements.
• ×Confusing the return values of the two methods.
• ×Not clearly articulating the purpose (side effects vs. transformation) for each iterator.

What a strong answer covers

• Explain `attr_accessor` as a convenient method that automatically defines both a getter (reader) and a setter (writer) method for an instance variable.
• Describe its usefulness in reducing boilerplate code for common attribute access patterns.
• Differentiate `attr_reader` as defining only a getter method, allowing read-only access.
• Differentiate `attr_writer` as defining only a setter method, allowing write-only access.

Where people lose the point

• ×Incorrectly stating that `attr_accessor` creates the instance variable itself (it only creates the methods).
• ×Confusing the roles of `attr_reader` and `attr_writer`.
• ×Failing to explain *why* it's useful (boilerplate reduction).

What a strong answer covers

• Explain that a `Class` is a blueprint for creating objects, supports inheritance, and can be instantiated.
• Explain that a `Module` cannot be instantiated and does not support inheritance in the same way; its primary uses are for mixins and namespaces.
• Describe mixins as a way to share behavior across classes (multiple inheritance of behavior) without traditional class inheritance.
• Describe namespaces as a way to group related classes, modules, and constants to prevent naming collisions.
• Provide scenarios: use a class when you need to create objects with state and behavior; use a module for shared functionality (mixins) or code organization (namespaces).

Where people lose the point

• ×Stating that modules can be instantiated or have instances.
• ×Confusing the purpose of modules with traditional class inheritance.
• ×Not clearly explaining both mixin and namespacing roles of modules.

What a strong answer covers

• Define inheritance as an 'is-a' relationship where a subclass inherits methods and attributes from a single superclass, promoting code reuse and polymorphism.
• Define mixins (via modules) as a way to achieve 'has-a' or 'can-do' relationships, allowing a class to include behavior from multiple modules without single-inheritance limitations.
• Scenario for inheritance: `Dog < Animal` (a Dog *is an* Animal, sharing core animal behaviors).
• Scenario for mixin: `User include Authenticatable` (a User *can be* authenticated, adding authentication behavior).
• Emphasize that Ruby supports single inheritance for classes but multiple inheritance of behavior through modules.

Where people lose the point

• ×Suggesting that Ruby supports multiple class inheritance.
• ×Not clearly distinguishing between 'is-a' and 'has-a' / 'can-do' relationships.
• ×Providing scenarios that don't clearly illustrate the appropriate use of each concept.

What a strong answer covers

• Explain that blocks are anonymous code chunks passed to methods, not objects themselves, and are temporary.
• Describe `Proc` as an objectified block, allowing it to be stored and passed around, with 'loose' argument handling and a `return` that exits the *enclosing method*.
• Describe `Lambda` as a special type of `Proc` with 'strict' argument handling (raises `ArgumentError`) and a `return` that exits *only the lambda itself*.
• Provide a code example demonstrating the different return behaviors of a Proc and a Lambda when called from within a method.

Where people lose the point

• ×Incorrectly stating that blocks are objects.
• ×Confusing the argument handling rules for Procs vs. Lambdas.
• ×Misunderstanding or misrepresenting the scope of `return` within Procs and Lambdas.

What a strong answer covers

• Define `self` as a special variable that always refers to the *current object* (the receiver of the current method call or the current context).
• Explain that inside an instance method, `self` refers to the instance of the class.
• Explain that inside a class method (defined with `self.method_name` or `ClassName.method_name`), `self` refers to the class itself.
• Explain that in the top-level scope, `self` refers to the `main` object (an instance of `Object`).
• Provide code examples for each context to illustrate the changing value of `self`.

Where people lose the point

• ×Confusing `self` with `this` from other languages without explaining Ruby's specific context rules.
• ×Incorrectly stating that `self` always refers to the class.
• ×Failing to provide clear examples for different contexts.

What a strong answer covers

• Explain that `method_missing` is a hook method called by Ruby when an object receives a message for a method it does not define or inherit.
• Describe its parameters: `method_name` (symbol), `*args` (array of arguments), and `&block` (optional block).
• Common use cases: implementing DSLs, proxy objects, dynamic finders (e.g., `find_by_name` in ActiveRecord), and delegating calls.
• Potential pitfalls: performance overhead, making code harder to debug, masking typos, and potential security vulnerabilities if not handled carefully.
• Mention the importance of also overriding `respond_to_missing?` for proper introspection.

Where people lose the point

• ×Not mentioning `respond_to_missing?` which is crucial for proper behavior with `respond_to?`.
• ×Overlooking the performance implications or debugging challenges.
• ×Failing to explain the parameters `method_name`, `*args`, and `&block`.

What a strong answer covers

• Define a singleton class as an anonymous, hidden class that Ruby creates for every object.
• Explain that methods defined directly on a single object (e.g., `obj.define_singleton_method`) are actually added to that object's singleton class.
• Describe how the singleton class sits in the inheritance chain *between* the object itself and its actual class, influencing method lookup.
• Illustrate how this mechanism allows for object-specific behavior without affecting other instances of the same class.
• Provide an example of defining a method on a single object and accessing its singleton class.

Where people lose the point

• ×Confusing the singleton class with the object's regular class.
• ×Incorrectly stating that singleton methods are added directly to the object's class.
• ×Failing to explain its position in the method lookup chain.

What a strong answer covers

• Explain that everything in Ruby is an object, and every object is an instance of a class (even classes are objects of the `Class` class).
• Describe the inheritance chain: an object's class inherits from its superclass, forming a hierarchy up to `BasicObject`.
• Detail the role of modules: they can be mixed into classes (using `include` or `prepend`), inserting themselves into the method lookup chain.
• Explain the method lookup path: Ruby searches the object's singleton class, then its class, then any modules included in that class (in reverse order of inclusion for `include`), then the superclass, and so on up the hierarchy.
• Mention `Object#method_missing` as the final fallback if a method is not found.

Where people lose the point

• ×Incorrectly describing the order of module inclusion in the method lookup chain (e.g., confusing `include` with `prepend`).
• ×Failing to mention the `singleton_class` as the first place Ruby looks for methods.
• ×Not clearly articulating that `Class` and `Module` are themselves classes/objects.

What a strong answer covers

• Explain that dynamic method creation allows you to define methods programmatically during program execution, rather than at compile time.
• Describe `define_method` as a method (available in `Module` and `Class`) that takes a method name (Symbol or String) and a block (or `Proc`) as arguments.
• Illustrate with an example: defining getter/setter-like methods for a list of attributes using `define_method` within a class.
• Discuss use cases such as creating DSLs, generating boilerplate code, or adapting to external data structures.
• Mention the context of the block passed to `define_method` (it executes in the context of the instance).

Where people lose the point

• ×Confusing `define_method` with `method_missing`.
• ×Providing an example that doesn't clearly demonstrate runtime method creation.
• ×Not explaining the context (`self`) within the block passed to `define_method`.

What a strong answer covers

• Explain `instance_eval` as a method that executes a block of code in the context of a *specific object instance* (`self` becomes that object).
• Describe `instance_eval`'s use cases: defining singleton methods, accessing private instance variables/methods of an object, or modifying an object's state from outside its class.
• Explain `class_eval` (also `module_eval`) as a method that executes a block of code in the context of a *class or module* (`self` becomes that class/module).
• Describe `class_eval`'s use cases: dynamically adding methods or constants to a class/module, modifying class definitions at runtime, or creating DSLs within a class context.
• Provide distinct code examples for both `instance_eval` and `class_eval`.

Where people lose the point

• ×Confusing the `self` context for `instance_eval` vs. `class_eval`.
• ×Incorrectly stating that `instance_eval` can add class methods directly to a class.
• ×Failing to provide clear, separate use cases for each method.

What a strong answer covers

• Explain that `**` is used with keyword arguments, which are key-value pairs passed to methods.
• Describe its use in *capturing* keyword arguments: when used in a method definition (e.g., `def my_method(a:, **options)`), it collects all unassigned keyword arguments into a Hash.
• Describe its use in *passing* keyword arguments: when used in a method call (e.g., `other_method(**hash)`), it expands a Hash into keyword arguments.
• Provide an example demonstrating both capturing and passing keyword arguments using `**`.
• Mention that keyword arguments provide more clarity and flexibility than positional arguments for options.

Where people lose the point

• ×Confusing `**` with `*` (single splat) for positional arguments.
• ×Incorrectly stating that `**` works with regular positional arguments.
• ×Failing to provide clear examples for both capturing and passing.

What a strong answer covers

• Define global variables (`$VAR`) as variables accessible from anywhere in a Ruby program, across all classes, modules, and methods.
• Explain potential issues: increased coupling, difficulty in testing, reduced readability, and potential for unexpected side effects due to global state modification.
• Discuss best practices: generally avoid global variables due to the issues mentioned, preferring local variables, instance variables, class variables, or constants.
• Mention specific, rare cases where they might be acceptable (e.g., `$LOAD_PATH`, `$DEBUG`, or for very specific, truly global configuration that is read-only after initialization).
• Suggest alternatives like configuration objects, dependency injection, or module-level constants for managing shared state.

Where people lose the point

• ×Advocating for widespread use of global variables.
• ×Not clearly articulating the negative impacts on maintainability and testability.
• ×Failing to suggest viable alternatives to global variables.