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

フリーランスのRustエンジニアの面談でよく聞かれるのは、Rustを本番でどの範囲まで使ったか、所有権・型・エラー処理をどう設計に生かしたか、unsafeや他言語との境界にどう関わったか、性能をどう測って直したかの4つです。面談官は、言語の知識の量より「この人にこのコードを預けたら、チームが保守を続けられる形で仕上げてくれるか」を確かめようとしています。

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

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

Rust案件の面談に出てくるのは、発注元の技術リードやRustを書いているエンジニアであることが多く、コードの話を深く掘り下げてきます。Rustは採用した理由がはっきりしている言語なので、面談官はその理由に応えられる人かを見ています。

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

1. 任せられる範囲：Rustで書いた範囲は、部品の一部か、サービス全体か、設計の判断まで含むか
2. 難しい場面での動き方：コンパイルが通らない、性能が出ない、境界で不具合が出たときに、何を見て何を決めたか
3. チームとの相性：レビューの仕方や書き方の決まりへの姿勢が、自社のやり方に合うか

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

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

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

1. 「Rustを本番で使った経験と、担当した範囲を教えてください」

確かめたいのは、任せられる範囲です。何を作ったか（API、ツール、組込みなど）、Rustで書いた割合、チームの人数、自分が設計まで決めたか、運用まで担ったかを短く伝えます。個人開発や検証の段階の経験は、本番の経験と分けて話すと、後の質問との食い違いが起きません。

架空の例：「ログを集めるエージェントをRustで書き直す案件で、4名のチームのうち、収集部分の設計と実装を担当しました。本番の運用は1年ほど見ていました」

2. 「なぜそのプロジェクトではRustが選ばれたのですか」

Rustの面談に特有の質問です。採用の理由を知っているかで、プロジェクトの目的を理解して書いていたかを測っています。速さ、メモリ安全性、配りやすさなど、理由と、その理由が設計にどう表れたかを結びつけて話すと伝わります。自分が選んだ立場でなければ、「決めたのは誰で、自分はその理由をどう実装に反映したか」を話します。

3. 「所有権や借用で設計に悩んだ場面と、どう解決したかを教えてください」

最もよく掘り下げられる質問です。答えは次の順番で組み立てると伝わりやすくなります。

• どんな構造で、何がコンパイルを通らなかったか
• どんな選択肢を並べたか（参照の持ち方を変える、所有を移す、共有の仕組みを使う、設計を分けるなど）
• なぜその案を選び、ほかの案を捨てたか
• 結果として、性能や読みやすさがどうなったか

「cloneで回避しました」だけで終わると、判断の中身が見えません。コストとの釣り合いをどう考えたかまで話せると、設計の力が伝わります。

4. 「エラー処理はどんな方針にしていましたか」

ライブラリとアプリケーションでエラーの型をどう分けたか、unwrapをどこまで許したか、エラーをどう記録して運用に生かしたかを確かめる質問です。チームの決まりがあったなら、その決まりと理由を話します。

5. 「unsafeやFFIに関わった経験はありますか」

関わり方を正確に話すことが大切です。自分でunsafeを書いたのか、レビューしたのか、既存の安全な部品を使っただけなのかを分けて話します。書いた場合は、どこまでをunsafeにし、どう安全な部品で包み、どう検査したかを伝えます。経験がない場合は、ないと言ったうえで、どう学ぶかを話すほうが信頼されます。

6. 「非同期処理で困ったことはありますか」

非同期の実行環境を使った経験の深さを測る質問です。処理が詰まった、意図せず待ち続けた、リソースを使い切ったなど、具体的な不具合と、その原因をどう突き止めたかを話します。

7. 「性能の問題をどう見つけて、どう直しましたか」

何で測ったか、どこが遅かったか、何を変えて、どれだけ改善したかを、測り方とあわせて話します。数字は前の案件の機密に触れない範囲で、「処理時間がおおむね半分になった」のように割合で示すと扱いやすくなります。

8. 「Rustに慣れていないメンバーに、どう関わりましたか」

チームでRustを使い続けられるかを確かめる質問です。レビューでの伝え方、書き方の決まりの整備、勉強会など、自分が担った範囲を話します。

面談の中で、コードを書く課題やコードを読む質問が出ることもあります。進め方は技術テストの記事で解説しています。

準備は「設計と不具合の場面」を3〜4つに絞る

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

1. 場面を選ぶ：所有権の設計、エラー処理の方針、境界の不具合、性能の改善など、性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：状況、困ったこと、選択肢、選んだ理由、結果、学びを書き出す
3. 規模をそろえる：期間、チームの人数、自分が担った範囲を、どの場面でも同じ言い方で言えるようにする
4. 2分版と5分版をつくる：最初は2分で話し、掘り下げられたら詳しく話せるようにする
5. スキルシートと照らし合わせる：シートに書いた範囲と話の内容が一致しているかを確かめる

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

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

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

組込みの案件ではハードウェアの担当者、WebAssemblyの案件ではフロントエンドの担当者が面談に入ることもあります。その場合は、相手の領域との受け渡しで工夫した点を話すと、限られた時間を有効に使えます。

Rustならではの逆質問

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

• Rustを選んだ理由と、Rustで書く範囲（全体か一部か）
• チームの中でRustを書ける人の数と、レビューの体制
• unsafeの扱いや書き方の決まりの有無
• 使っているツールチェーンの版と、更新の進め方
• 開発環境とビルドの方法（手元のPCか、配布された環境か）

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

よくある質問

Rustの実務経験が短く、個人開発が中心です。面談でどう話せばよいですか？

個人開発の経験は、本番の経験と分けたうえで、設計で悩んだ点と解決の仕方を中心に話します。あわせて、ほかの言語で本番を運用した経験を、Rustの案件でどう生かすかを話すと、任せられる範囲が伝わりやすくなります。

unsafeを書いた経験がありません。不利になりますか？

案件によります。Webのバックエンドなど、unsafeをほとんど使わない案件も多くあります。経験がない場合は正直に伝え、unsafeを使う部分をどうレビューし、どう避けるかの考え方を話せれば十分なことが多いでしょう。

面談でコードを書く課題が出たら、どう臨めばよいですか？

完成を急ぐより、考えていることを声に出しながら進めるほうが評価されやすくなります。所有権やエラー処理で迷った点を、迷った理由とあわせて伝えましょう。見送られやすい理由は面談で見送られる理由の記事で解説しています。