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

Scalaエンジニアのフリーランスの面談でよく聞かれるのは、どの版のScalaをどんな書き方の現場で使ったか、失敗をどう型で表したか、抽象化をどこで止めたか、副作用をどこに閉じ込めたか、移行や性能の問題をどう解いたかの5つです。面談官は、知っている機能の数より「この人がうちのコードに入ったら、チームの書き方に合わせて読みやすく書けるか」を確かめようとしています。

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

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

Scalaの案件の面談には、参画先の技術リードや、Scalaで長く書いてきた開発者が出てくることが多くあります。Scalaは同じ処理を何通りにも書ける言語なので、面談官は書き方の選び方の理由を聞きたがります。

見ている点は、おおむね次の3つです。

1. 書き方の型が合うか：標準ライブラリのFuture中心か、エフェクトを型で扱うライブラリ中心か、Scala 2か3か。自社の現場に近い経験か
2. 読みやすさへの感覚：高度な型を使えることより、チームの習熟に合わせて抽象化の程度を決められるか
3. 本番で問題を追えるか：ビルドの依存の衝突、JVMのメモリやスレッド、遅い処理の原因をどこまで自分で調べられるか

以下の質問は、この3つのどれかを確かめるためのものです。

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

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

1. 「直近の案件で使っていたScalaの版と、主なライブラリを教えてください」

確かめたいのは、書き方の型が自社に近いかです。Scalaの版（2.12・2.13・3）、ビルドの仕組み、非同期の書き方（Futureか、エフェクトのライブラリか）、Webの層やデータベースのライブラリを短く伝えます。名前を並べるだけでなく、「チームの中ではこういう書き方が決まりだった」と一言添えると、現場の姿が伝わります。

架空の例：「Scala 2.13で、非同期はエフェクトのライブラリに統一していました。業務のエラーはEitherで返し、例外は境界の層でだけ扱う決まりでした」

2. 「失敗やエラーはどう扱っていましたか」

Scalaの面談でとても多い質問です。Option・Either・例外をどう使い分けたか、業務のエラーとシステムのエラーをどこで分けたかを話します。なぜその使い分けにしたかまで話せると、決まりに従っていただけでないことが伝わります。

3. 「抽象化をやりすぎた、あるいはやめた経験はありますか」

Scalaらしい質問です。型クラスやimplicit（Scala 3ではgiven・using）で共通化しようとして、読めるコードにならなかった場面や、あえて単純な書き方を選んだ場面を話します。面談官は、高度な書き方を自慢する話より、チームのことを考えて書き方を選んだ話を評価しやすい傾向があります。

4. 「副作用のある処理は、どこに集めていましたか」

データベースや外部APIの呼び出しを、どの層に集め、どう試験していたかを確かめる質問です。処理を途中で止めるときの資源の解放や、並行で動かす数の抑え方まで話せると、本番での振る舞いを分かっている印象になります。使ったことのないライブラリについて聞かれたら、知っている考え方とどう対応するかを話せば十分です。

5. 「Scala 2と3の違いで、移行のときに問題になる点は何ですか」

移行を控えた現場でよく聞かれます。公式の移行ガイドでは、Scala 3はScala 2.13でコンパイルされたライブラリを使える一方、Scala 3のコンパイラはScala 2のマクロを展開できないことなどが示されています（2026年10月時点）。移行の経験がある人は、依存の洗い出しから反映までの順番と、詰まった点を話します。経験がない人は、何を最初に調べるかを順に示せれば、考え方は伝わります。

また、2026年9月にScala 3.9が新しい長期サポートの系列として公開されています。Scala 3の現場では「どの版に合わせるか」の話題になることもあるため、公式の案内に目を通しておくと話がしやすくなります。

6. 「性能の問題やビルドの不具合を調べた経験を教えてください」

遅い処理、メモリの不足、依存の衝突など、原因が分かりにくかった場面を選びます。何から疑い、どの道具で確かめ、何が原因だったかの順に話します。Scalaのコードではなく、JVMの設定や依存の版に原因があった話は、本番で頼れる人だという印象につながります。

7. 「コードレビューで、どんな指摘をすることが多いですか」

チームの書き方をそろえる側に回れるかを確かめる質問です。指摘の内容と、指摘の伝え方（理由を添える、代わりの書き方を示す）の両方を話します。

8. 「なぜScalaの案件を選んでいるのですか」

長く続けられるか、ほかの言語の案件へ移るつもりかを確かめる質問でもあります。Scalaのどこを生かしたいのかと、得意な領域（バックエンド、共通基盤、データ処理など）を添えると、案件との合い方が伝わります。

コードを読む・書く課題が出ることもある

Scalaの案件では、面談の中で短いコードを読んで説明したり、その場で小さな修正を考えたりする課題が出ることがあります。ねらいは正解の速さより、考えながら話す様子を見ることです。

• 分からないところは、分からないと言ってから、どう調べるかを話す
• 書き方が複数ある場合は、どれを選ぶか、なぜかを口に出す
• Scala 2と3のどちらの前提かを最初に確かめる

課題の種類と準備の仕方は技術テストの記事で解説しています。

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

1. 場面を選ぶ：失敗の扱い方、抽象化の判断、副作用の設計、移行または性能の調査など、性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：状況、選択肢、選んだ理由、結果、次に変えたことを書き出す
3. 版とライブラリをそろえる：どの案件で何の版を使ったかを、スキルシートと同じ内容で言えるようにする
4. 短いコードを手元で書いておく：説明に使えそうな書き方を、自分の言葉で説明できる形にしておく
5. 2分版と5分版を用意する：最初は短く話し、掘り下げられたら詳しく話す

スキルシートと話の内容がずれると、どちらも信用されにくくなります。シートの書き方はScalaのスキルシートの記事、冒頭の自己紹介は面談の自己紹介の記事をご覧ください。

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

Scalaならではの逆質問

逆質問は、参画後のずれを防ぐ確認に使います。Scalaの案件では、次の点を聞いておくと判断しやすくなります。

• Scalaの版と、移行の予定の有無
• 非同期の書き方とライブラリの方針、チームの書き方の決まりが文書になっているか
• レビューの進め方と、1つの変更が反映されるまでの流れ
• チームの中でScalaに詳しい人の数と、相談できる相手
• 障害の当番の有無

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

よくある質問

参画先と違うエフェクトのライブラリしか使ったことがありません。不利になりますか？

不利になるとは限りません。面談官が見ているのは、副作用をどこに閉じ込め、資源をどう解放するかという考え方であることが多いためです。使ったライブラリでの書き方と、参画先のライブラリでの対応する書き方を説明できるようにしておくと安心です。

Scala 3の経験がないと面談で厳しく見られますか？

Scala 2.13で動いている現場やSparkの案件では、Scala 3の経験がなくても問題にならないことがあります。新しく作る案件や移行を控えた案件では聞かれやすいので、手元でScala 3に触れ、Scala 2との違いを自分の言葉で話せるようにしておきましょう。

Javaの経験が長いことは、どう話せばよいですか？

JVMの性能調査やJavaのライブラリとの組み合わせなど、Javaの経験が生きる場面を具体的に話すと評価につながります。あわせて、Scalaでは例外やnullに頼らず型で失敗を表す書き方に移れていることを示しましょう。Javaの面談との違いはJavaエンジニアの面談の記事も参考になります。