技術面接でのテンプレート質問の使用[終了]

私は最近、インタビューで技術的な質問について同僚と議論しました。卒業生として、私は多くの企業を巡り、同じ質問を使用していることに気付きました。例は、「数が素数かどうかを判断する関数を書くことができますか？」、4年後、特定の質問はジュニア開発者にとっても非常に一般的であることがわかりました。私はこれを正しい方法で見ていないかもしれませんが、ソフトウェアハウスは彼ら自身のインタビューの質問を考え出すのに十分な知性を持つべきではありませんか？私は卒業生として約16回のインタビューに参加しましたが、約75％で同じ質問が出されました。これにより、多くの企業が怠andで単純なGoogleであると信じるようになります。「ソフトウェア開発者にインタビューするためのテンプレートの質問」であり、このアプローチをとることで自分自身を傷つけていると感じています。

質問：いくつかのテンプレートから一連の質問を使用する方が良いでしょうか、それともソフトウェアハウスがより独創的で、独自のインタビュー資料を作成するように努力すべきですか？

私の観点から言えば、インタビューに失敗して出かけ、めちゃくちゃになった質問に対する良い答えを探した場合、質問が同じであれば次のインタビューを飛ぶことができました。

これらの種類の質問の多くは、明確な質問を考え出すのが難しいため、ドメインの知識をできるだけ少なくする必要があり、誰かが次のようなトリックの質問にならずにアルゴリズムを考え出す能力を必要とするため、取得」または「取得しない」、および候補者を比較するための回答の歴史的背景があること。また、最高の質問には複数のレベルの正解があり、面接官は候補者の問題解決スキルを評価できます。たとえば、誰かが簡単な素数発見アルゴリズムを提案した場合、実装またはインタビュアーを最適化して候補者をより洗練されたアルゴリズムの1つに導く方法について話し合うことができます。

私はグループに参加しており、多くの異なる開発者が特定の問題が一連のインタビュー対象者にとってどれほど難しいかを評価しました。多くの人が最初にFizzBu​​zzを見て、それを特許的に簡単すぎると却下します。質問の難しさをよく理解せずにインタビューに参加した場合、インタビューした5番目の人は、最初の人に対して否定的な印象を与えながら、人々がFizzBu​​zzに苦しんでいることがわかったため、最初の人よりも大きな利点があります彼らは同じ闘争をしていたので、あなたはインタビューしました。

開発者が新しい質問を思いついた場合、彼らはまた、意図しない文化的または領域的な知識を埋め込まれがちです。たとえば、スポーツに関する質問をします。これは、あいまいさをすぐに見つけたり、「明白な」仮定を立てたりすることができる、そのスポーツのルールを知っている人々に有利になる傾向があります。このスポーツにまったく不慣れな人は、その場でゲームのルールを理解する必要があり、間違いを犯したり、あまり洗練されていない答えを見つけたりする可能性が高くなります。または、彼らは、候補者がいくつかの比較的マイナーな情報を知っている/覚えていると意図せずに仮定する質問をします。たとえば、会計システムに長年取り組んでいる人、誰もが複式簿記システムとは何かを知っている、または単純な複式簿記システムのスキーマ定義を前提とする質問は有能な開発者にとって明らかであると仮定するかもしれません。しかし、現金への借方が現金残高を増加させ、信用が現金残高を減少させるという考えに頭を悩ませなければならない優秀な開発者を簡単に投げることができます。しかし、会計101を採用した人はすぐに追いつきます。あなたの意図が会計の候補者の精通度をテストすることだった場合、これは完全に合理的な質問かもしれません。しかし、主題の専門家を探していない場合は、問題があります。しかし、現金への借方が現金残高を増加させ、信用が現金残高を減少させるという考えに頭を悩ませなければならない優秀な開発者を簡単に投げることができます。しかし、会計101を採用した人はすぐに追いつきます。あなたの意図が会計の候補者の精通度をテストすることだった場合、これは完全に合理的な質問かもしれません。しかし、主題の専門家を探していない場合は、問題があります。しかし、現金への借方が現金残高を増加させ、信用が現金残高を減少させるという考えに頭を悩ませなければならない優秀な開発者を簡単に投げることができます。しかし、会計101を採用した人はすぐに追いつきます。あなたの意図が会計の候補者の精通度をテストすることだった場合、これは完全に合理的な質問かもしれません。しかし、主題の専門家を探していない場合は、問題があります。

人々が使用する数百の「一般的な」テンプレートの質問に対する答えを誰かが覚えてしまう可能性はあると思いますが、それはインタビュアーとして私を悩ませません。そもそも、彼らがそうするのは印象的で、かなりの勤勉さと問題解決を反映しているでしょう。第二に、一般的にはかなり良いトレーニングです-開発者が文字列を逆にする方法を知っていて、素数を見つけるためのいくつかのアルゴリズムを知っていて、ループを書く方法を知っていて、FizzBu​​zzの制御構造を実装しているなら、さまざまなグラフアルゴリズムを知っています定期的に立ち上げるなど、多分かなりバランスの取れた開発者です。開発者が何も学習せずに答えを覚えることができた場合、インタビュアーが少し掘り下げたいと思ったとき、または彼らが答えたとき、彼らはキャッチされます

フィズバズ、文字列を逆にするなどの簡単な質問があると思います。それから、特定の質問があります。制約。最悪の部分は、技術的な知識のないリクルーターがこれらの質問のいくつかを尋ね、非常に具体的な答えを探していることです。...最適な答えを出さなければ、彼らはあなたを絶対バカだと思います。あなたの答えがうまくいくとしても、問題を解決し、最適ではないかもしれませんが、それは非効率的ではありません。

いくつかの例：
カードのデッキをどのようにシャッフルしますか？彼らはFisher-Yatesメソッドを探していますhttp://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle他の答えは「間違っています」.....これは、前にカードをシャッフルして、具体的に調べた場合を除いて、あなたが知っている可能性が高いものではありません。あなたは答えを出す過程でそれに出くわすかもしれませんが、私が見たことから、彼らはあなたがこの風邪を知っていると期待しているので、解決策を見つけるために与えられる多くの時間が与えられることは疑わしいです。別の非効率的な（ただし、より明白な）方法は、元の配列へのポインターと乱数である新しい配列を作成し、乱数で配列をソートすることです。次に、ソートされた配列を使用して、カードの新しい配列を作成します。いずれにせよ、私はそれを採用担当者に提示したことで0クレジットを得ました。

別の例は、すべて1からn-1までのn個の数字のリストで重複した数字をどのように検出するかについての質問です。明らかな答えは（時間の観点では比較的効率的です）、ハッシュテーブルを使用して各要素を挿入し、既に挿入されている要素が見つかった場合、重複を見つけます。最適な答えは、重複がない場合は数値が1〜nであるため、期待される合計はn（n + 1）/ nとして取得できることです。次に、配列を合計すると、実際の合計が得られますが、これは予想される合計よりも少なくなります。だから基本的にn-（予想合計-実際の合計）=重複番号...これはかなり特別なケースです....昔のインタビューの問題に関するオンライン投稿で、以前に同じトリックの関連するものについて何かを見たので、私は大丈夫だった....

もう1つは、追加のスペースを使用せずに文字列内のすべての単語を逆にします。私はそれについて考えなければならなかったし、リクルーターは私が思った5分でかなり焦りました（逆に文字列を分割して再結合するか、新しい配列に単語ごとに行くのは非常に簡単です）。最後の単語の境界線を見つけ、最初の単語の終わりを見つけ、リスト全体を常に1ずつ下にシフトしてから、適切な文字を挿入しました。次に、リストの最後に達するまで繰り返します。この方法は機能し、インタビュアーは同意しました（彼は少し専門的でした）が、非常に非効率的です。家に帰ったとき、私は最適な答えを探しました。それは単にリストを逆にしてから、個々の単語を逆にすることです。一部の人々はそれを思い付くかもしれません、

これらの問題のいくつかを見たら、それを簡単に解決できるようになりました。同じトリックのいくつかでいくつかの同様の質問があるからです。特に、n（n-1）/ 2の数式と数値リストにはいくつかのバリエーションがあることを知っています。しかし、これらの質問が何をテストするのかはまだわかりません。FizzBu​​zzは誰もができるはずのことです（ただし、それほど単純ではないバリエーションを見てきましたが、その場合、コードを入力/デバッグすることなく、インタビューの状況でそれが現実的かどうか疑問に思い始めます）。これらの質問のいくつかは、一度見れば明らかですが、もしあなたがそれらを見ていないなら、それらは明白ではありません。誰かが言及した後、バイナリ検索の最初の正しい実装が現れるまでに何年もかかりました...誰もがそれを読むことができるので、現在バイナリ検索はとても明白です。

それにもかかわらず、最悪の部分は、非技術的な人々があなたのソリューションが最適ではないが正しいと評価できないために質問をするときだと思います。彼らはあなたの解決策が提示されたものではないことを知っているので、それはすべて間違っている、あなたはその試みに対して信用を得られない。最適ではないソリューションでさえ、プログラミング構成の知識を示すことがよくあります。私がポーカーゲームをプログラミングしているのでなければ、誰かがカードのデッキをシャッフルできるかどうかは気にしません。たとえ私がそうであったとしても、彼らに効率的なアルゴリズムを示した後、私は中途半端な人なら誰でもそれに従うことができると確信しています。

テンプレートの質問は、テンプレートの質問をより多く見ている可能性が高いため、面接時間が長かった候補者に有利になるようです。FizzBu​​zzでさえ、最初にそれを見るとき、あなたはおかしくなりますが、何度も何度もそれを見ると、あなたはそれにもっと慣れます。最善の方法は、カスタムビジネスロジックを必要とするコーディングの課題を与えることです。たとえば、データセット（オブジェクト/レコードの配列）を作成してから、各オブジェクトに適用して回答を返すビジネスルールを作成します。たとえば、ある種の評価など、非常にカスタムルール）。彼らはおそらくレコードをループし、ロジックを何百万回も適用しますが、ルールは一意であるため、少なくとも作成したルールを理解し、正常に実装する必要があります。

予想される給与と、候補者のリストとそのお気に入りのビデオゲームのトップ3、そしておそらく初任給としましょう。ゼルダが好きな候補者は300のペナルティを受け取り、小さな人魚が好きな候補者は200のボーナスを受け取ります。ドンキーコングとスーパーマリオブラザーズは好きだが、マリオ博士は好きではない候補者には300ボーナスが与えられます。MetroidやKid Icarusが好きな候補者には200ボーナスなどが与えられます。ちょっと狂っているように見えますが、ビジネスルールを論理的なプログラム構成に変換し、ブールロジックの理解度をテストする能力を示します。全体的には、モジュラスとループを使用しないことを除いて、fizzbuzzとそれほど大きな違いはありません。もちろん、リストを提供してリストをループさせ、特定の出力条件を使用して結果を画面に出力することもできます。

私の最後の仕事の検索では、私は非常に似たような状況にありました。私は、すべての会社で同じリンクリストの質問を抱えていたと思います。

私が気づいたことの1つは、これらの質問が最初のインタビューで出されたことです。

インタビュアーの観点からは、人がこれらの質問を正しく理解できない場合、インタビューの準備をしていません。しかし、これは正しい考えだとは思いません。同社はグーグルからの回答を次のラウンドに移すことができる多くの人々を獲得するが、必ずしも有能な開発者である人々のグループではない。

FizzBu​​zzの定型的な質問は個人的に迷惑であることがわかりましたが、簡単なインタビューになりました。やりがいのあるインタビューが好きです。潜在的な従業員にインタビューするとき、問題を考えて解決できることを確認したいと思います。私は彼らがグーグルを使えることを期待しています。

会社には質問テンプレートが必要ですか？はい。最初の数ラウンドの候補者を評価するのに役立ちます。テンプレートは、Googleで簡単に見つけることができる一般的な問題で構成する必要がありますか？いいえ。それはほんの短いことで関係者全員が変わります。

「ソフトウェアハウスは、より独創的で、独自のインタビュー資料を作成するよう努めるべきですか？」

はい、彼らはそうすべきですが、実際に起こることはあなたが仕事に来て、あなたが明日2人の候補者の面接ループにいるというHRからのメールを見つけるということです。あなたはすでにワニの尻に近づいています、そして、あなたのマネージャーは、新しい、良い、インタビューの質問を考え出すのに半日かかったことに感謝しません。時間に追われて、あなたが質問に頼るあなたがき尋ねた、またはGoogleですぐに見つけることができることをされて。

あなたが言うような質問は、通常、fizzbuzzの質問であり、雇用に使用される質問ではありません。それらは否定的な質問です（つまり、正解するとどんな仕事も得られませんが、間違った解答をするとゴミ箱に捨てられます）。したがって、それらはあまり価値がありません。

後から出てくる質問は、彼らに考えさせる必要があり、たいていの場合、会社が行う仕事の種類やチームダイナミクスとは何かに強い関係があります。

答えは両方です。

彼らの質問のほとんどまたはすべてが同じである場合、それは確かに悪いことです（彼らにとってはそうです）。これはおそらく、インタビュアーがタスクに対して十分に準備されていないことを示しています。

FizzBu​​zzテストのような「テンプレート」エントリレベルの質問を使用すると、時間と労力をあまり投資することなく、完全に無能な人をすばやく取り除くことができます。それでも、テーマのバリエーションは、Googleから直接回答を聞くのを避けるのに役立ちます。繰り返しになりますが、作成したばかりのコードが実際に何をするのか、なぜそれが機能する（または機能しない）かを候補者に尋ねることは簡単です。技術的に熟練したインタビュアーであれば、誰かが答えを知っているふりをしているかどうかをすばやく検出できると思います。

そしてさらに重要なことは、誰かがエントリーレベルのテストに合格すると、難しい質問が出てくるはずです。ここでは、定型回答を暗唱するだけでは不十分です。個人的には、謎の特定の解決策よりも、インタビュー対象者の思考プロセスと問題解決能力全般に興味があります。他の重要なトピックは、開発プロセスとアプローチです。これらのトピックに関する具体的な質問ではなく、自由な議論を開始します。これらの主題については正解も不正解もありませんので、事前に準備することはできません。しかし、議論から私は、私とチームがこの候補者と協力して快適かどうかについて多くを学びます。

したがって、いくつかの限られた量の「テンプレート」質問は問題ありませんが、良い面接はフロープロセスであり、面接官は候補者の（広告および実際の）スキルレベル、精神状態（神経質/疲労）などを含む状況に適応する必要があります。

擬似コードのインタビューテンプレート：

question（FizzBu​​zz_type_question）==正しい場合

それぞれ（array_of_more_interesting_questionsの質問q）question（q）else

インタビューを終了します。

インタビューは次のように分けられるべきだと思います。

• 社会的側面（人事以外）-この人は私たちの組織にうまく適合していますか？彼は正しい態度を持っていますか-彼は私たちの管理スタイルに従うことをいとわないでしょうか？企業とチームは異なるため、これは独創的である必要があります。

• 役割に対する一般的な適合性-繰り返しますが、これは場所によって異なるはずです

• コア：仕事の主な分野に焦点を当てた主題の質問-これは科学的であり、科学的であるため独創的である必要はありません。

• 日常業務適合性：これらは、候補者が日常的に行うことを期待する主題に関する質問です。それは科学的かもしれないが、それは彼がすることが期待される実際の仕事からのものであるほうがよい。この部分は場所によって異なります。