Senior Rails Engineer Interview: De Wervingsrubric van een Fractional CTO voor 2026

Een founder waar ik als fractional CTO mee werk vroeg me vorig kwartaal om in twaalf weken tien senior Rails engineers aan te nemen. Een team van vijf moest opschalen naar vijftien, de Series B stond op het punt te sluiten, en elke hire was kritiek voor de volgende release. We screenden tweeënzestig CV’s, deden achttien volledige loops en deden vier aanbiedingen. De andere veertien waren geen slechte engineers. Ze waren alleen geen senior Rails engineers, hoe hun CV er ook uitzag.

Na negentien jaar Rails heb ik veel van deze loops gedaan, en de grootste fout die teams maken in een senior Rails engineer interview is “senior” behandelen als een functie van jaren. Dat is het niet. Senior is een functie van oordeelsvermogen, debug-instincten, productie-littekens en het vermogen om “ik weet het niet” te zeggen zonder met je ogen te knipperen. Dit is de rubric die ik gebruik, de vragen die ik daadwerkelijk stel, de signalen waarop ik scoor, en de red flags die iemand vóór de lunch op “nee” zetten.

Wat een Senior Rails Engineer Interview Eigenlijk Meet

Voor je over structuur nadenkt, moet je eerlijk zijn over wat “senior” betekent voor de rol die je invult. In mijn fractional CTO werk trek ik een harde lijn: een senior Rails engineer kan een feature van begin tot eind eigenaar zijn, inclusief de saaie delen — de migratie, de background job, het rollout-plan, de metric die ze na deploy in de gaten houden, en de rollback als het mis gaat. Ze hebben geen tech lead nodig die hen vertelt wat ze moeten doen. Zij vertellen de tech lead wat ze gaan doen.

Dat klinkt vanzelfsprekend, en toch testen de meeste senior Rails engineer interview-loops die ik zie er niets van. Ze testen leetcode. Ze testen trivia. Ze testen “ken je de nieuwste gem”. Geen daarvan voorspelt of de persoon gaat shippen. De vier dingen die ik daadwerkelijk wil meten in een loop zijn: productie-oordeel, debug-methode, code-smaak en communicatie onder druk. Alles in mijn rubric komt terug op een van die vier.

Het andere wat de rubric moet doen is goedkoop zijn. Elke extra ronde is een belasting voor de kandidaat, voor je team, en voor je hiring-snelheid. Ik draai een loop van vier rondes die vier uur kandidaattijd kost en ongeveer zes uur interviewertijd per finalist. Alles meer is zelfgenoegzaamheid.

De Senior Rails Engineer Interview Loop in Vier Rondes

De structuur ligt vast. De inhoud rouleert zodat kandidaten niet kunnen valsspelen via Glassdoor.

Ronde één — telefonische screening (30 minuten). Hiring manager. Doelen: bevestigen dat het CV echt is, motivatie bevestigen, niveau kalibreren, verwachtingen zetten. Ik stel drie vragen: vertel me over je laatste opgeleverde project, wat heb je end-to-end bezeten, vertel me over een productie-incident dat jij hebt veroorzaakt. De derde vraag filtert meer kandidaten uit dan de andere twee samen.

Ronde twee — coderonde (60 minuten). Pair op een realistische Rails-taak. Geen leetcode. De taak is open, heeft minstens drie redelijke oplossingen, en beloont vragen stellen. Senior engineers stellen vragen. Mid engineers beginnen te typen.

Ronde drie — architectuur-ronde (75 minuten). Whiteboard of gedeeld document. We ontwerpen samen een systeem. Het punt is niet het ontwerp. Het punt is hoe ze redeneren over trade-offs, wat ze vragen voor ze antwoorden, en of ze een keuze kunnen verdedigen zonder defensief te worden.

Ronde vier — war stories (45 minuten). Twee engineers, één gestructureerd gesprek. Drie vragen: vertel me over een keer dat je productie hebt gebroken, vertel me over de slechtste Rails-code die je ooit hebt geschreven, vertel me over een technische beslissing waar je spijt van hebt. Als ze geen van deze vragen kunnen beantwoorden, zijn ze niet senior.

Totaal: 3,5 uur kandidaattijd, plus een take-home voor finalisten als de rol dat vereist. Ik gebruik take-homes zelden — ze zijn nadelig voor senior kandidaten met gezinnen. Als het moet, beperk ze tot twee uur en betaal voor de tijd.

De Coderonde: Vragen die Echte Senioriteit Onthullen

De beste coderonde-taak die ik de afgelopen twee jaar heb gebruikt is deze: hier is een Rails-model met te veel verantwoordelijkheden, fix het. Ik geef de kandidaat een User-model met twaalf callbacks, drie concerns, een methode die Stripe aanroept, een methode die een job enqueued, validaties die afhankelijk zijn van de environment, en één methode die inline een HTTP-call doet. Ik vraag: wat zou je als eerste veranderen, en waarom?

class User < ApplicationRecord
  include Notifiable
  include Searchable
  include Auditable

  has_many :subscriptions
  has_many :invoices

  validates :email, presence: true, uniqueness: true
  validate :email_must_be_business_domain, if: -> { Rails.env.production? }

  before_validation :normalize_email
  before_create :assign_referral_code
  after_create :create_stripe_customer
  after_create :send_welcome_email
  after_update :resync_with_crm, if: :saved_change_to_email?
  after_destroy :purge_external_data
  after_save :reindex_search

  def upgrade_to_pro!(plan_id)
    Stripe::Subscription.create(customer: stripe_customer_id, plan: plan_id)
    update!(plan: "pro")
    AnalyticsTracker.new.track(self, :upgraded)
  end
end

Een senior Rails engineer begint niet met refactoren. Ze beginnen met vragen. Wat roept upgrade_to_pro! aan? Is het de controller of een job? Wat gebeurt er als Stripe een time-out geeft — eindigen we met plan: "pro" en geen subscription? Welke testdekking is er? Veroorzaken de after_create callbacks al de soort callback-chaos waar ik eerder over schreef?

Een mid engineer begint concerns te extraheren. Een senior engineer realiseert zich dat de upgrade_to_pro!-methode de bug is, niet de callback-lijst. Ze pakken een service object, hebben het over idempotentie, stellen de vraag wat de controller eigenlijk wil retourneren, en pas daarna raken ze de callbacks aan. De volgorde van handelen is het signaal.

De tweede taak die ik laat rouleren is N+1. Ik laat ze een controller zien die driehonderd records laadt en JSON rendert, en ik vraag om het snel te maken. De truc is dat het antwoord niet altijd includes is. Soms is het preload, soms eager_load, soms een subquery, soms een select die twaalf kolommen weglaat die niemand gebruikt. Een senior Rails engineer kan uitleggen wanneer welke en waarom.

# Naïef
@orders = current_account.orders.recent.limit(300)
# In de view: order.customer.name, order.line_items.sum(&:total)

# Senior fix — kent het verschil tussen includes joins en preload
@orders = current_account.orders.recent.limit(300)
  .preload(:customer, :line_items)
  .select(:id, :customer_id, :total, :created_at)

# Senior vraagt ook: hebben we eigenlijk wel 300 nodig? Is dit een lijstview die pagineert?
# Senior vraagt ook: is total gedenormaliseerd, of sommen we line items per order?

De kandidaat die .includes(:customer, :line_items) plakt en stopt is niet senior. De kandidaat die het verschil uitlegt tussen preload (twee queries), eager_load (één grote LEFT OUTER JOIN), en includes (Rails beslist) en de juiste kiest voor dit geval — die is senior.

De Architectuur-Ronde: Vragen die Senior van Staff Onderscheiden

Dit is de ronde die ik zelf draai. De prompt is altijd concreet en altijd uit een echt probleem waar ik aan heb gewerkt. Mijn huidige favoriet: ontwerp een multi-tenant Rails-app voor een B2B SaaS waar elke tenant tussen een en tienduizend gebruikers heeft, tenants nooit elkaars data mogen zien, en we honderd tenants verwachten in jaar één en duizend in jaar twee.

De kandidaat heeft 75 minuten om me door te nemen hoe ze het zouden bouwen. Er is geen goed antwoord. Er zijn foute antwoorden. De foute antwoorden komen allemaal van kandidaten die een patroon kiezen voordat ze het probleem begrijpen.

De senior engineer vraagt eerst: wat is de juridische eis voor data-isolatie? Wat is de read-write-ratio per tenant? Hoe groot wordt de grootste tenant waarschijnlijk? Worden tenants ooit tussen regio’s gemigreerd? Pas daarna beginnen ze schema’s te tekenen. Ze wegen row-level scoping af tegen aparte schema’s tegen aparte databases, en ze kiezen er één en verdedigen die. Ze benoemen de failure modes van de keuze die ze maakten. Ze zeggen “wat ik hier opgeef is X.”

De staff-niveau engineer gaat verder. Ze noemen dingen waar je niet naar gevraagd hebt — back-ups per tenant, deletion onder GDPR, tenant-aware feature flags, observability die niet over tenants heen lekt. Ze vragen naar het team. “Hoe ervaren is het team dat dit gaat onderhouden? Want dat verandert mijn antwoord.” Die ene vraag is een van de sterkste staff-signalen die ik ken.

Andere architectuur-prompts die ik laat rouleren: ontwerp een webhook-ingestion-pipeline die een tienvoudige spike overleeft. Ontwerp een job-queue die zowel e-mails van tien milliseconden als exports van tien minuten moet verwerken zonder dat een van beide verhongert. Ontwerp een feature-flag-service voor een monoliet met vier teams. Geen daarvan gaat over Rails als framework — ze gaan over of de kandidaat over systemen kan denken.

Productie-Oorlogsverhalen: Het Belangrijkste Signaal

Als ik één ronde moest houden en de andere droppen, zou het deze zijn. Elke senior Rails engineer waar ik ooit mee gewerkt heb, heeft littekens. Ze hebben productie gebroken. Ze hebben een migratie gestuurd die de tabel locked. Ze hebben code geschreven die hen om 3 uur ‘s nachts opbelde. Ze herinneren het zich. Ze kunnen de vorm van het incident vertellen op een manier die laat zien dat ze ervan geleerd hebben.

De vragen zijn simpel. “Vertel me over een keer dat je productie hebt gebroken. Loop me door hoe je het vond, hoe je het oploste, wat je daarna veranderd hebt.” Ik luister naar vier dingen: hoe snel detecteerden ze, hoe vormden ze een hypothese, isoleerden ze voordat ze fixten, en welke procesverandering kwam eruit voort. Een kandidaat die zegt “ik heb een rollback gedaan en we gingen verder” is niet senior. Een kandidaat die zegt “we voegden een smoke-test toe, een query-timeout en een runbook-stap die deze klasse bugs vangt” wel.

De tweede war-story-vraag is mijn favoriet. “Wat is de slechtste Rails-code die je ooit hebt geschreven, en waarom was het de slechtste?” Senior engineers lachen en hebben er een klaar. Ze vertellen me over het god-model dat ze in 2019 schreven, de metaprogrammering-spike waar ze spijt van hebben, de Sidekiq-retry-storm die ze op een vrijdag stuurden. Junior engineers bevriezen. Mid engineers vertellen me over iets dat eigenlijk niet zo erg is. Senior engineers kiezen iets oprecht verschrikkelijks en leggen uit wat ze nu anders zouden doen.

De derde vraag is de calibratie-check. “Vertel me over een technische beslissing waar je spijt van hebt.” Dezelfde luistercriteria, maar het brengt smaak boven in plaats van brandblussen. Het beste antwoord dat ik ooit kreeg: “We kozen Mongo voor een transactioneel systeem omdat de lead engineer het wilde leren. Ik wist dat het verkeerd was en ik heb niet hard genoeg teruggeduwd. Twee jaar later migreerden we alles naar Postgres en ik bezat de migratie.” Die kandidaat heb ik diezelfde week aangenomen.

Red Flags in een Senior Rails Engineer Interview

Dit zijn de patronen die een kandidaat snel van misschien naar nee verplaatsen.

Ze kunnen N+1 niet in gewoon Nederlands uitleggen. Niet de term — de onderliggende mechaniek, waarom ORMs er gevoelig voor zijn, waarom count versus size versus length uitmaakt. Als ze het niet in twee minuten aan een junior kunnen uitleggen, hebben ze het niet doorleefd.

Ze wuiven testen weg. “We hebben tests” is geen antwoord. Ik wil weten welk soort, welke dekkingsfilosofie, wat ze doen als een test flakey is, of ze ooit een test verwijderd hebben en waarom. De kandidaat die me vertelt dat ze honderd snapshot-tests hebben verwijderd omdat het team gestopt was met de failures te lezen, is de kandidaat die ik aanneem.

Ze grijpen voor alles naar AI. Ik heb niets tegen AI in de dev-loop — ik draai een Ruby MCP Server in productie en gebruik Claude elke dag. Maar een senior engineer die niet over een stuk code kan redeneren zonder het model te vragen, is nog niet senior. Het model is een tool. Het oordeel of het antwoord van het model klopt, moet van de engineer komen.

Ze kunnen geen Postgres-extensie noemen die ze daadwerkelijk gebruiken, of een Postgres-specifieke feature waar ze om geven. Na negentien jaar ben ik moe van het “ik gebruik gewoon wat Active Record me geeft”-antwoord. Senior engineers kennen advisory locks, partial indexes, pg_stat_statements, EXPLAIN ANALYZE. Als de kandidaat nog nooit een query-plan heeft gelezen, zijn ze nog niet senior in een Rails-team dat Postgres draait.

Ze kunnen niet debuggen zonder de debugger. Pry en binding.pry zijn geweldig. Maar de senior engineer kan ook redeneren over een stack trace uit een logregel, kan een trage query vinden uit pg_stat_statements, kan een geheugenpiek correleren met een deploy zonder een debugger te hoeven aankoppelen. Een van die scenario’s doorlopen is de snelste manier om het te zien — zie ook de patronen die ik bespreek in memory leaks debuggen in Ruby on Rails productie.

De Scoringsrubric die ik Daadwerkelijk Gebruik

Ik scoor op vijf dimensies, één tot vier. Geen drieën. Jezelf van het midden af dwingen is het hele punt.

Productie-oordeel — zou ik ze op vrijdagmiddag laten deployen. Debug-methode — vormen ze hypothesen of gokken ze. Code-smaak — zou ik de code die ze in de loop schreven willen onderhouden. Communicatie onder druk — als ik terug duw, betwisten ze het idee of vatten ze het persoonlijk op. Domein-leren — hoe snel pikken ze iets op dat ze niet eerder gezien hebben.

Een vier is “sterk ja, zou ze actief op het team willen”. Een twee is “nee, niet aannemen”. Een één is “nee, en zou terugduwen als iemand anders ze wel wil aannemen”. Drie is verboden omdat het een schuilplaats is. Elke interviewer scoort onafhankelijk voor de debrief, en we laten scores niet zien tot iedereen ze opgeschreven heeft.

Het “bring back”-verdict bestaat maar ik houd het zeldzaam. Ongeveer één op de twintig kandidaten eindigt in bring-back, meestal omdat de loop op een slecht moment kwam of één ronde niet representatief was. Als een kandidaat twee keer naar bring-back gaat, zijn ze een nee — het signaal dat we geen overtuiging kunnen krijgen is zelf overtuiging.

Wat niemand bespreekt: kalibratie is belangrijker dan de rubric. Twee interviewers die dezelfde rubric gebruiken zullen verschillende scores produceren tot ze samen dertig loops gedaan hebben. Bouw die kalibratie bewust op. Debrief elke loop, ook de makkelijke. De rubric is een dwangmiddel, geen vervanging voor oordeelsvermogen.

FAQ

Hoe lang zou een senior Rails engineer interview-proces moeten duren?

Vier rondes, 3,5 uur kandidaattijd, twee weken kalendertijd. Langer en je beste kandidaten accepteren ergens anders. Korter en je krijgt geen overtuiging. Als je senior Rails engineer interview-proces langer dan drie weken end-to-end duurt, ligt het knelpunt bij je planning, niet bij de rubric.

Moet je senior Rails engineers een take-home opdracht geven?

Standaard niet. Take-homes zijn nadelig voor kandidaten met gezinnen, tweede banen of visumsituaties. Ze testen ook niet wat je denkt dat ze testen — de meeste kandidaten over-engineeren om senior te lijken of gebruiken AI om het antwoord te genereren. Als het moet, houd het onder twee uur, betaal voor de tijd, en gebruik het als gespreksopener in een vervolgronde in plaats van een pass/fail-gate.

Hoe screen je voor fractional of contract senior Rails engineers anders dan fulltime?

Fractional en contract loops zijn korter — meestal twee rondes — maar de war-stories-ronde is niet onderhandelbaar. Je koopt oordeelsvermogen, geen trainingspotentieel. Ik weeg de architectuur-ronde ook zwaarder omdat contractors midden in een bestaand systeem landen en het snel moeten lezen. Dezelfde rubric, maar de lat voor “productie-oordeel” gaat een volle punt omhoog.

Wat is de meest onderschatte senior Rails engineer interview-vraag?

“Wat is de kleinste pull request die je hebt gestuurd waar je het meest trots op bent?” Het brengt smaak, terughoudendheid en het gevoel van de engineer voor wat goed is op micro-schaal naar boven. Junior en mid engineers vallen terug op het grootste project dat ze stuurden. Senior engineers vertellen je over een wijziging van vijftien regels die een klasse bugs voor altijd oploste, of een revert van één regel die de launch redde.

Senior Rails engineers aannemen en moe van loops die false positives produceren? TTB Software helpt founders met interview-rubrics en technische due diligence als onderdeel van fractional CTO-trajecten. Negentien jaar Rails, tientallen loops, en een diep verankerde mening dat de war-stories-ronde de ronde is die je niet kunt overslaan.