CodeZine(コードジン)

特集ページ一覧

ソフトウェアエンジニアのスキルを測るには? コーディング面接の方法と、プログラミング力の測定と育成

プログラミング力、つけてますか? 第3回

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2021/06/01 11:00

目次

採用候補者のプログラミング力を測る

 あなたは、ソフトウェアエンジニアを採用したいとします。採用候補者に適切な実力があるかを測るため、採用プロセスの中で候補者と面接をします。そういうとき、みなさんはどういう面接をしているでしょうか?

 日本の面接現場においてしばしば見られた、あまり意味をなしているとは思えない面接があります。面接官が候補者のスキルや過去の経験などを聞き、候補者がそれに答え、なんとなく受け答えがあって、なんとなく良さそうだから採用、といった曖昧なやり方です。この手の面接をかつて私も受けたことがあります。印象は意外と馬鹿にならず、これでも案外評価できてしまうこともあります。しかし、受け答えは下手だが実際は優秀な候補者を落としてしまったり、受け答えだけが上手で全く優秀でない候補者を通してしまったりするリスクが高まります。

 私も採用候補者に、コーディングを評価する前に一般的なスキルやコードを書く姿勢についてさまざまな質問をしていた時期があります。その中には次のような候補者もいました。

 過去のプロジェクトもある程度も難しそうなことをやっており、実際にスキルもあると自称しており、コードを書くときの考え方・心構えを問うと非常に正しいことを言っているように感じます。しかし、実際にコードを書かせてみると、全くコードを書くことができないのです。「全くコードを書くことができない」のレベルは、単純なループが書けなかったり、単純なif文も書けないというレベルで、どうやって今までコードを書いてきたのか非常に不思議なレベルです。このような、受け答えは良さそうなのに実際にはコードが書けない候補者は、私の過去の経験では、書類審査通過者のうち5%程度いました。

 面接では、事前に候補者の何を測りたいのかを決め、それを測るための質問を用意しておく必要があります。普通は、最も測りたいことは、実際に候補者を採用したとして、この候補者が期待する役職をこなすことができるかでしょう。一般的には、ソフトウェアエンジニアにおいては、コードを書くことが最重要スキルの一つですから、コードを書くことができるかを必ず問うべきです。

コーディング面接

 実際に候補者にコードを書いてもらう面接は、コーディング面接と呼ばれます。コーディング面接という単語自体は前回の記事でも少し触れました。GAFAなどの西海岸の企業ではよく行われており、日本でもソフトウェアエンジニアのレベルの高い企業を中心に、コーディング面接が取り入れられています。

Googleでのコーディング面接

 私もかつてGoogleで採用の面接官をしていたので、Googleでのやり方を少しだけ述べておきます。機密保持契約があるため、詳細には紹介できず、公開されている情報をベースに述べていきます。それでもやり方の参考になると思います

 Googleでは、一人の候補者に対して、一対一の面接を複数回行います。ただし、最初の一人の面接の結果によっては、他の候補者が面接しても採用される見込みが薄いと判断され、それ以降の面接が組まれないこともあります。

 面接は、面接官があらかじめ用意してきた複数の問題を、候補者に目の前で実際に解いてもらうという形式で行われます。Googleが公式に出している動画があり、そこで多少の内容を知ることができます。個人的な感覚では、この動画で聞かれていることは結構易しめで、実際にはもう少し難しいことを聞いているように思います。

 面接の問題内容は公にはしていないはずなのですが、探すといくつか出てきます。ただし、Googleの面接だと有名な、バスにゴルフボールが何個入るかみたいなフェルミ推定をソフトウェアエンジニアの面接でやっている話は全く聞いたことがありません。また、問題が漏れていること自体は面接官も分かっているので、探したところで同じ問題が出ることは期待薄です。

 そもそも問題は単なる面接の会話の導入であって、それを解ける解けないで合否が決まるわけでもありません。きちんと基礎があって、問題を解くのにアイデアを出して議論ができるかが問われていますし、問題に関連した事柄がさまざまな形で深堀りして問われます。この深堀りにどこまで耐えられるかが面接の本題であると言ってもよいでしょう。深堀りされる内容は人によって全く異なりますが、得意分野の方へ深堀りされる傾向にあるので、いくつか得意分野を作っておくとよいでしょう。

コーディング面接の例

 さて、私も今の企業を創業してから、ソフトウェアエンジニアの面接にはコーディング面接を行っています。いくつかのタイプの問題を用意しており、コードを書く力とシステム設計の2つを問うようにしています。

 候補者のレベルが不明な場合、ソフトウェアエンジニアを目指すもの全員が知っておくべきで、かつある程度易しい(と思っている)ところから聞くようにします。例えば、配列中の特定の値を数えるコードを書いてもらったり、マージソートについて説明してもらったり、です。これは面接候補者に難しく考えなくていいですよとお伝えするためと、簡単な問題に正解してもらうことでリラックスしてもらうために行っています。この問題にうまく答えられない方もそこそこの割合(体感20%)でいますが、すごくヒントを出してでもなんとか正解してもらうようにしています。

 その後、候補者のレベルを知るために、本当に聞きたい問題を使います。私の場合は、ちゃんとコードが書けるか、設計ができるかということと、多少曖昧な仕様でも実装の落とし所を見つけて必要な設計が何であるべきか議論できるかを、コーディングを通じて聞いています。

 コードを書く力を問う問題では、スタックやキューを使える形で知っているか、再帰が書けるかを問うようにしています。典型的な例では、「任意の1文字にマッチする?や、0文字以上の任意の文字列にマッチする*を含むパターンがあって、文字列がパターンにマッチしているかを判定する」といったレベルのものです(この問題はLeetCodeではHardレベルと分類されていました)。経験的にこの難しさの問題は、腕が良いソフトウェアエンジニアはヒントなしででき、まともにコードをかけるレベルであればいくつかヒントをもらえばできるのですが、そうでないレベルの方はヒントをもらってもできません。これより難しいことを問うと、そもそも面接の体をなさないことの方が多いため、履歴書などの事前情報でできるとわかっているとき以外は使いません。

 実装の落とし所を聞く問題では、あえて正解がない課題を用意し、議論の過程を評価します。例として、「ウェブサーバーのデータをクロールしたいが、ウェブサーバーに極力負荷をかけたくないので100秒に100回程度までのアクセスにとどめたいです。このようにアクセス頻度を制限するものをしばしばthrottlerと言います。これをどのように設計しますか?」といったことを聞いたりします。

 プログラミングに慣れた人は大体「キューを用意して、過去100回のアクセス時刻を入れておき、最も古い時刻のものが100秒未満ならば待たせ、そうでなければ通過させる」という回答をします。制約を杓子定規にそのまま解釈すると確かにそうなります。しかし、これだと最初の1秒で100回アクセスし、残り99秒は待たせるということも許されます。そこで、「この方式だと、ウェブサーバーに極力負荷をかけたくないので、という部分に反していると思いませんか?」と聞くと、問題を読み替えて「1秒に1回だけアクセスを通す」みたいな回答が来ます(これが一番多い)。

 「たしかにそれもいいですね、でも、事後処理に1回3秒かかることが分かってるので最初3回アクセスしておいて事後処理を並列でやり、次にまた3回アクセスする、みたいなこともしたいんですよね……まあ1秒に3回ぐらいは同時アクセスしてもいいんじゃないでしょうか?」などと、色々と実際にありそうな条件を付け加えていきつつ、使いやすい設計を議論し、議論の過程を評価しています。 ここでアイデアが複数出て、アイデアの利点欠点を上手に比較できる人には設計をある程度任せられる、という判断をしています。

 ちなみに、この問題の頭の良い回答の1つの例として、クラウド上のバーストできるCPUなどで使われている、トークン方式があります。毎秒1つトークンが発行され、トークンは同時に5個まで保持でき、一度アクセスするにはトークンを1つ消費する、としておくとバースト的な利用も許されますし、100秒に100回程度までのアクセス、というのも満たせます。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:プログラミング力、つけてますか?

著者プロフィール

  • 川中真耶(カワナカシンヤ)

     株式会社ナレッジワークCTO / 株式会社ラムダボックス代表取締役。東京大学大学院情報理工学系研究科コンピュータ科学専攻を修了し、外資系IT企業にて、研究職やソフトウェアエンジニアとして勤務。他、国内ITベンダー勤務、スタートアップCTOの経験あり。現在2020年2月に株式会社ラムダボックスを創業...

あなたにオススメ

All contents copyright © 2005-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5