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. Middle: tieferes Verständnis, Optimierung und reale Arbeitssituationen.
Ruby schaut zuerst in die Singleton-Klasse des Objekts, dann in geprependete Module, dann in die Klasse selbst, dann in included Module in umgekehrter Reihenfolge ihrer Einbindung, dann eine Ebene höher zur Superklasse, und wiederholt das Ganze. SomeClass.ancestors gibt die tatsächliche Reihenfolge aus, was die meisten Diskussionen schneller klärt als jedes Herumrätseln. super setzt diese Kette genau dort fort, wo du gerade stehst.
preload lädt die Assoziation in einer zweiten Query. eager_load nutzt einen einzigen LEFT OUTER JOIN. includes entscheidet das für dich und wechselt zum Join, sobald du die Assoziation in einem where referenzierst. Greif standardmäßig zu includes und nenne die anderen beiden explizit, wenn du die Strategie erzwingen musst — meist weil der Join Zeilen dupliziert oder die zweite Query günstiger ist.
Fang bei den Logs und der Anzahl der Queries an, nicht beim Code-Lesen — die meisten langsamen Rails-Endpoints sind Query-Probleme. Achte auf N+1, auf einen fehlenden Index hinter einem where auf einer großen Tabelle und auf Arbeit, die im Request gar nichts zu suchen hat. EXPLAIN zeigt dir, ob der Index tatsächlich genutzt wird. Caching kommt danach, nicht stattdessen.
Du indexierst die Spalten, nach denen gefiltert und sortiert wird, und bei einem Mehrspalten-Index kommt es auf die Reihenfolge an — er kann nur ein Präfix seiner Spalten bedienen, nicht eine beliebige Teilmenge. Ein Index hilft nicht, wenn die Query ohnehin fast die ganze Tabelle anfasst, und er kostet bei jedem Write, weshalb alles zu indexieren ein eigenes Problem ist. Ein LIKE '%x' mit führendem Wildcard kann einen normalen B-Tree-Index überhaupt nicht nutzen.
Weil ein Job zweimal laufen kann — ein Retry nach einem Timeout, ein Absturz nach der Arbeit, aber vor der Bestätigung. Wenn ein zweiter Lauf die Karte doppelt belastet, ist das ein Bug im Job, nicht in der Queue. Sicher machst du das, indem du den Effekt an einen Key bindest: prüfen, ob die Belastung schon existiert, einen Unique-Index setzen oder die Operation von Natur aus wiederholbar machen.
Verhalten, das nicht den eigenen Zustand des Records betrifft, ziehst du raus — ein Service-Objekt für eine mehrstufige Operation, ein Query-Objekt für einen komplexen Scope, ein Form-Objekt, wenn ein Formular zwei Models umfasst. Beide Extreme sind real: ein 900-Zeilen-Model, das niemand mehr anfassen will, oder vierzig Ein-Methoden-Klassen ohne offensichtlichen Platz. Der Test ist, ob eine neue Person den Code anhand des Namens findet.
Im echten Interview sprichst du unter Druck. Cam stellt genau diese Fragen, bewertet jede Antwort und zeigt dir genau, was du verbessern musst.
Middle Ruby on Rails-Interview üben →