「Reactは3年使っていますし、Reduxも触っています。なのに技術面接で『それで、なぜそうしたんですか』と聞かれた途端に、うまく答えられなくなる」——フロントエンドエンジニアの方から、こういう相談を受けることが少なくありません。
私はIT・Web業界を中心に800名以上の転職支援に携わっていますが、面接後のフィードバックを読み比べると、落ちる方の多くは知識が足りないのではなく、知識を「使った」とは言えても「判断した」とは言えていないことが共通しています。今回は、React・状態管理・パフォーマンスの3つの質問で、答えの何が評価を分けるのかを、Before/Afterの言い換え例でお伝えします。
今回は、次の内容に沿ってご紹介します。
- フロントエンドの技術面接が、用語の正誤ではなく「選んだ理由」と「測った根拠」を見ている構造
- 状態管理・再レンダリング・パフォーマンス改善の3問それぞれの、使えるだけの答えと判断を語れる答えの対比
- 面接官が深掘りする順番と、答えに詰まったときの立て直し方
- 実務経験が浅い場合やReact Compiler時代の準備の仕方
目次
フロントエンドの技術面接でReactと状態管理を聞かれる意図
バックエンドの面接記事（バックエンドエンジニアの面接はDB設計とシステム設計のどちらを対策すべきか）でも書きましたが、技術面接は職種によって見ているものがまるで違います。バックエンドは、正規化やインデックス、サービス分割といった「データとシステムの構造」に対する設計判断が中心です。一方フロントエンドは、画面の状態をどこに置き、いつ再描画させ、ユーザーの体感をどう守るかという、もっと細かくて局所的な判断の積み重ねが見られます。
そのため、質問の形も変わります。「Reduxとは何ですか」「useMemoとuseCallbackの違いは」といった用語の定義は、最近の面接では入口として軽く聞かれる程度で、本題はその先です。私が面接官から聞くフィードバックでも、「定義は言えたが、自分のプロダクトに当てはめた話が出てこなかった」という指摘のほうが圧倒的に多く見られます。
面接官がこの質問で確かめたいのは、突き詰めると次の一点です。その人が、状況に合わせて道具を選び直せるかどうか。 「Reduxを使っています」は道具の名前であって、判断ではありません。同じプロダクトでも、チームが3人なのか30人なのか、データの大半がサーバー由来なのかで、正解は変わります。その前提を自分の言葉で説明できる人は、入社後に別のプロダクトでも同じように判断できるだろうと、面接官は読みます。
なお、ここで書く回答例は、特定の方の実際の相談をなぞったものではありません。私が面接官や企業の採用担当者から繰り返し聞く傾向を、答え方の型として組み直したものです。数字や技術要素は説明のための例なので、ご自身の実務の数字に置き換えて使ってください。
面接官が深掘りする順番を知っておく
技術面接の深掘りには、おおむね決まった順番があります。この順番を知っているだけで、質問の意図を取り違えにくくなります。
深掘りの典型的な流れ
- 何を使ったか（ライブラリ・構成の事実確認）
- なぜそれを選んだか（代替案との比較、当時の制約）
- どう確かめたか（計測、テスト、レビュー、本番での挙動）
- 今ならどうするか（振り返り、他の選択肢への理解）
使えるだけの答えは、1段目で終わっています。「Reduxを使いました」「useMemoを入れました」の事実確認までは言えるので、面接官が2段目に踏み込むと、そこで沈黙が生まれます。逆に、2段目と3段目まで先回りして話せる方は、面接官が聞く前に「当時はこういう制約があって、こう確認しました」と語れるので、深掘りの質問が減り、その分、別の話題に時間を使ってもらえます。
つまり準備の目的は、模範解答を覚えることではなく、自分の担当した変更について4段目まで言える状態にしておくことです。以降のセクションで、3つの定番質問を、この4段階に沿ってBefore/Afterで見ていきます。
状態管理：「Reduxを使っています」から「なぜそう分けたか」へ
最初の定番は、状態管理の質問です。「今のプロダクトでは状態管理をどうしていますか」という聞き方が多く、ここが一番、差がつきます。
Before（使えるだけの答え）：「Reduxを使っています。ActionとReducerで状態を管理して、非同期はRedux Thunkで処理しています。」
間違ってはいません。ただ、2段目の「なぜ」が空白です。面接官は「Contextでは足りなかったのですか」「そのstateは本当にグローバルである必要がありましたか」と続けますが、そこで「前からそうだったので」と答えてしまうと、既存の構成をなぞっただけの人という印象になります。
After（判断として語る答え）：「入社時点でReduxが入っていたので、まず何がどこに入っているかを棚卸ししました。すると、ストアの中身の大半が一覧や詳細のAPIレスポンスで、これはサーバー状態でした。そこでAPIレスポンスはTanStack Queryに寄せて、キャッシュと再取得を任せました。ストアに残ったのはログインユーザーやモーダルの開閉のような、本当にクライアント側だけの状態だったので、これは量が少ないためContextとuseReducerで足りると判断し、Reduxを段階的に外しました。」
Afterの核心は、技術名ではなく、状態を種類で分けたところにあります。サーバー由来のデータと、UIだけが持つ状態は、性質も寿命も違います。この切り分けを自分の言葉で語れる人は、「Reduxは古い」「Zustandが軽い」といった流行の話に引っ張られません。
この分け方は、Reactの公式ドキュメントにある考え方とも一致します。Reactの「stateの管理」では、stateを持ち上げるのか、Contextで渡すのか、useReducerを組み合わせるのかを、状況ごとに使い分ける前提で説明されています。また、冗長・重複したstateは不具合の元になりやすいという注意も、冒頭で書かれています。面接でこの観点を踏まえて話せると、実務の判断として聞こえます。
もう一つ大事なのは、選ばなかった選択肢にも理由を言うことです。「Zustandも検討しましたが、チームの全員がReduxの書き方に慣れていて、移行コストに見合う利点が当時はなかったので見送りました」のように、見送った理由が言える人は、一貫した基準を持っていると受け取られます。ライブラリの優劣を語るより、自分の判断基準を語るほうが、はるかに強い答えになります。
再レンダリング：「useMemoで最適化しました」から「測って原因を特定した」へ
次の定番が、再レンダリングとパフォーマンスの質問です。「再レンダリングを減らすために何かやったことはありますか」と聞かれて、多くの方が最初に口にするのがuseMemo、useCallback、React.memoです。
Before（使えるだけの答え）：「重い画面だったので、useMemoとuseCallbackで最適化しました。React.memoも使って、不要な再レンダリングを防ぎました。」
この答えが危ういのは、面接官の側から見ると「どこが遅かったのか」が一切わからないからです。さらに、React.memoやuseCallbackは入れたからといって必ず効くものではありません。Reactの公式ドキュメント（memo）にも、memoはパフォーマンス最適化としてのみ頼るべきもので、レンダリング中に作った関数やオブジェクトをpropsで渡していると毎回propsが変わり、まったく効かないこと、重いと感じる操作があればProfilerでどのコンポーネントに効くかを見てから足すことが書かれています。つまり、計測なしの「とりあえずmemo」は、公式の想定する進め方からも外れています。
After（判断として語る答え）：「検索フォームに1文字入力するたびに、横にある結果一覧まで再レンダリングされて、入力が引っかかる画面がありました。まずReact DevToolsのProfilerで確認すると、入力のstateを持っている親コンポーネントが更新されるたびに、子の一覧がすべて描画し直されていました。
memoで包むことも考えましたが、一覧に渡すpropsに毎回新しい関数やオブジェクトが入っていたため、そのままでは効きません。そこで、入力stateを入力欄のコンポーネント側に下げて、親が再描画されないようにしました。計測し直すと、入力時に一覧が描画されなくなったことが確認できました。」
Afterで評価されるのは、原因が更新範囲の設計だと突き止めている点です。memoやuseCallbackは対症療法で、根本は「stateをどこに置いているか」にあることが多い。公式ドキュメントも、まずchildrenで受け渡す、stateを下げるといった設計の見直しを先に勧めています。この順番で語れる方は、道具を足す前に構造を疑える人だと見てもらえます。
もう一つ、見落とされがちな論点があります。再レンダリングが増える原因として、useEffectの連鎖で状態を更新し合う書き方があります。「Effectは不要かもしれない」では、レンダリング中に計算できる値をEffectとstateで持つ必要はないこと、重い計算にはuseMemoを使えること、計算に1ms以上かかるかをconsole.timeで測ってから判断する目安が示されています。面接では「派生値をuseEffectで別stateに入れていたのを、レンダリング中の計算に直した」という話ができると、基礎を押さえた人として印象に残ります。
パフォーマンス改善：「改善しました」から「指標の前後比較」へ
3つ目は、もっと広い意味でのパフォーマンスの質問です。「パフォーマンス改善の経験を教えてください」は、フロントエンドの面接でほぼ必ず出ます。
Before（使えるだけの答え）：「画像を遅延読み込みにしたり、コード分割をしたりして、パフォーマンスを改善しました。かなり速くなりました。」
施策の名前は正しいのですが、「かなり速くなった」の根拠がありません。面接官は「どの指標で」「どの条件で」「どれくらい」と続けます。ここに答えられないと、施策を調べてやってみた人なのか、効果まで確認した人なのか、区別がつきません。
After（判断として語る答え）：「商品一覧ページで、スマホからの操作が重いという声が問い合わせに出ていました。まず、Core Web Vitalsの指標をフィールドデータで見ると、INPが悪化していました。web.devのINP解説では、INPは200ms以下が良好、判定は実ユーザーの75パーセンタイルで見るとされているので、その基準に照らして、改善前後を同じ条件で比べることにしました。
原因を調べると、絞り込みのたびに一覧全体を再計算していたので、計算を絞り込み結果だけに限定し、仮想化も検討しましたが、件数がそれほど多くなかったため、複雑さに見合わないと見送りました。結果として、INPが基準内に収まることを確認できました。」
ここでも評価されるのは、数字の大きさではありません。何を指標にし、どの基準で良し悪しを判断し、やらなかった施策の理由まで言えることです。数字が劇的でなくても構いません。「思ったほど改善しなかったが、原因はこちらだと分かった」という話も、計測していたからこそ言える内容なので、評価される傾向があります。
注意したいのは、数字を盛らないことです。面接官は、数字の出どころを必ず聞きます。ラボ計測（開発環境での測定）とフィールドデータ（実際のユーザーの計測）のどちらなのか、どのデバイスで測ったのか。曖昧なまま大きな数字を言うより、「手元の計測ではこうでした」と範囲を限定して話すほうが信頼されます。計測の経験が薄い方は、次のセクションの立て直し方も併せて読んでみてください。
比べてみると：使えるだけの答えと判断を語れる答え
ここまでの3問を、並べて整理します。
| 質問 | 使えるだけの答え | 判断を語れる答え |
|---|---|---|
| 状態管理 | 使っているライブラリ名と書き方 | 状態を種類で分けた理由、見送った選択肢の理由 |
| 再レンダリング | useMemo・memoを入れた | Profilerで原因を特定し、更新範囲の設計で直した |
| パフォーマンス | 施策名と「速くなった」 | 指標・基準・前後比較、やらなかった施策の理由 |
共通しているのは、Afterの答えがすべて「状況→判断→確認」の順になっていることです。技術名は文中に出てきますが、主役ではありません。主役は、そのときの制約と、自分が下した判断です。
私の実感では、同じ経歴の方でも、この順序で話せるかどうかで、面接官のフィードバックの質が変わります。「技術力は問題ないが、判断の根拠がもう少し聞きたかった」という見送りのコメントは、このパターンの典型です。
答えに詰まったときの立て直し方
準備をしても、深掘りで詰まる瞬間はあります。そのときの動き方で、評価が大きく変わることがあります。
最悪なのは、知らないことを知っているように繋いで話し続けることです。技術面接の面接官は、現場のエンジニアであることがほとんどで、ごまかしはすぐに見抜かれます。さらに、話が長くなるほど、後の質問で矛盾が出やすくなります。
立て直しの基本は、次の3つです。
詰まったときの3つの動き
- 分かる範囲と分からない範囲を切り分けて言う（「ここまでは確認しましたが、そこから先は見ていません」）
- 今の知識で、どう調べるか・どう仮説を立てるかを言葉にする
- 実務でやっていない場合は、そう認めたうえで、似た経験に橋をかける
たとえば、「INPの計測はやったことがありますか」と聞かれて経験がない場合は、「実際のINP計測は担当していません。ただ、Lighthouseでの計測は経験があるので、フィールドデータと手元の計測の違いを意識して取り組むと思います」のように答えます。できないことを認めたうえで、自分ならどう動くかを示せる人は、入社後に未知の問題にぶつかっても自走できると見てもらえます。
逆に、一度詰まってから「少し整理させてください」と10秒ほど考える時間を取るのは、まったく問題ありません。沈黙を恐れて早口で崩れるより、落ち着いて組み立て直した答えのほうが、評価は高くなります。
実務経験が浅い場合、React Compiler時代の準備
ここまでの話を読んで、「自分は状態管理を一から選んだ経験がない」と感じた方もいると思います。既存の構成に沿って機能を追加してきただけ、という方は多く、それ自体は普通のことです。
その場合は、選んでいない構成でも、理由を読み解いて語ることができます。「入社時点でこの構成でした。なぜこうなっているのかを先輩に聞いたところ、こういう経緯があって、今のチーム規模ならこの選択は妥当だと理解しました」と話せれば、判断の背景を理解しようとする姿勢が伝わります。ポートフォリオを通じて語る方法はフロントエンドエンジニアのポートフォリオに何を作るかで、jQuery中心の現場からの移行期間についてはjQuery中心のフロントエンドエンジニアがモダン環境へ移る年数で詳しく扱っています。
もう一つよく聞かれるのが、「React Compilerが入ればuseMemoもmemoも不要になるのでは」という論点です。公式ドキュメントでも、React Compilerが有効な環境では手動のmemoは基本的に不要になる、という趣旨の記載があります。ただ、面接で「だから理解は不要です」と答えるのは危険です。コンパイラが何を自動化しているのかを説明するには、そもそも再レンダリングがなぜ起きるか、どういうときに最適化が効かないかを理解している必要があるからです。
私は、この論点には次のように答えることを勧めています。「手動のmemoは減らせる方向だと理解していますが、更新範囲の設計やstateの置き場所は、コンパイラでは代わりに決められません。そこは引き続き自分で判断する部分だと思います」。道具が進化しても、設計判断は人間に残る、という立場は、面接官にも通りやすい答えです。
当日に向けた準備の進め方
最後に、準備の具体的な手順です。暗記ではなく、自分の経験の棚卸しとして進めます。
準備の手順
- 直近の担当変更を3つ選び、「何を・なぜ・どう確認し・今ならどうするか」の4段階をメモに書く
- 状態管理・再レンダリング・パフォーマンスのそれぞれについて、「選ばなかった選択肢と理由」を1つずつ用意する
- 数字を使う場合は、計測方法と条件をセットで書いておく
- ライブコーディングの課題に備え、簡単な一覧と検索フォームを、状態の置き場所を声に出しながら実装する練習をする
ライブコーディングやUI実装の課題があるときは、コードの完成度だけでなく、手を動かしながら判断を言葉にできるかも見られています。「ここは入力のstateをコンポーネント内に閉じたほうが、一覧が再描画されにくいので、こう書きます」と実況できる方は、完成度が多少低くても評価されやすい傾向があります。アルゴリズム系の出題への備えは、コーディングテストで落ちるパターンにまとめています。
よくある質問
用語を暗記しておけば、技術面接は通りませんか。 定義の確認は入口として聞かれますが、そこだけで合否が決まることは少ないというのが、私が面接官から聞く傾向です。評価を左右するのは、その用語を使って自分がどう判断したかを語れるかどうかです。
今のプロダクトが古い構成で、語れるような改善経験がありません。 大きな改善でなくても構いません。派生値をEffectからレンダリング中の計算に直した、入力stateを下げて再描画を減らした、といった小さな変更でも、Profilerで確かめた過程を話せれば十分に判断として伝わります。
数字で語れる実績がないときはどうすればよいですか。 数字を創作する必要はありません。「計測していないので体感ですが」と前置きしたうえで、何を確認して、何を根拠に直したのかを順に話せば、誠実さと思考の筋道は伝わります。
ReduxかZustandか、結局どちらを勧めますか。 どちらが正解ということはなく、チームの規模と状態の性質で変わります。面接では、どちらを選ぶかよりも、「サーバー状態とUI状態を分けて考えているか」を示すほうが評価につながります。
まとめ
フロントエンドの技術面接で「使えるだけ」と見られるか、「判断できる人」と見られるかの分かれ目は、知識の量ではなく、答えの順序にあります。ライブラリ名や施策名から入る答えは1段目で止まり、状況・判断・確認の順で語る答えは4段目まで届きます。
私がこの記事で一番伝えたかったのは、面接官が聞いているのは「何を使ったか」ではなく「なぜそうしたか、どう確かめたか」だということです。状態を種類で分けた理由、Profilerで突き止めた原因、指標で確かめた前後比較。この3つを自分の担当した変更で言えるようにしておけば、質問の形が変わっても対応できます。まずは直近の変更を1つ選んで、4段階のメモを書くところから始めてみてください。
