このページの概要
スキル面接の手法について、overflow社の評価基準や、面接での質問例をご紹介します。
目次
関連記事
スキル面接とは?
-
スキル面接では候補者の職務遂行能力、技術力などをインタビューして評価します。
-
過去の意思決定や行動をもとに評価する部分は、これまでの経験を振りかえるエピソードインタビューを用います。
- どのような状況で、どのようなことをしたのか、詳細を具体的に聞き取ってください。
-
新しい課題を与えられたときの思考特性や、反応などから職務に関する対応力、遂行力を評価する部分は仮定状況インタビューを用います。
-
評価基準によってエピソードインタビューと、仮定状況インタビューのどちらを用いるのが適切か異なるため、引き出したい評価項目に合わせてインタビューを設計しましょう。
overflow社の評価基準
- 以下overflowでの評価基準になりますが、実際には会社の規模・開発体制の規模・カルチャーの差違によって大きく変動する内容になります。
- あくまで参考情報としていただき、構造化(質問内容や評価基準の策定)を進める際は、自社で大切にしていること(スキル面、カルチャー面)の言語化からの実施をおすすめします。
コミットスタイル
下記、判定表に記載されている「Full」「Flexible」とは、弊社のコミットスタイルです。
※ 正社員は原則Fullコミット
Full | Flexible | |
稼働時間 |
8h/day x 20day ※フルコミット |
週2〜3日 |
OKR | メンバーによって設定 | 設定なし |
週一朝会 | 原則参加 | 申請制 |
判定表
コンピテンシー評価項目 | Full(社員)基準点 | Full 基準点 | Flexible 基準点 |
専門知識と経験 | tier3採用: 1点以上 tier2採用: 1点以上 tier1採用: 2点以上 | 1点以上 | 1点以上 |
課題解決力 | tier3採用: 1点以上 tier2採用: 1点以上 tier1採用: 2点以上 | 1点以上 | (不問) |
技術構造化力 | tier3採用: 1点以上 tier2採用: 1点以上 tier1採用: 2点以上 | (不問) | (不問) |
通過ライン | tier3採用: 3点以上 tier2採用: 5点以上 tier1採用: 6点以上 | 3点以上 | 1点以上 |
評価基準表
0点 (悪い) | 1点 (普通) | 2点 (良い) | 3点 (非常に良い) | |
専門知識と経験 |
・当社で使われている技術について議論ができない ・基礎的な部分で認識に誤りがある ・[普通] に挙げられる知識がない |
・当社で使われている技術について言語、ライブラリ、フレームワークのレベルで実務レベルの正しい知識があり、機能設計レベルの議論ができる ・[良い] に挙げられる経験はない |
・当社で使われている技術を用いた環境においてテスト、品質管理、運用保守、障害対応などいずれかの領域で主導的な立場をとった経験があり、有効性の高い方策を議論できる ・[非常に良い] に挙げられる知識・経験はない |
・システムアーキテクチャ、プロトコル、アルゴリズムなどの特定の領域の深い専門知識や経験を有している ・[普通] [良い] に挙げられる知識・経験も高いレベルで有する |
課題解決力 |
・状況下における課題や問題を把握できていない ・分析をしても主要な課題の見落としや、そもそもの間違いがある ・[普通] に挙げられる分析力、計画力がない |
・状況を分析することで主要な課題を見つけた上で何らかの対応計画を立てられるが、各種ケースの想定や細かな質問への回答に不備が残る ・[良い] に挙げられる計画の堅牢性はない |
・状況を分析することで主要な課題を把握できており、その解決に向けて各種のケースを見落としなく想定した対応計画を立てられる ・[非常に良い] に挙げられる視点の広さ・高さはない |
・[良い] に挙げられる主要課題の把握と計画だけでなく、副次的な課題や潜在的な課題も折り込んで対応計画を立てられる |
技術構造化力 |
・技術における再現性に対する意識がない ・ライブラリ等で再利用性を抽出するような発想がない ・[普通] に挙げられる行動または相応の考慮がない |
・自分の関わっているプロダクトコードから、再利用可能なパーツを自主的に抽出し、社内ライブラリ化や OSS 化ができる ・[良い] に挙げられる事業的なメリットにつながる根拠はない |
・他チームへの水平展開によるメリットを見いだせる要素を、社内運用フローや要素技術として整理し、他のチームが利用できる水準で落とし込める ・[非常に良い] に挙げられる一般性はなく、類似ドメインへの影響に留まる |
広範なドメインへの影響を期待できる基幹的な技術要素を下記のいずれかの水準で実現できる ・著名学会 (ACM、情報処理学会など) で採択される論文 ・GitHub において Star 数などで推し量れる著名OSS の開発 ・社内エンジニア500名以上の企業(目安)における基幹技術開発 |
エピソードインタビュー質問例
カテゴリ | 質問 | 深堀質問例 |
技術構造化力 |
維持、運用していく上で、意識的にとったアプローチはありますか? |
|
専門知識と経験 | 最近実装したものを、一つ教えてください。 | |
スキル:課題解決力 | 開発の中で、解決が困難だった実装課題は何ですか? | ・どのような結果・成果を得られましたか? ・他にはどのようなアプローチを検討しましたか? ・パフォーマンスやユーザビリティなどに懸念はありませんでしたか? |
その他 | 最近の開発体制について教えてください。 | 人数、職種構成、役割分担、レビュー耐性、周辺チーム etc の近況をヒアリング |
専門知識と経験 | これまでに設計したアプリケーション、機能について、設計の意図や技術選定を教えてください。 | テスト戦略は、どのようなものでしたか? |
技術構造化力 | 社内ライブラリや、OSS として自分で技術を開発したご経験があればお聞かせください。 | ・なぜ作りましたか? ・どのようなフローで使いますか? ・どんな人がユーザーですか? |
仮定状況インタビュー質問例
質問 | |
1.要件定義 | ・どのような機能を、ユーザーストーリーレベルで用意する必要があると思いますか? ・未確定で不明な部分がある場合はありますか? |
2.データ設計 | データモデル(テーブル設計)は、どのような構成を取りますか? |
3.外部設計 | ・1万人程度のアクティブユーザが使用すると仮定した場合、どの機能にボトルネックが発生すると思いますか? ・x 10倍のユーザとなった場合に、どこにボトルネックが発生すると思いますか? ・CPUやメモリなど計算資源の推測について、どのように行いますか? |
4.アーキテクチャ設計 | 技術スタックに制限がない場合、どのようなアーキテクチャを採用しますか? |
5.実装 | どのような流れで実装していきますか?具体的に例を挙げて説明してください。 |
6.運用 | ・リリース以後にモニタリングすべきKPIやメトリクスには、どのようなデータがありますか? ・リリースターゲットを早めてほしいというオーダーがあった場合、どのように進めますか? ・xxxxxの性能に問題が出ている場合、どのように状況分析しボトルネックがある箇所を改善しますか? |