Ruby-Interviews laufen auf zwei Ebenen ab: die Sprache selbst — Blocks, Module, die Method-Lookup-Chain — und dann Rails, wo es bei den meisten Fragen eigentlich um ActiveRecord und die Datenbank dahinter geht. Hier sind die am häufigsten gestellten Fragen, jeweils mit einer Musterantwort.
Zu jeder Frage gibt es eine Musterantwort, mit der du deine eigene vergleichen kannst.
Nur nil und false sind falsy. Alles andere ist truthy — auch 0, ein leerer String und ein leeres Array, und genau da stolpern Leute, die aus anderen Sprachen kommen. if items.empty? und if items bedeuten also etwas völlig anderes, und Letzteres ist fast nie das, was du eigentlich wolltest.
Ein String ist ein veränderliches Objekt, und jedes Literal erzeugt ein neues; ein Symbol ist unveränderlich, und dasselbe Symbol ist immer dasselbe Objekt. Deshalb eignen sich Symbole für Identifier — Hash-Keys, Methodennamen, Status-Werte —, weil sie nicht bei jeder Verwendung neu allokiert werden. Strings sind für Daten, die du anzeigst oder veränderst.
Ein Block ist ein Stück Code, das einer Methode übergeben wird, geschrieben mit do...end oder geschweiften Klammern. yield ruft ihn aus der Methode heraus auf, und block_given? prüft, ob überhaupt einer übergeben wurde. Blocks sind der Grund, warum sich Ruby-Code so liest, wie er sich liest — each, map, open und Transaction-Wrapper sind alles Methoden, die einen Block entgegennehmen und steuern, was drumherum passiert.
Zwei Unterschiede, die wirklich zählen. Eine Lambda prüft ihre Arity und wirft bei falscher Argumentanzahl einen Fehler; ein Proc füllt den Rest stillschweigend mit nil auf. Und return in einer Lambda kehrt aus der Lambda selbst zurück, in einem Proc dagegen aus der umschließenden Methode — dadurch kann ein Proc eine Methode beenden, bei der du das gar nicht erwartet hättest.
include fügt die Methoden eines Moduls als Instanzmethoden hinzu, extend fügt sie als Singleton-Methoden auf dem jeweiligen Objekt hinzu — extend im Klassenkörper liefert also Klassenmethoden. prepend schiebt das Modul in der Lookup-Chain *vor* die Klasse, sodass die Methode des Moduls gewinnt und über super die ursprüngliche Methode erreichen kann. Ein Blick auf ancestors zeigt genau, was passiert ist.
Eine Query lädt eine Liste, und jeder Zugriff auf eine Assoziation innerhalb der Schleife feuert eine weitere Query pro Zeile ab — 1 + N. Die Lösung ist, die Assoziation vorab mit includes zu laden. preload nutzt immer eine separate Query, eager_load erzwingt einen einzelnen LEFT JOIN, und includes entscheidet je nachdem, ob du nach der Assoziation filterst. Das Gem bullet weist in der Entwicklung genau darauf hin.
Nicht beim Erstellen der Relation. User.where(active: true) gibt eine Relation zurück und fasst dabei nichts an; die Query läuft erst, wenn du die Daten tatsächlich brauchst — bei each, to_a, first, count oder einem Template, das sie rendert. Diese Faulheit ist es, die das Verketten von Scopes erlaubt, und sie erklärt auch, warum ein vermeintlich langsames where oft unschuldig ist und die eigentlichen Kosten weiter hinten in der Chain liegen.
Eine Validierung lebt im Model und läuft in Ruby; ein Constraint lebt in der Datenbank und gilt unabhängig davon, wer schreibt. Validierungen liefern verständliche Fehlermeldungen pro Feld, werden aber von update_column, von insert_all und von jeder anderen Anwendung umgangen, und sie verlieren bei einem Race zwischen zwei gleichzeitigen Requests. Gerade bei Eindeutigkeit braucht es einen Unique-Index — die Validierung allein ist eine Prüfung, keine Garantie.
Hooks, die rund um den Lifecycle eines Models feuern — before_save, after_create und der Rest. Ihren schlechten Ruf verdienen sie, wenn sie Seiteneffekte anhäufen: Ein Record wird erzeugt, das speichert ihn, das verschickt eine E-Mail, die wiederum einen Job enqueued, und ein Test, der eigentlich nur einen Record wollte, braucht plötzlich einen Mail-Stub. Alles, was nicht den eigenen Zustand des Records betrifft, gehört besser als expliziter Aufruf in ein Service-Objekt.
Bundler löst die Gem-Versionen auf, die dein Gemfile erfüllen, und installiert sie. Gemfile.lock hält genau fest, was dabei aufgelöst wurde, deshalb wird sie eingecheckt: bundle install auf einer anderen Maschine reproduziert dieselben Versionen, statt sich einfach die neuesten zu ziehen. bundle update ist der bewusste Schritt, sie weiterzubewegen.
Im echten Interview sprichst du unter Druck. Cam stellt genau diese Fragen, bewertet jede Antwort und zeigt dir genau, was du verbessern musst.
Ruby on Rails-Interview üben →