Las entrevistas de Ruby van en dos capas: el lenguaje en sí — blocks, módulos, la cadena de búsqueda de métodos — y luego Rails, donde la mayoría de las preguntas en realidad son sobre ActiveRecord y la base de datos que hay debajo. Aquí están las preguntas más frecuentes, cada una con una respuesta modelo.
Cada pregunta viene con una respuesta modelo con la que puedes comparar la tuya.
Solo nil y false son falsy. Todo lo demás es truthy — incluyendo 0, un string vacío y un array vacío, que es donde caen los desarrolladores que vienen de otros lenguajes. Por eso if items.empty? e if items significan cosas completamente distintas, y lo segundo casi nunca es lo que querías.
Un string es un objeto mutable y cada literal crea uno nuevo; un symbol es inmutable y el mismo symbol es siempre el mismo objeto. Eso hace que los symbols sean la elección correcta para identificadores — claves de hash, nombres de métodos, estados — porque no se reasignan en cada uso. Los strings son para datos que muestras o modificas.
Un block es un trozo de código pasado a un método, escrito con do...end o llaves. yield lo llama desde dentro del método, y block_given? comprueba si se pasó uno. Los blocks son la razón por la que el código Ruby se lee como se lee — each, map, open y los wrappers de transacciones son todos métodos que reciben un block y controlan qué pasa alrededor de él.
Dos diferencias que importan. Un lambda verifica su aridad y falla si el número de argumentos es incorrecto; un proc rellena silenciosamente el resto con nil. Y return dentro de un lambda retorna del propio lambda, mientras que dentro de un proc retorna del método que lo contiene — así es como un proc puede terminar un método sin que lo esperaras.
include agrega los métodos de un módulo como métodos de instancia, extend los agrega como métodos singleton en ese objeto — así que extend en el cuerpo de una clase da métodos de clase. prepend inserta el módulo *antes* que la clase en la cadena de búsqueda, así que el método del módulo gana y puede llamar a super para llegar al original. Revisar ancestors muestra exactamente qué pasó.
Una consulta carga una lista, y luego tocar una asociación dentro del loop dispara una consulta más por fila — 1 + N. La solución es cargar la asociación de antemano con includes. preload siempre usa una consulta separada, eager_load fuerza un único LEFT JOIN, e includes elige entre ambos según si filtras sobre la asociación. La gema bullet los señala en desarrollo.
No al construir la relation. User.where(active: true) devuelve una relation y no toca nada; la consulta se ejecuta cuando necesitas los datos — each, to_a, first, count, o una plantilla que los renderiza. Esa pereza es lo que te permite encadenar scopes, y también explica por qué un where que parece lento suele ser inocente y el costo real está más adelante en la cadena.
Una validación vive en el modelo y se ejecuta en Ruby; una restricción vive en la base de datos y se mantiene sin importar quién escriba. Las validaciones dan errores amigables por campo, pero las saltan update_column, insert_all, otra aplicación, y pierden en una carrera entre dos requests concurrentes. La unicidad en particular necesita un índice único — la validación sola es una verificación, no una garantía.
Hooks que se disparan alrededor del ciclo de vida de un modelo — before_save, after_create y el resto. Se ganan la mala reputación cuando acumulan efectos secundarios: crear un registro lo guarda, eso envía un email, que encola un job, y un test que solo quería un registro ahora necesita un stub de correo. Cualquier cosa que no sea sobre el propio estado del registro es mejor como una llamada explícita en un service object.
Bundler resuelve las versiones de gemas que satisfacen tu Gemfile y las instala. Gemfile.lock registra exactamente qué se resolvió, por eso se comitea: bundle install en otra máquina reproduce las mismas versiones en lugar de tomar lo más reciente. bundle update es el acto deliberado de moverlas.
En una entrevista real hablas bajo presión. Cam hace estas mismas preguntas, evalúa cada respuesta y muestra exactamente qué mejorar.
Practicar entrevista de Ruby on Rails →