ITエンジニア志望者にとって、時に「避けては通れない道」となるコーディング選考。実際に人気企業では、どのような試験や採点が行われるのだろうか。今回はLINE株式会社の協力の下、外資就活ドットコムの会員が参加(*1)する模擬コーディング試験を開催。LINEが実際の選考で出すような問題を、参加者に解いてもらった。
その解答内容を題材に、LINEの新卒採用でコーディング試験を担当する大澤和宏さんと、特別ゲストのAtCoder高橋直大社長の対談を実施。2人の言葉から、「良い解答」「そうでない解答」の差、そしてコーディング選考と競技プログラミングの違いなどが見えてくる。【藤崎竜介】
*1 AtCoderで中級者とされる茶色もしくは緑色レベル、かつ2024年卒業予定の学生を対象に参加者を募集(AtCoderのランクについては、公式ページで詳細を確認できる)
〈Profile〉
写真左/高橋直大(たかはし・なおひろ)
AtCoder株式会社 代表取締役社長。
慶應義塾大学大学院政策・メディア研究科修士課程修了。2012年にAtCoderを創業。2008年にマイクロソフト主催の「Imagine Cup 2008」Algorithm部門で3位入賞したのを皮切りに、世界的なプログラミングコンテストで高成績を出し続けている。
同右/大澤和宏(おおさわ・かずひろ)
LINE株式会社 開発3センター サービス開発1室 室長。
2011年にLINEへ入社。現在はエンターテインメント系サービスなどを開発する部署を統括しつつ、エンジニア新卒採用にも関わる。
◆内容や肩書は2022年10月の記事公開当時のものです。
油断すると時間切れに……。コードを書く力に加え、問題を「読む」力も試されるLINEのコーディング試験
<対談実施までの流れ>
① 外資就活ドットコムの会員を対象に模擬コーディング試験への参加者を募集
↓
② 応募理由などを基に選出した参加者9人が、LINEが作成した試験をオンラインコーディング試験プラットフォーム「Track Test」上で受験
↓
③ LINEが全解答を採点した上で、内容をAtCoder高橋直大社長と共有
↓
④ 対談当日
(取り上げる解答は全9件の中から選びだした、計4件)
――最初にLINEの大澤さんから、今回出題した問題やLINEが実施しているコーディング試験について簡単な説明をお願いします。
この問題には、全ての受験者が実装すべき「基本実装」と、時間が余ってより実力を披露したい受験者のための「応用実装」の二つの仕様があります。これらの差は、応用実装では追加で「時間指定」の配達リクエストを扱う必要があり、実装すべきクエリの種類が増える点です。
応用実装でのみ必要な情報は、「応用実装(クリックして展開)」をクリックすることで確認できます。応用実装の仕様は複雑で難しいため、まず基本実装が動作することを確認してから応用実装に着手することを勧めます。
概要
あなたは、配達サービスの管理システムを作成することになった。このシステムは、配達リクエストを複数受け取り、一人の配達員がいつ何を配達すべきかを指示することが主な役割である。
利用者は、配達物を配達センターに持ち込んで配達を依頼する。配達センターの従業員は、それぞれの依頼に対して配達リクエストを作成してシステムに送る。
配達リクエストには、固有の配達IDと配達時間と配達タイプが必ず記載される。システムが配達リクエストを受け取ったら、そのリクエストが異常だったり不可能だったりしないかを確認したあとに受理する。受理された配達リクエストのみ、システム内で管理される。
このシステムでの配達員は 1 人のみを想定する。配達員は、システムが自分に配達リクエストを割り当てるのを待つ。二つ以上の配達リクエストが同時に配達員に割り当てられることはない。配達リクエストが割り当てられたら、配達員はすぐに配達に向かい、配達時間をかけて配達を完了し、配達リクエストが割り当てられるのを再度待つ。
配達リクエストには、通常、速達の配達タイプがある。同時に通常と速達の配達待ちの配達リクエストがある場合、速達のものを優先して配達員に割り当てる。
応用実装(クリックして展開)
また、このシステムの特徴として、配達予定時刻を分単位で指定する機能が実装される。
これを実現するために、応用実装の配達リクエストには、加えて時間指定の配達リクエストがある。時間指定の配達リクエストでは、配達予定時刻が指定される。このリクエストが受理されると、その配達を行うことが予定される時間帯で、配達員が予約される。例えば、30 分の配達時間の配達リクエストが 21:45 に時間指定されている場合、21:15 から 21:45 まで配達員が予約される。時間指定の配達リクエストが複数受理されている場合、このように予約された時間帯も同じ数だけ存在する。予約された時間には他の配達をすることができないので、これらの予約された時間帯は配達員が忙しい時間帯とみなされる。
システムは、配達リクエストを受け取って管理し、適切な時間になったら配達員に対して配達リクエストを割り当てる。
上記の説明では、細かい仕様や具体的な入出力方式はまだ書かれていないことに注意せよ。下記の「詳細な仕様」に基づいて、配達員に適切な配達リクエストを適切な時間に割り当てるプログラムを実装せよ。
採点
それぞれのクエリが正しく実装されているかを確認するための秘密のテストが用意されているため、もし公開テストケースで満点が取れたとしても、最終的な結果が満点ではない可能性がある。そのため、公開テストケースで満点が取れても、プログラムにミスがないか確認することを勧める。
詳細な仕様
日時
- 与えられる日時は、以下の制約とフォーマットを満たす日付と時刻の組である
- 日付は 1 以上の整数で表される。日付 n+1 は日付 n の翌日である。また、クエリで与えられる日付は 10 以下であることが保証される。
- 時刻は hh:mm 形式で与えられる。00 < hh < 23, 00 < mm < 59 が保証される。
配達リクエスト
- 配達リクエストは以下の情報を持つ。
- 配達ID: 5 桁の数字。先頭の数字が0であるような番号も与えられうる。
- 状態: 配達待ち、配達中、配達済のどれか。
- タイプ: NORMAL (通常), EXPRESS (速達), SCHEDULED (時間指定、応用実装のみ) のどれか。
- 配達時間: 配達の所要時間 (分)
応用実装(クリックして展開)
- SCHEDULED タイプの配達リクエストは、加えて以下の情報を持つ。
- 配達予定時刻: 配達が完了すべき時刻
- 配達時間帯: 配達を行っている時間帯。つまり、「配達予定時刻から配達時間だけ前〜配達予定時刻」の時間帯を指す。ただし、配達予定時刻から配達時間だけ前は含み、配達予定時刻は含まない。
配達員
- 配達員の状態には二通りあり、配達リクエストが割り当てられて配達中か、配達リクエストの割り当て待ちかのどちらかである。
- 配達員の忙しい時間帯がシステムに管理される。忙しい時間帯に被る配達リクエストの受理はなされず、また、忙しい時間帯に被る配達の割り当ては行われない。
- 時間指定の配達リクエストが存在しない基本実装では、忙しい時間帯は存在しないので、忙しい時間帯に配達リクエストや配達の割り当てが抵触する場合は考えなくてよい。
応用実装(クリックして展開)
- システムが時間指定の配達リクエストを受理したら、配達員は必ず配達予定時刻から配達時間分だけ前の時刻に、その配達が割り当てられなければならない。そのため、配達予定時刻から配達時間分だけ前〜配達予定時刻の間、配達員は配達をしなければならないので、他の配達が行われないように調整する必要がある。
- 時間指定の配達リクエストが存在する応用実装では、忙しい時間帯は以下のように定義される。
- 忙しい時間帯とは、SCHEDULED タイプの配達リクエストの配達が予定されている時間帯である。より厳密には、受理された SCHEDULED タイプの配達リクエストそれぞれについて配達時間帯を列挙し、それらの和集合が忙しい時間帯である。
配達員への割り当て
配達員が割り当てを待っている状態ならば、毎分ごとに、システムは割り当てるべき配達リクエストがないかを確認する。割り当てるべき配達リクエストは、各時刻で 0 個もしくは 1 個である。
割り当てるべき配達リクエストを探すために、システムは以下の条件を上から下の順に確認する。
応用実装(クリックして展開)
- 現在が、配達待ちの SCHEDULED タイプの配達リクエストを割り当てるべき時刻であれば、それを割り当てる。
- 厳密には、受理された配達待ちの SCHEDULED タイプの配達リクエストの中で、現在時刻から配達時間後に配達予定時刻と一致するものがあればそれを割り当てる。
- 「配達待ち」かつ「今割り当ててもその配達時間帯が忙しい時間に被らない」の配達リクエストのうち、タイプが速達のものがあるかを確認する。あるならば、そのうち最も配達リクエストの日時が早いものを割り当てる。
- 「配達待ち」かつ「今割り当ててもその配達時間帯が忙しい時間に被らない」の配達リクエストのうち、タイプが通常のものがあるかを確認する。あるならば、そのうち最も配達リクエストの日時が早いものを割り当てる。
配達員が配達を割り当てられたら、その時刻から配達時間後までの間、配達中の状態になる。ただし、配達が割り当てられた瞬間は配達中であるが、割り当てられた時刻から配達時間後ちょうどでは割り当て待ちの状態であるものとする。
配達リクエストの受理
- NORMAL および EXPRESS タイプの配達リクエストが受理されるためには、配達時間が 120 分以下である必要がある。
応用実装(クリックして展開)
- SCHEDULED タイプの配達リクエストが受理されるためには、以下の全てを満たす必要がある。
- 配達時間が 60 分以下
- 今すぐに配達を始めれば、配達予定時刻かそれより前に配達が完了できる。つまり、配達予定時刻が、現在から配達時間だけ経過した時刻もしくはそれより後である。
- 現在配達中の配達リクエストがある場合は、その配達を完了してからすぐに配達を始めれば、配達予定時刻かそれより前に配達が完了できる。つまり、配達予定時刻が、現在配達中の配達が終わる時刻から配達時間だけ経過した時刻よりも後である。
- 現在の忙しい時間が、今受理しようとしている配達リクエストの配達時間に被らない。
- SCHEDULED タイプの配達リクエストが受理されたら、忙しい時間にその配達時間帯を追加する。
配達リクエストのキャンセル
応用実装(クリックして展開)
- 受理された配達待ちの配達リクエストは、キャンセルできる。
- NORMAL と EXPRESS タイプの配達リクエストは、今後、受理された配達リクエストとみなされなくなる。
- SCHEDULED タイプの配達リクエストは、受理された配達リクエストとみなされなくなる。また、そのリクエストの配達時間帯を忙しい時間から削除する。
- 受理されていない配達リクエストや、配達中・配達済みの配達リクエストは、キャンセルできない。
配達リクエストの状態確認
- 受理された配達リクエストが、配達待ちなのか配達中なのか配達済みなのかを調べるための機能が実装される必要がある。
- 受理されていない配達リクエストの状態を確認することはできない。
システムの処理順序
- システムは毎分、以下の 3 ステップの処理をこの順序で行う。
- Step 1: その時刻で配達完了した配達リクエストがあるかを確認し、あれば配達完了のお知らせを出力する。配達が完了したら、その配達リクエストは配達済み状態になり、配達員は割り当てを待ち始める。
- Step 2: その時刻でクエリが与えられたかを確認し、あればクエリの処理を行う。
- Step 3: その時刻で配達リクエストが配達員に割り当てられたかを確認し、配達リクエストの割り当てを出力する。配達リクエストが割り当てられたら、その配達リクエストは配達中状態になり、配達員も配達中の状態になる。
入出力形式
- プログラムに与えられる入力は、標準入力を介して行われる。
- 改行コードは\n (<LF
>)である。最終行の末尾にも改行コードが付与される。
- 入力は、NORMAL クエリ・EXPRESS クエリ・SCHEDULED クエリ、CANCEL クエリ、STATUS クエリが時系列順に与えられる。クエリと情報の数は与えられないので標準入力の最終行まで読み込むこと。これらの数は合計で 100 以下であることが保証される。
- 同じ時刻のクエリは与えられない。
- 同じ時刻で複数行に渡って出力を行う必要があるときは、「配達完了のお知らせ」「クエリの出力」「配達リクエストの割り当て」の順に出力せよ。
Step 1: 配達完了のお知らせ
- それぞれの時刻で、その時刻に配達が完了するような配達リクエストがあるかを確認して、もしあれば以下を 1 行で出力せよ。
[日時] [配達ID] has been delivered.
Step 2: クエリ
NORMAL クエリ
- 従業員が、NORMAL タイプの配達リクエストをシステムに送るためのクエリである。
- 日時、文字列NORMAL、配達ID、配達時間がスペース区切りで与えられる。
例: 日付 3 の 5 時 12 分に、配達IDVjfisfの配達リクエスト (タイプ NORMAL) が発行された。この配達は 20 分で完了する。
3 05:12 NORMAL jfisf 20
- 上から条件を確認し、該当する出力を 1 行で出力せよ。
- 配達時間が 120 分以下ではない場合、以下を 1 行で出力せよ。
[日時] ERROR: Delivery time cannot exceed 120 minutes.
- 配達リクエストが受理される場合、以下を 1 行で出力せよ。
[日時] [配達ID] has been accepted.
EXPRESS クエリ
- 従業員が、EXPRESS タイプの配達リクエストをシステムに送るためのクエリである。
- 日時、文字列EXPRESS、配達ID、配達時間がスペース区切りで与えられる。
例: 日付 3 の 5 時 12 分に、配達ID`jfisf`の配達リクエスト (タイプ EXPRESS) が発行された。この配達は 20 分で完了する。
3 05:12 EXPRESS jfisf 20
- 上から条件を確認し、該当する出力を 1 行で出力せよ。
- 配達時間が 120 分以下ではない場合、以下を 1 行で出力せよ。
[日時] ERROR: Delivery time cannot exceed 120 minutes.
- 配達リクエストが受理される場合、以下を 1 行で出力せよ。
[日時] [配達ID] has been accepted.
応用実装(クリックして展開)
SCHEDULED クエリ
- 従業員が、SCHEDULED タイプの配達リクエストをシステムに送るためのクエリである。
- 日時、文字列SCHEDULED、配達ID、配達時間、配達予定時刻がスペース区切りで与えられる。
例: 日付 3 の 05:12 に、配達IDjfisfの配達リクエスト (タイプ SCHEDULED) が発行された。日付 4 の 21:00 に配達されるよう時間指定されており、配達時間は 30 分である。そのため、システムは配達員に対して日付 4 の 20:30 に配達を指示する必要があり、20:30 から 21:00 までが忙しい時間に追加される。
3 05:12 SCHEDULED jfisf 30 4 21:00
- 上から条件を確認し、該当する出力を 1 行で出力せよ。
- 配達時間が 60 分以下ではない場合、以下を出力せよ。
[日時] ERROR: Delivery time cannot exceed 60 minutes.
- 今からすぐに配達を始めても希望の配達予定時刻に配達ができない場合は、以下を出力せよ。具体的には、配達予定時刻が、現在から配達時間だけ経過した時刻よりも前である場合にこのエラーメッセージが出力される。
[日時] ERROR: The scheduled delivery time is too close.
- 現在配達中の配達リクエストがあり、かつ、その配達を完了してからすぐに配達を始めても配達予定時刻に配達が完了できない場合は、以下を出力せよ。具体的には、配達予定時刻が、現在配達中の配達が終わる時刻から配達時間だけ経過した時刻よりも前である場合にこのエラーメッセージが出力される。
[日時] ERROR: The scheduled delivery time is too close because other delivery is being made.
- 現在の忙しい時間が、今受理しようとしている SCHEDULED タイプの配達リクエストの配達時間に被っている場合は、以下を出力せよ。
[日時] ERROR: The scheduled delivery time cannot be specified because the delivery person is busy making another delivery.
- 上記のいずれにも当てはまらない場合、以下を出力せよ。
[日時] [配達ID] has been accepted.
- 現在配達中の配達リクエストがある場合は、配達予定時刻が、現在配達中の配達が終わる時刻から配達時間だけ経過した時刻よりも後である。
- 現在の忙しい時間が、今受理しようとしている SCHEDULED タイプの配達リクエストの配達時間に被らない。
CANCEL クエリ
- ユーザが、配達リクエストのキャンセルをシステムに送るためのクエリである。
- 日時、文字列CANCEL、配達IDがスペース区切りで与えられる。
例: 日付 3 の 05:12 に、配達IDjfisfの配達リクエストをキャンセルしたい場合
3 05:12 CANCEL jfisf
- 上から条件を確認し、該当する出力を 1 行で出力せよ。
- キャンセルしようとしている配達リクエストが過去に受理されたものではない場合は、以下を出力せよ。
[日時] ERROR: The request is not found.
- キャンセルしようとしている配達リクエストが、配達中もしくは配達済みの場合は、以下を出力せよ。
[日時] ERROR: The request that has been processed cannot be cancelled.
- 上記のいずれにも当てはまらない場合、以下を出力せよ。
[日時] [配達ID] has been cancelled.
STATUS クエリ
- ユーザが、配達リクエストの状態を確認するためのクエリである。
- 日時、文字列STATUS、配達IDがスペース区切りで与えられる。
例: 日付 3 の 05:12 に、配達IDjfisfの配達リクエストの状態を確認した場合
3 05:12 STATUS jfisf
- 上から条件を確認し、該当する出力を 1 行で出力せよ。
- 確認しようとしている配達リクエストが過去に受理されたものではない場合は、以下を出力せよ。
[日時] ERROR: The request is not found.
- 確認しようとしている配達リクエストが配達待ちの場合は、以下を出力せよ。
[日時] [配達ID] is awaiting delivery.
- 確認しようとしている配達リクエストが配達中の場合は、以下を出力せよ。
[日時] [配達ID] is being delivered.
- 確認しようとしている配達リクエストが配達済の場合は、以下を出力せよ。
[日時] [配達ID] has been delivered.
Step 3: 配達リクエストの割り当て
- それぞれの時刻で、その時刻に割り当てられた配達リクエストが存在するかを確認し、もし存在するならば以下を 1 行で出力せよ。
[日時] [配達ID] has been assigned.
大澤:LINEのコーディング試験では通常、「アルゴリズム問題」と「業務志向の実装問題」の2問を出していて、今回参加者の皆さんに解いてもらったのは後者です。前者は競プロでよく出てくるような一般的なアルゴリズムの知識を問う内容で、競プロをやっている人なら割とすんなりクリアすると思います。
一方、業務志向の問題は人によって結果に結構差が出るので、この企画の対象に選びました。
高橋:問題文がかなり長いのが特徴的ですね。
大澤:はい。LINEのようなWebサービスに限らず、あらゆるシステムの開発はまず自然文で書かれた仕様書があって、それを基にエンジニアが全体のアーキテクチャやデータ構造を考えつつ、どんなコードに落とし込むかを決めますよね。
なので業務志向の問題は毎回、仕様書にあたる問題文をしっかり読み込んで実装する実力があるかが、問われる内容にしています。
高橋:だから実務に近いという意味で、業務志向という位置づけなんですね。
大澤:その通りです。
高橋:問題文が長く解答時間も2時間半に限られているので、競プロとはかなり違う向き合い方が求められそうですね。競プロだと大抵、問題の内容自体はもっとシンプルなので、いろいろなアプローチでコードを書きながら効率の良い方法を探って、方向性がしっかり固まってから実装することが多いと思います。
でもこの問題だと、アプローチを決めるのに集中しすぎると時間が経ってしまいますね。
大澤:はい。そうなると実装にかける時間がなくなってしまいます。なので説明会などでは、「問題を読みながら、ラフでもいいのでデータ構造の設計とかを考えたほうがいい」みたいなことを言っています。
高橋:ここまで問題が長いと、国語力も試されますね。
大澤:そうですね。もちろん国語力を主に見たいのではないのですが、一方で実務だと機能を1つ作るだけでもかなり長い仕様をインプットしたりしますよね。なので問題を誤解なく読む力も、良いサービスを作る上で大事だと捉えています。
◆試験はTrack Test上で実施
スコアだけでなく、コードの“中身”も評価対象
――では、いくつか解答を取り上げつつ、大澤さんと高橋社長にディスカッションしてもらいたいと思います。まずは1人目、Aさんについてです。
大澤:これはあまり良くない例として取り上げました。競プロ向けのテクニック集などを参考にしているのかもしれませんが、forループをマクロでコンパクトにして書いています。効率的にループを回したいという意図なのだと思いますが、これくらいのループならば普通にfor文を書いてほしいですね。
理由は、LINEの開発では基本的にチームプレーを大事にしているからです。十数人、数十人といった規模のメンバーで1つのソースコードを作り上げていったりするので、誰が見てもすぐに分かるようなコードを書くことが大切です。
この書き方が致命的な減点になるものかというと、そうでもありません。でも評価する側としてこういう書き方はしてほしくないので、ここで取り上げました。
高橋:評価が難しい解答ですね。個人的には、実装の時間が限られることを踏まえると、このやり方をするのも理解できるんです。こういうふうにマクロを使った方が、慣れている人なら絶対に速いですから。
評価の対象を、出題の時点で明示した方がいいかもしれないですね。大澤さんの話を聞くとスコアと同じくコードの“中身”も重視するということなので、それを出題の時点で示してあげるわけです。純粋にスコアだけで評価されるならこのマクロの使い方は自然でしょうし、コードの中身が評価されるならこういうアプローチが良くないことは競プロの人たちも分かるはずです。
大澤:確かに、そこは改善点ですね。新卒採用向けのコーディング試験自体、まだ模索中というのが正直なところです。これまで3回実施しましたが、解答内容を検証しつつ毎年少しずつ変えて、より良いものになるようにしています。
高橋:ところでこの業務志向の問題だと、明確な「正解」を定めているのですか。
大澤:共通のテストデータをインプットした際に出力される値として、正解はあります。他方で、その値を得るためのアプローチは完全に参加者一人一人に委ねていて、自由です。
LINEのコーディング試験は再挑戦も可能。何度か落ちた後に合格し、入社した人も
――次の解答についても、解説などを聞かせて下さい。2人目、Bさんについてです。
大澤:良い部分と悪い部分があります。良かったのは、この問題の肝である配達時間の計算を関数で処理して効率化している点ですね。あとは、配達に2時間以上かかる場合に注文を受け付けない形にするための、分岐処理みたいな仕組みも関数を使って構築できています。2時間以上かのチェックと、それに該当する際にエラーを出力する部分ですね。
求められる機能を設計しようとする意図は、コードから伝わってきます。
――良くなかった点は。
大澤:データ構造を全部リストで作っていて、可読性とメンテナンス性が低くなっています。どのインデックスに何が入っているかはコメントに記されていますが、それを都度確認するのは効率的とはいえませんし……。既に述べたようにチームプレーを重視しているので、可読性は大事です。
――では3人目、Cさんはどうでしょう。
大澤:クエリに対応したクラスをちゃんと作ってデータ構造を設計しようという意図が見えるので、そこは良いポイントです。問題文では入力用のクエリを用意した上で処理を求めているので、その大事な部分を整理して読みやすくしている点は特に評価したいですね。
一方、main関数の中に全てのコードを書いているのは改善点です。この問題内容に対して速く解く手法としては、必ずしも間違ってはいません。良い点数を取れていますしね。ただ、我々はプログラム全体を設計する力を重視していて、関数を分けるとか構造化した書き方がされていないと、そのあたりの力が見えてこないというのが正直なところです。
高橋:この人は特に競技プログラマーっぽい書き方ですね。今までの人も競プロをやってそうなコードでしたが。実際の試験でも、こういう書き方が多いですか。
大澤:そうですね。逆に、しっかりクラス構造を作る人もいますが、割合としては多くありません。
高橋:ところでこの問題、時間が限られることもあってどうしても「運」の要素も出てくる気がします。そこはどう考えていますか。
大澤:それは否定しません。だから、というわけではないのですがLINEのコーディング試験は最大7回まで受けられるようになっていて、つまりたとえ落ちても、ある回数までは再挑戦できるんです(2022年7月時点、問題内容は毎回異なる)。それによって、ある程度公平性は担保できていると考えています。
高橋:それなら納得できます。7回やって結果が出なかったなら、それは実力ですね。
大澤:実際に入社したエンジニアの中にも、何回か落ちた後に数度目の受験でクリアした人が結構います。人によっては、最初は緊張して実力を出せなかったりしますしね。
高橋:よくよく考えてみると、「できる人」が実力以外の部分で1回や2回落ちてしまう可能性がある半面、「できない人」が受かってしまうことはなさそうですね。その意味では、採用試験の問題としてよくできている印象です。
スコアより、読みやすさを評価。「人に見せるコード」が求められるコーディング試験は、競プロとは別物
――最後の4人目、Dさんについてもコメントをお願いします。この人を最も高く評価しているようですね。
大澤:はい、その通りです。
高橋:あ、こっちの方が高評価なんですね。スコアが一番高いのはCさんですが……。
大澤:そうですね。コードの中身を評価した結果です。今回の参加者で唯一ちゃんとクラスを設計して、構成要素を的確に分割した書き方をしてくれています。パーサ(*2)もちゃんと関数に分けて書いていますね。エンジニアが簡単なバッチ処理を作る時にさらっと書くような感じに書けているというか。即戦力になりそうなコードです。
*2 各プログラミング言語の規則に則った構文になっているかをチェックするためのプログラム
高橋:少し驚きました。僕からしてみるとCさんとの違いはさほど大きくないんですが、スコアのビハインドが覆るほどDさんを高く評価しているわけですね。
大澤:そうですね。実務でコードを書けるかを重視する結果、こうなっている感じですね。繰り返しになりますが、まずはクラス設計をちゃんとやれているかどうか。必ずしも100%正しい設計である必要はありません。クラスに属するメソッドの位置づけとかもクリアな書き方がされていれば、我々と同じ目線でコードを書けることが分かるので、評価は高くなりますね。
高橋:ちなみに、例えば書き方はDさんみたいな感じで、ケアレスミスによってスコアが0点だったとしたら評価はどうなりますか。
大澤:さすがに低くなるでしょうね。これまで述べてきた通りスコアだけでなくコードの中身も評価対象ですが、とはいえ毎回、最低限取ってほしいスコアを“足切りライン”として設定していて、それを下回ると基本的には合格にしません。
高橋:逆に、Cさんが今回提出したのと同じような書き方で満点を取ったとしたら、Dさんとどっちを評価しますか。
大澤:やっぱりDさんですね。もちろん、ハイスコアを叩き出せる人が優秀なのは確かです。Cさんもコードが読みにくいわけではないので、低評価というわけではありません。
――今回対象にする4つの解答全てに対して、コメントをいただきました。高橋社長は全体を通してどんな感想を抱きましたか。
高橋:面白いですね。競プロだとやっぱり、スコアが全てじゃないですか。選考は競技じゃないのでスコア以外の部分も評価されるだろうなと思っていましたが、こんなに違うとは……。
なので、競プロとは別物だとあらためて感じました。確かに、一緒に開発する人のことを考えてコードを書けるかは大事です。LINEさんに限らず、どの会社も採用で重視しそうですよね。
だから、競プロよりも「人に見せるコード」を意識する必要があるんだと思います。コードはコンピューターだけが読むものじゃないんだよ、ということですね。
あと、コーディング試験ではなくてコーディング面接をやる企業もあるじゃないですか。これまで僕は、「コーディング試験はスコアが大事だから書き方はあまり気にしなくていい」「コーディング面接は問題を解けたかはさほど重要でなくて、良いコミュニケーションを取れるかがポイント」みたいな感じで言及することが多かったと思います。
でも、少なくともLINEさんの場合はコーディング試験だけど書き方がかなり見られるんですね。これは大きな発見でした。
――最後に大澤さんに聞きたいのですが、コーディング試験以外の選考、つまり面接などではどんなことを主に評価するのでしょうか。
大澤:候補者によって見る部分は変わるので一概には言いにくいですが、共通項があるとすれば実はコーディング試験にもつながっていて、チームで力を発揮できそうかですね。面接では、インターンや研究活動におけるチームプレーの経験を聞くことが多いはずです。チーム内でどういう立ち回りをしていたか、とかですね。
あとは、広い意味で課題解決に寄与ができる人かどうか。エンジニアリングって、結局課題解決じゃないですか。例えば「こういうシステムを作ってほしい」と言われたときに、仮にその必要がなければ「これをやればシステムを開発しなくて済みます」みたいな感じで、エンジニアリングのこと以外も考えつつ提案できる人は、採用したいですね。
エンジニアの仕事はコードを書くだけではありません。それに、コードを書いた瞬間から技術的負債が生じるので、そのメンテナンスなどトータルのコストも念頭に入れて課題解決を考えられる人は貴重だと捉えています。