プログラマーの力量を見極める--面接官になったら尋ねるべき質問実例集

　ソフトウェア開発者を採用する面接の場においては、応募者の専門家としての力量を見極めることが最も困難な作業の1つである。彼らの考え方については、面接時に少しやり取りを行えばそれなりに見当が付くだろう。しかし、実際のプログラミング経験を推し量るのは至難の業だ。一部の企業では、さまざまなテストを実施することでこれを行おうとするものの、筆者の経験から言えば、こういったテストは近代的な開発環境では必要性が薄い知識（IDEのオートコンプリート機能や、F1キーの押下で表示されるヘルプ、インターネットといったものがあるため、ライブラリの知識は以前ほど重要ではなくなっている）の丸暗記能力を試すだけに終わることも多い。そこで本記事では、開発者を評価するうえでの優れた質問を紹介するとともに、なぜそれらが優れているのかを説明している。あなたが技術的な質問に対する返答を判定する自信がないというのであれば、上級開発者にも同席してもらえばよい。本記事で紹介している質問は汎用性のあるものとなっているため、あなたのプロジェクトに関する特定の質問を行うに先立って候補者を絞り込むために使用できるはずだ。

コンピュータ科学に関する基礎的な質問

　筆者は長い間、「プログラマー」を名乗る人であれば誰でも、コンピュータ科学に関する一定レベルの基礎知識を有しているものだと思っていた。しかし、そんなことはまったくない（！）ということが分かった。開発者であれば必ずコンピュータ科学の学位を持っているわけではないものの、開発者は皆、一定レベルの基礎的な知識を有していて然るべきである。こういった知識は日々のプログラミングで必ず必要となるわけではないものの、開発者であれば理解しておかなければいけないはずである。基礎的な知識の有無を判定する質問の例として、以下のようなものを挙げることができる。

• 「等値」と「等価」の違いを説明してください（この質問はTechRepublicのTony Patton氏に教えてもらったものである）。
• 「値渡し」と「参照渡し」の違いは何ですか？オブジェクト指向システムや手続き型システムにおいて、これらにはどのような違いが存在するのかを説明してください。
• 「ポリモーフィズム」とは何かを説明してください。
• 「悲観的ロック」と「楽観的ロック」を比較し、違いを明確に述べてください。

　これらの質問のうち、最初の2つに答えられない応募者は、どう考えても「入門者レベル」ということになる。また残り2つの質問は、「中級」開発者であれば答えられるはずである。

思考問題

　MicrosoftやGoogleといった企業が採用面接において応募者の問題解決能力を推し量るために行っている難しいテストがよく話題に上る。こういったテストはよく考えられており、有用であるものの、ほとんどのマネージャーや企業にとって、応募者にパズルを解かせる丸1日がかりのテストに時間を割く余裕などないというのが実情だろう。しかし、応募者がいかにうまく問題に立ち向かい、解決策を相手に伝えることができるのかを知っておくことは重要だ。筆者の経験から言うと、この種の質問の中で最も優れているのは「鶏の問題」である。筆者は約3年前の採用面接でこの質問を耳にした際、素晴らしい質問だと感心したものだ。具体的には、応募者に対して「自分の好きなようにできるとすれば、どのような鶏をデザインしますか？そしてその理由は何ですか？」と質問するわけである。この質問には「正しい答え」も「間違った答え」も存在しないものの、問題へのアプローチ方法を心得ている応募者であれば、詳しく回答できるはずである。また、応募者の中には「哲学者ぶって」（あるいはさらに悪い場合には非協力的な態度を示して）、「そもそも、鶏をデザインする必要が本当にあるのですか？」といった質問を返してくる者もいるだろう。こういった回答によって、仕事に対する彼らの姿勢をうかがい知ることもできるはずである。この質問は、上級開発者やソフトウェアアーキテクトの職を求めている人々に特に適している。もちろん、質問は鶏である必要はない。どのような動物でもよいし、何らかの機械であっても構わない。

ホワイトボードプログラミング

　（筆者の知る限り）採用面接で行われることが少なくなっている課題に「ホワイトボードプログラミング」というものがある。このテストでは、ある問題を応募者に与え、それを解決するアプリケーションを記述してもらうのだが、その際にはロジックの内容とその理由を説明しながらホワイトボードに擬似コードを記述してもらうようにするのである。ある観点から見た場合、このテストは上述の「鶏の問題」の実践版と言うこともでき、これによってその人物の開発者としての力量をうかがい知ることができる。このテストにはさまざまなシナリオを用いることができるため、あなたの会社の環境に合わせてもよいし、より一般的なものにしてもよい。このテストを成功させる鍵は、ホワイトボード上で表現しきれる量の擬似コードで解決でき、ライブラリ知識をあまり必要としない問題を作り出すことにある。詰まるところ、このテストの目的はプログラミングにおける自らの思考過程を説明できる人材を探し出すことであり、応募者がツールの使えない状況にどう対処するのかということを知るためではない。以下は、ホワイトボードプログラミングに適した問題の例である。

• 数値Xのフィボナッチ数を計算する。
• 指定された数値Xが素数であるかどうかを判定する。
• ループを使わずに配列の順序を逆にする。
• Fizz Buzz（関連英文ブログ）

　確かに、上記の問題は極めて基本的なものであるが、それらを解決するための短く正しい擬似コードを記述できる開発者の少なさにはあなたも驚くことだろう！もちろんのことながら、募集している職種に特化した質問を行っても構わない。

　筆者はある採用面接において、ホワイトボードプログラミングの変形版とでも言うべきものにお目にかかったことがある。問題を与え、擬似コードを記述させるのではなく、面接者が擬似コードを提示し、その動作を説明するよう求めるのだ。これは採用面接における優れた課題であり、コードを解析したうえでトラブルシューティングや修正を行う能力を判定するための優れたテストだと言える。

コードのレビュー

　コードのレビューは、開発プロセスの一部を構成することが一般的になっている。筆者が採用面接において効果的であると実感したテストは、応募者に何らかのコードを示し、レビューを行うよう求めるというものである。もちろん、そのコードには何らかの問題が存在していなければならないわけだが、そういった問題はピリオドが抜けているといった、コンパイラによってチェックできるものであってはならない。そういった問題を作り込むのではなく、応募者が最適化や、「フェンスポストエラー」（またはその他のよくある間違い）の存在を指摘できるようなコードにすべきである。こういったテストを用いることで、応募者が良いコードと悪いコードの違いを理解しているか、あるいは良いコードの書き方を知っているかといったことを判定できるようになる。

「よくある質問」

　ほとんどの採用面接で尋ねられる標準的な質問というものがいくつかある。例えば、「現在の仕事においてあなたが今までに直面した最も困難なことは何ですか？」や、「あなたの最も大きな弱点は何だと思いますか？」といった質問である。こういった質問は使い古されているとはいうものの、どのようなケースにおいてでも有効である。また、問いかけの内容を開発分野に絞ることで、さらに有益な質問とすることもできる。例を挙げると、「あなたの最も大きな弱点は何だと思いますか？」と質問するのではなく、「ウェブ開発におけるどういった側面が、あなたにとって最も大きな弱点だと思いますか？」と質問するわけである（ウェブ開発の部分は、あなたが関与しているプロジェクトに合わせて置き換えることができるはずだ）。また、応募者があなたの求めているスキルすべてを有していない場合、「こういったツールをすぐに習得できると思いますか？」といった質問をしてはいけない。相手は必ず、できると答えるためだ。そうではなく、当初は必要なスキルすべてを有していなかったにもかかわらず、仕事を遂行できたという経験について語ってもらうのが良いだろう。

経験をじっくり吟味する

　履歴書を審査する際に注意すべき大きな問題として、応募者がプロジェクトにほんの少ししか関与していないにも関わらず、そこで中心的な役割を果たしたかのように記載するというものがある。例えば、あるブレインストーミングにおいて筆記役を務めただけの人物が、履歴書に「仕様の検討と策定において豊富な経験がある」と記述することもあり得るわけである。このため、履歴書に記載されている経験について、あなたが興味を惹かれたものについては特に、具体的な内容を質問しなければならない。そして、応募者の答えを掘り下げていくわけである。こういったやり取りのイメージを描きやすいよう、以下にSusan（面接者）とKevin（応募者）の会話を例として紹介する。

Susan：あなたの履歴書には、CRMシステムの新規開発において重要な役割を果たしたと書かれていますが、そのことについてもう少し詳しく説明してもらえますか。

Kevin：その開発は、ASP.NETとMicrosoft SQL Serverを使用したウェブアプリケーションのものであり、開発言語はC#でした。

Susan：あなたはその開発においてどのような役割を果たしたのでしょうか？

Kevin：私はデータアクセス層とビジネスロジックを担当し、ユーザーインターフェースとの連携部分を実装するためにデザイナーとの共同作業も行っていました。

Susan：データベースとの通信にはどういったテクノロジを使用したのですか？また、ビジネスロジックはどこに格納したのですか？

Kevin：テーブルの構造はデータベース管理者によってあらかじめ設定されていたので、わたしはNHibernateを使用して該当データベース上での作業を行いました。そして、適切なメソッドや機能以外を隠蔽したデータアクセスオブジェクトを新たに作成しました。また、NHibernateやデータベース自体では行うべきでないデータ検証処理やデータ変換処理も別途担当しました。

　こういった質問を行うことで、Susanは短時間でものごとの核心をつかむことができたことになる。もしもKevinがプロジェクトにおける自らの役割や、使用したテクノロジ、その制約といったことについて明確に答えられなかったのであれば、彼は自らの経験を誇張して履歴書に記載しているという判断を下すことができるはずだ。

結論

　開発者の採用は一筋縄ではいかない。そして、不適切な人材を採用してしまうと、その人材が失敗をしでかしてもなかなか気付かない場合があり、そのフォローにはさらに時間がかかる場合もある。理想を言えば、応募者について知るために、一般的に行われている面接よりももっと長い時間をかけるべきであるものの、そのような余裕があることは少ないだろう。本記事で紹介しているティップスは、優れた開発者とそうでない開発者を見極めるために役立つはずである。