engineering-hiring-rubric について
engineering-hiring-rubricは、職種とレベルに応じたエンジニア採用基準と面接スコアカードを作成するスキルです。行動評価の基準、技術問題の評価方法、面接構成、振り返りの指針をまとめ、一貫した候補者評価を支えます。
主な機能
- 01職種とレベル別の期待値
- 02面接構成と評価項目の対応表
- 03評価基準付きの技術面接問題
- 04行動評価のシグナルと振り返り用メモ
活用シーン
- 01特定のエンジニア職向けスコアカード作成
- 02面接ラウンドと評価項目の計画
- 03面接官間の候補者評価基準の調整
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ mohitagw15856/ pm-claude-skills --skill engineering-hiring-rubricインストール後、Claude Code で/engineering-hiring-rubricを入力して読み込まれたか確認します。
詳細
エンジニア採用ルーブリック
特定の職種とレベルのソフトウェアエンジニアを評価するための、完全な採用ルーブリックと面接スコアカードを作成します。面接官同士で事前に評価を比較したことがなくても、同じ候補者を1レベル以内の差で評価できるほど具体的な内容にしてください。そのためには、明確な行動指標(各コンピテンシーについて、「強く採用」と「採用」がそれぞれどのような状態か)、評価基準を文書化した調整済みの技術質問、直近の印象によるバイアスではなくシグナルを明らかにするための、構成化されたデブリーフ形式が必要です。また、面接官がよくある評価バイアスに気づき、それに対処できるよう、キャリブレーションの注記も含めてください。
必須入力
まだ提示されていない場合は、以下の情報を確認してください。
- 職種 — バックエンド、フロントエンド、フルスタック、SRE/プラットフォーム、データ、ML、またはモバイルエンジニア
- レベル — ジュニア(L3/IC2)、ミッド(L4/IC3)、シニア(L5/IC4)、またはスタッフ(L6/IC5)。異なるレベル名称を使用している会社の場合は、その名称を確認してください
- チームの背景 — チームが開発しているもの、チームの規模、採用者が初年度に取り組む課題
- 技術スタック — 技術質問で使用する主要な言語とフレームワーク。スタックを明示してください
- 面接形式 — 実施する面接(電話スクリーニング、コーディング、システム設計、行動面接、持ち帰り課題)。指定がない場合は、推奨形式を提示してください
出力形式
エンジニア採用ルーブリック:[職種] — [レベル]
職種: [例:シニアバックエンドエンジニア] 相当するレベル: [例:L5/IC4/シニア] チーム: [チーム名と、開発しているものを一文で説明] 技術スタック: [言語とフレームワーク] 面接プロセス: [各面接を順番に列挙]
1. 職務の定義とレベルへの期待
この職務の内容
[担当するシステム、解決する課題、協業相手を含む、業務範囲を説明する2~3文。提示されたチームの背景に合わせて具体的に記述してください。]
レベルの基準
このレベルで「採用」を推奨するための最低基準を定義してください。理想的な候補者像ではなく、最低ラインです。
| 項目 | [レベル] の最低基準 | 1レベル下(不採用) | 1レベル上(期待以上) |
|---|---|---|---|
| 技術的な担当範囲 | [例:「最小限のガイダンスで、サービスまたは主要な機能領域を端から端まで担当する」] | [例:「明確に定義されたタスクを完了する。範囲や進め方についてガイダンスが必要」] | [例:「チーム横断の技術的な取り組みを主導し、技術的な方向性を定める」] |
| 問題解決 | [例:「曖昧な問題を、具体的なサブ問題に自力で分解する」] | [例:「定義された問題はうまく解決するが、曖昧さに苦労する」] | [例:「他の人が見落とす問題を特定し、組織レベルの技術課題を構造化する」] |
| コード品質 | [例:「本番環境に対応できるコードを書く。エッジケースを予測し、大幅な手戻りなしにレビューできる」] | [例:「動作するコードを書くが、レビューで大幅な指摘が必要」] | [例:「コード品質の基準を定め、他の人にも採用される再利用可能な抽象化を設計する」] |
| コミュニケーション | [例:「技術的な判断を、同僚や関係者に明確に伝える」] | [例:「直属のチームとは円滑にやり取りできるが、チーム横断や関係者とのコミュニケーションに苦労する」] | [例:「チーム間の技術的な合意形成を主導し、他の人が参照する文書を作成する」] |
| オーナーシップ | [例:「担当業務を本番環境へのリリースまでやり遂げ、リリース後も監視し、問題に先回りして対応する」] | [例:「割り当てられた業務を完了し、問題を報告するが、解決まで主導しない」] | [例:「チーム横断で成果に責任を持ち、自分の担当業務の範囲を超えてチームのプロセスやシステムを改善する」] |
2. 面接プロセスの構成
| ラウンド | 形式 | 所要時間 | 面接官 | 評価する能力 |
|---|---|---|---|---|
| 電話面接 | ビデオ通話、技術的な質問 | 45 min | [採用マネージャーまたはシニアエンジニア] | 問題解決能力、コミュニケーション能力、基本的な技術力 |
| コーディング面接 1 | ライブコーディング — [platform] | 60 min | [エンジニア] | コーディング、データ構造、コード品質 |
| コーディング面接 2 | ライブコーディング — [platform] | 60 min | [エンジニア] | アルゴリズム、デバッグ、コード品質 |
| システム設計 | ホワイトボード/共有ドキュメント | 60 min | [シニア/スタッフエンジニア] | システム設計、スケーラビリティ、技術的なコミュニケーション |
| 行動面接 | 構造化面接 | 45 min | [採用マネージャー] | オーナーシップ、協調性、成長志向 |
| [任意] 持ち帰り課題 | 非同期プロジェクト | [X hours] | [レビュアー] | コード品質、徹底性、実際の問題解決能力 |
面接評価項目マトリクス: 各能力項目は、少なくとも 2 人の独立した面接官が評価する必要があります。
| 能力 | 電話面接 | コーディング 1 | コーディング 2 | システム設計 | 行動面接 |
|---|---|---|---|---|---|
| コーディング | ○ | ● | ● | ○ | |
| システム設計 | ○ | ● | |||
| 問題解決能力 | ● | ● | ● | ● | |
| コード品質 | ● | ● | |||
| コミュニケーション能力 | ● | ● | ● | ● | ● |
| オーナーシップ | ○ | ○ | ● | ||
| デバッグ | ● | ● |
● = 主な評価指標 ○ = 補助的な評価指標
3. コーディング面接ガイド
質問の選定
各コーディング面接では、問題を 1~2 問選びます。問題は 30~40 分で解けるものとし、残りの時間を議論や追加質問に充てます。複数の解法レベルがある問題を優先し、候補者がどこまで考えを深められるかを確認できるようにします。
問題テンプレート
問題: [タイトル]
プロンプト(候補者に読み上げる):
[問題文 — 具体的に記述してください。制約(入力サイズ、値の範囲)を含めてください。問題解決力ではなく問題読解力を試すような曖昧さは避けてください。]
例:
取引日の各分における株価を表す整数のリストが与えられたとき、ちょうど1回の購入と1回の売却で得られる最大の利益を返してください。購入する前に売却することはできません。
優秀な候補者が尋ねる確認質問:
- [例:「リストは空でもよいですか?」/「すべての値は正ですか?」/「利益は負になり得ますか — つまり、利益が得られない場合は0を返すべきですか?」]
解答のティア:
| ティア | アプローチ | 時間計算量 | 空間計算量 | シグナル |
|---|---|---|---|---|
| ベースライン | [ブルートフォース — O(n²) のネストされたループ] | O(n²) | O(1) | 問題を解ける。正しさを理解している |
| 期待値 | [シングルパスで、これまでに見た最小価格を追跡] | O(n) | O(1) | 強い問題解決者。トレードオフを説明できる |
| 強み | [プロンプトなしでk回の取引に一般化、またはクールダウン変種に拡張] | O(n) | O(1) | スタッフレベルの一般化思考 |
追加質問:
- [例:「最大k回の取引ができるとしたらどうしますか?」]
- [例:「この関数をどのようにテストしますか?テストケースを3つ書いてください。」]
- [例:「コードレビューで説明するつもりで、コードを順を追って説明してください。」]
この問題の評価ルーブリック:
| シグナル | 強い採用 | 採用 | 不採用 |
|---|---|---|---|
| 問題の理解 | すぐに1〜2個の確認質問をする。コーディング前にエッジケースを特定する | 1回のプロンプトで問題を理解する。1〜2個のエッジケースを見落とす | 問題を誤解する、または繰り返しの確認を必要とする |
| 解答の質 | O(n) の解答。クリーンなコード。すべてのエッジケースを処理する | ヒントありで O(n)。コードは読めるが軽微な問題がある | ヒントありで O(n²)、または重大な問題を抱えた正しい解答 |
| コードの質 | 適切に命名された変数。論理的な構造。コードレビューを通過する | 機能的だが冗長、または命名が一貫していない | 追いにくい。大幅なレビューフィードバックが必要 |
| コミュニケーション | 思考を終始言語化する。計算量を説明する。自己修正する | 求められれば解答を説明する。追加質問にうまく答える | コーディング中は無言。自分のアプローチを説明できない |
| 追加質問 | 自信を持って解答を拡張する。さらなる改善点を特定する | 適度なプロンプトで追加質問に対応する | 拡張やトレードオフの説明ができない |
4. システム設計面接ガイド
[レベル]に適した設計スコープ
[レベル]では、候補者に以下を期待します:
- [例: シニア:「容量見積もり、コンポーネントの内訳、障害モードの議論を含む完全なシステムを設計する」]
- [例: ミドル:「システムの中核コンポーネントを設計する。スケーラビリティと障害処理についてプロンプトが必要な場合がある」]
- [例: ジュニア:「シンプルなクライアントサーバーシステムを設計する。完全な分散システムの知識よりも思考の明確さに重点を置く」]
設計に関する質問の例
質問:「[URL 短縮サービス/レートリミッター/通知サービス/配車マッチングシステムのうち、チームの領域に関連するものを選んで]を設計してください。」
評価項目:
| 項目 | 評価内容 | 強い採用判断 | 採用 | 不採用 |
|---|---|---|---|---|
| 要件の明確化 | 設計を始める前に候補者が質問するか | 何も描き始める前に、対象範囲、規模、SLA、主要なユースケースを確認する | いくつか質問するが、規模やSLAを見落とす場合がある | 要件を明確にしないまま、すぐに設計を始める |
| 高レベル設計 | 主要なコンポーネントを説明できるか | 選択理由を示した明確なコンポーネント分解を行い、データフローも説明する | 妥当な分解を行うが、複雑にしすぎたり単純化しすぎたりする場合がある | 主要なコンポーネントが欠けている、またはデータフローを説明できない |
| データモデル | システムのスキーマやデータ構造を設計できるか | 中核となるエンティティをモデル化し、正規化と非正規化のトレードオフについて議論する | 妥当なスキーマを設計するが、インデックスやパーティショニングの必要性を見落とす場合がある | データをモデル化できない、または明らかに不適切なスキーマを作成する |
| スケーラビリティ | ボトルネックを特定し、対処できるか | ボトルネックを事前に特定し、必要に応じて水平スケーリング、キャッシュ、シャーディングを提案する | 質問されればスケーリングについて議論し、妥当な解決策を提示する | ボトルネックを特定できない、または規模に合わない解決策を提案する |
| 障害への対応 | 障害発生時に何が起きるかを考えているか | 単一障害点、リトライロジック、冪等性など、障害モードについて事前に議論する | 質問されれば障害について議論し、いくつかの障害モードを特定する | 障害について考えず、正常系のみを前提とする |
| コミュニケーション | 設計を明確に説明できるか | 実際の企業でエンジニアチームとのミーティングを主導できる | おおむね理解できるが、説明にいくつか不明瞭な点がある | 理解しにくく、面接官が設計を把握できない |
設計を掘り下げる質問
候補者が設計を説明した後、理解の深さを確かめるために次の質問を使います。
- 「ピーク時に書き込みリクエストが毎秒 10,000 件届いた場合に何が起きるか、順を追って説明してください。」
- 「プライマリデータベースが停止しました。システムには何が起きますか?」
- 「X QPS と見積もりましたが、100 倍の負荷に対応する必要がある場合、設計をどう変更しますか?」
- 「このシステムが高負荷で最初に破綻する箇所はどこですか?」
- 「本番環境でこれをどのように監視しますか?オンコール対応用のランブックはどのようなものになりますか?」
5. 行動面接の質問集
すべての質問をコンピテンシーに対応付けます。行動面接の各ラウンドでは、STAR 形式(状況、課題、行動、結果)で 4~6 問を尋ねます。誘導的な質問は避けてください。
コンピテンシー:オーナーシップと遂行力
-
「設計から本番環境の監視まで、一貫して担当した経験について教えてください。リリース後に問題が起きた際、どのように対応しましたか?」
- 強い評価につながる兆候: 事前の監視設定、自ら発見した具体的なインシデント、およびその後に変更したことを説明する
- 弱い評価につながる兆候: コードを書いて引き継いだことだけを説明し、本番環境での挙動について触れない
-
「大幅に遅延した、または失敗したプロジェクトについて説明してください。あなたの役割は何でしたか?何に責任を持ちましたか?」
- 強い評価につながる兆候: 失敗に対する自身の貢献を率直に認め、仕事の進め方を具体的にどう変えたかを説明する
- 弱い評価につながる兆候: 遅延の原因をすべて外部要因のせいにし、自分の行動を振り返らない
コンピテンシー:技術的判断力
-
「重要な技術的決定を下した経験について教えてください。どのような選択肢を検討し、どのように決定しましたか?」
- 強いシグナル: 代替案を挙げ、明確なトレードオフを説明する。誰に相談したかを説明し、今でも同じ決定をするか振り返る
- 弱いシグナル: 意思決定のプロセスを説明せずに「Xが正しい答えだと分かっていました」と言う
-
「技術的な方針に異議を唱えなければならなかった経験について教えてください。相手はマネジメント層でも同僚でも構いません。何が起きましたか?」
- 強いシグナル: 根拠に基づく異議申し立てを行い、建設的に伝える。議論に負けたとしても、決定後はその方針に沿って行動する
- 弱いシグナル: 異議を唱えたことがない、または根拠なく感情的に反発する
コンピテンシー:コラボレーションとコミュニケーション
-
「複雑な技術的概念を、技術に詳しくないステークホルダーに説明しなければならなかった経験について教えてください。どのように説明しましたか?」
- 強いシグナル: たとえや簡略化したモデルを使い、相手が理解したかを確認し、聞き手に合わせて説明を調整する
- 弱いシグナル: 「技術的に説明して、私を信頼するよう伝えました」
-
「同僚とアプローチについて強く意見が対立した状況について教えてください。どのように解決しましたか?」
- 強いシグナル: 第三者の意見やデータを求め、正しい結果を出すことを重視し、自分が正しいと証明することにはこだわらず、関係を維持する
- 弱いシグナル: すぐにエスカレーションする、または十分に話し合わずに譲歩する
コンピテンシー:成長と学習
-
「過去2年間に犯した重大な技術的ミスについて教えてください。そこから何を学びましたか?」
- 強いシグナル: 具体的なミスを挙げ、明確な原因分析を行い、その後の具体的な行動の変化を説明する
- 弱いシグナル: 具体的なミスを挙げられない、または弱みを見せないために軽微な問題を説明する
-
「[関連する技術分野]の最新動向をどのように把握していますか?最近学んで実際に活用したことを、具体例とともに教えてください」
- 強いシグナル: 情報源を挙げ、具体的なプロジェクトで学びを活用し、具体的な成果を出している
- 弱いシグナル: 具体例なしに「ブログを読んでいます」と言う。学びを活用した例がない
6. 面接の総合評価シート
面接ラウンドごとに評価シートを1枚作成してください。デブリーフの前に、すべての評価シートを集めてください。
INTERVIEW SCORECARD
===================
Candidate: ______________________
Interviewer: ______________________
Round: ______________________
Date: ______________________
Interview format: ______________________
COMPETENCY RATINGS
Rate each dimension independently. Do not average.
Scale: 1 = Strong No Hire | 2 = No Hire | 3 = Hire | 4 = Strong Hire
1 2 3 4 Notes
Coding / Technical skill [ ] [ ] [ ] [ ] ___________________________
Problem solving [ ] [ ] [ ] [ ] ___________________________
System design [ ] [ ] [ ] [ ] ___________________________
Code quality [ ] [ ] [ ] [ ] ___________________________
Debugging [ ] [ ] [ ] [ ] ___________________________
Communication [ ] [ ] [ ] [ ] ___________________________
Ownership [ ] [ ] [ ] [ ] ___________________________
Collaboration [ ] [ ] [ ] [ ] ___________________________
SPECIFIC EVIDENCE
What did the candidate do or say that drove your rating?
(Required — write observable behaviors, not impressions)
Strongest signal (positive):
___________________________________________________________________________
Strongest concern or gap:
___________________________________________________________________________
OVERALL RECOMMENDATION
[ ] Strong Hire [ ] Hire [ ] No Hire [ ] Strong No Hire
OVERALL RECOMMENDATION RATIONALE
(Required — 3–5 sentences minimum. State your recommendation, the evidence
that supports it, and the specific gap or risk if not a Strong Hire)
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Level signal: This candidate demonstrated [ L_ / L_ ] level behaviors.
SHOULD INTERVIEWERS DISCUSS BEFORE DEBRIEF?
[ ] No — I have a clear independent signal
[ ] Yes — I need context on [specific area] to complete my assessment
7. 採用推薦の枠組み
| 推薦 | 意味 | 使用する場面 |
|---|---|---|
| 強く採用 | 候補者がレベル基準を上回り、チームで高い成果を上げると確信できる | 3つ以上のコンピテンシーで基準を上回る証拠があり、重大な懸念がない |
| 採用 | 候補者がレベル基準を満たし、良好なパフォーマンスを発揮すると確信できる | 必須コンピテンシーをすべて満たしており、今後伸ばすべき領域が1つある場合もある |
| 不採用 | レベル基準を満たしていない | 1つ以上の必須コンピテンシーが基準に達していない、または不足を短期間で補うのが難しい |
| 強く不採用 | 明らかに適合していない。基準を大幅に下回る、または特定の不採用要因となるシグナルがある | 複数のコンピテンシーに重大な不足がある、または価値観・行動面に懸念がある |
[Role]の[Level]での必須採用コンピテンシー: [「不採用」と評価されたコンピテンシーが1つでもあれば、他の領域のパフォーマンスにかかわらず、総合評価も「不採用」とする3~4つのコンピテンシーを列挙します。例:「シニアバックエンドエンジニアでは、コーディングとシステム設計が必須採用コンピテンシーです。行動面で優れたパフォーマンスを示しても、コーディングが「不採用」の評価であることは補えません。」]
デブリーフのルール: 「強く採用」は、次の条件を満たす場合に限り、1つの「不採用」を覆すことができます。(a)「不採用」の評価が必須採用コンピテンシーに対するものではないこと。(b)「強く採用」と評価した面接官が、その懸念が不採用の決定要因にならない理由を説明できること。「強く不採用」は覆せません。採用マネージャーにエスカレーションしてください。
8. デブリーフのアジェンダ
評価シートの内容を口頭で共有する前に、デブリーフを行ってください。全員がまず評価シートを記入して提出します。
DEBRIEF AGENDA — [Candidate Name]
Duration: 45 minutes
Facilitator: [Hiring Manager]
0:00 – 0:05 SCORECARD REVIEW
Each interviewer states their overall recommendation only (no rationale yet).
Facilitator notes alignment and disagreements on whiteboard/doc.
0:05 – 0:15 EVIDENCE ROUND
Go around the table. Each interviewer shares:
- Their strongest positive signal (observable behavior, not impression)
- Their biggest concern (observable behavior, not impression)
No discussion yet — just evidence gathering.
0:15 – 0:30 DISCUSS DISAGREEMENTS
Address only the competency dimensions where interviewers disagree.
Anchor discussion on: "What did you observe?" not "What do you think?"
If interviewers assessed different competencies, disagreement may reflect
insufficient signal — note this.
0:30 – 0:40 DECISION
Reach a decision on overall recommendation.
If consensus: state the recommendation and rationale.
If not consensus: hiring manager makes the call and states why.
0:40 – 0:45 PROCESS NOTES
- Were any questions unclear or hard to compare across candidates?
- Any bias signals observed during the debrief? (see Section 9)
- Feedback to improve the process for next time.
9. 評価調整とバイアス低減に関する注意事項
この職種の面接を初めて担当する前に、すべての面接官に以下を説明してください。
| バイアス | 現れ方 | 対策 |
|---|---|---|
| ハロー効果 | 第1ラウンドでの優れたパフォーマンスが、第2ラウンドの評価に影響します | 他の評価を読む前に評価シートを提出し、各コンピテンシーを個別に評価します |
| 類似性バイアス | 「好感を持てる」が「自分と考え方が似ている」と結びつきます | すべての評価に観察可能な根拠を求め、次の点を確認します。「これは候補者の能力に関する兆候か、それとも自分との類似性に関する兆候か」 |
| 直近性バイアス | 最後の印象が総合評価を左右します | 面接中にメモを取り、終了後すぐに根拠を書き留めます。振り返りでは記憶ではなく、書面の根拠を使用します |
| 期待のアンカリング | 最初の面接官の意見が、他の全員の評価の基準になります | 振り返りの前に面接官同士で口頭で話し合わないでください。振り返りの開始前に評価シートを提出します |
| 「カルチャーフィット」を隠れみのにする | 具体的な行動の根拠なしに「カルチャーフィットしない」と判断します | この評価シートでは「カルチャーフィット」は有効な評価項目ではありません。根拠を示したうえで、コラボレーションとコミュニケーションを評価してください |
| 資格バイアス | 学位や以前の勤務先が評価に過度な影響を与えます | 面接前の説明資料に学歴を記載しないでください。実証された行動に注目します |
| 自信 ≠ 能力 | 正解かどうかにかかわらず、表現力の高い候補者が高く評価されます | 話し方ではなく、回答の質を評価してください。各質問に対して、記述された評価基準を使用します |
品質チェック
- レベル基準表では、そのレベルにおける具体的な最低基準を定義しています。目指すべき特性ではなく、1つ下と1つ上のレベルとの比較も含めます
- すべての行動に関する質問に、Strong Hire と Weak/No Hire のシグナルを明示的に記載しています。質問文だけでは不十分です
- コーディング問題には、時間計算量と空間計算量を含む解答の段階と、行動の基準を示す質問ごとの評価基準があります
- システム設計の評価基準では、少なくとも要件の明確化、コンポーネント設計、データモデル、スケーラビリティ、障害対応を評価します
- 評価シートには、印象ではなく、観察可能な行動を記入する項目(「候補者は何をしたか、または何を言ったか」)があります
- その職種とレベルで必須のコンピテンシーを明示しています
- 振り返りのアジェンダでは、アンカリングを防ぐため、口頭での話し合いより前に評価シートを提出することを義務付けています
アンチパターン
- コンピテンシーごとに行動基準を1つだけ記載しないでください。Strong Hire と No Hire のそれぞれに該当する状態を定義する必要があります。そうしなければ、面接官は評価基準を調整できません
- 独立した評価項目として「カルチャーフィット」を設けないでください。類似性バイアスを覆い隠すため、すべての判断には観察可能な行動の根拠を使用する必要があります
- 振り返りの前に、面接官が評価シートのフィードバックを共有できるようにしないでください。振り返り前の口頭での話し合いは、最初に示された意見を全員の基準にしてしまいます
- すべてのエンジニアリング職に同じ必須コンピテンシーの一覧を設定しないでください。シニアバックエンドエンジニアとフロントエンドエンジニアでは、譲れないコンピテンシーが異なります
- 評価調整時のバイアスに関する注意事項を省略しないでください。ハロー効果、直近性バイアス、資格バイアスについて説明を受けていない面接官は、すべての面接で同じバイアスを再現してしまいます
使用例となるフレーズ
- 「面接の評価基準を作成してください。」
- 「採用プロセスを設計してください。」
- 「技術面接の評価シートを作成してください。」