Joel on Software

Joel on Software   このページは"ジョエル・オン・ソフトウェア

 

※新しい翻訳はJoel on Software Translation Projectにあります。

その他の "Joel on Software" の記事(日本語)

その他の "Joel on Software" の記事(英語)

著者へのメール(英文のみ)

 

ゲリラ的雇用面接のすすめ


Joel Spolsky ジョエル・スポルスキ
翻訳: 松村 弘典
2000-03-23

Fog Creek Softwareでは適切にスタッフを採用する事が必須である。我々の業界では対象となる人々を3つのタイプに分類する事が出来る。一方には 未洗のイモ とでも呼ぶべき、この業種に従事するのに基本的なスキルさえも持ち合わせていない集団がいる。これらの人たちは履歴書を注意深く確認して2,3の簡単な質問をする事で比較的容易に除外する事が出来る。対極には スーパースター と呼ばれる、パーム上で動くLispコンパイラを週末の暇つぶしにアセンブリ言語で書いてしまうような人たちがいる。これらの中間にあたるのが大多数の「応募者」で、何かしらやってくれるのではないかと思わせる人たちである。ここで紹介する幾つかのトリックはこれら一般的な応募者とスーパースターとの違いを見極めるためのものであり、Fog Creek Softwareはスーパースター以外は採用しない。

まず始めに。Fog Creek Softwareに採用されるような人材には以下の要素が求められる。

賢くて、
結果に結びつけられる。

これは非常に重要だ。ただこの点さえ思い出せてもらえれば良い。夜布団に入る前に毎晩暗誦して欲しい。我々の欲しているのは「 才能 」に溢れた逸材であり、特定のスキルを持つ技術者ではない。どのようなスキルも技術的に数年すれば時代遅れとなる。重要なのはどのような新技術でも習得する事の出来る人を採用する事であり、たまたまちょうど良いタイミングでSQLを知っていた人を採用する事ではない。

賢くて を定義するのは容易ではないが、先々で紹介してゆく面接の質問のなかでどうやって探してゆくかを見てゆこう。「 結果に結びつけられる 」ことは重要だ。しばしば大企業で見かける 賢くて しかし 何にも結果に結びつけられない人はたいがい博士号を掲げていて、常に非現実的な学術的思想を持ち出すのでほとんどの人から相手にされない。彼らにとっては学術的に問題を掘り下げてゆく事こそが至上であり、日程どおりに納品できる事は重要な事ではない。これらの人々は簡単に識別する事が出来る。彼らは大きく異なるコンセプトにセオリー的な類似性を見出す事が大好きで、たとえば「表計算はプログラミングのひとつの発展形だ」といって一週間ほど姿を消し、それがいかにプログラム言語に類似した計算言語としての属性を持つかについてのすばらしい論文を書き上げる。非常に賢い。が、役には立たない。

さて、 結果に結びつけられる賢くない 人たちはろくすっぽ物事を考えずに事を進めるので、結局誰か他の人が後始末をしなければならなくなる。有能な人たちの時間を吸い上げるこれらの人たちは会社の「負債」と言い換えることが出来る。関数化してまとめる事もせずにソースコードのブロックを丸ごとコピー&ペーストするような人たちがこれにあたる。結果的には確かに「結果に結びつけられ」てはいるが、あまり賢いやり方ではない。

面接で最も重要な事は:

結論を出すということ。

面接の結果として、あなたは候補者に関する鋭い決断を下さなければならない。ここでの決断には2通りしか存在しない。 採用 か、 不採用 である。自分のPCに向かい、あなたのフィードバックを人事担当に即刻送信する。件名には候補者の名前を、本文の一行目は 採用 か、 不採用 であるべきだ。あとは何故そうなのかを説明する文が一行二行あればいい。

これら以外の決断は存在しない。 決して「他グループでなら採用してもいいんじゃないかな」のようなことは言わない事。これは大変無礼な答えで、候補者は私と働くには少々力不足だが、他の凡人部署には適当であろうと言っているのと同じである。もしもあなたがこれを言いそうになったら、機械的に「不採用」と翻訳していい。もしも候補者が君の部署のある業務を器用にこなせる可能性があったとしても、他部署ではまったく戦力になりそうにないというのであればやはり 不採用 だ。状況は刻一刻と変化してゆくものであり、我々が求めているのはどこで何をしていても成功に結びつける事が出来る人材である。もし君がSQLの天才的なエキスパートを見つけたとしても、それ以外のことを学べない人材であれば 不採用 だ。彼にFog Creekでの将来は無い。

決して 「たぶんね。なんともいえないが」も言わない。なんともいえないんだったら 不採用 だ。別に難しい事じゃない。同様に、「 どちらともとれない 」も 不採用 「基本的には採用だけど少し心配な点が・・・」などと言わない事。これも 不採用 なのだ。

面接で忘れてはいけない最も重要な点はここにある ―優良な候補者を誤ってはじいてしまう事は不良な候補者を誤採用するよりはずっとマシ― 不良候補者の不手際を修正するために、ゆくゆく多大なる優秀な人々の時間、ひいては会社のコストを犠牲にしなければならなくなる。少しでも不安要素があれば 不採用 だ。

面接をしてゆくとたくさんの候補者を落とさなければならなくなるだろうが、そんな事は心配しなくてもいい。Fog Creekは誰も採用できないだろうが、そんな事は 君の問題じゃない。採用担当者の問題で、人事部門の問題で、代表者の問題だけど君の問題じゃない。無能な人材が集まった巨大なソフトウェア会社に成長してしまうのと、小さくても高品質な会社である事と、どちらが重要化を常に自問して欲しい。もちろん優秀な候補者を探す事は重要だし、すべての人は優秀で有用な人たちを採用する事が面接の役割である事は理解している。が、もし君がFog Creek Softwareで面接官をするのならばあたかも我々には優秀な候補者が潤沢にいるかのように振舞って欲しい。どれだけ優秀な候補者が枯渇していたとしても妥協して合格点を下げる事は行ってはならない。

とは言っても、どうやってこの難しい決断を下したらよいのか。ここは基本に戻り、面接中に次の質問を自分自身に投げかけて欲しい。 「この人は賢いか?」 「この人は 結果に結びつけられる人か?」 正しい答えを得るためには、候補者に正しい質問を投げかける必要がある。

参考までに、この世で考えうる最低の面接の質問を挙げておく。「Oracle8iでのvarcharとvarchar2の違いは何か?」。Fog Creekが採用したい人間像とある特定のどうでもいいトリビアを知っているかどうかには何の関連性も無い。インターネットで15秒で調べられるような内容を知ってるか知っていないかにどのような価値があると言うのか。

実際のところまだまだひどい質問は存在するので、それらについても後述する。

ようやく本トピックの核となる「面接の質問」に入った。私の面接の質問リストは実は私のマイクロソフトでの初めての仕事で手に入れたものだ。いくつもの有名なマイクロソフト面接質問が存在しているし、誰もが自分のお気に入りを持っている。君もそのうち自分が 採用・不採用 を決断する為に欠かせない自分だけのお気に入りの質問群を蓄積してゆくだろう。ここでは私が使用していて有効だったテクニックについて説明する。

私は面接の前に候補者の履歴書を眺め、 面接の計画 を紙切れに書き留める。計画と言ってもたかだか自分の質問したい問題リストだが。例えばプログラマーの面接では下のような計画になる。

    1. 紹介
    2. 候補者が最近関わったプロジェクトについて質問
    3. 解答のない問題
    4. C関数に関する問題
    5. 自分の解答に満足しているか質問
    6. 設計に関わる問題
    7. 挑戦的な質問
    8. 何か質問がないか質問

面接の前には、私は候補者に関する事前知識をなるべく耳にしないよう細心の注意を払う。仮に君が、既に面接が始まる前に候補者は賢い人だと思ってしまっていたら(たとえばそれがMITの博士号を取得したというそれだけの理由であったとしても)、そこから先一時間の間候補者が何を話そうともその印象が塗り替えられることは無い。君が候補者は呆け者だと思ってしまったらその先入観は面接中のどんな言葉でも払拭される事はないだろう。面接はとてもデリケートな秤のようなもので、たかが一時間余りの面接で人を判断するのは強引にも思える。ここでもし君が事前に得る少しばかりの先入観は大きな錘のようなもので、どちら側に乗ろうがその面接自体が無駄なものになってしまう。かつて一度、面接前に採用担当が私の部屋にやってきて「お前はこの候補者を 気に入るはずだ」と言った事があり参ってしまったことがある。今ならば「私がそこまでその候補者を気に入る自信があるならば何故即刻採用としないんだ、面接するのは私の時間の無駄じゃないか」と言えたろうが、その時私はまだ若く気も弱かったので面接を行う事にした。彼があまり賢くない返答をすると「これはきっと例外に違いない、聞き方が悪かったのかも」等のように彼の全ての言動を色眼鏡で見るようになってしまっていたので、結局いまいちの候補者であったにもかかわらず 採用 としてしまった。ところで他の全ての面接官は彼のことを 不採用 としていたらしい。従って、「採用担当の言う事には耳を貸すな」「候補者の事前情報収集は行うな」そして、「自分独自の結論が出るまでは他の面接官と候補者について話をするな」ということを強く勧めたい。これらは科学的根拠に基づいたものだ。

紹介 のフェーズは候補者をリラックスさせる意図で提供される。私は大体30秒程度で私が誰でどのように面接を行ってゆくのかを説明する。私はこのとき常に候補者に対して、我々が興味を持っているのは「 どのように」問題を解決してゆくかで、解決案そのものではないということを理解してもらうようにする。ところで面接中に机をはさんで候補者と対面する事は極力避けるようにしたい。これは両者の間に障壁を生成し、候補者を緊張させて本当の姿を確認する事が出来なくなってしまう。むしろ机を壁向かいにしたり、回り込んで候補者と同じ側に座って精神的な距離を縮めてあげることにより、候補者の精神状態に邪魔されないよりよい面接が期待出来る。

2番目は候補者が直近で関わっていたプロジェクトについての質問である。新卒対象であれば卒業論文の内容や、最も長期間就学したお気に入りの選択科目の事でも良い。例えば私は時々、「前学期に受講した科目のうちどれが一番好きだった?別にコンピュータに関連していなくても良いよ」というような質問をする事がある。実際のところ私は彼らがコンピュータに無関連の学科を習得していたと聞いてもそれはそれで喜ばしい事だと思える。彼らの科目スケジュールを見ると最低履修時間分のコンピュータサイエンスの科目以外は全て音楽関連で埋まっている事もあり、にもかかわらず「私はオブジェクト指向データベースについての科目が好きでした」というような返答を受けることがある。それはそれで良いのかも知れないが、私はそこででっち上げられるくらいならば素直にコンピュータよりも音楽が好きと返答してくれたほうが好ましいと思う。

中途採用の候補者であれば前職について聞いてみるのが良いだろう。

この質問で私が期待しているインプットはひとつ、「 情熱 」だ。候補者が直近で関わったプロジェクトについて以下の兆候が見られればそれはとても良い事である。

  • 候補者がそれについて語る時、とても興奮した面持ちになる;一般的に人はそのようなときには早口で雄弁になり、表情が生き生きしてくる。これは候補者が興味を示した対象に対して情熱的になれるということを示す。ろくに仕事の内容を咀嚼せず、どうでもいいやと機械的に処理するような人々はそこらじゅうに溢れている。ネガティブな方向の情熱を見せたとしても、それはポジティブなものと同じくらいによい兆候である。「前職ではほげほげを設置する担当だったが、顧客はわからずやで云々」のコメントも我々が採用したい類のものだ。悪い候補者はこれらのことをどうでもよいことと考えており、面接中もまったく食いついてこない。候補者がプロジェクトについて語っているうちに面接中であることを忘れてしまっているような様子が見られればそれは本当に良い兆候だ。時に候補者はがちがちに緊張して面接に望む。これは至極あたりまえの事なので私は特に気にしない。ひとたび電算機的モノクロアートについて語りだしたら今までの緊張がうそのように興奮して語りだす、そんな情熱的でこだわりのある人と仕事が出来る事を望んでいる(ちなみに電算機的モノクロアートがどのようなものかを知りたければモニタの電源を抜いてみると良い)。
  • 候補者がそれについて語るとき、とても慎重に言葉を選ぶ;かつて私が断った候補者の中には、一般人が理解できる言葉で前プロジェクトについて語ることの出来ない人がいた。しばしば理系の学卒者には世の中の全ての人がBatesのセオリーやペアノ数論を理解しているものと錯覚している人がいる。もしも候補者がその兆候を見せ始めたら、話をさえぎって「練習だと思って私の祖母にも理解できるように説明してもらえますか」と言ってみるのもいい。ここまで言っても 相変わらず 業界用語をちりばめて理解不能な説明を続行する連中がいる事にはまったく驚かされる。
  • もしもプロジェクトがチーム編成のものであれば、候補者のリーダーシップについて確認する事が出来る。ときに候補者が「我々はXのようにしたかったのだが、我々のボスはYと指示するし、顧客はZを欲しいと言った」といったことを口にしたなら、私は「で、 君は それについてどうしたんだい?」と聞いてみる。好意的な返答はこうだ。「そのとき私はチームのみんなを集めて提案書を書き上げて・・・」。対する悪い返答とは「私に出来る事など 何も 無かった。解決不可能な状況でした」といったところか。「 賢くて、結果に結びつけられる 」というキーワードを思い出して欲しい。誰かが 結果に結びつけられる 人かどうかを判断する為には、過去にその人が物事の解決を試みたかどうかを確認してみればいい。候補者がリーダーシップを発揮して結果に結びつけられることの出来たひとつの例について単刀直入に聞いてみるのも手だろう。

さて、リストの3番目は 解答のない問題 だ。これは楽しめる。この質問ではわざと答えようの無い問題を出して、候補者がどのように対処するかを観察する。たとえば「シアトルに視力調整士は何人いるか」「ロサンゼルスにガソリンスタンドは何件あるか」「ピアノの調律士はニューヨークに何人いるか」など。

  • 賢い候補者はあなたが彼らの知識を試しているわけではないと察知し、数々の仮定に基づいた非常にざっくりとした答えを導き出すだろう。「ロサンゼルスの人口が7百万人として、1人あたりの所有台数は平均2.5台として・・・」。仮定が見当違いなものだったとしても構わない。質問に食いついてくると言う事が大切なのだ。「満タンにするのに4分で、ガソリンスタンド一軒あたり10台のポンプがあり、毎日18時間営業で・・・」。候補者たちは地域の発展具合を計算に用いるかもしれない。突飛な創造性を見せつけたり、ロサンゼルスの電話帳を要求するなど様々な形で君を驚かすこともあるだろう。これらは全て良い兆候だ。
  • あまり賢くない候補者はイライラしたり機嫌を悪くする。まるで君が火星人か何かのようなまなざしでにらみつけているだろうから、君は助け舟を出してやる必要がある。「たとえば君がロサンゼルスの規模程度の町を創るのであれば、いくつくらいのガソリンスタンドを設置する?」のように。もう少しヒントを与えて、「ガソリンを満タンにするには何分位かかるんだろう」としてもよいかも知れない。これだけ言ってもポカンと口を開けて更なる助け舟を待っているような、賢さのかけらも見受けられない候補者がいるだろう。この類の人達に問題解決能力は存在せず、我々も助けは期待していない。

プログラミングの問題に関しては、私はC言語で単純な関数を書くようお願いする。私の投げる典型的な問題を挙げる。

  1. 文字列をインプレイスで反転させる
  2. 単リストを末尾から先頭に反転させる
  3. 1バイトのデータ内で、立っているビットの数を数える
  4. バイナリサーチ
  5. 文字列中でもっとも長い単語を検索する
  6. atoi
  7. itoa (これは良い。彼らはスタックかstrrevのどちらかを使わなければならないから)

5行以上のコードを求められるような問題は敬遠するべきだろう。そんな時間は無いはずだ。

これらの問題についてもう少し掘り下げてみよう。1番、文字列のインプレイス反転について。私がこれまで見てきた全ての候補者は始めに必ずと言っていいほど引っかかる。彼らは例外なく別バッファを割り当てて、そこに反転した文字列を埋めてゆくのだ。問題は誰がそれを割り当てるのかと言うこと。この質問はたくさんの候補者から大変興味あるひとつの事実を私に伝えてくれた。Cを知っていると思っているほとんど全ての人達はメモリやポインタについて理解できていないのだ。このような人たちがプログラマとして仕事をしていると言う事実はにわかには信じ難いが、紛れも無い事実なのだ。この問題を用いて、以下の点を確認する事により候補者を判定する事が出来る。

  • 関数の実行速度は充分速いか? strlen を何回呼ぶ事になるのか考えてみよう。かつて私はO(n)であるべきstrrevのアルゴリズムがO(n^2)になってしまっているアルゴリズムを目にした事がある。彼らは繰り返しの strlen をループの中で呼んでしまっていたのだ。
  • ポインタ演算を使用しているか?これは良い兆候である。たくさんの「Cプログラマ」は実はポインタ演算についてよく知らない。私は原則に候補者から何か一つのスキルが欠けているという事を不採用の理由にはしないが、Cのポインタについて理解することはスキルではなく才能であると言う事を発見した。コンピュータサイエンスのコースは毎新学期200名程の、4つの頃にはアタリ社製800のBASIC言語で複雑なアドベンチャーゲームを書けていたような生徒が入学してくる。彼らは大学でPASCALを学びながら楽しい時を過ごす・・・ある日突然教授が「ポインタ」を語り始めるまで。 そこまで 。もうそれ以上の事は何も分からない。9割方の生徒はポリティカルサイエンスのコースに鞍替えして、「コンピュータサイエンスのコースには魅力的な異性が見つからなくってさあ」等と友人に弁解する。 どうやら大部分の人々はポインタを理解するための脳の一部分を持たずして生まれてくるようだ。 ポインタの理解はスキルではなく、才能の類である。ポインタの理解にはインダイレクト且つ多重に関連付けを行う論理的思考が要求され、どうあがいてもそれが出来ない人だっているのだ。

3番目の問題では彼らがC言語のビット演算子をどれだけ良く学んだかを観察できるが・・・これ こそは才能ではなくスキルだ。だから君は多少彼らに助けの手をさしのべてあげても良い。おもしろいのは彼らにまずバイト中の立っているビットを数える関数を書いてもらってから、それを高速化するよう要求する事だ。非常に賢い候補者はプログラムの初期化時にルックアップ配列を作成するだろう(どれだけ多くともたかだか256エントリ程度なのだから)。それなりに賢い候補者とも要求メモリ・コード量と実行速度とのトレードオフについて興味深い会話が出来る。さらに彼らにプレッシャーを与えてもいい。初期化時にルックアップテーブルを作成する時間を費やしたくない、とか。賢い候補者はキャッシュを提案してくるかもしれない。初めての値の場合のみビットを数えてからルックアップテーブルを更新して、次から同じ値が来た時に再計算しなくてもいいように。更に賢い候補者は出現パターンを利用して格段に効率よく同テーブルの作成が行えるような方法を発明するかもしれない。

君が他人がコードを書くところを観察するときには、下記のテクニックが助けになるだろう。

  • 常に候補者に対して、エディタなしでコードを書く事は難しい事だから解答用紙が汚くなってしまう事は理解しているということを伝えて安心させてあげる事。コンパイラなしでバグの無いコードを書くのは難しいという事も理解していて、それは考慮に入れるというのも伝える。
  • 良いプログラマの兆候:良いプログラマは「{」を書いたら数行分の空白の下に「}」を書き込んでから中を埋めてゆく。彼らは変数名にも荒削りながら何かしらの命名規約を設けているだろう。良いプログラマのループ変数名は短い傾向がある。もし CurrentPagePositionLoopCounterのような変数名を見かけたら候補者はこれまで実際にプログラムを書いた事は無いという証だ。時々君は「 if (0==strlen(x)) 」のように 定数 を比較オペレータの左辺に持ってくるCプログラマを見かけるかもしれない。これは非常に良い兆候だ。彼らは何度も紛らわしい「=」と「==」に悩まされ、新しい自衛手段を見つけざるをえなくなったと言う事を示している。
  • 良いプログラマはコードを書く前に設計を行う。ポインタが関連する場合など特に顕著である。例えば君が単リストを反転させる問題を出したとき、良い候補者は用紙の端にノードと矢印を走り書きして、何がどこにつながっているかを書き込んでゆくことだろう。むしろそれは必須である。人間でいる限り、幾つかの箱とその間の矢印を書かずして単リストを反転させることは不可能なのだ。悪いプログラマはいきなりコードを書き始める。

無論君は彼らの関数内にバグを見つけることだろう。その為に5番目の「 自分の解答に満足しているか質問」があるのだ。「良し。じゃ、どこにバグがあるか教えて?」と聞いてみるといい。世にも憎らしい模範的なフリー回答の質問だ。全てのプログラマはミスを犯すが、そのこと自体に罪は無い。自分達で見つけることが出来ればよいのだ。文字列操作関数では彼らのほとんどは新しい文字列のNULL端末処理を忘れるだろう。ほぼ全ての関数で、「あと一歩なのに」という間違いがあるだろう。セミコロンを忘れているかもしれない。長さ0の文字列を渡すとうまく動作しなかったり、mallocが失敗したらアクセス例外が発生するかもしれない。候補者がバグの無いコードを書くなんてほぼありえないと思っていい。もっともその場合には次のやりとりは更に楽しいものになる。「君のコードにはバグがある」と君が言ったとき、候補者は注意深く自分のコードを見直すはずだ。そうしたら君は、候補者がいかに外交的且つ力強く彼のコードが完璧なものであるかを説得できるか観察できる。たいがいの場合、次に進む前に彼らに対して自分の回答に満足しているかどうかを聞く事は良いアイデアだ。どこかのクイズ番組の司会のように。

パート6、設計に関わる問題。候補者に何かしら設計するよう要求する。Excelを設計したJabe Blumenthalは候補者に対して家を設計するよう問題を出すのが好きだった。Jabeによると、ホワイトボードに向かって歩き出し、いきなり真四角を書いた候補者がいたそうだ。無論彼は即刻 不採用 。設計の質問だというのに何を考えているのか。

  • 良い候補者は君からその問題についてもっと情報を得ようと試みるだろう。家は誰の為のもの?私のポリシーとして、その家はどんな人のために建てるのかも聞かずに設計に飛びつくような人間は雇わない。しばしば彼らの設計を遮って「君は聞き忘れているけど、この家は身長48フィートで盲目のキリンさん一家の為のものなんだよ」と邪魔してやらなければいけないのは非常に嘆かわしい事だ。
  • さほど賢くない候補者は設計は単純なお絵かきだと錯覚している。何も書かれていない板に気の向くまま書き込んでゆけばよいのだ、のように。賢い候補者は設計とは複雑なトレードオフの連続であると言う事を理解している。優秀な設計の質問にはこんなものがある。「町の通りの角に置くゴミ箱を設計せよ」。数え切れないほどのトレードオフの連続だ。ゴミ箱は簡単に空っぽに出来なければいけないが、中身が簡単に盗まれるようではいけない;簡単に物を投げ入れる事が出来て、けれども風の強い日にも中身が飛ばされる事の無いように;丈夫で、しかし安価に;町によってはテロリストが爆弾を隠しにくいように、というのもあるだろう。
  • クリエイティブな候補者は解答に直接結びつかない興味深い答えで君を驚かすかもしれない。私の好きな質問の一つに「 盲目の人のために調味料の棚を設計せよ」と言うのがある。候補者は当然調味料入れのどこかに点字を付ける事になるのだが、質問を重ねるにつれ私は、様々な理由によりほとんどの場合フタの上に落ち着くのだということを発見する。一人、調味料は棚ではなく引き出しに入れるべきだと提案してきた候補者がいた。点字は縦になぞるより、横になぞるほうが快適だと言うのだ(試してごらん)。この創造性には驚いた。何度も面接を繰り返してきたけど、そんな回答は聞いた事が無かったのだ。これは問題の枠を跳び越えた一つの創造性を提示した。その回答のインパクトと、他に否定的な部分が無かったと言うそれだけで私は彼を採用したが、彼はその後Excelチーム内で最も優れたプログラムマネージャの一人となった。
  • 見切り をつけようとする態度の有無を観察する。これは「 結果に結びつけられる」という行動の一部だ。しばしば候補者は同じ考えを行ったり来たりして決断できなかったり、難しい質問を避けようとする事がある。彼らはそれらについて放置したまま次に進もうとするだろう。これらはあまり良い兆候ではない。良い候補者はたとえ君が足を引っ張ったとしても物事を先に進めてゆこうとする傾向が自然に体に染み付いている。仮に同じように議論の繰り返しになったとしても彼らはこんな風に言うだろう「このことについて丸一日議論する事も出来るけど、何かしら形にしなきゃいけないからXという決断で行こう」。これは本当に好ましいサインだ。

これらはそのまま7番目の「 挑戦的な質問 」につながる。これも楽しい。面接中、君は候補者が完全に100%疑いもなく正しい事を言う事を待つ。そうしたら君は「あれ?ちょっと待ってよ?」と言ってから2分ほど詭弁をふるって完全否定する。 彼らの言っている事が正しいとわかっている事 について議論を仕掛けるのだ。

  • 弱い候補者はあっさり過ちだと認める。 不採用
  • 強い候補者は君を説得する方法を見つけるだろう。カーネギー卿の全ての教えを駆使して君を打ち負かす。「もしかしたらあなたの言っている事を誤解しているのかもしれませんが、・・・」と控えめにアプローチしてくるだろうが、彼らの地盤は譲らない。 採用 だ。

確かに面接と言うシチュエーションでは候補者と君との立場が対等であるとは言い難い。君の立場が強い為に萎縮してしまい、議論をすることを候補者が遠慮してしまう危険性は十分ある。 それでも 、良い候補者と言うのは議論することについて積極的な傾向があり、それこそ面接中であるということすら忘れてしまってただ君を説得する事に専念するだろう。我々が雇用したいのはそういう人達なのだ。

最後に、君は候補者に対して何か不明な点があるかどうか質問すべきだ。面接官の幾人かは面接テクニックのマニュアルどおりにここで候補者が知的な質問をするかどうか観察するようだ。私個人としては別にここで候補者が何を聞いてきてもあまり気にしない。この時点では既に面接の結果について決断されているのだ。そもそも候補者は一日で5人から6人の面接官に出くわすのだ。そのそれぞれに異なるすばらしく知的な質問をしろと言うのは土台無理な話だろう。何も質問が無いならそれで結構。

私は常にいつだって必ず面接の最後に5分ほどFog Creekのことを売り込む。これは君が 候補者を採用する気が無かったとしてもとても大切な事だ。もし君が幸運にもすばらしい候補者に出会ったのだとしたら、この時点で君は全てを賭けて彼がFog Creekに入る事を確実にするだろう。だが、もしそれが悪い候補者だったとしても、Fog Creek Softwareについてエキサイトさせて、会社に対して好印象を抱いたまま帰路につかせるようにしたい。こう考えたらいい、彼らは従業員候補であるだけでなく、お客様であり、或いは外部採用担当者であると。もし彼らがFog Creekは仕事をするのに素晴らしい環境であると思えば、友達にも応募を勧めることだろう。

そういえば、避けるべき最低の面接の質問を幾つか紹介すると約束した事を思い出した。

まず始めに。違法な質問は避ける事。人種、宗教、性別、国籍、年齢、兵役、階級、性的嗜好や身体障害に関連する全ての質問は「 違法」である。もし候補者の履歴書に1990年に兵役についていたと書かれていても、湾岸戦争に行ったかどうかなど聞かない事。法律違反だ。履歴書にハイファのテクニオン大学卒と書かれていたとしても、どんな遠まわしにでもイスラエル系移民か?などとは聞かない事。法律に反している。 このページ で違法な面接の質問についてなかなか良い議論が展開されている(もっとも、それ以外の面接の質問にはバカバカしい物が目立つが)。

次に、質問する事によって、それがあたかも採用判断の基準であったり、我々がそれを非常に意識するのだと言う事を候補者に誤解させてしまうような質問はしない事。私の思いつく最良の例としては、候補者は妻帯者か否か、子供はいるのかを質問する事だ。このような質問は、まるで我々が「子持ちは仕事に対する貢献度が低い」とか、「産休を取られるんじゃないか」など懸念しているような誤った印象を与える。

最後に。6本の同じ長さのマッチ棒を使って4つの同じ形の正三角形を作れの類の頭の体操のような質問は避ける事。ひらめきが全ての質問を投げ、相手がそれに気づくか否かを観察したところで「賢くて結果に結びつけられる」人かどうかの情報は得られない。

面接とは確固たる理屈に基づくものと言うよりむしろ、抽象的なアートであろう。しかし、もし君が「 賢くて結果に結びつけられる 」という基本を思い出すことが出来れば君の面接はきっとうまく行く。もしも機会があったら同僚に面接時にどんな質問をするのかだとか、期待する回答だとかを聞いてみるといい。レドモンドの16号ビルカフェテリアでは昼食時のこの話題がいつまでも皆のお気に入りだ。



この記事の原文(英語)は The Guerrilla Guide to Interviewing です。 

ジョエル・スポルスキは、ニューヨーク市の小さなソフトウェア会社  Fog Creek Software の設立者です。イェール大学を卒業後、マイクロソフト社、Viacom社、 Juno社でプログラマとして働きました。


このページは著者の個人的な意見を掲載したものです。
All contents Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky