LLMアプリケーションエンジニアの採用面接方法（MLエンジニアではなく）
実際に採用しようとしている職種
「LLM エンジニア」あるいは「AI アプリケーションエンジニア」は 3 年前には存在しなかった職種が、今ではすべてのプロダクトチームに存在しています。これは機械学習エンジニアと同じ仕事ではありません。スキルの重複は約 30% 程度です。
機械学習エンジニアはモデルを訓練し、本番環境に配置します。LLM アプリケーションエンジニアは既に訓練済みのモデルを活用して、プロダクト機能に変える仕事をします。プロンプト設計、評価ハーネス、レトリーバル パイプライン、ツール呼び出しのスキャフォルディング、レイテンシーとコスト最適化、モデルが予想外の出力をしたときの優雅な失敗処理です。最も経験豊かなエンジニアは、退屈で大事な仕事の半分に時間を費やします。評価、可視化、ガードレールの設計です。プロンプトの巧妙さではなく。
ML エンジニアの面接キットでこれらの候補者を評価すると、出荷できない研究者を採用し、モデルを訓練したことのない実装者を落とします。汎用的なソフトウェア エンジニアのキットで評価すれば、AI 固有のスキルの表面全体を見逃します。
検査する価値のある 5 つの能力
この職種は検査可能な 5 つの領域に分解されます。ほとんどの面接ループは 3 時間の候補者の時間で 5 つのうち 4 つをカバーできます。
- プロンプト設計と反復。 構造化された出力を確実に生成するプロンプトを作成できるか、そしてそれが機能しないときに反復できるか？
- 評価の思考方法。 直感的なチェックで見落とすような回帰を検出する評価を設計できるか？
- 故障モード推論。 モデルがゴミ出力を返すとき、彼らは何が起きたのかのモデルを持っているか、そしてそれを直す計画を持っているか？
- システム統合。 モデルを実際のプロダクト サーフェスに配線できるか（レトリーバル、ツール呼び出し、ストリーミング、リトライ、キャッシング）、本番環境で崩壊しないか？
- コスト と レイテンシーの認識。 選択肢がどのくらいのコストがかかるかを知っているか？ 30 秒の遅延がユーザーの信頼にどのような影響を与えるかを知っているか？
認知能力と一般的なソフトウェア エンジニアリングはまだ重要です。これらを前提条件として扱い、LLM 固有のラウンドの焦点にしません。
機能する 4 段階のループ
これは、中堅からシニアレベルの LLM アプリケーション エンジニア職に推奨するループです。
ステージ 1: 非同期プロンプト エンジニアリング ワークサンプル（90 分）
候補者に小さなデータセットを提供します。30 から 50 の入出力ペアが、現実的なプロダクト タスクを表しています。例：カスタマー サポート メールから構造化フィールドを抽出する、サポート チケットを 7 つのカテゴリのいずれかに分類して信頼度スコアを付与する、顧客イベント ログから顧客向けメール サマリーを生成する。
彼らの課題：望ましい出力をデータセット全体で生成するプロンプト（またはプロンプトとコードの短いパイプライン）を作成し、それが依然として失敗している場所とその理由を 1 段落のメモを添えることです。
あらゆる AI ツールを許可します。これはポリシー B ラウンドです。正確なフレーミングについてはAI 使用ポリシー ガイドを参照してください。測定しているスキルは、援助なしでそれができるかどうかではなく、ツールを使ってツールで構築する方法です。
評価基準：
- データセット全体での出力の信頼性
- 故障モード分析の品質（段落はプロンプト自体より多くを物語ります）
- 彼らが評価に手を出したか、それとも単に結果を見ただけか
ステージ 2: ライブ評価設計（45 分）
ステージ 1 のプロンプトと、意図的に壊されたバージョンを見せます。回帰を検出する評価を設計するよう依頼します。口頭ではなく、実際のエディターで評価テスト コードを作成することで。
これがループ内で最も差別性のあるラウンドです。強い候補者は以下を行います：
- 完全一致、セマンティック類似性、ルーブリック採点の評価スタイルを区別し、タスクに最適なものを選択する
- 明確な肯定的なケース、エッジ ケース、対立的なケースを含める
- 評価スイートが CI でどのように実行されるか、失敗のしきい値は何か、および時間経過に伴ってそれを更新する方法について話す
弱い候補者は、ハッピーパスをテストする 3 つのアサーションを書いて完了と呼びます。
協調的なコード エディターでこれを実行して、候補者の思考プロセスをキーストロークごとに観察できます。一時停止はたくさんを物語ります。
ステージ 3: システム設計 - モデルで構築（60 分）
プロダクト ブリーフを彼らに渡します。「営業担当者が顧客の過去 90 日間のサポート チケットを貼り付けて、アカウント マネージャーと共有できる『チャーン を心配すべきか』の 1 段落の分析を取得できる機能のバックエンド設計。」
これらについてプローブします：
- プロンプトをどのように構造化するか（システム、ユーザー、ツール呼び出し？）
- コスト と レイテンシー プロファイルをどのように処理するか（同期？webhook による非同期？ストリーミング？）
- それをどのようにテストするか（ゴールデン例、ベースラインに対する A/B テスト、ループ内の人間？）
- 次のモデル アップグレード後、回帰をどのように検出するか
- モデルが特定のアカウント名を幻覚させた場合、どうするか
成果物はダイアグラムではなく、会話です。スコアリング ガイダンスについてはシステム設計ルーブリックを参照してください。
ステージ 4: ウォークスルー + 構造化行動面接（45 分）
2 つの半分に分かれた 1 つのラウンド。最初に 25 分間、フォローアップ質問テンプレートを使用してステージ 1 のワークサンプルをウォークスルーします。次に、非エンジニアリング ステークホルダー（プロダクト、デザイン、サポート）との協力に関する 20 分間の構造化行動質問。ほとんどの LLM 機能の故障モードはコードを書かない人によって検出されるからです。
実際のシグナルを生成する質問パターン
LLM アプリケーション エンジニアリング ラウンドに適用する価値のある 3 つのパターン。
「本番環境で壊れたプロンプトを見せてください。何を変更しましたか？」 これはキットの中で最良の質問です。強い候補者は、具体的な修正を伴う具体的なストーリーを持っています。弱い候補者は、抽象的なプロンプティングについて話します。
「この機能に使用できる最も安いモデルは何ですか？ なぜそれを使用していないのですか？」 コスト認識をテストし、彼らが暗黙のうちに選んだ品質とコストのトレードオフを明示させます。「常に最大のモデルに手を出す」という答えは、あらゆるシニアリティ レベルで懸念です。
「プロンプトが以前のバージョンより優れていることをどうやって知りますか？」 彼らが実際に評価を実行するか、単にバイブを信じるかをテストします。 LLM 機能を品質を測定せずに出荷した候補者の驚くべき割合があります。
機能しないもの
チームが試してから放棄した少数のアプローチ。
- LeetCode スタイルのアルゴリズム面接。 ほぼすべての LLM アプリケーション作業はアルゴリズム的ではありません。得られるシグナルは仕事と無関係です。より広い議論についてはLeetCode なしで開発者をスクリーニングするを参照してください。
- 「90 分でスクラッチからチャットボットを構築します。」 速度入力をテストしますが、エンジニアリングではありません。興味深い決定は、API 呼び出しの配線ではなく、評価設計と失敗処理に存在します。
- プロンプト雑学スクリーン。 「温度とは何ですか？」 語彙をテストしますが、判断ではありません。判断を直接テストしてください。
- トランスフォーマー内部に関する数学ホワイトボード。 モデル研究者を採用している場合に役立ちます。レトリーバル パイプラインと評価スイートで週を過ごす人にとっては無関係です。
AI を使用する職種の誠実さに関する質問
これは、すべてのチームが直面するラウンド トリップの質問です。候補者がワークサンプル中に Claude または ChatGPT を使用することが許可されている場合、モデルに仕事をさせるのを妨げるものは何ですか？
3 つのこと、組み合わせて：
- ステージ 4 ウォークスルー。彼ら自身のプロンプト、評価、またはシステム設計を擁護できない候補者は、実際には仕事をしませんでした。成果物が何を言っているかは関係ありません。
- ステージ 2 ライブ評価設計。このラウンドはプロクター監視付きエディターで実行され、45 分間、チャット ツールはありません。偽造するのは難しいです。
- ステージ 1 の提出物のコード一貫性分析。AI 生成コードは、候補者が偽装するために AI も使用したときでも、構造的な特徴があります。
ポイントは赤手掴みで彼らを捕まえることではありません。すべての候補者のスコアが、実際のエンジニアリング週間で、実際に使用するツールを使用して何ができるかを反映していることを確認することです。
次に何をするか
今四半期に LLM 採用を開始している場合、最も効果的な行動は、シニア バックエンド エンジニア ループの再利用を停止することです。ルーブリックの最初のバージョンで上記の 5 つの能力のうち 3 つを選択し、1 つのワークサンプルと 1 つの評価設計演習を作成し、キャリブレーションのために 2 人の内部エンジニアで実行します。
次に、5 人の外部候補者で実行します。候補者 3 までに、ループがそれ以前のものより鋭いかどうかはすでに知られています。職種は変わります。規律は変わりません。実際のシグナルを生成する方法を選択してから、シグナルが候補者のものであることを確認してください。