コードテストでtrack.runを使っている話と、採用のミスマッチを防ぐために大切なこと

コードテストでtrack.runを使ってる話と採用フロー

古川陽介氏：よろしくお願いします。私はプライベートでは、Japan Node.js Associationというところの代表理事をやっております。今日はどちらかというと会社の中の話です。

コードテストだけではなく、面接やそういうところで何をやっているのか参考になる部分はあるのかなと思うので、発表させていただこうかなと思っています。

コードテストなんですけど、全面的に採用してるよりは、今はトライアルです。インターンの時にコードテストとして、「track」っていうコードテストツールを採用しています。

これはどういうものかというと、Web上で回答できる……さっきちょっと<a href=""https://logmi.jp/tech/articles/320584" target="_blank">Codilityの話があったと思うんですけど、それにすごく似てるツールですね。

我々がやってるのは、やっぱりWebアプリケーションを作る会社なので。データベースの操作ができないと話にならないよねとか。HTTP APIの送信・受信ができないと話にならないよねとか。そういうコードテストの内容があります。それだけではなくてアルゴリズムの問題とか、あと数学の問題とかもあったりしますね。

なので解くのはけっこう長くて、全部解こうとするとだいたい2～3時間くらいかかりますね。先ほどメルカリのTakayamaさんからのお話に「はやい（うまい、やすい）」ってあったと思うんですけど、なかなか時間を食ってしまう感じもします。

実力を見ているだけじゃなくて、入社意欲っていう面もある程度見ようと思って測っているので、注意深くやればだいたい高得点が取れるんです。なんですけど、そういうことすらもしたくない人はお断りさせてもらっている感じですね。

なのでめんどくさい問題も多いんですけど。面倒くさい問題って、コードテストの内容がですね（笑）。そういう問題も多いんですけど、ある程度の技術力プラス、それだけではなくてモチベーションみたいな、意欲みたいなものも見ています。

コードテストの内容

（スライドを指して）これはコードテストの内容です。1つ目、アルゴリズムですね。入力された文字が与えられた文字のうち、最長の回文になっている「たけやぶやけた」みたいなやつですね。そうなっている部分を表示するプログラムを作ってくださいって。アルゴリズムの問題だとこんな感じのやつですね。

わりとありがちなな感じもしなくはないですが、ふつうに解こうとすると、なんとなくO(n^3)か(n^2)とかで解いちゃいますよね。最後の問題が100万桁くらいから（笑）、円周率の3.1415っていうのがずっと並んでるやつがあって、その100万桁の中から最長の回文を探せっていうふうになっているので。そうするとなかなか、ふつうのオーダーだと解けません。

これは本当は、思いつくかどうかわかりませんが、Manacherのアルゴリズムがあって、それを使うと回文がもう少し現実的なオーダーで解けるという問題になっていますね。

ここまでくると知識問題になってしまいますが、そこまでいかなくても、例えば最後の問題まで解けなかったとしても、ふつうの問題は「15字以内から探す」というのもあったりします。徐々に桁数が大きくなっていって、アルゴリズムが長くなればなるほど計算量の効率的なものが必要になってくる。ただそこまで知らなかったとしても高得点は取れるっていう感じですね。

あとは数学の問題で「始めに階段の0段目にいる。あなたは足が長いので、1段上にいく、2段上にいく、3段上にいくの3パターンの登り方がある。6段目に登る方法は何通りか？」みたいな。これは動的計画法ですね。

こういったような問題が多い感じですね。こういうのを解いてもらうんですけど、「だいたい2～3時間」と言ったんですが、超優秀な人だとだいたい1.5時間で95パーセントくらいの正答率を叩き出しますね。

これ以外にもSQLの問題とかWeb APIの問題とかあるんですけど、全部出したとしても実力差っていうのはけっこう出ていて。95パーセントくらいの点数を叩き出す人もいれば、もうちょっと時間が必要な人もいたりします。

trackの良いところ

trackには1つ良いところがあって、これが解けても解けなくても、自由にアピールできるんですよね。「解けなかったんだけど、こういうことを思って、こういうところに時間かかってしまいました」っていうことが、一応Web上で記述ができるんです。

例えばデータベースのSQLとかの問題だったら、クエリに関する説明とか実装した際に工夫した点などを自由に記述してくださいみたいなことが書けます。ここである程度アピールできるって感じですね。「ここにちょっと詰まってしまいました」みたいなことが書ける。なので、解けても解けなくても、部分点もらいにいこうとする姿勢がとれるっていう感じですね（笑）。

ただUIは少しわかりにくいこともあります。左ペインに問題が書いてあって……これ撮影NGなんですけど、SQLの問題です。全ユーザーを表示してくださいってあって右にエディタが書いてあるんですけど、このエディタに慣れてないと解きにくかったりします。

だいたい、操作に慣れたエディタとかを使って書いて、書ききったらここに貼り付けて、下のターミナルのところで試すと実行できる感じなんですけど、やっぱり書きにくかったり、Web上のエディタだと完璧じゃなかったりするので。

そういうところでハイライトがよくわかんなかったり。そんな使いにくさはまぁまぁあります。ただ、やればやるほど、ある程度コツがわかってくるっていう感じではあります。

なので一応やってるのは、点数だけを見てフィルタにするのはちょっと危険かなと。もちろん思いっきり0点とかは考えますけど、ある程度の点数取れているんだったらそこから意欲を受け取って、面接時の参考値にするっていう感じにしています。点数だけを見てフィルタにするっていうのは、うちだとやってないって感じですね。

採用のミスマッチを防ぐには

だいたいここまでがコードテストの話です。面接に進むとどうなるかというと、これはインターンの面接と中途の面接の2種類あるんですけど、僕がやってるのはだいたい中途採用の面接です。

面接は、個人的には「相互理解する場」として捉えております。採用で1番不幸なこととしては、採用した人が期待と違ったり、会社が採用された人にとって期待と違ったとかだと思っています。

これはよく言われている、採用のミスマッチっていう問題ですよね。この採用のミスマッチが起きないようにするっていうところで、お互いを理解できる場として捉えようと思っています。

双方がwin-winな関係であることが1番良いかなと思っていて、そのためにはどうするかっていうのを1番気を付けてやっています。

1つは、面接の前の職務履歴書からある程度質問を考えていくとか。「職務履歴書」とか言ってる時点で超ドメスティックな会社って気もしますけど（笑）、まぁある程度質問を考えていて。

例えば帳票管理、「Excelみたいなものを作るのにReactを導入した」っていう人がいたとして、それに対して想定する質問をある程度考えておくんですね。ExcelライクなものをReactで作る時に、数行だと問題ないかもしれないけど、数10行、数100行に増えてしまったらどうやってパフォーマンスを担保しますかとか。そういうことを考えておく。

ほかにも「メディアサービスを作った」みたいな人に対しては、「想定される人数に対してどうやってスケールするアーキテクチャにしましたか」みたいな。僕、Ceylon系のことやってるんで、そういう質問が多いんですけども。こういうことが質問されることがありますね。

あとは「何をしたか」っていうのを聞きたいわけじゃなくて、「何を学んだか」を聞くようにしています。これはToDoのDone Listを聞きたいわけじゃなくて、ドラマが聞いてみたいっていうところなんで。どうやって調べて何をしたかっていう感じです。

悪い例としては、「XXXというサイトをYYYという技術を使って効果を出しました」と言われてもあまり理解ができなくて。良い例としては「XXXというサイトをYYYという技術を使って効果を出しました。結果、ZZZという学びを得ました」って、この最後のところまで言ってほしい。最後の学びを得たところまで聞きたいです。

面接も育成の場として捉えています。どういうことかというと、面接では議論することも多いんだけど、議論して論破したいわけじゃなくて。一緒にどういうことがしたかったかとか、さらに良いソリューションはないかどうかっていうのを探って、対話を通じてお互いを学べる機会っていうのにしています。

例えば実際にあった話だと、「XXXだとYYYで困りませんか？」みたいなこと言ったら、「ZZZっていうライブラリがあるんですよ」みたいなことを候補者のほうが僕より深く知っていて。それを僕は知らなかったっていう例もあったりします。なので、こういう感じでお互いが学べる機会だと思ってやっている感じですね。

面接される側が心がけるべきこと

今のは僕がどちらかというと心がけていることなんですけど、そうじゃなくて面接を受講する側が心がけると良いこととしては、入社にフォーカスを合わせた話をするんじゃなくて、入社後にフォーカスを合わせた話をしてほしいと思ってます。

どういうことかというと、入社にフォーカスを合わせた話される時って、例えば「凄腕のエンジニアが多いので、ここに入っていろいろ学びたいんです」って言われても、こっちとしては何が良いかわかんないんですよね。

こちらとして何がメリットがあるのかっていう話をやっぱり聞いてみたくて。目標に合わせるよりも、もうちょっと遠めにボールを投げる意識をつけておいてほしいなと思ってます。

入社後にどういうメリットがあって、どういう働き方ができるかっていうところにしておくと、ある程度意識の高いところに投げることになります。途中で失速してもボールを投げてるところが高いぶん、最後の目標っていうところに届きやすいんじゃないかなというふうに思っています。

採用面接はお互いに対話できる場所であるべき

まとめです。コードテストではインターンということもあって、「技術力だけじゃなくて意欲も見てます」っていうところと、イケてないところもいくつかあるので点数だけでふるいにかけるみたいなことはしてないです。

採用面接は会社が候補者を一方通行で判断する場所ではなくて、お互いにWin-Winになるようにして、対話できる場所としてやっています。効果的にWin-Winな環境としてやるためには、事前に質問を考えるとか「何をしてきたか」じゃなくて「何を学んだか」を聞くとか、面接の場を育成の場として使って議論するとかっていうことをやっています。

さらにみなさん、面接される側がやったほうが良いこととしては、入社にフォーカス当てて話すんじゃなくて、入社したらどう貢献できるかっていうところにフォーカスを当てて話してほしいなと思っております。

以上になります。「リクルートテクノロジーズではエンジニアをぼしゅ（以下略）」でございます。ありがとうございました。

（会場拍手）

司会者：ありがとうございました。