mayah.jp

先日、某VC投資先の方々に対して、「ソフトウェアエンジニアの採用時にコーディングテストをやりたいがどうしたら良いか？」ということについて語ってきたので、こちらにもエッセンスをまとめたいと思います。

コーディングテストの目的

なぜ我々はコーディングテストをやるのでしょうか？

もちろん、第一目的はソフトウェアエンジニアの採用候補者のスキルを見極めるためです。

過去に、経歴も良さそう、技術的な議論もスムーズにできる、なのにコードが書けない候補者に、私は何度か出会っています。「コードが書けない」のレベルは、（ある程度易しい）論理をプログラムに翻訳できず、まともな if 文が書けないというレベルを言っています。熟練者でもド・モルガンの法則をうっかり間違えるぐらいはあると思いますが、そういう話ではありません。コードが書けない候補者は、そもそも条件が書き下せません。このような候補者を雇ってはいけません。でも、経歴が良く、議論もスムーズなので、第一印象はとても良いです。しかし、コードは書けない。コーディングテストを実施することが、このような候補者を見分ける簡単な方法です。

ところで、コーディングテストの副作用として、自社の技術力を候補者に一定示すことになります。このコーディングテストに通った人しか採用されてないなら、自社メンバーに一定の技術力が見込めると採用候補者に思ってもらうことができます。また、コーディング面接の形式でコーディングテストを行う場合、技術議論によって、こちらのレベル（高いも低いも）を示すことになります。良い候補者にとっては、面接自体が魅力づけになり得ます。コーディングテストをやっていないという理由で選考を辞退する候補者の話もしばしば耳にします。

自社で見極めたいスキルを洗い出しましょう

コーディングテストで見極められるスキルには、例えば以下のようなものがあります。何を重視するかを自社で考えてください。

• 知識・経験
  • プログラミング言語・周辺環境
  • フレームワーク
  • アルゴリズムやデータ構造
  • セキュリティ
• 能力
  • システム設計能力
  • コーディングの速さ
  • コーディングの正確さ
• チーム開発の態度
  • 適切なコメントを書くか？
  • 変数名・関数名は意味がわかるものをつけているか？
• 問題に向き合う態度
  • 問題の解を考える前に、問題をきちんと理解することに努めるか？　いきあたりばっかりか？
• 議論に向き合う態度
  • 議論になった時に、正しい着地点を見つけようとするか？　自分の意見を通そうとするか？

コーディングテストは、あくまで「ワークサンプルテスト」であるべきです。すなわち、自社での仕事を擬似的な環境で行ってもらうものです。自社であまり使わないような知識を重視して聞くべきではありません。自社で大事だと考えているスキルを問うようにします。チーム開発が大事だと考えているならばチーム開発の態度を問うべきです。コーディングテストというとアルゴリズムの試験をすれば良いと思ってしまいがちですが、難しいアルゴリズムを理解していることが重要な会社ならそうするべきですし、使わないならばそこまで重視するべきではありません。もちろん、アルゴリズムとデータ構造の最低限の知識・経験は全てのソフトウェアエンジニアがしっておくべき知識ですから、候補者に求めて良いとは思います。

コーディングテストの形式

採用において重視するスキルを洗い出したら、形式を決定します。

コーディングテストは、大きくわけて３つの形式が考えられます。

• 宿題形式
• 試験形式
• 面接形式

自社で、採用候補者の何を測りたいのかを中心に、自社で可能な形式かを合わせて形式を決定します。場合によっては複数の組み合わせ (宿題 → 面接) にします。

宿題形式

宿題形式は、期間を設けて、課題を解いてもらい、提出する形式です。

• pros
  • 多少難しい問題、込み入った問題が出題できます。
  • コメントの書き方、変数の命名法なども見れます。
  • git の履歴などを提出してもらうこともできます。
• cons
  • 不正が稀にあります。
  • 実際の回答時間がわかりません。
  • 想定外の回答をされても修正することができません。
  • 技術的な議論はできません。

試験形式

オンラインで問題を解答・提出してもらう形式です。

• pros
  • 実施が楽で、足切りには最適です。
• cons
  • 不正が稀にあります。
  • 問題のレベルを動的に変更しづらいです。
  • 技術的な議論はできません。
  • フレームワーク系の知識は聞きづらいです。

面接形式

面接内で問題を解いてもらう形式です。

• pros
  • 不正しづらいです。
  • レベルを動的に変更できます（ヒントや発展問題）。
  • 技術的な議論が可能です。
  • コーディングの過程を見ることができます。
• cons
  • 面接官の技術レベルが必要です。
  • 短い時間で聞けることしか聞けません。
  • チーム開発の作法はあまり聞けません。

評価ポイントを決めましょう

面接での評価ポイントは予め決めておきましょう。問題が解けたら通す、というのは足切り以外ではあまり良いやり方とは言えません。

大きくわけて、評価には次の２つの考え方があると思います。

• 育成コストを払えないので即戦力が欲しい
• 即戦力でなくても良いが、育成可能な候補者が欲しい

即戦力が欲しい場合は、言語知識、フレームワーク知識などの、すぐに使える能力を持っているかどうかを中心に見るべきです。

一方、育成して戦力になれば良いという立場であれば、言語知識やフレームワーク知識を問うより、最低限の知識と、良いお作法でものを考えてきたか？　のようなものを中心に見るべきです。

私は後者の立場で見ている場合が多いです。個別の言語知識やフレームワークの知識は、良いお作法でものを考えてきたならば業務内で身につけられると考えており、不足をそれほど問題にしていません。一方、考え方は積み重ねが必要で、簡単には身につかないと考えているため、こちらを重視して評価しています。この考え方は、育成コストはある程度払うので、レベルがあがりやすい特性を持つ候補者を選別している方法だと言えます。また、良い考え方をしていないと思った場合、他社でテックリードをずっとはってきたような方でもお断りしています。

コーディングテスト（面接形式）の実施方法

面接形式の実施方法はさまざまです。google docs のようなものに書いてもらっても良いですが、IDE を使いたい候補者もいるでしょう。こちらは、柔軟に対処できるのが一番良いと思っています。

meety たてときました

面接の悩みを共有できるかなと思ってカジュアル面談をたてておきましたのでお気軽にどうぞ。

(どうでもいいけど hugo で OGP 画像を貼る簡単な方法がわかりませんでした)