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

Kotlinエンジニアのフリーランス面談でよく聞かれるのは、Kotlinでどこまでの実務を担ったか、Javaとの境界やnullをどう扱ったか、コルーチンを本番でどう使い何が起きたか、版の更新や移行をどう進めたかの4つです。面談官は文法の知識より、「この人に任せたら、Kotlinらしく保守しやすいコードを書き、問題が起きたときに自分で原因を追えるか」を確かめようとしています。

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

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

Kotlinの案件の面談には、発注元のテックリードやKotlinの経験がある開発者が出てくることが多くあります。そのため、使った技術の名前を並べるより、なぜその書き方を選んだかを聞いています。

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

1. Kotlinの実務の深さ：Javaの書き方を置き換えただけか、型の仕組みや非同期処理を生かして設計してきたか
2. 既存資産との付き合い方：Javaのコードやライブラリ、古い版の設定が残る現場で動けるか
3. 自走できるか：問題が起きたときに、ログや指標から原因を追い、直して説明できるか

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

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

1. 「Kotlinの実務はどのくらいですか。Javaとの比率も教えてください」

確かめたいのは、Kotlinの経験の中身です。期間に加えて、新しいコードをKotlinで書いていたのか、Javaとの混在の中で一部だけだったのか、使ったフレームワークは何かを短く伝えます。Javaの経験が長い人は、Javaの期間とKotlinの期間を分けて話すと、スキルシートとの食い違いが起きません。

架空の例：「直近の2年は、Spring Bootの新しいAPIをすべてKotlinで書いていました。既存の部分はJavaで、チーム全体ではおよそ半々です」

2. 「null安全をどう生かしていましたか。Javaのライブラリとの境界は？」

Kotlinらしい設計ができるかを測る質問です。?を付けて逃がすだけでなく、どこでnullを許し、どこで型として排除したかを話します。Javaのライブラリが返す値をどの層で受けて、Kotlinの型に変換していたか、といった具体的な線の引き方を示すと伝わります。

3. 「コルーチンを本番で使って、困ったことはありますか」

差がつきやすい質問です。「使ったことがある」で終わらせず、次の順で組み立てます。

• どんな処理でコルーチンを使ったか
• 何が起きたか（処理が取り残された、例外が握りつぶされた、遅延が増えたなど）
• どうやって原因に気づき、何を直したか
• その後、チームの書き方として何を決めたか

Kotlinの公式ドキュメントは、Ktorがコルーチンを使って高いスケーラビリティを得ていると説明しています（2026年10月時点）。非同期の処理を扱う現場は多いため、キャンセルや例外の伝わり方まで説明できると、設計を任せてもらいやすくなります。

4. 「sealedクラスやdata classで、業務の状態をどう表しましたか」

型で業務を表す力を見ています。たとえば処理の結果を成功と失敗の型に分けた、状態の遷移を型で表してwhenで漏れなく扱った、といった例を、それで何が防げたかとあわせて話します。

5. 「Spring BootとKtorのどちらを使っていましたか。版はいくつでしたか」

技術の前提が合うかの確認です。フレームワークと、Kotlin・JDK・フレームワークの版を答えます。版を上げた経験があれば、何が変わり、どこでつまずいたかを添えると、運用の経験として受け止められます。版を正確に覚えていない場合は、おおよその時期とともに「当時の最新の系列から一つ前」のように答え、あいまいな数字を言い切らないほうが無難です。

6. 「JavaからKotlinへの移行は、どう進めましたか」

移行の案件で特に深く聞かれます。どのモジュールから移したか、なぜその順番にしたか、混在する期間にビルドとテストをどう保ったか、Javaのコードから呼ばれる部分をどう公開したかを話します。自分が決める立場でなかった場合は、決めた人と自分が担った範囲を分けて伝えます。

7. 「テストとビルドはどうしていましたか」

単体テストと結合テストの分け方、モックの使い方、GradleのKotlin DSLを自分で直せるかを見ています。依存関係の更新を自分で進めた経験があれば、その手順を一つ話せるようにしておきます。

8. 「本番で遅延や障害が起きたとき、どう調べましたか」

自走できるかの確認です。どの指標やログで気づき、JVMのメモリやスレッドの状態をどう見て、原因をどう特定したかを順に話します。原因が自分のコードでなかった場合も、切り分けの手順を話せれば経験として伝わります。

技術課題やコードを見せる場面への備え

面談の前後に、簡単な技術課題や、過去に書いたコードの説明を求められることがあります。課題が出た場合は、動くことに加えて、なぜその書き方にしたかを短く説明できることが見られます。課題の範囲や扱いの考え方は技術テストの記事で解説しています。

公開しているコードを見せる場合は、前の現場のコードや社名が含まれていないかを先に確かめます。業務のコードを持ち出して見せることは、守秘の面で問題になります。

準備は「判断の場面」と「起きた問題」を3〜4つに絞る

1. 場面を選ぶ：設計の判断、コルーチンの問題、移行や版の更新、障害の調査など、性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：状況、気づいたきっかけ、選択肢、選んだ理由、結果、チームで決めたことを書き出す
3. 数字をそろえる：期間、チームの人数、Kotlinとほかの言語の比率を、どの場面でも同じ数字で言えるようにする
4. 2分版と5分版をつくる：最初は短く話し、掘り下げられたら詳しく話せるようにする
5. スキルシートと照らし合わせる：シートに書いたフレームワークや版と、話の内容が一致しているかを確かめる

面談官はシートを見ながら質問するため、話とシートがずれると、どちらも信用されにくくなります。シートの書き方はKotlinのスキルシートの書き方、冒頭の自己紹介は面談の自己紹介の記事で解説しています。

Kotlinならではの逆質問

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

• 新しいコードはKotlinで書くのか、Javaの保守がどのくらいあるか
• Kotlin・JDK・フレームワークの版と、版の更新の方針
• コルーチンを使っているか、使っている場合の書き方の決まり
• コーディング規約や静的解析の設定があるか
• 移行の案件なら、移す順番と、残りの範囲の見込み
• 障害の当番があるか

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

よくある質問

Kotlinの実務が短いのですが、面談ではどう話せばよいですか？

Kotlinの期間とJavaなどほかの言語の期間を分けて示し、Kotlinで書いた部分で自分が判断したことを中心に話します。期間を長く見せるより、短い期間でもKotlinらしい設計の例を一つ具体的に話せるほうが、評価につながりやすくなります。

AndroidでKotlinを書いてきた経験は、サーバーサイドの面談で通用しますか？

言語とコルーチンの経験は土台として伝わります。ただ、データベースの設計やトランザクション、APIの設計、本番の監視について聞かれることが多いため、サーバー側で担った経験があれば、それを中心に話せるよう準備しておきましょう。

面談で答えられない技術の質問が出たらどうすればよいですか？

分からないことは分からないと伝え、似た経験や、調べるとしたらどこから当たるかを添えるのが無難です。知らないことを推測で言い切ると、掘り下げられたときに信頼を損ねます。見送られやすい理由は面談で見送られる理由の記事で解説しています。