← Back to Practice
Practice · Interview · Card 2
"Tell me about service objects."
The interviewer is testing calibration, not vocabulary. The definition is a warmup; the rest of the answer is what scores.
The question
"What's a service object, and when would you use one?"
Your job
Define it. Name a real use case. Then — the part most candidates skip — name when you wouldn't reach for one.
Take a moment. Senior answers always end with a trade-off or a caveat. Where would yours go?
The senior framing
A senior answer has four pieces: definition, when to use, when not to use, awareness of the alternative school.
"A service object is a plain Ruby class that owns one business operation, exposed via a call method. I reach for one when an operation has multiple side effects that need to be coordinated, when it's invoked from more than one place, or when isolating it makes it testable without booting controllers. I don't reach for one when the action is short, single-purpose, and called from one place — that's premature abstraction. Worth flagging: the 37signals school prefers rich domain models over service objects, so I'd ask the team what convention they use before introducing one to a codebase that doesn't have them."
Junior framings that don't land
- "A PORO with a
callmethod. Use one whenever a controller action has more than ten lines." Definition is right; the rule is too rigid. Ten lines isn't the threshold; "the action mixes multiple responsibilities that benefit from being separately testable" is. - "A service object replaces controller actions. They handle HTTP requests." Service objects don't handle HTTP. They're called by controllers; the controller still parses params and renders responses.
- "An ActiveRecord model with no table backing it, using callbacks to coordinate side effects." AR callbacks are exactly the thing service objects often move away from. AR involvement is a smell here.
- "They make code cleaner." Vague. Score: 0. Replace with a specific reason — testability of one flow, reuse from multiple callers, separation of concerns from a controller action.
What the rubric scores
- Definition. Can you describe what the object is.
- Specific use case. "I'd extract one when X happens" — concrete.
- When NOT to use. The "premature abstraction" caveat is the senior signal.
- School awareness. Bonus: name that the 37signals camp keeps logic on the model. Acknowledges there's more than one valid Rails style.
Theory
For the full walkthrough of service-object extraction with real OSS examples, read SOLID · SRP · Service Objects.