Hexletのチームは、技術面接の実施において多くの経験を持っています。 ウェビナー「 インタビュー：雇用主からの見解 」で経験とアドバイスを共有しました。 そして今日、私たちは人々がインタビューの準備をするのを手伝う会社からのヒントとともに記事の翻訳を公開しています。
私からは、これらのヒントの有用性にもかかわらず、ここで説明されている人があなたでない場合、それをエミュレートする必要はありません。
専門的にチャット
コードの議論を始める前に、ほとんどのインタビュアーはあなたの経験について議論することを好みます。 彼らは聞きたい：
- コードに関するメタ認知。 「品質」コードの意味を知りたいですか？
- 責任とリーダーシップ。 競争の激しい環境で働くことを考えていますか？ 必要ではない場合でも、何か間違ったことを修正していますか？
- コミュニケーション。 技術的な問題についてあなたと話し合うことは実用的ですか、それとも苦痛ですか？
次のポイントのうち少なくとも1つが必要です。
- 解決した興味深い技術的な問題の例。
- あなたが何とか克服した対人紛争の例;
- マネージャーまたは株主の役割はどうでしたか？
- 前のプロジェクトで異なる方法で行う価値があったことのストーリー。
- あなたの好きな言語についてのいくつかのささいなこと、そしてあなたがそれについて好きなことと嫌いなこと
- 会社の現在の製品とビジネスに関する質問
- 会社のエンジニアリング戦略に関する質問（テスト、スクラムなど）
みんなに興味がある。 自分の業績を誇りに思っていること、会社が何をしているかに興味があること、言語や作業プロセスについて自分の意見があることを示してください。
対話を続ける
プログラミングに関するトピックに進むとすぐに、主なことは対話を維持することです。 面接中に助けを必要としたが、会話に喜んで参加した候補者は、そのトピックについて長続きしなかった候補者よりも明らかに優れている可能性があります。
どのような種類のタスクを理解します。 タスクには2つのタイプがあります。
- プログラミング インタビュアーは、問題を解決するためにクリーンで効率的なコードを書くことを望んでいます。
- 短い会話 。 インタビュアーは、あなたに何か伝えたいと思っています。 多くの場合、質問は（1）高レベルのシステム設計（「Twitterクローンをどのように構築しますか？」）または（2）ささいなこと（「JavaScriptの魅力とは？」）のいずれかです。 時々、「実際の」質問の準備のために、ささいなこともあります。たとえば、「整数の配列をどれくらい速くソートできますか？ さて、今では、整数の代わりに....があります。」
コードを書き始めたときに、インタビュアーが「本当の」質問に進む前に短い答えを望んだだけです。 「このためのコードを書く必要がありますか？」
チームで働く方法を知っていることを示してください 。 インタビュアーは、あなたとチームとしてタスクに取り組むのがどのようなものか知りたいので、チームワークができることを明確にしてください。 たとえば、「私」の代わりに「私たち」を使用します。例えば、「幅優先の検索があれば、O（n）の答えが得られます」。 コードを書く場所（紙またはボード）を選択する必要がある場合は、常にボードを選択してください。 この場合、あなたはインタビュアーの隣にいて、問題を解決します（彼の反対ではなく、テーブルの形で障壁があります）。
大声で考えてください 。 本当に！ 「このようにしようとしましょう-それがうまくいくかどうかはわかりません。」あなたが立ち往生している場合は、あなたが思うことを言ってください。 うまくいくかもしれないと言ってください。 うまくいくと思うものと、なぜうまくいかないかを言ってください。 これは、簡単な短い質問にも適用されます。 Javascriptでクロージャを説明するように求められた場合、「スコープに関連する何か、関数に何かを入れる」という答えは、答えの90％としてカウントされます。
何も知らない場合は認めてください 。 事実（たとえば、特定の言語の些細なこと、ランタイムの詳細など）に触れた場合、知らないことを知っていることを示さないでください。 代わりに、「わからないが、そうだと思うので…」と言う。 それは他のオプションの除外を含むかもしれないので、それらが意味のない結果を持っていることを実証するか、他の言語や他のタスクと比較するためです。
結論に急がないでください 。 すぐに答えを投げないでください。 彼が忠実であれば、あなたはまだそれを説明する必要がありますが、そうでなければ、あなたは愚かに見えます。 急いで何も得られず、ほとんどの場合、インタビュアーをからかうだけです。
ストッパーから抜け出す
時々、自分が無重力状態に陥ることがあります。 リラックス。 これは、すべてがその意味を失ったという意味ではありません。 インタビュアーは、原則として、質問に正確に答える能力よりも、さまざまな角度からタスクを合理的に見る能力よりも重要であることを忘れないでください。 希望がこれ以上ないように思えたら、推論を続けてください。
写真を描きます。 黙って考えて時間を無駄にしないでください-取締役会で考えてください。 いくつかの異なるテスト入力データを描画します。 望ましい結果を得るプロセスを描きます。 次に、アプローチをコードに変換することを検討してください。
問題のより単純なバージョンを解きます 。 セット内で4番目に大きい要素を見つける方法がわかりませんか？ 最初の要素を見つける方法を考え、このアプローチを適応できるかどうかを考えます。
単純で効果のないソリューションを作成し、後で最適化します。 総当たり攻撃を使用します。 少なくともいくつかの答えを得るためにあなたの力ですべてをしてください。
もっと頻繁に大声で考えてください 。 あなたが知っていると言います。 うまくいくと思われることと、うまくいかない理由を述べてください。 これが実際に機能するか、出力の修正バージョンが機能することが突然判明する場合があります。 または、ヒントを得ることができます。
手がかりを待ちます。 インタビュイーを予想して見ないで、ちょっと考えてみてください-インタビュアーはあなたに何かを言うことをすでに決めているかもしれず、中断しないようにただ待っています。
メモリ境界とランタイムについて考えてください 。 決定を最適化できるかどうかわからない場合は、大声で考えてください。 例：
- 少なくともすべての要素を考慮する必要があるので、O（n）を行わないよりはましです。
- 大まかな解決方法は、すべての可能性をチェックすることです。これはO（n 2）です。
- 答えにはn 2個の要素があるので、少なくとも同じ時間を費やす必要があります。
思いを解き放つ
あなた自身についてつまずきやすい。 最初に自分の考えを取り除くことに集中し、次に詳細を心配します。
ヘルパー関数を呼び出して続行します。 アルゴリズムの一部（大小を問わず）の実装方法がわからない場合は、スキップしてください。 「これはXを実行します」と言って、適切な名前の補助関数にアピールし、続行します。 ヘルパー関数が簡単な場合、それを実装する必要さえないかもしれません。
構文については心配しないでください 。 必要に応じてしばらく英語に切り替えます。 構文に戻ると言ってください。
十分なスペースを確保してください 。 おそらく、後で行間にコードまたはメモの行を追加する必要があります。 ボードの上部から開始し、コードの各行の後に空白行を残します。
インデックスの正確なチェックは後で行います。 「<」または「<=」のforループが何になるか心配する必要はありません。 最後にこれに戻ることを思い出してください。 主なことは、メインアルゴリズムを書き留めることです。
わかりやすい変数名を使用します 。 少し時間がかかりますが、
コードで迷子にならないように役立ちます。 numsの代わりにnames_to_phone_nums_mapを使用します。 型を変数に入れます。 ブール値を返す関数は、「is_」で始まる必要があります（言語で採用されている標準に応じて、関数名の最後に「？」などのその他のオプションがあります）。 リストを含む変数は、「s」で終わる必要があります。 理解している基準を選択し、それらに固執します。
すべてを整理する
例としてソースデータを使用して、決定を手動で声を出して行ってください 。 プログラムの実行時に変数に含まれる値を記録します。 頭の中でやってもメリットはありません。 これにより、説明中にインタビュアーが持つ可能性のあるバグを見つけ、疑念を払拭することができます。
off-by-oneエラーに戻ります。 「<」の代わりに「<=」を使用する必要がありますか？
境界線のケースをテストします。 これらには、空のセット、シングルトンセット、または負の数が含まれる場合があります。 ボーナスとして、ユニットテストに言及してください！
退屈しないでください 。 面接官の中には、物事を整理することについて気にしない人もいます。 よくわからない場合は、「原則として、国境のケースのコードを確認します。これをさらに行う必要がありますか？」
練習する
結局、練習に勝るものはありません。 さらにインタビューをご覧ください。
紙にペンでコードを書きます 。 だまされてはいけません。 最初は不快かもしれません。 いいね 実際の面接の際にそれを台無しにしないように、今この不器用さを取り除く必要があります。