技術面接について

製品、確立されたチーム、資金があります。 あなた（チーム）はうまく機能し、経営陣は開発をスピードアップし、品質を改善し、製品の技術開発にリソースを費やすことができるように、それぞれ人を雇うためにより多くのお金を払う用意ができています。 あなたはすでにあなたに興味のある良い給料と鮮明な説明でhhに広告を掲載し、20人の候補者を選択しました。明日、インタビューを開始します。 正確に何を尋ねるかを考え出すだけです。 おなじみの状況？ それから猫にようこそ。



状況は少しユートピアかもしれませんが、多くの場合もこの記事の一部です。 例外は、「昨日人を必要とする」企業、または新しい人をまったく必要としない企業であり、単に「市場を観察する」だけで、（または）「希少な専門家」を見つけることを望んでいます。

つまり、この記事は、チームを強化するためにお金とエネルギーを投資したい人を対象としています。



そもそも、一時的なニーズのために人を雇うことは非常に有害です。 サーバー側の開発に少し時間がかかるとしましょう。 これは、サーバー側のプログラマーを雇う必要があるということですか？ いいえ、実際に。 かなり活発な開発を行っている場合、さまざまな部分の優先順位は必然的に変わります。 この意味で、来月のタスクのために人を雇うことは愚かです。 結局、1か月が経過し、人ができます。 そして今月、サーバー側の開発に穴を埋めると、次の段階では、サーバー側はインターフェースがリベットで留められるよりも速く書かれていることがわかります。 そして、来月、UIプログラマーを雇う必要がありますか？ または、サーバー側で弱いリンクを起動しますか？ いいえ、別のアプローチの価値があります。 以前に製品開発で行ったことを確認してください。 売り上げ、投資家、または開発の目標を誰に決定するかを尋ね、たとえば1年前にあなたが何を待っているかの写真を作成してみてください。 ここで、過去および将来、どのような人がより効率的に作業するのに役立つか想像してみてください。 複数の人に自己紹介していただければ幸いです。 ほとんどの場合、こことここでチームを強化できることがわかります。 そして、どこかで強すぎることが判明した場合（したがって、どこかで薄すぎる場合）、既存のチームの誰かが活動の種類を「切り替える」ことに同意する可能性があります。



したがって、「理想的な」候補者の肖像画をいくつかスケッチしました。 技術面接を実施する時が来ました。 ところで、あなたの会社では、技術面接が従業員を雇用する決定に影響を与えることを願っていますか？ 多くの場合、人々は会社を「家族」または「時間を過ごすのが楽しいチーム」として話します。 だから、会社はまだ家族ではありません。 そして、ボウリングに行く友達ではありません。 もちろん、人がkleptomaniaまたはハンセン病にかかっている場合、たとえ技術的な面接に最も合格したとしても、彼を仕事に連れて行くことは危険です。 しかし、個人の資質にこだわらないでください。 原則として、技術面接の前または後に、ある人が何らかの焦点を外すかどうかを調べる必要があり、この意味で、そのような「非技術的」面接は「しきい値」の役割を持ちます。合格すれば、彼が「会社の魂」であるか、または良心的な従業員であるかは関係ありません。 しかし、実際には、これおよびその他すべての決定は、技術面接によって正確に決定される必要があります。 あなたの会社の人事部で、キャリアの願望や「10年後に自分が誰なのか」や「会社があなたを雇うべき理由」について質問する候補者を悩ませている場合、技術専門家を探すのは時期尚早です。 最初に、新しいHRを見つける必要があります。



しかし、技術面接を依頼するにはどうすればよいですか？ テストをしますか？ ある人が最後の仕事で何をしていたかを調べますか？ 難しい質問をしますか？ braingames.ruでパズルを書く？

これらのオプションを順番に見てみましょう。



テストは時間を節約するのに良いことのように思えるかもしれません。 ただし、適切なテストを作成することは十分に困難です。このタスクに多くの時間を費やす必要があります。 悪いテストでは、面接にあまり出席せず、「典型的な」質問に対する答えを知らない候補者を除外することができます。 非常に悪いテストは、ちょっと違うことをしていた本当にクールな候補者を排除することができます。 一般に、テストは単なる主要なフィルターです。 あなたの意見で5つの平凡な質問に答えることができなかった人を雇うことはできません。 しかし、テストの後、彼に一言も聞かずに人を雇う価値はありません。



最後の仕事で何をしましたか？ 応募者が以前の仕事で何をしたか、彼はあなたと一緒にはしません。 原則として、会話のトピックを見つけるためにこのような質問をすることができます。 しかし、正直なところ、これは時間の無駄のようです。 私の練習から例を挙げます。

-最後の仕事で何をしましたか？

-まあ、最適なルートの検索と都市通信のシステムをシミュレートする複雑なシステムがありました（...）

-ダイクストラのアルゴリズムとは何ですか？

「ええ、はい、そのようなことを聞​​きました。」

合計-何を学びましたか？ なし。 ある種の複雑なプロジェクト。 プロジェクトが何であるか、この従業員が何をしたか、最終的に彼がうまくやることを学んだことは明らかではありません。 その人について何も見つけないように5分間無駄にしました。 もちろん、30分を費やしてすべてを分解することができます。 しかし、2つの「しかし」があります。

まず、時間に感謝します。 各候補者に4時間を費やした場合、本当に価値のある候補者に「到達しない」ことができます。 一般的に、私の意見では、インタビューは時間枠、たとえば1時間に厳密に制限されるべきです。 そして、あなたがこの時間の間に人からの決定に必要なものをすべて振り払おうとしてください。

第二に、その人物が誰であるかに焦点を合わせないでください。 彼があなたの会社で誰になれるかを評価してください。 あなたの候補者は、あなたが過去の仕事で、あなたが月にした週にモジュールをしたと言いますか？ おそらく、最後の仕事でクールなビジネスプロセスと大量の既成のコードがあり、このモジュールをあなたとまったく同じように実行できたでしょうか？ または、最後の仕事で候補者は何も驚くべきことをしなかったように思われましたか？ それは非常によくあるかもしれません。 しかし、おそらくこれは三流の「角とひづめ」で生長した才能のある人であり、あなたは彼のすべての可能性を発見するでしょう！ 私を信じてください、多くの状況では、熟練した専門家よりもそのような人のために戦う価値があります。



トリッキーな質問をする必要がありますか？ 昨日、ハブで読んだとしましょう。Javaのハッシュコードは（いつも考えていたように）アドレスではなく、乱数であり、候補者がこれを知っているのか疑問に思っています。 または、先週、あなたはnixesをいじくり回し、「[」は言語としてのbashスクリプトの一部ではなく、「[」と呼ばれる通常のプログラムの一部であることがわかりました。 候補者がこれを知っているかどうかを調べることは有用でしょうか？

ここでも、質問と回答のオプションを失ってみる価値があります。

役割を果たします。

-Object.hashCode（）とは何ですか？

-さて、これはオブジェクトのアドレスです

2番目のオプション：

-Object.hashCode（）とは何ですか？

-はい、乱数ジェネレーターがあるため、戻ります。

この質問に3分費やしました。 最初の候補と2番目の候補をどのように比較しますか？ そのうちの1つが他より優れていると言うことができますか？ たぶん、余暇のgrepcodeで2回目です。 または、仕事の代わりにhabrを読んでください。 または多分そうではありません。 しかし、これはあなたに何かを言っていますか？



人が実現の微妙さを知っているかどうかは関係ありません。 それどころか-ささいなことを知ることは非常に重要だと思います。 アセンブラーを知っている人は、Java開発者を探しているときでも、彼を知らない人よりも私にとって価値があります。 しかし、残念なことに、「あなたは何を知っていますか」という直接的な質問はほとんど意味をなさないほど多くの些細なことがあります。 時間が限られているため、何百ものことを尋ねることはできません。



それで、何を尋ねますか？



私は、あなたが通常していることの流れの中で会話を行い、候補者があなたがしばしば解決する問題をどのように解決するかを見るのが最善であるように思えます。

アプリケーションにUIロジックとサーバーコードがあるとします。 候補者にもっと面白いと思うことを尋ねてください。

サーバーコード？ 素晴らしい。 プログラムにいくつかの典型的なコードを紹介しましょう。 候補者がどのような質問を持ち、理論的な知識と実際のニーズをどのように結び付けるかに興味があります。

この問題を言ってみましょう：



コードスニペットがあります

void x(List<String> a) { …Some processing }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

候補者への質問-このコードでは、「何らかの処理」の前にリストをアルファベット順に並べ替える必要があるとします。 あなたは何をしますか？ ところで、はい、すぐにCollections.sortについて候補者に伝えることができます-「語彙」はチェックしていません。

候補が

 void x(List<String> a) { List<String> b = new ArrayList(a); Collections.sort(b); …Some processing with b }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（候補者がこの方法でこの問題を解決し、ソートを開始しなかったことを願っています）。



ただし、問題の解決策は主なものではありません。 主な議論。

なぜ彼は新しいリストを作成し、古いリストを使用しなかったのですか？ 常に正しいですか？

なぜArrayListを使用し、他の何かを使用しなかったのですか？ 彼は他に何があるか知っていますか？



最も興味深いのは、ここでの議論がほぼ無限に続くことです。 候補者は、ArrayListがランダムアクセスであるため、ArrayListの方が優れていると言います。また、並べ替える前に、並べ替えが配列にデータをコピーし、それを返すと言います。 候補者によると、ArrayListはより良くなっていますか？ どうして？ それともとにかく良いですか？



候補者との会話は、彼の考え方を明らかにする必要があります。 彼が知っている詳細をご覧ください。 新しい何かにどのように反応しますか？ そして最も重要なこと-彼はあなたが彼に与えた情報を正しく処分できますか？ 実際、抽象的な「すべての知識」は通常は特に重要ではありません。最終的には同僚が近くにいて、問題のある問題をしばしば話し合うことができます。 同僚はわかりますが、新しい従業員の代わりにコードを書くことはないので、アドバイスを聞いた後、プログラムをより良く書くことができるかどうかを理解してみてください。



または別の例を言う。



「ガベージコレクターとは」と聞かないでください。 「何世代がそこにいるのか」と聞かないでください。 誰がどれだけ気にしますか。 gcがどのように機能するかについて、人はどのような違いを語ることができますか？あなたの仕事にとっては、パフォーマンスの問題が発生した場合、その人が問題を解決できるかどうか、そして世代ごとのアセンブリについて、または同時マークスイープgcについての悲惨な話を伝えることができるかどうかだけが重要です。

誰かがGCの興味深い問題を、それがどのように機能するかを知らなくても解決できると言っているのではありません。 一度、もちろん、彼女は幸運かもしれません。 しかし実際には、知識は非常に重要です。 問題は異なります。何かがどのように機能するかを伝えることができるすべての人が、この何かで問題を解決できるわけではありません。 そして、一般的に言って、直観、一般的な技術的知識は、問題を解決するために、どこかで読まれたアルゴリズムの記述よりもしばしば重要です。

たとえば、gcの場合は、いくつかの実際的な問題を再度もたらすとよいでしょう。

「2ギガバイトのヒープでプログラムを開始し、実行速度が遅い場合、どうしますか？」

-ヒップを増やす

速くなりますか？ そして、最も興味深いのですが、この質問に対する答えを尋ねる価値はありませんが、私にとって「より速い」ものは何ですか？ 候補者がスループットと待ち時間の違いを理解しているかどうかを確認してください。 それが何であり、何が違うのか尋ねないでください。 上記の問題の発言中に、候補者がそのような些細な質問をすることが起こらない場合、実際には、これらの質問はありません。 ただし、会話していることを忘れないでください。 候補者が採石場に飛び込んだ場合は、候補者を止め、さまざまなパフォーマンス特性について教えてください。 候補者は彼らのことを聞いたことがありませんでしたが、彼は股関節の成長が一方を改善するかもしれないとすぐに気づきましたが、もう一方を間違いなく悪化させましたか？ まあ、それは素晴らしいです！



そのような例は無限にあります。 最良の部分は、そのようなパズルは基本的に考えられており、番号が付いていないことです。新しい候補者にそれぞれ異なることについて尋ね、特定の候補者にパズルを適応させることができます。