役職別チャレンジ準備
最初の面接ラウンドでは、ポートフォリオのウォークスルーを飛ばして、25～45分のタイムボックス付きライブ問題、または持ち帰り課題に進むケースが増えています。応募によってユーザーは面接の場に足を踏み入れます。これがその中で起こることです。
3つのモード：想定されるチャレンジの生成、ライブでのリハーサル、振り返り。通常は連続して行います。
開始前に
<workspace>/jobsearchos.config.mdを読む。modules.challenge_prepが false の場合は、その旨を一行で伝えて停止する。<workspace>/profile/identity.mdを読み、role_title、seniority、target_titlesを取得する。形式と採点はその役職に合わせて調整される。ツールがファイルを読めない場合は、ユーザーに貼り付けてもらう。- モデル：リサーチには
models.search、チャレンジと批評の作成にはmodels.deepを使用する。セッションが Opus 上の場合は、その旨を一行で伝えて続行する。検索は1回、最大2件まで。この企業の資料が<workspace>/jobs/に存在する場合（スラッグで一致、任意のプレフィックス）、検索は行わずにその資料を読む：リサーチは既に完了している。
モード1：チャレンジの生成
リサーチ、最大5分
資料が存在すればそれを使用する。それ以外の場合は1回検索する：製品が何をするか、誰が支払うか、その役割が担当する領域や範囲は何か。
彼らが実際に使う形式を選ぶ
デザイン系役割（プロダクトデザイン、UX、リサーチ、デザインシステム）のデフォルト：
| シグナル | 可能性の高い形式 |
|---|---|
| エンタープライズ、複雑なドメイン、エグゼクティブまたはデータプロダクト | アプリ批評、続いて1フローの再設計 |
| スケールアップ、複数のサーフェス、求人広告にシステムに関する文言 | 複数のサーフェスでずれたパターンを統合する |
| アーリーステージ、「初めての採用」、創業者が面接 | ゼロからイチへ：問題文からコアループを設計する |
| 求人広告にAI、エージェント、 またはコパイロットの記載あり | システムが時々間違えるサーフェスを設計する |
| 求人広告が曖昧またはジェネラリスト | プロダクト思考：1つの指標を選び、それを動かす3つの方法を提案する |
その他の役割の場合、同じロジックを role_title に適応させる：
| 役割ファミリー | 典型的な形式 |
|---|---|
| プロダクトマネジメント | プロダクトセンス（ユーザーのための製品改善または設計）、実行（指標が落ちた、診断する）、戦略（市場参入またはロードマップ優先順位付け）、持ち帰りPRD文書 |
| エンジニアリング | 企業のコアワークロードに対するシステム設計、現実的なスニペットのデバッグまたはコードレビュー、トレードオフノート付き持ち帰りサービス |
| マーケティングおよびグロース | 予算とチャネル制約付きキャンペーンブリーフ、データ抽出からのファネル診断、ローンチのためのポジショニング |
| データおよびアナリティクス | ステークホルダーの質問付きの不完全なデータセット分析、指標定義、実験設計 |
| セールス、カスタマーサクセス、オペレーション | 模擬ディスカバリーコール、アカウントプラン、プロセス再設計ケース |
| その他 | 求人広告の動詞を使用する：彼らがあなたを雇ってやらせたいことが、テストされることである |
最も可能性が高いと判断したものをユーザーに伝え、次点を一行で述べて、不意を突かれないようにする。ライブ形式か持ち帰り課題かを明記する（リハーサルが異なるため、モード2参照）。
面接官が言うようにブリーフを書く
意図的に不完全に記述する。実際のブリーフは仕様書ではなく、制約が付いた2、3文である。明確なブリーフはテスト対象を取り除いてしまう。
**[企業名] · 想定形式: [名称]** · 次点: [名称]
*彼らが口に出して言うであろうブリーフ*
"[2、3文。ユーザーまたはステークホルダー、状況、制約。成功基準やスコープはなし。]"
*タイムボックス:* [25 / 45] 分、または [持ち帰り：時間と成果物]
*採点基準:* [3つのこと、それぞれ一行]
*落とし穴:* [このブリーフが招く具体的な誤った方向]
そこで停止する。解いてはいけない。ヒントを与えてはいけない。
モード2：リハーサル
ライブ形式：ユーザーが口頭または文章で回答する。あなたは面接官を演じる。現実的な制約変更（「データはリアルタイムではなく週次で更新されます」）で一度割り込み、質問があれば簡潔にキャラクターのまま回答し、時間を管理する。試行中にコーチングしてはいけない。
持ち帰り形式：ユーザーが成果物またはアウトラインを共有する。あなたは採用パネルがそれをざっと見るようにレビューする：5分で、決定、トレードオフ、および注意点を探す。
モード3：振り返り
ユーザーがやったことを説明する、ノートを貼り付ける、またはスクリーンショットを共有する。以下の順序で採点する。これら6つはすべての役割で共通。最初の項目の表現は柔軟に変える。
- 解決する前に問題を再定義する。 シニアレベルでの最も一般的な失敗は、与えられたブリーフをそのまま解くことである。優秀な候補者は最初の数分を使って、ユーザーまたはステークホルダー、関係する決定、成功の定義を明確にし、仮定を口に出して修正可能にする。
- 意図的に範囲を絞る。 何をやらないか、そしてその理由を早い段階で明示する。タイムボックス付きチャレンジでのスコープクリープは判断力の欠如と見なされる。
- トレードオフを示す。 何を試し、何を却下し、その代償は何だったか。コストのない決定は決定として認識されない。
- 考えながらも読みやすい状態を保つ。 考えを口に出し、大まかにスケッチし、確認する。4分間の沈黙は部屋の興味を失わせる。
- 何かを着地させる。 3つの選択肢をそのまま返すのではなく、次のステップを伴う具体的な方向性を1つ提示する。選択肢を返すことは、決断を避けていると見なされる。
- 注意点を添える。 「これはデータが毎日更新されることを前提としていますが、確認します。」しばしば最も強力な動きであり、ペーパーよりもライブで効果的である。
profile/voice.md またはピラーファイルにユーザー自身の習慣（例えば特徴的なトレードオフのストーリー）が示されている場合、どのピラーストーリーがトレードオフのポイントに適合するかを述べる。作り出してはいけない。
批評の提示
直接的で、具体的で、サンドイッチ法は使わない。ユーザーが必要とするのは、結果を変えたであろう2つのことである。
**採点**
再定義: [強い / 薄い / できていない] · [一行]
範囲絞り込み: [...]
トレードオフ: [...]
読みやすさ: [...]
着地: [...]
注意点: [...]
**結果を変えたであろう2つのこと**
1. [具体的に、言うべきだった文を含めて]
2. [同様]
**覚えておく一言:** [実際に言った良かった点、引用して返す]
再利用可能なオープナー
これらはコストがかからず、最初の3分を稼ぐ。ユーザーの口調に合わせて表現を調整する。
- 「始める前に、あなたが何を求めていると思うかを言い換えさせてください。間違っていたら止めてください。」
- 「ここでのユーザーは誰で、彼らはどんな決定を下そうとしていますか？」
- 「[X]は除外して[Y]に集中します。理由は[理由]です。もしそれが間違った半分なら教えてください。」
- 「[こと]を仮定しています。それが正しくなければ、これは変わります。」
- 「ここで削るものを挙げます。そしてその代償を説明します。」
- 「ここで一旦止めます。次に[X]が必要で、[方法]でそれを得ます。」
記録場所
<workspace>/jobs/ にあるその企業の資料に ## Challenge prep セクションを追加する（構造は <workspace>/jobs/_TEMPLATE.md 参照）：ブリーフ、試行内容を1段落で、2つの修正点。フロントマターに interview_prep_challenge: completed を設定する。資料が存在しない場合は、テンプレートから jobs/1-<companyslug>.md を作成し、そのセクションのみを記述する（プレフィックス 1-、このスキルに到達することは screening を意味するため）。既存のファイルの名前は決して変更しない。それは /log-application の役割である。