エンジニアの採用にはコーディングテストが必須だという風潮もあるし、果たして本当にそうなのかという意見もよく聞きます。

私は直近の採用プロセスでコーディングテストを経験しましたし、採用面接に応募し受ける側でも面接官側でもそれなりに経験があることもあります。

ということもあり、最近なんとなくコーディングテストに感じていることを、自分の考えを整理することを目的としてまとめます。

コーディングテストの種類

Webサービスやオンラインチャットツールを用いた「オンライン」での実施か、面接時に会議室のホワイトボードを用いた「オフライン」での実施か、の概ね２択になると思います。

オンラインでも、コーディングテスト用のサービスを用いて実施するタイプ、課題を与えられて期限内に回答するタイプ、Zoomなどを用いたミーティング中に課題を実施するタイプなど様々です。

オフラインでも、ホワイトボードに擬似コード的なものを記述するパターンもありますし、スタートアップなどでは面接官とペアプロやモブプロを実施する例も聞きます。

それぞれの方法の功罪や、何を採用すればよいのか等々を述べられるほど網羅的には把握をしていませんが、一通りの方法を経験はしたことはあります。なのでこの記事では、個人の感想という体裁で記事を書いていきます。

オンライン：コーディングテストサービスを用いる方法

Codilityや、日本だとTrackなどが有名なコーディングテストサービスだと思います。

私も、最近内定をもらった会社でも「応募者」としてオンラインコーディングテストを実施しました。以前在籍していた会社で「面接担当」としてコーディングテストサービスを使用していたこともあります。

コーディングテストサービスを用いた際に感じたメリットは以下です。
・非同期で実施できるので実施時間や評価する時間を柔軟に調整できる。
・明らかに水準に達してない人を判断できる。

逆にデメリットは以下です。
・問題の運用が大変。実力を判断できる有効な問題を作るのは大変だが、かなり頻繁にメンテナンスしないと対策される。
・どのように問題を解いたか、解決プロセスについては把握できない
（※サービスによっては時系列でコードの変化などを見ることができるものもありますが、一人づつトレースするのは時間的コストも大きい）
・心理的・時間的敷居が高いため、コーディングテストを実施すると応募数が少なくなる。引く手あまたな会社であればよいが、そうでもない会社の場合応募が減ってしまう。

個人的には、プログラムの基礎的な力であったり、ベースとなるアルゴリズムの能力有無を確認するためには良いプロセスだと思います。Web上のオンラインテストであれば会社側の実施コストもそこまでかかりません。

ただ、その運用はかなり難しく、オンラインのコーディングテストだけで応募者の実力すべてを測るのは現実的ではないと感じます。

基本的には、採用プロセスの一番最初に設定し、足切りプロセスとして導入するのが一番良いと思います。

オンライン：独自課題の事前提出

特にコーディングテストサービスなどを用いず、独自のプログラム課題を出すような会社も多く存在すると思います。

応募者は、出された課題を基に、プログラムコードなどの成果物をGitHubにPushしたり、ファイルをまとめて提出する、という形で実施します。

小さい会社であればイニシャルコストが小さくてすむようにも見えますが、会社側としては課題のメンテナンスや、提出いただいた課題の採点などの管理に手間がかかるように思えます。

基本的にはコーディングテストサービスを用いた時のようなメリット・デメリットがあり、かつ運用負荷という側面でデメリットが大きい実施方法だと思います。

オンライン：面接中のコーディングテスト

エンジニア採用の間口を広げたり、応募者・会社双方の負担を軽減することを目的に、面接をZoomなどを用いてオンラインで実施するケースが増えてきたと感じています。

オンラインで面接をしつつ、オンラインでコーディングテストを実施するケースも増えてきているように思いますし、私も経験したことがあります。

コーディングテストサービスを用いて非同期でコードを書いてもらう時とくらべて、面接中に面接官とディスカッションをしながら物事を解決していくので応募者側もやりやすさがありますし、面接官側も解決プロセスをつぶさに確認できるためより応募者の水準や対応能力が見やすいという側面があるかなと思います。

基本的にメリットが大きいと個人的には思っている方法ですが、以下は課題になりがちだなと思います。
・オンラインチャットとコーディングテストを統合的に管理できるようなツールが（私の観測範囲では）あまりない。なのでコーディングテストの運用は手弁当になりちょっと負担が大きい。
・同期的に実施するため、双方拘束時間が長くなりがちで負担が大きい。
・ネットワーク環境の良し悪しに影響されやすい

この方法は、足切りでオンラインのコーディングテストサービスを実施し、その後の一次面接〜二次面接などのプロセスで技術力の深堀りする際に実施するのが良いかなと思います。

オフライン：面接中のホワイトボードコーディング

一般的に多くの会社で「コーディングテスト」と言った場合、応募者に課題を出した上でその結果をホワイトボードに書いてもらう、というパターンが多いのかなと思います。

私も以前、ホワイトボードにフィボナッチ数列を出力するプログラムを書けとか、キャッシュアルゴリズム（LRUか何か）を書け、という課題を出された事があります。

特に事前準備や環境をしなくても実施はできるので、一番導入コストが少なくて済む方法かなと思います。その分、実効性、有効性についてはかなり微妙だと思います。一番の理由は、書いたコードを評価するのが難しいことです。

書く側も、エディタやIDEでプログラムを書くという行為と、ホワイトボードにそれを書くというのは全く違う行為で、ホワイトボードはプログラムを書くのに適切なプラットフォームでも無いので、あまり実力が反映されないという側面があります。

評価する側も、実際に脳内で動きが想像できる人は良いですが、書かれた内容の妥当性を瞬時に判断できる人があまりいないです。

ということで、個人的な主観では、ホワイトボードを用いたコーディングテストはお互いにとって得るものが少ない、と思っています。

もちろん、システムの課題を提示しそれを実現するアーキテクチャを記載してもらうなど、プログラムよりもう少し抽象度の高い問題を書いてもらう方法としてはホワイトボードを用いたディスカッションは悪くないと思います。

オフライン：面接中のペアプロ・モブプロ

ホワイトボードを用いたコーディングテストよりももう少し有効な方法として、スタートアップなどでは面接中にペアプロやモブプロを実施するところも増えてきたように思います。

あらかじめ会社側がPC環境とプログラム課題を用意し、そちらを用いて応募者が課題解決をしていく、という方法です。

課題を進めていくために曖昧な部分については都度ディスカッションができるなど、応募者にとっては安心感がありますし、面接官側もより実践に近い形で素振りをすることで実務的な能力を判断することができます。

デメリットとしては、
・面接官側にもそれなりの水準の技術力が求められること
・準備が大変で、拘束時間も長くなりがちなこと
あたりだと思います。

個人的な所感

コーディングテストについて、個人的には以下のような考えを持っています。

・アルゴリズムを問うようなもの、最低限のプログラミングスキルを測るようなものは、コーディングテストサービスを用いて事前に実施をしたほうが良い。
目的は「足切り」。ボトムの水準を定義し、そこを満たさない人を機械的に判断するための手法として導入する。

・面接時には、思考プロセスや課題解決の仕方などを把握する手法としてコーディングテストを使用する。出来上がったプログラムの網羅性や完成度よりも、どのように課題解決をするか、実務的な能力を判断するために実施する。コーディングだけでなく、アーキテクチャ設計やデータモデリングなどの課題でも良い。

・「コーディングテスト」は一つの手法だが、免罪符ではない。コーディングテストは足切りには使えるが、実務的なコーディング能力の優劣や、仕事の適応能力のありなしを把握するのは難しい。コーディングテストの結果だけを見て採用、というのはやめておいた方がよい。
コーディングテストの結果が良くても仕事では良いコードが書けない人も多い。本当は仕事でバリバリコードを書けるのに面接官側の不備や配慮不足で良い結果が出ないケースもある。
コーディングテストにだけ頼るのでなく、多面的にその人を評価する取り組みが大事。ということを忘れずに、応募者に配慮した環境づくりが大事。

面接官が配慮すべきこと

五月雨に書きます。

コーディングテストは、課題やその答えを知っている人（面接官）と、知らない人（応募者）の間で大きな情報バイアスがあります。なのでどうしたって、応募者は面接官が理解している内容を超える答えを出すことは稀です。

その事を配慮せずに、時間内にゼロから取り組んだら絶対に解決できなさそうな高度なアルゴリズムや過大な課題を応募者に課すような人がいますが、これは辞めたほうが良いです。
僕の視点だと、優位な立場にいる人が、弱い立場にいる人を虐めて悦に入っているようにしか見えません。少しストレッチすれば解決可能な課題を出された時と、明らかに無理そうな課題を出された時では応募者側の心理的なモチベーションにも差がでます。

コーディングテストは、面接官の自己顕示欲やプライド、優越感を満たすために行うものではありません。応募者が気持ちよく回答でき、正しくいつもどおりの力が発揮できる環境を作ることに注力すべきです。

コーディングテストの課題を出す場合は、以下をはっきり定義させておくべきです。
・入力
　（データ範囲、フォーマット、渡され方等々）
・期待する処理プロセス
　（ナイーブなものでよいのか、排他や並列性を考慮しいたものにすべきなのか等々）
・出力
　（結果の出力フォーマット、出力結果の使われ方等々）
・評価方法
　（テストケースが All Green になったら OK。実行時間はxx秒以内、等）

特にホワイトボードを用いたコーディングテストで見かける光景なのですが、この辺を曖昧なまま課題を出す人が多いように思います。結果、応募者側は何をすればよいのか曖昧なまま課題を進めざるをえず、後出しジャンケン的に不備を指摘されたりしがちです。

個人的に、上記のようなポイントを曖昧なままに課題を出してくる人は「仕事においても要件定義や課題の分析ができない人」「端的に仕事ができない人」と捉えてしまいます。そしてその感覚は実際に大きくハズレていないように思えます。

上述の内容にも関係しますが、採用面接は「会社が応募者を選抜する場」というだけではありません。「応募者が会社を選抜する場」でもあります。
面接官側・会社側が応募者よりも様々な意味で優位な立場にいがちですが、そこに甘んじてよろしくない言動や行為をしてしまい、その結果「この人・この会社のやり方はイケてないな」と思われたら、たとえ良い人だと思っていても応募者から逃げられてしまうだけでなく、その人の周りにもネガティブなイメージいが蔓延してしまいます。自分が応募者を見ているだけでなく、自分が見られている、という視点を常に忘れてはいけないと思います。

二度とおこしたくない面接でのエピソード

こういう記事を書いているのは、過去の苦い思い出があることも一因です。面接官側の立場として。

以前在籍していた会社の上司（CTO）と一緒に面接官として面接をした際に、CTOが応募者に対して極めて曖昧な課題……隣で聞いていても何をしてほしいのかよくわからない課題……を突然出したのを見たことがあります。
そもそもコーディングテストをする予定はその面接ではなかったので時間も確保していなく、途中で会議室を変えながらテストが終わるまで応募者を拘束するということになってしまいました。その間CTOは「こんな簡単な問題がわからないんですか？」「（僕ぐらいの経験があれば）誰でもすぐ解けますよ」とパワハラにも似た発言を連発をしてました。
（正直、横で聞いていても、そもそも何をしたいのか日本語レベルで理解が難しく感じました）

結果、その応募者は「何をしたら許してもらえるんだろう」「意味がわからない」という恐怖により思考が停止してしまい、完全にフリーズしてしまいました。

伏線として、私がその応募者と質疑応答していた際に結構レベルの高いやりとりをしており、一方CTOはその内容についてこれず全然理解できなかった、的外れの発言を連発してしまった、という事がありました。
CTOとしては、それで失ったメンツを取り返すために、優越感を保つために予定になかったコーディングテストを実施したのかな、自尊心を保つ行動に出たのかな、と今では推測しています。

私も諸々面接の場でフォローや、その後のアフターフォローをしてとりなしたのですが、結局その時に応募者側にネガティブなイメージと心理的なダメージを与えてしまったようです。その方には内定オファーを出したのですが、結果的に辞退をされてしまいました。

このような面接は、個人的には二度と経験をしたくないです。なので、改めて自分の中でコーディングテストに対してどう取り組むかを整理する、という目的で雑文を書きました。