Preferred Networks LLMフロントエンド面接体験記：ストリーミング出力・リッチテキスト編集・AIインタラクションの完全評価
2年のフロントエンド経験でPreferred Networks LLMフロントエンド面接、React+TypeScript、ストリーミングSSE実装、リッチテキストエディタ、AIインタラクション設計、パフォーマンス最適化を網羅
背景紹介
まず私の状況から説明します。フロントエンド開発として2年の経験があり、主な技術スタックはReact + TypeScriptです。以前はAIスタートアップで会話型AIプロダクトのフロントエンドを担当していました。会社が大規模言語モデルアプリケーションを構築していたため、ストリーミング出力、SSE、リッチテキスト編集など、AIインタラクション関連の技術に精通していました。その後、Preferred NetworksのLLMフロントエンドチームが採用しているのを見て、このポジションが私の経験に非常に合っていると感じ、履歴書を提出しました。
正直なところ、面接前はかなり自信がありました。AIフロントエンドという方向性は比較的新しく、ストリーミング出力とAIインタラクションを実際に構築した人は多くないからです。しかし、面接を通じて、彼らがテストする深さが私の予想をはるかに超えていることが分かりました。これらの技術を使えるだけでなく、基盤となる原理とパフォーマンス最適化の詳細を理解している必要がありました。以下、面接プロセスを詳しく振り返ります。
面接プロセスの振り返り
一次面接：React + TypeScript + ストリーミングSSE
一次面接の面接官は非常に有能なフロントエンドエンジニアでした。まずプロジェクト経験について話し、その後技術面接が始まりました。最初にReactのレンダリングメカニズムについて聞かれ、Fiberアーキテクチャの原理を説明するよう求められました。Fiberはレンダリング作業を小さな単位に分割し、中断と再開が可能で、タイムスライスと優先度スケジューリングを実現していると説明しました。面接官はConcurrent ModeとSync Modeの違いについて追及しました。Concurrent Modeでは、Reactは低優先度の更新を中断して高優先度の更新（ユーザー入力など）を処理でき、長時間タスクがメインスレッドをブロックするのを防げると説明しました。
次にTypeScriptの高度な型について聞かれ、DeepPartial型を実装するよう求められました。再帰的条件型を書きました：type DeepPartial
次に重要な部分が来ました：ストリーミングSSEの実装。面接官はSSEクライアントをゼロから実装するよう求め、接続管理、再接続、メッセージ解析を含めるよう指示しました。EventSourceとfetchを使った2つのアプローチを書き、EventSourceの制限（GETのみ、カスタムヘッダー不可）と、fetchでSSEを実装する利点（POST対応、カスタムヘッダー、より柔軟なエラー処理）を説明しました。
面接官はfetchベースのSSEの具体的なコードについて追及しました。ReadableStreamでレスポンスボディを読み取り、TextDecoderでデコードし、\n\nでメッセージを分割し、eventとdataフィールドを解析するロジックを書きました。面接官はさらにバックプレッシャー処理について聞きました。消費速度が生産速度に追いつかない場合、ReadableStreamのcancelとpauseメカニズムを使用するか、アプリケーション層でバッファ管理を行えると説明しました。
また実践シナリオ問題もありました：ユーザーが同時に複数の会話リクエストを発行した場合、並行性とキャンセルをどう管理するか？AbortControllerでリクエストライフサイクルを管理し、各リクエストのコントローラーをMapに保存し、会話を切り替える際に前のリクエストをキャンセルすると答えました。一次面接は約55分で、非常に詳細でした。
二次面接：リッチテキスト編集 + AIインタラクション
二次面接はフロントエンドアーキテクトで、アーキテクチャ設計とインタラクション体験により注目していました。まずリッチテキストエディタの実装について聞かれ、ContentEditableとCanvasベースのアプローチを比較するよう求められました。ContentEditableはシンプルでアクセシビリティが良いがブラウザ互換性の問題が多い、Canvasはパフォーマンスが良くレンダリングの制御がしやすいが実装が複雑でアクセシビリティが低いと説明しました。面接官はProseMirrorとSlateのアーキテクチャ比較について追及しました。ProseMirrorはドキュメントモデルがより厳密（Schema制約）、Slateはより柔軟（プラグインアーキテクチャ）であり、AIシナリオでの適用性について説明しました。
次にAIインタラクションにおけるリッチテキストレンダリングが重点的に聞かれました。面接官は「LLMから返されるストリーミングMarkdownコンテンツを、どうやってリアルタイムでリッチテキストにレンダリングしますか？」と聞きました。これは以前やったことがあったので、いくつかの主要な課題を説明しました：ストリーミングMarkdown解析（インクリメンタル解析、不完全な構文処理）、リアルタイムレンダリング（新しいトークンが来るたびにDOMを更新）、コードハイライト（パフォーマンス問題を避けるための遅延ハイライト）、数式レンダリング（KaTeX/MathJaxの非同期読み込み）。
面接官はストリーミングMarkdown解析に特に興味を持ち、実装アプローチの詳細を説明するよう求めました。状態マシンを使ったインクリメンタル解析について説明し、解析状態スタックを維持し、新しいトークンが来るたびに状態を更新すると述べました。不完全な構文（閉じられていないコードブロックなど）については、構文が完全になるまでバッファしてレンダリングしないと説明しました。面接官はコードブロックのストリーミングハイライトについて追及しました。Shikiを使った遅延ハイライトが可能で、ストリーミング出力中はプレーンテキストでレンダリングし、コードブロックが閉じた後に構文ハイライトを適用することで、頻繁なリフローを回避できると説明しました。
次にAI会話のインタラクション設計について聞かれました。面接官は「AI会話プロダクトと従来のチャットプロダクトで、フロントエンド実装における最大の違いは何だと思いますか？」と聞きました。いくつかのコアの違いを挙げました：ストリーミング出力にはリアルタイムレンダリングが必要、AIの返信は長くなる可能性があるため仮想スクロールが必要、Markdown/コード/数式など複数のコンテンツタイプをサポート、タイプライター効果とカーソルアニメーションが必要、中断と再生成のサポートが必要。面接官は仮想スクロールの実装に興味を持ち、動的高さの仮想スクロールアプローチについて説明しました。
またAIインタラクションの状態管理についても聞かれ、会話状態のデータ構造を設計するよう求められました。ConversationStoreを設計し、messages配列（各メッセージにid、role、content、status、metadata）、現在の生成状態（idle/streaming/paused/error）、リクエストキューなどを含めました。面接官はメッセージの楽観的更新とエラーリカバリ戦略について追及しました。
二次面接は約65分で、最も深い面接でした。面接官はAIインタラクションの多くの詳細な問題にまで踏み込みました。
三次面接：プロジェクト深掘り + パフォーマンス最適化
三次面接はフロントエンドリーダーで、総合的な評価でした。まず以前に構築したAI会話プロダクトについて詳しく説明するよう求められ、技術選択、アーキテクチャ設計、コア機能の実装詳細まで話しました。面接官は多くの追及をしました。「なぜSlateではなくProseMirrorではないのか？」「ストリーミングレンダリングのパフォーマンスボトルネックはどこか？」「大規模ドキュメントのメモリ問題をどう処理するか？」などです。
次にパフォーマンス最適化が重点的に聞かれました。面接官はシナリオを提示しました：100件のメッセージがある会話ページで、各メッセージに長いテキスト、コードブロック、数式が含まれる可能性があり、ページがひどく遅い場合、どう最適化するか？いくつかのレイヤーからソリューションを説明しました：
レンダリングレイヤー：仮想スクロールで可視領域のメッセージのみレンダリング、コードハイライトの遅延処理、数式の遅延読み込み、画像の遅延読み込み。計算レイヤー：Markdown解析にWeb Workerを使用、構文ハイライトにWeb Workerを使用、大テキストのチャンク処理。メモリレイヤー：長いメッセージコンテンツのオンデマンド読み込み、不可視メッセージのDOM解放、画像とコードブロックのキャッシュ管理。ネットワークレイヤー：リクエストのバッチ化、プリロード、ストリーミング最適化。
面接官はWeb Workerの使用に非常に興味を持ち、Worker通信のオーバーヘッドと最適化について説明するよう求めました。Transferable Objectsを使ってシリアライゼーションのオーバーヘッドを回避、SharedArrayBufferでメモリを共有、メッセージをバッチ送信して通信頻度を減らすと説明しました。
またReactパフォーマンス最適化の具体的な実践についても聞かれ、memo、useMemo、useCallbackの使用シナリオと過剰最適化の落とし穴について説明しました。面接官は特にReact 19の改善がAIインタラクションに与える影響について聞き、use()フックとSuspenseの改善がストリーミングレンダリングにどう役立つかを説明しました。
最後にキャリアプランとAIフロントエンド方向への見解について話しました。三次面接は約55分でした。全体的に、面接官は皆非常にプロフェッショナルで、的を絞った質問が多く、一般的な質問ではありませんでした。
主要質問まとめ
1. React Fiberアーキテクチャの原理を説明、Concurrent ModeとSync Modeの違い
2. DeepPartialとDeepReadonly型を実装
3. inferを使ってPromiseの内部型を抽出
4. SSEクライアントをゼロから実装、接続管理と再接続を含む
5. fetchベースのSSE実装コードとバックプレッシャー処理
6. 複数の会話リクエストの並行管理とキャンセル
7. ContentEditableとCanvasベースのリッチテキストエディタアプローチを比較
8. ProseMirrorとSlateのアーキテクチャ比較
9. LLMからのストリーミングMarkdownコンテンツをリアルタイムでリッチテキストにレンダリングする方法は？
10. ストリーミングMarkdownのインクリメンタル解析アプローチ
11. コードブロックのストリーミング構文ハイライト
12. AI会話と従来のチャットのフロントエンド実装におけるコアの違い
13. 動的高さの仮想スクロールの実装
14. AI会話の状態管理データ構造を設計
15. 100件のメッセージがある会話ページのパフォーマンス最適化
16. Web Workerの使用と通信最適化
17. Reactパフォーマンス最適化の実践と過剰最適化の落とし穴
18. React 19がAIインタラクションに与える影響
心得とアドバイス
1. ストリーミング出力はAIフロントエンドのコア能力。SSE実装、ストリーミングMarkdown解析、リアルタイムレンダリングはAIフロントエンド面接の必須トピックです。原理から実装まで明確に説明できなければなりません。
2. リッチテキスト編集は差別化要因。すべてのAIフロントエンドポジションがリッチテキスト編集の経験を要求するわけではありませんが、ProseMirror/Slateのアーキテクチャと実装原理を明確に説明できれば大きなプラスになります。
3. パフォーマンス最適化には実戦経験が必要。AIインタラクションシナリオでのパフォーマンス問題は独特です（ストリーミングレンダリング、大規模ドキュメント、複数のコンテンツタイプ）。面接官は最適化テクニックの暗記よりも、実際の問題を解決する能力を重視します。
4. TypeScriptを深く学ぶ。AIフロントエンドは型安全性の要件が高く、高度な型や型推論が面接で頻繁に出題されます。
5. AIインタラクションの最新プラクティスに注目する。この方向は急速に変化しており、新しいインタラクションパターンと技術ソリューションが常に登場しています。面接で最新プラクティスの知識を示すことは競争力を高めます。
FAQ
Q：AIフロントエンドと通常のフロントエンドの最大の違いは何ですか？
A：コアの違いはストリーミング出力とAIインタラクションです。通常のフロントエンドのデータは確定的ですが、AIフロントエンドのデータはストリームで生成され、リアルタイムレンダリングと状態管理が必要です。また、AIインタラクションは複数のコンテンツタイプ（Markdown、コード、数式）のレンダリングを伴い、技術的な複雑さが高くなります。
Q：AIプロダクトの経験なしでAIフロントエンドの面接を受けられますか？
A：はい、ただしストリーミング出力とAIインタラクションの理解を示す必要があります。SSEストリーミングレンダリングとリアルタイムMarkdown解析を実装したAI会話デモを作成することをお勧めします。面接で披露できれば非常に説得力があります。
Q：Preferred Networks LLMフロントエンドチームの技術スタックは何ですか？
A：主にReact + TypeScript、状態管理にZustand、リッチテキスト編集にSlate、ビルドツールにViteを使用しています。AIインタラクションの経験はコアのプラス要素です。
Q：面接でライブコーディングは多いですか？
A：かなり多いです。一次面接と二次面接の両方にライブコーディングのセクションがあり、主にSSE実装、TypeScript型体操、状態管理設計です。面接前にライブコーディングの練習をお勧めします。
Q：AIフロントエンドのキャリアの見通しはどうですか？
A：非常に有望です。ほぼすべてのLLMプロダクトにフロントエンドが必要であり、AIインタラクションを本当に理解しているフロントエンドエンジニアは希少です。この方向は通常のフロントエンドよりも技術的障壁が高く、報酬もより競争力があります。