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

Reactエンジニアのフリーランス面談でよく聞かれるのは、どの範囲を担ったか、コンポーネントをどう分けたか、状態をどこに置いたか、品質をどう支えたかの4つです。面談官は、知っているライブラリの数より「この人に画面の設計を任せたら、チームのコードがどうなるか」を確かめようとしています。

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

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

Reactの案件の面談には、現場のテックリードやフロントエンドの担当者が同席することが多く、技術の話を具体的に掘り下げてきます。ただし、聞きたいのは用語の説明ではなく、なぜその書き方を選んだのかという判断の理由です。

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

1. 任せられる範囲：決まった画面の実装までか、共通部品や設計まで任せられるか
2. コードの質の考え方：読みやすさ、壊れにくさ、表示の速さ、使いやすさをどう扱ってきたか
3. チームとの相性：レビューの受け方や、デザイナー・バックエンドとのやり取りが自社のやり方に合うか

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

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

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

1. 「直近の案件で、どこからどこまでを担当しましたか」

確かめたいのは任せられる範囲です。チームの人数、自分の立場、担った範囲（画面の実装、共通部品、設計の方針、レビュー）を短く伝えます。「Reactで開発していました」だけでは範囲が見えません。

架空の例：「フロントエンド4名のチームで、注文管理の画面群の実装と、フォームの共通部品の設計を担いました。方針はテックリードが決め、私はレビューも担当していました」

2. 「コンポーネントをどういう考え方で分けていますか」

設計の考え方を確かめる質問です。一般論より、実際に分けた画面を一つ取り上げて、どこで分け、なぜそうしたか、後から困ったことは何かを話すと伝わります。分けすぎて受け渡しが増えた失敗も、気づいて直した経緯まで話せれば評価の材料になります。

3. 「状態はどこに置いていましたか。ライブラリは何を使いましたか」

最もよく掘り下げられる質問の一つです。ライブラリの名前を並べるより、サーバーから取ってくるデータと、画面だけで使う状態を分けて考えているかが見られています。どの状態をどこに置き、なぜそのライブラリ（または使わない判断）を選んだかを順に話します。useEffectをどんな場面で使い、どんな場面では使わないようにしていたかも聞かれやすい点です。

4. 「TypeScriptはどの程度使っていましたか」

型をどこまで厳しくしていたか、APIの型をどう用意していたか、型で防げた不具合の例を話します。型の設定を自分で決めたのか、決まった設定の中で書いていたのかを分けて伝えると、誇張していない印象になります。TypeScriptの面談で見られる点はTypeScriptエンジニアの面談の記事でも扱っています。

5. 「表示が遅い画面をどう改善しましたか」

性能の経験を確かめる質問です。何で遅さに気づいたか（利用者の声、計測の数値、開発ツール）、原因をどう突き止めたか、何を変えたか、変えた後どう確かめたかの順で話します。メモ化を足しただけで終わると、原因の見立てが見えません。計測してから手を入れたという順番が伝わることが大切です。

6. 「テストはどう書いていましたか」

何をテストし、何をしなかったかを聞いています。部品の単体テスト、画面の操作のテスト、ブラウザを使った通しのテストのうち、どれをどの程度書いていたか、テストがあって助かった場面を話します。テストの経験が少ない場合は、少ない理由と、自分で補っていた確認の方法を正直に伝えましょう。

7. 「Next.jsなどのフレームワークは使っていましたか」

サーバーで描画する部分とブラウザで動かす部分をどう分けたか、データの取得をどこで行ったかを話します。使ったことがない場合は、Reactだけの構成で何を自分で組み立てていたかを話すと、経験の重さが伝わります。

8. 「デザイナーやバックエンドの担当者とはどうやり取りしていましたか」

チームとの相性を見る質問です。デザインと実装の食い違いをどう相談したか、APIの形が合わないときにどう決めたかを話します。相手の都合も聞いたうえで、記録を残して決めた流れが伝わると安心されます。

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

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

1. 場面を選ぶ：部品の分け方、状態の置き場所、性能の改善、テストや版上げなど、性質の違う場面を3〜4つ選ぶ
2. 場面ごとにメモをつくる：状況、ほかの選択肢、選んだ理由、結果、今ならどうするかを書き出す
3. 版と構成をそろえる：React・TypeScript・フレームワークの版や、主なライブラリを、どの場面でも同じ内容で言えるようにする
4. 短い版と詳しい版をつくる：最初は1〜2分で話し、掘り下げられたら詳しく話せるようにする
5. スキルシートと照らし合わせる：シートに書いた担当範囲と話がずれていないかを確かめる

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

オンラインの面談では、画面共有でコードや画面を見せるよう求められることもあります。公開できるものを用意しておくと話が早く進みますが、前の現場のコードを見せることは避けましょう。進め方はオンライン面談の記事が参考になります。

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

面談の相手が技術者でない場合は、技術の細部より、何を作り、どんな問題を解いたかを中心に話すと伝わりやすくなります。

Reactならではの逆質問

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

• 使っているReactとフレームワークの版、版上げの予定
• 状態管理やスタイルの書き方の方針と、それを決めている人
• テストの範囲とレビューの進め方
• デザイナーとの受け渡しの方法と、仕様を決める人
• 最初に担当する画面や機能

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

よくある質問

面談でコーディングの課題を出されることはありますか？

案件によってはあります。事前に課題を渡される場合も、面談中に画面共有で書く場合もあります。完成させることより、どう考えて進めたかを声に出して説明できるかが見られることが多いので、詰まったときも考えている内容を話しましょう。

クラスコンポーネントの経験が長いことは不利になりますか？

古い書き方の経験そのものは、既存画面の刷新の案件で生きることがあります。そのうえで、関数コンポーネントとフックでの開発経験を話せることが前提になる案件が多いため、直近で書いたコードや学んだ内容を具体的に伝えましょう。

面談で見送られた理由が分からないときはどうすればよいですか？

紹介を受けた窓口に、答えられる範囲で理由を聞いてみるのが一つの方法です。よくある理由は面談で見送られる理由の記事にまとめています。技術の話が抽象的だった、担当範囲がシートと合わなかった、といった点を振り返ると、次の準備に生かせます。