Rubyエンジニアのフリーランス面談でよく聞かれる質問と答え方の準備

Rubyエンジニアのフリーランス面談でよく聞かれるのは、どの版のRailsでどんな構成のサービスを担当したか、既存のコードをどう読んでどう直したか、遅い処理やジョブの失敗にどう対応したか、テストと更新にどう向き合ってきたかの4つです。面談官は、知識の量より「このチームのコードを渡したら、壊さずに機能を出し、問題が起きたときに自分で原因を追えるか」を確かめようとしています。

答えるときは、模範解答を覚えるより、自分の経験から「判断した場面」を3〜4つ選び、どの質問にもそこから答えられるように準備しておくのが近道です。面談全般の答え方の型は業務委託の面談でよく聞かれる質問と答え方で解説しているので、この記事ではRubyの面談に固有の質問に絞ります。

Rubyの面談で面談官が見ていること

Rubyの案件の面談に出てくるのは、開発チームのリーダーやCTOであることが多く、本人もRailsでコードを書いています。そのため、用語を知っているかより、話の中に出てくるコードの読み方と判断の根拠を聞いています。

面談官が知りたいのは、おおむね次の3点です。

1. 入ってすぐ動けるか：自分たちと近い版・構成のRailsを触ってきたか、既存のコードを読んで直せるか
2. 壊さずに出せるか：テストを書き、影響の範囲を見極め、小さな単位で本番に出す習慣があるか
3. 問題を自分で追えるか：遅い処理、ジョブの失敗、障害が起きたときに、原因を調べて直した経験があるか

以下の質問は、この3点のどれかを確かめるためのものです。質問の意図が分かれば、答えの中心に何を置くかも決まります。

よく聞かれる質問と答え方の考え方

ここで示す答えの例は、組み立て方を伝えるための架空の例です。そのまま使うのではなく、ご自身の経験に置き換えて準備してください。

1. 「直近のサービスの構成と、担当した範囲を教えてください」

確かめたいのは、入ってすぐ動けるかです。RubyとRailsの版、画面までRailsで作る構成かRailsをAPIにしてフロントエンドを分けた構成か、チームの人数、自分が担った工程（設計・実装・テスト・リリース・障害対応のどこまでか）を短く伝えます。「Rails開発」とまとめず、版と構成を最初に言うと、面談官は自分たちのサービスと重ねて聞けます。

架空の例：「Ruby 3.2とRails 7.1の予約サービスで、画面はHotwireで作る構成でした。エンジニア4名のチームで、機能の設計からリリース後の一次対応までを担当していました」

2. 「既存のコードを読んで直したとき、どこから手をつけましたか」

Rubyの面談で最も特徴的な質問です。Railsの案件のほとんどは、すでに動いているサービスに途中から加わる形のため、他人のコードを読む力を見ています。答えは次の順番で組み立てると伝わります。

• どの機能のコードで、どんな状態だったか（モデルに処理が集まっていた、テストがなかった、など）
• 影響の範囲をどう調べたか（呼び出し元、コールバック、ジョブからの参照など）
• 直す前に何をしたか（テストを足した、動きを記録した）
• どの単位で分けて直し、どう本番に出したか

「リファクタリングしました」だけで終わると、判断の中身が見えません。なぜその単位で分けたかまで話せると、設計の考え方が伝わります。

3. 「遅い処理やN+1に気づいたとき、どう見つけてどう直しましたか」

Active Recordを性能まで考えて使えるかを見る質問です。気づいたきっかけ（監視の数字、ログ、利用者の声）、原因の調べ方（発行されたSQL、実行計画）、取った手（includesやpreloadの使い分け、インデックス、集計の見直し）、改善の前後の数字を話します。数字が手元になければ、「表示にかかる時間が目に見えて短くなった」のように、確かめた方法を添えます。

4. 「テストはどの粒度で書きますか。テストのないコードにはどう向き合いますか」

テストを書くこと自体は前提として扱われることが多く、差がつくのは判断の部分です。モデル・リクエスト・画面操作のどこで何を確かめるか、テストデータの作り方で気をつけていること、遅くなったテストをどう保ったか、テストのない古いコードにどこから足したかを話します。「カバレッジを上げました」より、何を守るためにどこに書いたかが聞かれています。

5. 「RubyやRailsの版の更新に関わったことはありますか」

運用の長いサービスの案件で、よく掘り下げられる質問です。どの版からどの版へ、自分は何を担当したか（非推奨の置き換え、gemの更新、テストの修正、段階的なリリースのどこか）、何が壊れてどう見つけたかを話します。チームで経験した更新を自分が主導したように話すと、「どの非推奨で苦労したか」と聞かれたときに答えに詰まります。関わった範囲を正確に伝えるほうが信頼されます。

6. 「ジョブの失敗やデータの不整合、障害が起きたとき、何をしましたか」

問題を自分で追えるかを見る質問です。Sidekiqなどのジョブが失敗したときの再実行の設計、二重実行への備え、本番で起きた障害の発生から復旧までの流れ、再発を防ぐために変えたことを話します。自分が一次対応をしていない場合も、障害のあとにチームで何を変えたかを話せれば、運用への関心が伝わります。

7. 「レビューで指摘されて直したこと、レビューで見ていることは何ですか」

少人数のチームで一緒に働けるかを見ています。指摘を受けて設計を変えた経験を一つ、自分がレビューするときに見る点（発行されるSQL、テストの意図、規約からの逸脱、マイグレーションの影響など）を話します。前の現場のレビュー文化を批判する話し方は、「自分たちも同じように言われるのでは」と受け取られやすいので避けたほうが無難です。

8. 「gemの選定や、規約から外れる判断をしたことはありますか」

Railsの規約を理解したうえで、どこで外れる判断をしたかを見る質問です。gemを選ぶときに確かめること（更新の頻度、依存の多さ、代わりの手段）、サービスオブジェクトやconcernの使い方でチームと決めたことなどを話します。「規約どおりにしか書いたことがない」でも、理由をもって規約に沿ってきたことを話せば問題ありません。

9. 「開始できる時期と、稼働の条件を教えてください」

開始時期、週の稼働日数、チャットで連絡が取れる時間帯、会議に出られる曜日、リモートか出社か、夜間のリリースや障害の連絡に応じられるかを聞かれます。答えに迷いがあると、条件のずれが参画後に表に出ます。希望の単価を聞かれたときの答え方は面談で希望単価を聞かれたときの答え方で解説しています。

技術面談・コーディングテストがある場合

Rubyの案件では、会話の面談に加えて、簡単なコードを書く課題や、既存のコードを読んで問題点を挙げる形の技術面談が行われることがあります。見られているのは、正解を出す速さより、読みながら何を考えているかを言葉にできるかです。

• コードを読むときは、処理の流れを声に出して確かめる
• 気になった点（SQLの発行回数、例外の扱い、テストのしやすさ）は、直す前に挙げる
• 分からない部分は推測で押し切らず、「ここは実際に動かして確かめたい」と言う

課題の量が多く、長い時間を無償で求められる場合は、線引きを考える必要があります。備え方は技術面談・コーディングテストへの備え方で解説しています。

準備は「判断の場面」を3〜4つに絞る

上の質問は数が多く見えますが、答えの材料は共通しています。準備は次の手順で進めると効率的です。

1. 場面を選ぶ：既存コードの改修、性能の改善、版の更新、ジョブや障害の対応など、性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：状態、気づいたきっかけ、調べ方、選んだ手と理由、本番への出し方、結果、次に変えたことを書き出す
3. 版と構成の数字をそろえる：RubyとRailsの版、チームの人数、担当した工程を、どの場面でも同じように言えるようにする
4. 2分版と5分版をつくる：最初は2分で話し、掘り下げられたら詳しく話せるようにする
5. スキルシートと照らし合わせる：シートに書いた版、構成、担当範囲と話の内容が一致しているかを確かめる

スキルシートとの一致は特に大切です。面談官はシートを見ながら質問するため、話とシートがずれると、どちらも信用されにくくなります。シートの書き方はRubyエンジニアのスキルシートの記事、冒頭の自己紹介の組み立て方は面談の自己紹介の記事で解説しています。

面談の相手によって重心が変わる

Rubyの面談は、相手によって聞かれる内容の重心が変わります。

立ち上げの案件では、事業責任者が一人で面談することもあります。その場合は、技術の細かい話より、仕様が固まらない中でどう形にしてきたかに重心を置くと、限られた時間を有効に使えます。

Rubyならではの逆質問

面談の終わりには、こちらから質問できる時間があります。逆質問は、印象づくりより参画後のずれを防ぐ確認に使います。Rubyの案件では、次の点を聞いておくと判断がしやすくなります。

• 今のRubyとRailsの版と、更新の予定があるか
• テストとCIはどこまで整っているか。レビューは誰が、どのくらいの時間で行うか
• 画面までRailsで作る構成か、APIとフロントエンドを分けた構成か
• 本番のデータベースやコンソールの操作は、誰がどう行うか
• 会議の頻度と時間帯、出社する日の有無
• 担当する範囲が、インフラやフロントエンドまで広がる想定か

一般的な逆質問の考え方は業務委託の面談で聞いておくべき逆質問にまとめています。逆質問で聞いた内容は、契約前の確認にもそのまま使えます。案件を選ぶときの確認点はRuby案件の選び方で整理しています。

よくある質問

Railsの経験が1つのサービスだけでも、面談で不利になりますか？

サービスの数より、そのサービスでどこまで担ったかが見られます。1つのサービスで機能開発から改修、更新、障害対応まで経験していれば、十分に話せる材料があります。複数の版や構成を経験していない点は、学習中の内容を実務と分けて正直に伝えれば問題になりにくい傾向があります。

技術の質問に答えられなかったとき、どうすればよいですか？

知らないことは、推測で答えるより「触ったことがないので、調べて確かめたい」と伝えるほうが信頼されます。そのうえで、近い経験があれば、それをどう応用できそうかを話します。面談で見送られやすい受け答えは面談で見送られる理由の記事で解説しています。

オンラインの面談でコードを見せてほしいと言われたら、どうしますか？

前の現場のコードは守秘の対象なので、見せられないことを伝えて問題ありません。代わりに、公開している小さなRailsアプリや、gemへの修正の提案があれば、その場で画面を共有して説明できます。公開できる成果がない場合は、書き方の考え方を口頭で伝えれば十分です。環境の準備はオンライン面談で気をつけることをご覧ください。