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. Middle: comprensión más profunda, optimización y situaciones reales de trabajo.
Ruby busca en la clase singleton del objeto, luego en los módulos prepended, luego en la clase misma, luego en los módulos included en orden inverso de inclusión, luego sube a la superclase, y repite. SomeClass.ancestors imprime el orden real, lo que resuelve la mayoría de las discusiones más rápido que razonarlo. super continúa por esa misma cadena desde donde estés.
preload carga la asociación en una segunda consulta. eager_load usa un único LEFT OUTER JOIN. includes elige por ti, cambiando a un join cuando referencias la asociación en un where. Usa includes por defecto, y nombra los otros dos cuando necesites forzar la estrategia — normalmente porque el join está duplicando filas o la segunda consulta es más barata.
Empieza por los logs y el número de consultas, no leyendo código — la mayoría de los endpoints lentos en Rails son problemas de consultas. Busca N+1, un índice faltante detrás de un where sobre una tabla grande, y trabajo que no necesita estar en el request en absoluto. EXPLAIN te dice si el índice realmente se usa. El caching es lo que haces después de eso, no en lugar de eso.
Indexas las columnas por las que filtras y ordenas, y para un índice de múltiples columnas el orden importa — puede servir un prefijo de sus columnas, no cualquier subconjunto. Un índice no ayuda cuando la consulta toca de todos modos la mayor parte de la tabla, y cuesta en cada escritura, así que indexar todo es un problema en sí mismo. Un LIKE '%x' con comodín al inicio no puede usar un índice B-tree normal en absoluto.
Porque un job puede ejecutarse dos veces — un retry después de un timeout, un crash después del trabajo pero antes de la confirmación. Si ejecutarse dos veces cobra la tarjeta dos veces, eso es un bug del job, no de la cola. Lo haces seguro asociando el efecto a una clave: verifica si el cobro ya existe, usa un índice único, o haz que la operación sea naturalmente repetible.
Saca el comportamiento que no es sobre el propio estado del registro — un service object para una operación de varios pasos, un query object para un scope complejo, un form object cuando un formulario abarca dos modelos. El modo de falla en ambas direcciones es real: un modelo de 900 líneas que nadie puede tocar, o cuarenta clases de un solo método sin un lugar obvio. La prueba es si una persona nueva puede encontrar el código por su nombre.
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 Middle Ruby on Rails →