採用面接ゲリラガイド(version 3.0)

From The Joel on Software Translation Project

Jump to: navigation, search

Joel Spolsky / 青木靖 訳
2006年10月25日 水曜


無政府主義者とフリーラブの提唱者とバナナの権利の擁護者の寄せ集めの一団が、プエルト・バリャルタを出たラブボート号をハイジャックし、7日以内に要求が受け入れられなければ616人の乗客と327人の乗員もろとも、船を沈めると脅している。要求は何か? 番号を控えていない小額紙幣で100万ドルと、評価の高いWaterloo Fortran IVコンパイラ、WATFIVのGPL実装だ。(フリーラブの連中がバナナの権利の連中と合意できることがいかに少ないかは驚くばかりだ。)

Interviewing1.jpg

フェスティバルクルーズ社のプログラミングチームのチーフプログラマとして、あなたはFortranコンパイラを7日間でスクラッチから作れるか判断しなければならない。あなたには2人のプログラマがサポートにつく。

どうだ、できるか?

「条件によりますね」とあなたは答える。アーティクルを書いていることの何がいいかというと、何かをあなたが言ったことにしても、あなたはそれに対して何もできないってことだ。

条件って何のだ?

「えーと、私のチームでUML生成ツールは使えますかね?」

それは本当に重要なことなのか? 3人のプログラマで7日間でWaterloo Fortran IVだぞ。UMLツールに成否がかかっているというのか?

「そうは思いません」

じゃあ、何にかかっているんだ?

「19インチモニタはもらえますか? それとジョルトコーラをストックしておいてほしいですね」

もう一度言うが、それが重要なことなのか? できるかどうかがカフェインで決まるのか?

「そういうわけじゃありません。あ、待って。あなたはプログラマを2人、スタッフとしてつけると言いましたよね?」

ああ。

「誰を?」

それは重要なことなのか?

「もちろん! チームで馬が合わなければ、一緒に仕事はできません。それにFortranコンパイラを一週間で自分で作れるようなスーパースタープログラマなんてわずかしかいませんが、6ヶ月かけてもスタートアップバナーを表示するプログラムも書けないようなプログラマはごまんといるんです」

どうやら何かに行き当たったようだ!

ソフトウェアプロジェクトにとって一番重要なのは人なんだとみんなリップサービスはするけれど、それについて何ができるかとなると誰にも良くわからない。いいプログラマを手に入れたければ、最初に正しくやらなければならないのは適格なプログラマを雇うということだ。そしてそのためには誰が適格なプログラマか見分けられる必要があり、それは通常面接プロセスで行われる。だから今回は面接のすべてについて話すことにしよう。

(この実地の面接というのは、履歴書の順序づけ電話でのふるい分けから始まる採用プロセスの一部にすぎない。このアーティクルでは実地の面接だけを扱う。)

Interviewing2.jpg

採用されることになる人は少なくとも6人の人と面接するようにすべきだ。そしてその中には候補者の同僚となる人(これはマネージャではなくプログラマということだ)が少なくとも5人含まれているようにすべきだ。年配の世慣れたマネージャが候補者の面接をし、その人の判断だけで採用が決まってしまうような会社を知っているだろう。そういった会社ではあまり優れた人々は働いていない。1回の面接をすり抜けるのはとても簡単なことで、非プログラマがプログラマの面接をする場合は特にそうだ。

もし6人のうちの2人が採用すべきでないと判断したなら、その候補者は採用しない。だから候補者が採用されない場合、早ければ最初の2回で面接を打ち切れるわけで、そうするのは悪いアイデアではないが、残酷になるのを避けるため、候補者にはあらかじめ何人と面接することになるか言わないほうがいいかもしれない。私は面接者の誰でも候補者を落とせるという会社のことを聞いたことがあるが、これはちょっと行き過ぎという気がする。上級スタッフが候補者を落とすのは認めてもいいと思うが、下級スタッフの1人の気に入らなかったというだけで誰かを落とそうとは思わない。

たくさんの人の面接を同時にやろうとはしないこと。それはフェアじゃない。それぞれの面接は、1人の面接者と1人の被面接者が、閉まるドアとホワイトボードのある部屋でするべきだ。長い経験から言えることだが、面接に1時間はかけないと決断を下すことはできないだろう。

面接では3種類の人たちを見ることになる。一方の端には無知な大衆がおり、この仕事に必要となる最も基本的なスキルさえ欠いている。彼らはたいてい2、3の簡単な質問をするだけで、かぎ分けて取り除くことができる。その反対側の極端には、才能豊かなスーパースターがいて、彼らは週末に趣味でNintendo DS用のLispコンパイラをアセンブラで書いていたりする。そしてその中間には、何かには貢献できそうに見えるたくさんの「なんとも言えない人たち」がいる。コツはスーパースターと何とも言えない人を見分けるということで、何とも言えない人は採用しないということが肝心なのだ。

そして面接の終わりには、その候補者について鋭い決断をする準備ができていなければならない。その決断には2種類の結論しかない。採用か、不採用かだ。それ以外の答えというのはあり得ない。「採用してもいいけど、私のチーム以外に」とは決して言わないこと。これは無礼であり、候補者があなたと働けるほど頭が良くはないが、しかし向こうのチームの負け犬たちとならやっていけるだろうと言っているようなものだ。「採用してもいいけど、私のチーム以外に」と言いたくなったら、ただそれを機械的に「不採用」に変換すればいい。候補者があなたの抱えている特定のタスクは見事にこなせるが、他のチームではあまりうまくいかないだろうという場合、不採用だ。ソフトウェアの世界では、物事は非常に早く非常に頻繁に変わるので、あなたが投げ込むどんなプログラミングタスクでもうまくこなせるような人が必要なのだ。何かの具合で、SQLについては頗る優れているが、その他のトピックとなると何も学べないようなイデオサバンを見つけたという場合も不採用だ。あなたは短期的な痛みの解決と引き替えに、ずっと長く続く痛みを抱え込むことになる。

「いいかもしれないけど、わからない」とは決して言わないこと。もしわからないなら、それは不採用を意味する。これはあなたが考えるよりずっと簡単なことなのだ。わからないって? じゃあノーと言えばいい! 境界線上だという場合も、不採用だ。「まあ、採用にしてもいいかな。ただちょっと気にかかるのは・・・」みたいなことは決して言わないこと。そういうのもまた不採用だ。煮え切らないものはすべて機械的に「ノー」に置き換えて差し支えない。

Interviewing3.jpg

なぜ私はこのことに関してそんなに強行なのか? それはいい候補者を落とす方が、まずい候補者を採用するよりもずっとましだからだ。まずい候補者にはたくさんの金と労力がかかり、彼らのバグを直すために他の人の時間が奪われることになる。間違って採用した人を解雇するのには何ヶ月もかかり、悪夢のように難しいかもしれない。彼らが訴訟に打って出ようという場合には特にそうだ。状況によっては、解雇するのがまったく不可能になるかもしれない。まずい社員はいい社員のやる気をくじく。そして彼らはプログラマとしてはまずくとも、人間としては本当にいいやつだったり、この職をどうしても必要としているため、あなたは彼らを解雇するのが忍びないかもしれず、あるいは解雇することでみんなうんざりすることになるかもしれない。そういうのは嫌なものだ。

一方でいい候補者を落とすというのは、ある実存的な意味において不正なことが行われたことになると思うのだが、だけど、ねぇ、彼らがそんなに頭がいいんなら、大丈夫、彼らにはいい仕事の口がたくさんあるだろうから。あまりに多くの人を落として採用する人を誰も見つけられなくなるんじゃないかと心配しないことだ。面接の間は、それはあなたの問題ではないのだ。もちろんいい候補者を探し出すのは重要なことだ。しかしひとたび誰かを面接するとなったら、ドアの外には900人の候補者が列をなしているのだという振りをするのだ。優れた候補者を見つけ出すのがいかに難しく感じられようと、基準を下げてはいけない。

OK、私は最も重要な部分をまだ話していなかったね——誰かを採用すべきかをどうやって知るかということだ。

原理的には単純だ。あなたが探す人というのは

  1. 頭が良く
  2. 物事を成し遂げる

以上。これがあなたの探すもののすべてだ。記憶しておくように。毎晩布団に入る前に復唱するといい。短い面接の間にあまりたくさんのことを調べる時間はないだろうから、その候補者が空港で足止めされたときに一緒にいて好ましい相手かどうかとか、彼らがATLとCOMのプログラミングを知っている振りでなく本当に知っているか確認しようとして時間を無駄にしないことだ。

頭はいい物事を成し遂げない人というのは、しばしばPhDを持っていて大企業で働いているが、まったく実用的でない彼らの言うことなんか誰も聞いてはいない。彼らはスケジュール通りに出荷することよりも、何かアカデミックなことについてあれこれと考える。そういう種類の人は概念的に大きく隔たったものの間にある理論的な類似性を指摘したりするのを好む事で識別できる。たとえば、彼らは「スプレッドシートというのは、実際のところ、プログラミング言語の特殊なケースにすぎない」みたいなことを言い、そうして1週間ほど休みを取って、プログラミング言語としてのスプレッドシートの理論計算言語的属性についての見事でスリリングな論文を書くのだ。頭はいいが役には立たない。そういう人を見分けることのできるもうひとつの場合は、彼らがあなたのオフィスにコーヒーマグ片手に現れ、JavaのイントロスペクションとCOMタイプライブラリの相対的優位性についての長い議論を、ベータ版をリリースしようとしているその日にやろうとするようなときだ。

頭は悪い物事を成し遂げる人というのは、考えもなしにバカなことをやり、誰か他の人がその後始末をしなければならなくなる。彼らは貢献できないばかりか、優れた人々の時間さえ奪ってしまうので、会社にとってはお荷物になる。彼らは製品のコアのアルゴリズムをさっき読んだばかりのビジターパターンを使ってリファクタリングしようとするのだが、完全に誤解していて、配列の要素をループで加え合わせるだけの単純なコードを、AdderVistiorクラス(しかもスペルミスがある)とVisitationArrangingOfficerシングルトンクラスを使うように変えていて、プログラムはもはや動かなくなっている。

Interviewing4.jpg

面接で頭の良さをどうやって見出せばいいのか? 第一の良い兆候としては、何度も同じことを繰り返し説明せずに済むということがある。会話はただ自然に流れる。しばしば候補者は何か本当の洞察や知能や頭の鋭さを示すようなことを言う。だから面接で最も重要な部分は、候補者がいかに頭がいいか示せる状況を作るということだ。その意味で最悪の面接者は自慢屋だ。彼は面接の間中ずっと自分でしゃべっていて、候補者には「ええ、本当に。まったくそう思います」と言うくらいの時間しか与えない。自慢屋は誰でも雇ってしまう。彼らは候補者が「こんなにも自分と同じ考え」なのだから、頭がいいに違いないと思うのだ。

2番目にまずい面接者はクイズショー面接者だ。このタイプの人は頭がいいというのは「たくさんの事実を知っていること」だと思っている。彼らはただひたすらプログラミングに関する雑学問題を出し、正解に対してポイントを与える。面白半分に、地上で最悪の面接質問を挙げておこう。「Oracle 8iのvarcharとvarchar2の違いは何か?」 これはひどい質問だ。この特定の雑学について知っている人と、あなたが採用したいと思う人との間には、想像しうるどのような相関もない。そんな違いを誰が気にするの? 15秒もあればオンラインで調べられるというのに! 頭がいいというのは「雑学問題の答えを知っている」ことではないというのを覚えておこう。何にしても、ソフトウェアチームというのは特定のスキルセットではなく、資質を持った人を雇いたいものなのだ。人々が仕事に持ち込むどんなスキルセットも、2年もすれば技術的に古くなってしまうだろう。だからJDBCでMySQLデータベースにアクセスする方法をたまたま知っている人よりは、どんな新しいテクノロジーでも学ぶことのできる人を雇った方がいい。

一般に、ある人について最も多くのことを知る事ができる方法は、その人に話をさせることだ。彼らに自由解答式の質問と問題を与えるのだ。

では何を聞けばよいか?

私が個人的に使っている面接質問のリストは、私が最初に仕事をしたMicrosoftに端を発するものだ。Microsoftの面接質問には、有名なのがそれこそ何百とある。誰もが本当に気に入っている質問のセットを持っている。あなたも自分なりの面接スタイルと質問のセットを開発することで、採用/不採用の判断に役立てることができるだろう。以下では私が使っていてうまく行っているテクニックをいくつか示していこう。

面接の前に、私は候補者の履歴書を読み返し、面接のプランを紙切れに書き出すようにしている。プランと言っても、要は私が聞きたいと思っている質問のリストだ。次に挙げるのはプログラマの面接で使う典型的なプランだ。

  1. イントロダクション
  2. 候補者がやった最近のプロジェクトについての質問
  3. 簡単なプログラミングの質問
  4. ポインタ/再帰の質問
  5. 答えに満足しているか?
  6. 質問は?

私は候補者に対する先入観を与えるものを避けるように非常に注意を払っている。誰かがMITのPhDを持っているというだけの理由で、その人が部屋に入ってくる前から頭がいいだろうと思っていたとしたら、彼らが一時間の間に何を言おうと、その先入観は覆らない。候補者がコミュニティカレッジに行っていたのだから頭が良くはないだろうと思っていたとしたら、彼らが何を言おうとその先入観は覆らない。面接というのはとても精密な秤のようなものなのだ。誰かを一時間の面接に基づいて判断するというのはとても難しく、すごく微妙な判定になるかもしれない。しかしあなたが候補者について前もって少しばかり知っていたとすると、それは大きな重りを秤の一方に載せるようなもので、面接は無意味なものになってしまう。一度、面接の直前に、リクルーターが私のオフィスにやってきて言ったことがある。「あなた彼のこときっと気に入るわよ」。これにはすごく苛立った。私が言うべきだったのは、「私が気に入るとそんなに確信しているんだったら、面接で私の時間を無駄にしたりしないで、さっさと彼を採用したらいいじゃない」ということだ。しかし私は若くて経験もなかったので、彼を面接することにした。彼があんまり頭の良くないことを言った場合でも、私は「ああ、法則を証明する例外ってやつだ」と思った。私は彼の言うことをすべて、バラ色の色眼鏡を通して見ていたのだ。彼がひどい候補者だったにもかかわらず、私は採用と言っていたことだろう。それでどうなったと思う? 彼を面接した他のみんなは不採用と言ったのだ。だからリクルーターの言うことには耳を貸さず、面接前に候補者のことを聞いて回ったりせず、それぞれ別個に結論を出すまでは他の面接者と候補者について決して話さないこと。それが科学的方法というものだ。

Interviewing5.jpg

面接のイントロダクションは候補者をリラックスさせるためのものだ。私はここに来るまでのフライトはどうだったかと聞く。それから30秒くらい使って自分が誰で、インタビューがどう進められるのか説明する。私はいつも、興味があるのは問題をどう解くかであって、答えそのものではないと言って候補者を安心させるようにしている。

パート2は候補者がやった最近のプロジェクトについての質問だ。大学生を面接する場合には、卒論があればそれについて、なければ彼らが履修した授業で本当に楽しんでやった長期のプロジェクトを含むものについて聞けばいい。たとえば、私はよく「前の期に取った授業で一番好きだったのは何? コンピュータ関係でなくてもいいよ」と聞く。業務経験のある候補者を面接するときは、前の職で最後に割り当てられていた仕事について聞けばいい。

ここでも自由解答式の質問をし、ゆったり座って耳を傾け、そして時折、彼らが言葉に詰まっているようなときに、「それについてもう少し聞かせて」と言おう。

自由解答式の質問で探すべきものは何か?

1) 情熱を探す。頭のいい人々は、自分のやっているプロジェクトに対し情熱的なものだ。彼らはそのテーマについて話していてとても興奮する。早口になり、生き生きとしてくる。情熱的に否定的であるというのも同じように良い兆候でありうる。「私の前の上司は何でもVAXコンピュータでやろうとして、それというのもあの人にわかるのはそれだけだったからなんです。あの間抜け!」 何かはできるのだが、やっていることについて本当に関心を持ってはいない人というのがあまりに多い。そういう人に何かをやる気にさせるのはすごく難しい。

まずい候補者は関心を持たず、面接の間まったく熱くならない。候補者が何かについて情熱的であることの本当に良い目印となるのは、それについて話しているとき、しばらくは面接を受けていることすら忘れてしまうということだ。候補者が入ってきたときに、面接という状況下ですごく緊張していることがある。これはもちろん普通の事であり、私は別に気にかけない。しかし彼らに計算的単色画について話させると、彼らはすっかり興奮して、緊張のあとがすっかり消える。いいね。私は物事に関心を持っている情熱的な人が好きだ。(計算的単色画の例を見たければ、モニタのプラグを引っこ抜いてみるといい。) 彼らに何かについて挑んでみるのもいい(試してみて——彼らが何かたぶん正しいことを言うのを待って、それに対して「そんなはずはない」と言ってみるのだ)。 彼らは反論し、5分前には冷汗をかいていたのに、こだわりを持っているものだから、あなたが「彼らの人生についての重要な決断」をもうじき下そうとしているということすら忘れてしまうのだ。

2) いい候補者は、どのようなレベルであれ、物事を説明するのに注意を払う。前にやっていたプロジェクトについて話すとき、普通の人が理解できるように説明できない候補者を私は落としてきた。コンピュータサイエンス専攻の人は、ベイツの定理とは何かとか、O(log n)が何を意味するのかといったことを誰でも知っているものだと仮定しがちだ。彼らがそれをやり始めたなら、いったん彼らを止めて、「お願いだから、練習だと思って、私の祖母でも理解できる言葉で説明してくれないか」と言う。この時点でも多くの人が依然ジャーゴンを使い続け、自分の考えを相手に理解させることに完全に失敗する。カーン! あなたはそういう人を基本的に雇いたいとは思わないだろう。彼らは自分の考えを人に理解させるためには何が必要か理解できるだけの頭を持っていないからだ。

3) プロジェクトがチームでのものなら、彼らが果たしたリーダーシップの兆候を探す。候補者は「私たちはXをやっていたのですが、ボスがYといい、クライアントはZと言ったんです」みたいなことを言うかもしれない。私は「それであなたは何をしたの?」と聞く。これに対するいい答えはたぶん「私は他のメンバーといっしょに提案書を書き・・・」というものだ。まずい答えはたぶん「私にできることは何もありませんでした。不可能な状況だったんです」というものだ。頭が良く物事を成し遂げる、というのを思い出して。誰かが物事を成し遂げるか知ることのできる唯一の方法は、その人が過去において物事を成し遂げてきたか見ることだ。実際、あなたは彼に、最近リーダーシップを発揮して何かを成し遂げたときのことについて、例を挙げるように直接聞いてもいい。たとえば体制上の惰性を打開したというような。

Interviewing6.jpg

しかし面接の時間のほとんどは、候補者にコードを書けることを示させるのに使うべきだ。

エディタなしでコードを書くのが難しいことは理解しており、ホワイトボードに書いたものがごちゃごちゃしていても大目に見るということ、また、コンパイラなしにバグのないコードを書くのが難しいこともわかっており、それを考慮するということを話して、候補者を安心させるようにしよう。

私は1日の最初の面接には、すごーく簡単なプログラミング問題を含めるようになった。そうするようになったのはドットコムブームのときで、HTMLが「プログラミング」だと思っている人たちがたくさん面接に顔を出すようになったためだ。それで彼らの相手であまり多くの時間を無駄にしないようにする方法が必要になった。それは今日仕事しているプログラマであれば誰でも1分くらいで解けるはずの問題だ。いくつか例を挙げよう:

  1. 文字列が大文字のアルファベットA-Zではじまるかどうかを調べる関数を書け
  2. 与えられた半径を持つ円の面積を求める関数を書け
  3. 配列の要素の値を加え合わせよ

こういうつまらない問題はあまりに簡単に見えるので、最初彼らに聞いたときには、みんなすぐに正しい答えを出すものと思っていた。私が発見したのは、みんな問題を解くことは解いたのだが、解くのにかかった時間に大きな差があったということだ。

このことは私になぜ債権取引の仕事ができないのかを思い起こさせる。

ジャレドは債権トレーダーだ。彼はいつも私に自分のやった興味深い取引のことを話してくれる。オプションと呼ばれるものがあり、それにはプットとコールがあって、そしてマーケットがスティープになるときにはスティープナーにプットする。これはすごく混乱させられる。しかし奇妙なのは、私はこれらの言葉のそれぞれが何を意味しているのかはわかっているということだ。プットが正確に何か分かり(何かをある価格で売る権利だが、売る責任はない)、プットを持っていてマーケットが上がるとき何が起きるかほんの3分あればわかる。しかし私にはそれがわかるのにまるまる3分かかる。プットは最初のごく小さな部分で、そのほかのたくさんの要素が出てくるような、もっと込み入った話を彼がすると、私はすぐに筋を見失ってしまう。思考の中で迷子になってしまうのだ(「待てよ、マーケットが上向くということは、利率は下がるだろ、それでプットは何かを売る権利なわけだから・・・」)。そうするとジャレドはグラフ用紙を取り出して1つ1つ順を追って説明し始める。私の目はぼうっとしてしまい、すごく惨めに感じる。私は細かい部分部分はすべて理解しているにしても、全体像が掴めるほどに十分早く理解する事ができないのだ。

そして同じ事がプログラミングでも起きる。基本的なコンセプトが考えるまでもないというくらい簡単に思えるのでなければ、大きなコンセプトを把握することはできないのだ。

イェール大学の数学教授だったサージ・ラングは、解析学の最初の授業の日、学生にすごく簡単な代数の問題を出していた。その問題はほとんどの者が解くことができたが、ある者は書くのが追いつかないくらい早く解いたのに対し、他の者はしばらく時間がかかった。そしてラング教授は書くのが追いつかないくらい早く解いた学生は解析の授業でAを取り、その他の者は取れないだろうと言った。まるまる1期分の宿題とテストと中間テストと期末テストで決まる解析学の成績に対し、簡単な代数の問題を解くスピードによって優れた予測ができるのだ。

簡単なものを時速100マイルのスピードで片づけられなかったなら、高度なものには到達できないのだ。

しかしいいプログラマというのは立ち上がってホワイトボードに答えを書いているとき、ときどき巧妙なひねりを加える(そうだ! Unicodedのサポート! いいぞ!)。そしてそれには30秒かかる。だから彼らが本当に優れているか判断するために、再帰とポインタという切り札を出すことになる。

Interviewing7.jpg

15年に渡ってプログラマを面接してきた経験から私は確信しているのだが、最高のプログラマはみな、複数の抽象レベルを同時に易々と扱える才能を持っている。プログラミングの場合で言うと、これは特に再帰(頭の中に同時に複数のレベルのコールスタックを保持することになる)や、複雑なポインタベースのアルゴリズム(オブジェクトのアドレスがオブジェクト自体の抽象的表現のようになっている)を全然問題なく扱えるということだ。

私はCのポインタを理解できるというのはスキルではなく、才能であるということに気付いていた。コンピュータサイエンスの初年度の授業には、学期のはじめにいつも200人くらいの学生がいる。彼らは皆4歳のときにPCのBASICで複雑なアドベンチャーゲーム書いてたりする。彼らは大学で楽しくCやPascalを学ぶのだが、ある日教師がポインタを導入すると、突如として彼らはわからなくなってしまう。彼らはもはや何も理解できなくなり、クラスの90%が逃げ出して政治科学専攻に切り替え、そして友達にはコンピュータサイエンスのクラスにはあまりかわいい子(かっこいい人)がいなかったから切り替えたのだと言うのだ。何かの理由で、多くの人は脳のポインタを理解する部分を持たずに生まれてくるように見える。ポインタは複雑な形態の二重に間接的な思考を必要とし、ある人々にはそれは単に不可能なのだが、いいプログラムを書くためにはきわめて重要なものなのだ。多くの「スクリプト屋」たちはプログラミングをJavaScriptのスニペットをホームページにコピーするところからはじめ、それからPerlを学ぶのだが、ポインタについて学ぶことはなく、彼らにはあなたの必要とするクオリティのコードは決して作ることができない。

これがあなたの耳にしているあの「リンクリストを逆にする」とか「木構造の中のループを見つける」といった有名な面接問題がある所以なのだ。

いいプログラマはすべて再帰とポインタを扱えるべきであり、これはその人がプログラマとして優れているか見分けるためのいい方法でもあると私は考えている。しかしあいにくと最近のプログラミング言語はほとんど完全にこの技術を不要にしているというのが本当のところだ。10年前にはコンピュータサイエンスの学生が再帰と関数プログラミングの授業を1つと、CかPascalによるデータ構造の授業を1つ取ることなく大学を出ることはなかったのだが、今日では、他の点では申し分ない大学の多くがJavaだけで楽に乗り切れるようになっている

近頃では、あなたが面接する多くのプログラマは、再帰や、ポインタや、データ構造でさえ、つまらない実装上の詳細であり、今日の楽しいプログラミング言語が抽象化し去るべきものだと考えている。そして「あなたが最後にソーティングアルゴリズムを書いたのはいつのことですか?」と言ってせせら笑うのだ。

しかし私はあまり気にはしていない。私はERの医者が解剖学を理解していることを望んでいる。たとえ彼女がしなければならないのが、コンピュータ制御の心臓細動除去器の接点を私の胸につけて、大きな赤いボタンを押すことだけであったとしてもだ。そして私はプログラマにはCPUレベルまで理解していることを望んでいる。たとえRuby on Railsがあなたの心を読んで完全なWeb 2.0ソーシャル・コラボレーティブ・ネットワーク・サイトをマウスクリック3回で作ってくれるのだとしてもだ。

Interviewing8.jpg

インタビューの形式が、表面的にはただ候補者がホワイトボードにコードを書くだけというものであっても、私のここでの本当の目的は、そのコードについて会話をすることなのだ。「なんでそんな風にしたの?」「君のアルゴリズムのパフォーマンス特性はどういうものだろう?」「何か忘れてない?」「バグがどこにあるかわかる?」

これは、難しすぎるプログラミング問題を出すのも気にかけないということだ。候補者が手を付けられるチャンスがありさえすればいい。そうしたら私は進めながら小さなヒントや、小さな足がかりみたいなものを喜んで出してあげる。私は誰かに三角形を平面に投影することを求めるかもしれない。典型的なグラフィックスの問題だ。三角法について助け船を出すのは全然問題ない(SOH-CAH-TOAだよ!)。そして私がどうやってそのコードをスピートアップできるか聞くときには、ルックアップテーブルについてちょっとしたヒントを出してやるかもしれない。私が喜んで出してやるヒントは、実際は(Googleで見つけられるような)雑学問題の答えなのだということに注意してほしい。

あなたはもちろん彼らの関数にバグを見つけることだろう。それで面接プランの5番目の質問がくる。「そのコードで満足している?」 あなたは「OK、じゃあバグはどこにあるかな?」と聞きたくなるかもしれない。典型的な地獄の自由解答式質問だ。プログラマは誰でもミスをする。そのことに悪いことは何もない。ただ彼らはそれを見つけられる必要があるのだ。Cの文字列関数では、ほとんどの大学生は新しく作った文字列を0終端し忘れる。ほとんどあらゆる関数で、彼らは良くあるエラーを作り込む。ときどきセミコロンを付け忘れる。彼らの関数は長さ0の文字列では正しく機能しないかもしれず、あるいはmallocが失敗したときに一般保護違反を起こす・・・ごくごく希に、最初からバグのまったくないコードを書く候補者がいる。そういう場合には、この質問はさらに楽しいものとなる。あなたが「このコードにはバグがあるよ」と言うとき、彼らが自分のコードを注意深く見直し、それから礼儀正しいながらも毅然としてコードは完璧だと断言するか見てみるのだ。

面接の最後のステップとして、候補者に質問がないか聞く。あなたが彼らを面接しているにしても、いい候補者にはどこで働くかについてたくさんの選択肢があり、彼らはこの日を使ってあなたのところで働きたいと思うか判断しているのだ。

面接者によっては、候補者が「知的な」質問をするか見ようとする。個人的には、私は彼らが何を聞こうと気にかけない。この時点では私はすでに心を決めているからだ。候補者は1日のうちに5人か6人の人たちに会わなければならず、5人か6人の人に異なる鋭い質問をするというのは難しい事なので、彼らに聞くことが何もなかったとしても差し支えない。

私はいつも面接の最後の5分間を、候補者に対して会社と仕事を売り込むのに使っている。これは実際彼らを採用しない場合でも重要だ。幸運にもとてもいい候補者が見つかったという場合、その人が間違いなく働きに来てくれるようにするためにできることは何でもしようと思う。そして彼らがまずい候補者であった場合でも、会社のことを好きになり、いい印象を持って帰ってほしいと思う。

そうだ、本当にまずい質問の例をもっとあげるべきだったのを思い出した。

何よりも違法な質問を避けること。何であれ人種や宗教、性別、国籍、年齢、兵役適格性、退役ステータス、性的指向、身体障害に関する質問をするのは、アメリカでは法に反する。彼らの履歴書に海兵隊にいたと書いてあったとしても、たとえ楽しく会話するためであっても、イラクに行ったのかと聞くことはできない。それは兵役ステータスに基づく差別を禁じる法律に反するのだ。彼らの履歴書にハイファのテクニオンにいたとあっても、たとえ雑談としてであろうと、あなたの奥さんがイスラエル人だったり、ファラフェルが好きなのでおしゃべりしたいと思っただけなのであっても、彼らがイスラエル人なのかとは聞かないこと。それは国籍に基づく差別を禁止する法律に反するのだ。

次に実際には気にもしていなければ判断の基準にもしていないことについて、気にしていたり判断の基準にしているように見えるような質問は避けること。これについて思いつく一番いい例は、子供がいるかとか、結婚しているかと聞くことだ。これは子供のいる人は仕事に十分な時間をさけないとか、産休を取るかもしれないとあなたが気にかけているような印象を彼らに与えることになる。基本的に、彼らが面接を受けている対象の仕事に関係がある質問だけをすること。

最後に、6本の同じ長さの棒を並べて4つの同じ形の三角形を作れ、というような頭の体操みたいな質問は避けること。海賊や大理石や暗号が出てくるものはみんなだめだ。そういったもののほとんどは"Aha!"クイズで、答えを知っているか知らないかのどちらかで決まる問題だ。こういった問題で答えを知っているというのは、単にその問題を前に聞いたことがあるというだけのことだ。だから面接者としてのあなたは、彼らが知的な飛躍をするかどうか見ようとしたところで、それによって「頭のいい/物事を成し遂げる」ことについての情報は何も得られないのだ。

以前私は、「無理な問題」、あるいは「封筒裏の問題」として知られるものを使っていた。これの典型的な例は、「シアトルにピアノ調律師は何人いるか?」というものだ。候補者は答えを知るわけがないのだが、頭のいい候補者はあきらめずに、もっともらしい数字を推定しようと嬉々として取り組む。ちょっと考えてみましょう。調律師はたぶん・・・えっ、シアトルの人口ってどれくらいでしたっけ? ピアノを持っているのは1%くらいかな? ピアノを調律するのは年に2回くらいでしょうか? 1台調律するのにかかるのは35分とか? もちろん全部間違っている。しかし少なくとも彼らは問題に挑戦している。こんな質問をしている理由は、それで候補者と話ができるからだ。「OK、35分としておこう。でもピアノの間の移動時間はどう?」

「いい指摘ですね。ピアノ調律師があらかじめうまく予約を取っておけるなら、移動時間が最小になるようにスケジュールを調整するでしょう。520号線を日に3度も行ったり来たりするよりは、月曜にレドモンドのピアノを全部やってしまおうとするでしょう」

いい封筒裏の問題は、候補者と話ができるようにしてくれ、彼らが頭がいいかについて考えをまとめる助けになる。悪い「Aha!」海賊問題の場合は、通常候補者がしばらくの間ただあなたを見つめていて、それから降参と言って終わりになる。

面接の終わりに、その人が頭が良く物事を成し遂げる人だと納得させてくれ、4人か5人の他の面接者も同じ意見なら、あなたはその人を雇ってもたぶんまずいことにはならないだろう。しかしもし何であれ疑念があるなら、誰かもっといい人の現れるのを待った方がいい。

候補者について決断を下すのに最適な時は、面接が終わった3分後だ。あまりに多くの会社が、面接者が結果を出すのに何日、あるいは何週間もかけさせている。あいにくと、時が経つほど記憶は薄れていくものなのだ。

私は面接者には面接のあと即座にメールでフィードバックを返すように求めている。最初に「採用」か「不採用」かを書いて、そのあと1パラグラフか2パラグラフ使って理由を説明するのだ。これの納期は面接の終わった15分後だ。

あなたが決断するのに困難を感じるなら、簡単な解決法がある。不採用にすればいい。確信が持てない人は単に雇わないことだ。最初の何回かは、少し神経にこたえるかもしれない。もし誰も見つけられなかったらどうしよう?と不安になるかもしれない。それは大丈夫だ。履歴書の処理と電話でのふるい分けのプロセスがちゃんと機能していれば、あなたはたぶん直に面接した人の20%くらいを採用することになるだろう。そして頭が良く物事を成し遂げる候補者を見つけたときには、あなたにはそれとわかる。その人にぞくぞくしなかったなら、別な人を当たることだ。


(オリジナル: The Guerrilla Guide to Interviewing (version 3.0))

戻る

Personal tools