Practice · Interview · Card 6
"Walk me through what happens when belongs_to runs."
A deep-dive question. The interviewer wants to hear that you know the framework, not just that you use it.
The question
An interviewer asks:
"When I write belongs_to :user in a model, what does Rails actually do at class-load time? Be specific."
Your job
Form an answer in your head. Don't reach for the docs. When you have it, reveal the rubric and compare. The rubric isn't "the right script" — it's what an interviewer will be listening for.
Take a moment. Think about: how many methods does belongs_to add, what class-level metadata it registers, what validation it installs by default, and where the implementation lives.
The senior framing
A senior answer names the surface generated, the class-level metadata registered, the validation installed, and at least one implementation file. You don't have to recite every method; you have to convey that you know there's a list.
Something like:
"It defines a family of instance methods — the reader, the writer, build/create variants, reload, and dirty-tracking helpers. On the class, it registers a reflection that other Rails internals like eager loading, fixtures, and the form builder read. In Rails 5+ it installs a presence validation by default, controlled bybelongs_to_required_by_default. The dispatching point isActiveRecord::Associations::ClassMethods#belongs_to, which delegates to a builder class,Associations::Builder::BelongsTo."
Junior framings that don't land
- "It adds a
usermethod." Names one of about eight things. The interviewer asked for depth; this signals shallow exposure. - "It generates SQL to join the user table whenever you access the association." Factually wrong — the association is lazy by default. JOINs only happen with
eager_loadorjoins. - "It modifies the schema to add a foreign key." Confuses model-level declaration with migrations.
belongs_tonever touches the database schema. - "It's magic." The single most senior-disqualifying answer.
What the rubric scores
- Surface enumeration. Do you name the family of methods (reader, writer, build, create, reload, dirty-tracking) or just one?
- Class-level effects. Do you mention the reflection? The validation? The optional callbacks for
touch:andcounter_cache:? - Implementation grounding. Can you name a file or a class involved? Even a plausible-sounding one signals you've read framework code.
- Knowing what you don't know. "I'm not 100% sure of the exact module path, but I know the builder class handles the methods and the reflection." Lands as senior; pretending to know reads worse than honest hedging.
Theory
For the full walkthrough — every method generated, every option's effect, where each piece lives in the Rails source — read Reading the Source · What belongs_to :user actually adds.