QuipperのWebエンジニア採用におけるコードテスト
Webエンジニアの基本採用プロセス
書類のスクリーニング
一次面接
コードテスト
二次面接
VP of Engineering 面接
オファー面談
一問あたり二時間程度で溶ける問題を3問程度といてもらう
テストがありTODOが明確
1ファイルの編集で完結
候補者には自宅でといてもらい、回答を送ってもらう
どうしてこうしているか？
もともとは1つのアプリケーションをまるごと作ってもらう形式だった
コードテストのプロセスだけで2週間かかっていた
合否判定が難しいということも合った
結果、採用プロセスの中で、コードテストでの落ち率が多かった
譲れなかったこと
コードテストはなくさない
書いたコードを後悔していない候補者も多い
譲ったところ
最低限のレベルを担保することに集中する
何故今純粋なアルゴリズム問題ではないのか？
日本ではまだメジャーな手段とは言えない
欧米と違って、ソフトウェアエンジニアが必ずしもCSの学位を持っていることを前提としていない
どうしても訓練を積んでいない候補者が少なく、パイが少なくなってしまう
我々がサービスを創る上でまだボトルネックになっていない
そこまでアルゴリズムがネックになることがなく
DBのアクセス数やキャッシュ戦略がシステムのパフォーマンスに対して支配的でそこをまず確認したいから
どのように作ったか？
同時にコードテストで担保できない部分をどうするかを議論した
問題のたたき台を作り、社内のエンジニアのフィードバックを集めた
難しすぎないか。
運用では
環境の差が出ないようにDockerfileをテストに含めている
普段のワークフロー自動テスト
採用メンバーのエンジニアがモブレビュー
Codilityやtrack などのオンラインテストはまだ利用してない
導入してみて
狙ったどおり提出までの時間が大幅に短縮
スクリーニングプロセスとしては機能していそう
とはいえ調整やメンテナンスは必要
まだ簡単すぎるのではという疑念を捨てきれない
一方、インドネシアでは
1つのアプリケーションをまるごと書いてもらっている
現地企業はほとんどがコードテストを実施している日本のようにコードテストの実施が採用上不利になることがない