こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
ゆめみさんが行っているエンジニア選考でどのようなポイントをチェックしているのか？という話など、技術選考に関する様々な話が聞けるイベントです。
会の様子
コーディング問題を公開している理由
ゆめみさんでは、コーディング問題をGithubに公開しているそうで、この理由を教えてくれました。以下の理由があったそうです。
- 会社全体としてなんでも公開する(透明性を重視する)文化があったこと
- 選考を受ける人が、受けた後に問題を確認することでストレスを感じてしまうこと
- 制限時間内に解けるか？をあまり重要視していないため。仕事で使える力が間違いなくあることを重視している
- 選考を受ける人目線で、技術選考にどれくらい力を入れられるかわからないので、転職にあたってどれくらい準備が必要かわかったほうがやりやすいと思ったから
- ゆめみがどういう人を求めているか？を対外的に公開することができるから
- デメリットが見当たらないため
盗作チェックはする？
フロントエンドレベルであれば、リポジトリを所定のリンクに提出してもらうので他の人の回答が見える&ゆめみの問題を解いてみた系の記事の存在があるため、盗作ができてしまうようですが、これのチェックはしているのか？という話がありました。
盗作を意識しながらコードをチェックすることはないそうですが、現代の技術からすると明らかに古い技術がモダンな技術の中に紛れ込んでいたり、コミットが異常に大きかったりする場合...違和感を持つようなものは原点しているということでした。
印象に残ったコードは？
以下のようなコードは印象に残ったということでした。
- 非常に短いコード
- 考えに至った過程が書かれているようなコード
- 問題の制約を意図的に破った上で、なぜ破ったのか？というのが記載されているコード
フィードバックが厚いと有名だがなぜか？
落ちた人にも受かった人にもフィードバックを厚くしているということで、それはなぜか？という話を聞いていきました。
- 真面目にやったのに落ちた場合にもやもやしてしまう。それは会社としても望んでいないことなので、何かしら対策をしたいと感じた。
- フィードバックを活かしてもう一度受けてもらってもいいし、他の選考に活かしてもらってもいいし、選考に時間をかけてくれたことに何かしらお礼をしたいと思った。
といった理由が挙がっていました。
また、一度落ちた人がフィードバックを活かして再度試験にチャレンジすることもウェルカムだということでした。(それだけ会社を魅力に感じているということなのでむしろ嬉しい)
評価基準
以下のようなポイントを評価基準としているそうです。
- (Flutter) 評価ポイントは公開している。アディショナルな点で言うと、書いていないポイントを理由と共に実装して提出してきた場合は加点する。
- (iOS) コミットメッセージとコミットの粒度はよく見る。
- (サーバーサイド) 問題が簡単なので、一回動いた後にどのようにリファクタリングしているのか？というところを重点的にみている場合が多い。
- (インフラ・SRE) (部下がいてその部下をリードしてもらうという前提を置いて*1テストしているので)どのようにタスクを振り分けるのか？という部分をみている。難しいところとヒントだけ出して放置してもある程度なんとかなると思っているところをうまく切り替えられる人は評価が高い。
- (フロントエンド) 非常にシンプルな課題になっているが、課題から見えない部分(例えばアニメーションなど)も色々と作り込める課題になっている。また、OSSを上手に使えるか？というのも重視している。
新卒/中途でみている観点をどう変えているか？
以下のような話が出ていました。
- (Android/iOS) 新卒/中途で問題は一緒。問題にレベルを振っているので(初級/中級/上級...)、中途ならよりレベルの高いものにチャレンジしてくれると嬉しいなと思っている。なお、中級ができたけど初級ができないということはない。
- (Flutter) 立ち上がりたてで今後改善していく前提だが、現状は特に分けていない。ただ、中途の場合はバックグラウンドがあるので、そのバックグラウンドを頭に入れながらコードを見ていくことはある。
テストを作る時にはどれくらい時間をかけたか？
- (サーバサイド) 問題は取ってきたものなので問題を作ることに時間は使っていないのだ、公開されている問題は端から端まで全て見て、言語によって難度が依存しないのか？時間内に解けるような問題か？といった部分をチェックした。
- (iOS) どういった課題にしようか？というところからスタートしたので、何ヶ月もかかった。そこまで時間は掛からなかったが、あえてダメなコードを書くのは大変だった。*2
- (Flutter) プロジェクトを作る作業(ダメダメコードを作るような作業)をしていないのでiOSやAndroidよりは簡単だった。
- (インフラ・SRE) 1テストあたり4時間くらい。一人でばーっとたたき台を作って、チーム内レビューでブラッシュアップして、という形でやっている。
- (フロントエンド) ベースはさっくりと数時間で作った。そこから運用しながら少しずつ手を加えた。各々が最新の技術で作るシンプルな課題になっているので、この運用で回っている。
評価基準を統一するための工夫/レビュー体制
- (サーバサイド) 14名くらいで見ていて、ペアでレビューするようにしている。また、高い点数をつけたコードをシェアしたり、オープンコードレビュー回を開いたりしている。週で3人分くらい見たりしている。
- (iOS/Android) (チェックリスト的な形で)チェック項目を用意している。4-5人くらいで見ている。
- (フロントエンド) 5-6人くらいで見ている。まずは動いているか？を重視している。Nextには書かないけど加点になるような部分はあるので、若干人によって変わるとは思うが、項目は話し合って決めているので、面接官が違った結果落ちてしまった人がいる、ということはないようにしている。レビュー負荷はあまりにも高くならないように、1-2時間で回している。(1ヶ月あたり35人分くらいの人を見ている)
- (Flutter) まだ始めたての部分なので、新鮮な気持ちで作ってもらったプロジェクトを少人数で見ている。
- (インフラ・SRE) 応募の母数が少ないので、他の職種よりも薄めの人数でやっている。2-3人で見ている。
会全体を通した感想
領域ごとにどんなポイントを見ているのかを知ることで、業務でどのような点を大切にしているのかが垣間見えたのが印象的でした。
コーディング試験や技術面接というと得体の知れない感覚があったのですが、色々とポイントを知ることができて、非常に有意義な時間になりました。
