インタビューについて（エリック・リッパート）

以前、技術面接のプロセスに関する古い記事を2つ（オリジナル： 1つ 、 2つ -およそTransl。）再公開しました。 私はインタビューをどのように行い、何に注意を払うかについて、より詳細に説明できると信じています。



私の主な目標は次のとおりです。

• 悪い労働者を雇わないでください。
• 優秀な労働者を雇います。
• 候補者に会社の好印象を残す。

もちろん、悪い従業員を雇うことを避けることは、良い従業員を雇うことよりもはるかに重要です。 優秀な従業員がいない場合、これは非常に悪いことですが、スタッフの不足はチームの生産性を何年も低下させる可能性があります。



最後のポイントも重要です。 人を仕事に連れて行きたいなら、明らかに良い印象を与えなければなりません。 しかし、私も否定されているすべての人が私たちの良い意見を持っていることを望みます。 彼らには話をしたい友人がいます。 いつか彼らは私たちの製品の購入を決定するか、それを勧めることができます。 面接は費用のかかるビジネスプロセスです。 もし彼が雇用につながらないなら、多分私たちはクライアントを獲得するか、少なくとも自分自身に大きな恩恵をもたらすでしょう。



インタビューは次のとおりです。



まず、申請者が快適であること、喉の渇きを癒す何かがあること、トイレに行きたくないなどを確認する必要があります。 それから、誰かが私の前に誰かにすでにインタビューしている場合、私は尋ねます、「お元気ですか？」 この質問の目的は、雰囲気を和らげ、会話を開始し、候補者が面接に関して質問があるかどうかを確認することです。 候補者がすでに自分自身をどのように見せたかについての情報を持っていることもありますが、意思決定を目的とするものではありません。 （Microsoftは、チェーン内の次のインタビュアーに潜在的な問題を掘り下げることができるように、できるだけ早くフィードバックを行うことをお勧めしました。コベリティでは、各インタビュアーが公平に開始する可能性が高くなります。



その後、候補者の履歴書から古くて面白くないものを選択します。まず、「エレベーターピッチ」-プロジェクトを説明するいくつかの文、面白さ、重要性を説明してください-そして、このプロジェクトで解決した問題を詳細に説明してください。



これも、候補者が履歴書から何かについて話しているので、候補者がリラックスするのに役立ち、おそらくそれが得意です。 まず最初に調べたいのですが、インタビューを受けた人は普通にコミュニケーションできますか？ あなたは履歴書から物事について1つか2つの文を話すことができない人がどれだけいるかに驚くでしょう。 第二に、彼らはこのプロジェクトで実際に何をしましたか？ それは衝撃的かもしれませんが、人々は常に自分の長所を飾ります。 候補者の正確な行動の詳細を調べたところ、彼が本当に「賢くて物事を終わらせる」（賢くて物事を成し遂げる-およそTransl。）かどうかを理解できます。



それから、私たちは本当に興味深い段階に進みます：技術的な挑戦です。 目標は、候補者が毎日書く必要のある種類のコードを書くことができるかどうかを調べることです。 ボード上で手書きでコードを書くことは批判されていることを知っていますが、この批判に同意します。 これは不自然な環境であり、実際のコード記述と同じではなく、ストレスの多い状況などです。 私はそのような困難を最小限に抑える質問を考え出そうとしますが、候補者が実際の仕事に対処するかどうかをまだ示すことができます。 （そして、人がボードにコードを書きたくない場合、コンピューターでそれを行うことができます。しかし、私が尋ねる質問は、6行以上のコードを書く必要はほとんどありません。最高の求職者は、テキストエディターの助けなしで半ダース行を書くことができるはずです。



そして、この段階は本当に重要です。 応募者が通常とは異なる一連の要件を満たしていることを確認します。 言語分析ツールに取り組んでいるチームの候補者は、コンピューターサイエンスの理論的基礎に強く、同時に不完全なコードの現実の世界で働くことができるはずです。 科学者の理論を深く理解する一方で、実際のコードを書くことができず、バイナリツリーとは何かを教えてくれなかった経験豊富な産業プログラマーのブレークスルーについてインタビューしました。



優れた技術タスクには次の特徴があります。

• 短時間で少量のコードで配信および解決できます。
• 突然の洞察を必要とせず、ストレスの多い状況で達成することは困難です。
• これはなぞなぞのなぞではありません。
• 候補者のレベルをより適切に評価するために、それをより困難または容易にすることができます。
• 申請者が職場で解決しなければならない問題と同様。
• コードの記述だけでなく、既存のコードの読み取りやファジー要件への対処など、他のスキルもテストします。

私がMicrosoftで長年使用しており、Coverityでさらにうまく機能するタスクには、次のスキームがあります。



まず、パブリックAPIのC ++で記述された2つのメソッドがあり、それぞれが3行の非常に単純なコードで構成されています。 APIは、「サーバー」上の「タスク」を管理し、「クライアント」によって使用されます。 スクリプトは意図的に非常にぼやけていますが、コードは明確です。 各行に候補者を渡し、候補者がコードを理解していることを確認します。 ここでは、単純な構文の基本的な理解だけが必要です（候補者の大半は履歴書によるとC ++に精通しています。これは仕事に必要なためです）。



次に、このコードを調べて問題がないか候補者に指示します 。 そして、他の誰かのコードを調べるときに、彼がどの方向を掘るかを観察します。 提示されたコードには、設計、信頼性、セキュリティ、テスト容易性、移植性の問題があります。 候補者が自分で見つけた問題を調べ、何かを見逃した場合は、「クライアントがサーバーを意図的に中断しようとした場合、どうしますか？」または「このコードをコンパイルして64ビットマシンで実行するとどうなりますか？」彼がヒントを理解しているかどうかを確認します。



これは、毎日使用する必要がある本当のスキルです。まず、自分のコードと同僚のコードのコードレビューを行います。 次に、私のビジネスは、コード内のコードを分析し、それがコードであると判断するプログラムを作成しています。 申請者が他人のコードを検証できない場合-どこでも成功する可能性は低いです。 6つの命令を含むプログラムで数十個のエラーを検出できない場合、エラーを検出するコードアナライザーを作成することはできません。



ここでは、対象分野の理解、批判的思考、および基本的な知識を探しています。 多くの場合、この段階では危険信号があります。 たとえば、64ビットアーキテクチャではポインターの長さが64ビットであることを知らない「コンピューターサイエンスの博士号」の申請者がいました。 はい、そしてなぜ彼らは知っている必要がありますか？ 彼らが言うように、天文学は望遠鏡を作る科学ではありません。 理論的なコンピュータサイエンスの広範な知識は、必ずしもプロセッサとメモリ間のバス帯域幅の知識を必要としません。 しかし、一般的なアーキテクチャでのポインターの実装方法を理解していない候補者は、ポインターの長さに関連するエラーを探しているアナライザーの開発チームで働いて成功することはほとんどありません。



また、多くの申請者はコードの誤りを特定していますが、その結果を説明することはできません。 未定義の動作は、定義により未定義です。 しかし、悪意のあるクライアントが任意のメモリ（任意のメモリへのポインタ-およそTransl。）にポインタを割り当て、そのようなポインタを使用してサーバーに仮想メソッドを実行させると、コンパイラが実際にコードを生成する方法の理解を示します。



これは技術的なタスクの最初のフェーズです。 次のステップには、設計と、場合によっては少量のコーディングが含まれます。 「APIの実装は変更できますが、メソッドシグネチャは変更できません。検出された各エラーをどのように修正しますか？」 繰り返しますが、これは毎日使用しなければならない主要な作業スキルです。「サーバー」のエラーを修正し、「クライアント」の動作を変更できません。 おそらく、呼び出し元のコードは、顧客または別のチームに属しているか、すでに販売されている可能性があります。



この段階では、次のことに注意します。

• 他の危険信号はありますか？ 64ビットポインターを32ビット整数に圧縮して移植性の問題を解決しようとする候補者の数は膨大です。 解決するように頼むトリッキーな謎はありません。 10ポンドの袋に20ポンドの小麦粉を入れることはできません。 問題を解決する別の方法を見つける必要があることは明らかです。
• 申請者の手荷物にはどのような道具がありますか？ 最終的にすべての候補者は、32ビット整数から64ビットポインターにマッピングするための補助データ構造を追加する必要があることを理解しています。 彼らはそのようなマッピングの既存の実装を知っていますか？ そうでない場合、彼らはこれを書くことができると確信していますか？
• 候補者はタスクの本当に難しい部分を強調できますか？ ここでの難しさは、マッピングの必要性を認識することではなく、新しいキーと値のペアを追加するときにキーの一意性を確保することです（前のエピソードで述べたように、 オリジナルはおよそTranslです）。 「あなたの決定において、キー値の計算方法を教えたことはありません-この値は生成されるのですか？」と繰り返し尋ねても、一部の候補者は単にそれに注意を払わず、マッピングの仕組みを説明し続けます。 または、前のポイントに戻り、64ビット値を一意の32ビットキーに圧縮しようとしますが、これは不可能であり、それがマッピングの理由です。
• 候補者は、この論争の的となっている状況からどのように抜け出しますか？ 問題は意図的に曖昧で不明確であり、難しい部分は一意の値を生成しています。 2つのクライアントがあり、それぞれが2つの「タスク」を作成してから切断する場合、一意の32ビット整数キーを生成することは難しくありません。 数百万の顧客が数百万の「タスク」を生成している場合、一意のキーを取得することは非常に困難です。 多くの候補者は、このシステムに何人のクライアントと「タスク」があるかを決して尋ねません。したがって、一部の候補者はあまりにも複雑なアイデアを出し、原則としてスケーラブルではないソリューションを提供します。
• 候補者は以前に解決された問題と類似点を描くことができますか？ ストレスの多い状況ではこれを行うのは難しいですが、見るのはまだ面白いです。 一部の候補者は、「一意の32ビット数を生成し、クライアントが終了するまでそれを再利用しない」という問題は、32ビットバージョンのメモリマネージャーを作成した人が以前に解決しなければならなかったことにすぐに気付きました。 最後に、メモリマネージャとは（eng。メモリマネージャ-およそTransl。）：要求に応じて一意のポインタを提供し、解放するまで同じポインタを再度発行しないデバイス。 したがって、私が定式化した問題は、以前に解決された問題に減らすことができます。 一部の候補者は、メモリの割り当てや魔法のようなことについて話します。 多くの人は、問題がヒープの実装に似ていることに気付きました。 しかし、「Windowsから40億バイトのヒープを取得することで問題を解決し、個々のバイトをヒープから分離して一意の32ビット数を生成します」（eng。 Windowsでは、40億バイトのヒープが作成され、そこから1バイトが割り当てられて、一意の32ビット数が生成されます。 それは本当に解決済みの問題を本当に減らすでしょう！

候補者の成績がよければ、タスクの複雑化は非常に簡単です。 クライアントが多くのスレッドで使用されているとします。 どの同期戦略が高いスループットを維持しますか？ コンピューターの再起動時にタスクの状態を保存する必要があるとします。 サーバーがクラスター内にあり、負荷を他のサーバーにリダイレクトできる場合はどうなりますか。 彼らの知識の深さを知りたい。 または、クライアントの数を10に制限することにより、タスクを簡素化できます。 「タスク」が特定の特定の順序で開始および終了し、前のタスクが終了した後に次の「タスク」が開始すると仮定します。 などなど。 申請者には、少なくとも何らかの問題に対処したと感じてほしい。



面接の最後に、候補者がチーム、空席、会社などについて質問できるように、時間を作ろうとしています。 （だれも「リンクされたリストを展開するコードを書いてみませんか？」と尋ねたことはありません。だれかがこれを行った場合、私は非常に驚くでしょう）。 私にとって、これは私たちの会社を「宣伝」する機会であると同時に、応募者の質問から彼らにとって何が重要かを理解する機会でもあります。