技術面接中にどの程度の支援が必要ですか？[閉まっている]

私は多くの技術面接中に演技または座るように頼まれます。インタビュー対象者が紙で解決できることが期待される論理的な質問と簡単なプログラミングの問題を尋ねます。（キーボードにアクセスしたいのですが、それはまた別の問題です。）時々、人々は問題に対処する方法を知っていると感じますが、緊張や質問のいくつかの推測によってハングアップします（トリックの質問を意図したものではありません）。

上司が助けやヒントを与えるのを聞いたことはありません。彼はインタビューの回答に（それがどんなに良くても悪くても）感謝し、次の質問や問題に移ります。しかし、私はウサギの穴について、敗北と神経があなたを導く可能性があること、そしてそれがどのようにあなたの心を無効にするかについて知っています。失敗したインタビューの数。

困惑した面接対象者にヒントと支援を提供する必要がありますか？

私が同じような立場にあったとき、私はインタビューの相手に「私はグーグルだと思ってください。もしあなたがそう言うようなものを検索する必要があるなら」と言います。

ある質問では、インタビュー対象者はシリンダーの容積を把握できる必要があったので、誰かが「シリンダーの容積の公式をGoogleに求めなければならない」と言っても気にしませんでした。数式を覚えているかどうかではなく、問題を攻撃する方法を知っているかどうかに興味がありました。仕事のために、彼らは現実の世界をソフトウェアに変換する方法をしっかりと把握する必要があったので、それは重要な概念でした。

一方、私は彼らにその処方が必要だとは言いませんでした。

あなたは神経が問題になる可能性があることは正しいですが、私は人々が緊張していても、思考プロセスを表現できることを期待しています。単に答えを与えないことは受け入れられません。

問題解決と短い技術的な質問の両方に役立つ2つのアプローチがあります。

1. 最初のものはあなたの上司によって使用されます。ストレスの多い状況での人の行動をテストするために助けを提供しないでください。これは完全に有効なアプローチであり、その人についてのヒントを提供する場合があります。結局のところ、この人を雇ったら、彼女は同僚全員から絶え間ない援助を受けることができなくなります。

2. 2つ目は、ヒントとサポートを提供することです。サポートのレベルはそれほど重要ではありません。唯一重要なことは、あなたがその人により多くの援助を提供すればするほど、あなたが彼女の成功を評価する必要が減ることです。

個人的には、その人が自分で問題を解決できないことを確認し、助けがなければ解決できないと感じさせるために十分な時間をかけるべきだと思います。しかし、その後、あなたはその人に答え自体を伝えるまで、進歩的な助けを提供するかもしれません。

例：

‒ C＃で読み取り専用プロパティ、つまり、コンストラクタ内でのみ初期化でき、後で変更できない値を持つプロパティを作成する方法を教えてください。
- もちろん。キーワードを使用しreadonlyます。
- 本気ですか？プロパティとフィールドの違いを説明できますか？
‒ふむ プロパティは...見えます...取得して設定します...
‒ OK。したがって、フィールドはクラスまたは構造体内で宣言された変数であり、クラス/構造スコープ内で有効です。一方、プロパティはフィールドに似ていますが、値の読み取り、書き込み、または計算のメカニズムも提供します。さてどうでしょうreadonly？プロパティで使用されていますか？
‒フィールドにのみ使用されると信じています...
‒正しい。では、プロパティについてはどうですか？
‒読み取り専用にすることはできません。
- 本気ですか？ゲッターのみを持つプロパティはどうですか？
‒読み取り専用です。
‒それらの値は常に同じままになるということですか？
- はい。
‒いいえ、そうではありません。ゲッターを持つプロパティがあるという事実は、その値がクラスのインスタンスの存続期間中に変化しないことを意味しません。プロパティにアクセスするたびに増加するフィールドをゲッターが参照する場合、戻り値は連続的に増加します。
- 右。
- そう？決して変わらない値を持つプロパティを実装する方法を考えていますか？
‒いいえ
。‒読み取り専用のバッキングフィールドを使用できます。バッキングフィールドとは何ですか？
[...]

答えを出すことは、すべての場合において良い考えです。インタビュイーが私の答えに興味深いコメントをしたいくつかのケースがあり、そもそも質問に答えられなかったとしても、彼はまだ関連事項を知っていることを示した。

また、それ以上の助けを借りずに質問するだけで、その人についての情報をあまり持っていないことになります。彼女が答えを知っているか知らないという事実は別として。漸進的な支援を提供することで、その人が問題についてどのように考えているかを見ることができます。

また、その人が知らない他のことも表示される場合があります。上記の例を考えてみましょう。最初の返信で停止する場合、その人がフィールドとプロパティの違いを説明できないこと、またはバッキングフィールドが何であるかを知らないことを知りませんでした。

その人がすぐに答えれば、それは大丈夫です。彼女が何らかの支援を必要とする場合、これには何の問題もありません。あなたが自分で質問に答えることになった場合、それは悪い兆候であり、できれば面接対象者が他の質問に答えることができるでしょう。

インタビュー対象者が単純なもの（特定のパターンの名前など）にこだわっている場合は常に支援し、データベース接続の確立の詳細などを面白くさせたいと思っています。しかし、彼らが何かをデザインしようとしている場合、彼らが私が彼らが行くと推測している場所以外のものについて考えているなら、彼らを案内したり捨てたりしたくないので、私はあまり言いません。

非常に具体的な結果を念頭に置いたインタビュアーから特定の問題解決の質問をされたことを覚えていますが、彼は質問を私に明確に伝えることができませんでした。これは、多くのインタビュー対象者が遭遇する状況を説明しています。時々、空白の凝視は、その人が良い問題解決者ではないからではなく、質問をしている人が彼らが尋ねているものが明確でないためです。その場合、何も言わずに何もしないという同僚のアプローチは、候補者があなたの同僚のように思わないこと、または同僚の頭の中にいないことを証明するだけです。質問を別の言葉で明確にすると、関係者全員にとってより良い結果が得られると思います。

プログラマー（少なくとも私たちのほとんど）は真空で作業しておらず、インタビューは人為的な制限なしで十分にストレスが多いことを考えると、インタビュー対象者が要求または必要とするのと同じくらい多くの支援を提供したいと思います。

ただし、申請者の実際の能力レベルについて最終判断を下す際には、すべてを考慮してください。

上級職を探しているが、多くの助けが必要な人は、警鐘を鳴らします。

「高齢者」の場合、私は短い、自由な質問を提供し、彼らが答えよりも質問にもっと注意を払っています。私は、耳を傾け、コミュニケーションを取り、アクティブなリスニングを使用し、明確にし、そして私が好きなタイプのソリューションを提供する高齢者を見つけます。

「ラインエンジニア」の場合、申請者にコンピューターと問題を与え、数時間後にプログラミングテストにテクニックを使用してから戻ってきます。その状況で、私たちは事前に申請者に彼らが好むOSとツールを尋ねました（プログラマーの専門知識の興味深い部分でもあります）。それらが終了したら、グループとして、ソリューションと、他のソリューションよりも優れている理由-コードレビューを提示するように依頼しました。1日目に経験豊富なエンジニアに期待するすべてのスキル。

重要なのは、面接チーム全体が同じテストを行うために午後を取ったため、テストが公正であることがわかったということです。インタビュー対象者と同じように、各人のアプローチを調べるのに1時間を費やしました。

この2番目の手法により、私がこれまでに見つけた最高の「名も無き」プログラマー（履歴書の履歴書、面接の面倒なスキル）が見つかりました。

候補者がプロセスに慣れるために、簡単な自信を育てる質問でインタビューを始めることを好みます。これが機能する場合でも、仕事関連の資料よりもボディーランゲージをよく理解している候補者にメリットを与えることなく、後の質問から可能な限り多くの情報を収集できます。

minor hints口頭インタビュー中に提供することは、候補者がトピックをどれだけ理解しているかを確認するのに役立ちます。ただし、no hints各受験者に要求する標準テストが必要です。

基本的に、two main things潜在的な候補について知りたいことがあります：

a）個人的な特徴 -彼はあなたの会社やチームにうまく適合していますか

b）技術的スキル -彼は優れた技術的背景を持ち、新しいものを拾うことに興味を持っていますか

これらのポイントについて学ぶためには、潜在的な候補者を会話に参加させる必要があります。また、候補者がcomfortable during the interview現在のスキル（ソフトとテクの両方）と仕事をする可能性を最大限に理解できるようにすることも重要です。

さらに、潜在的な候補者のコミュニケーションスキルは、問題を解決するための彼の技術スキルと能力と同じくらい重要です。

注目すべきことの一部はコミュニケーションスキルです。質問について不明な場合、候補者は質問をして明確にする必要があります。私の意見では、これは良いことです。多くの場合、仕様を読んだり、この場合はインタビューの質問を処理するときに特定の仮定が行われるため、悪い決定が下されます。候補者はこれらの仮定に基づいて回答し、意図したポイントを完全に逃す可能性があります。質問に欠陥があるか、候補者である可能性があります。どちらの場合でも、コミュニケーションを介した明確化を可能にすることは、雇用主が探すべき価値あるスキルを示しています。

これは最終的にはインタビュアーとしてのあなたの性格に帰着し、あなたが重要だと思うもの、したがって本当に候補者を評価していると思います。

個人的には、アカデミック/難解なトリビアよりも実用的/実用的な能力を重視しています。私は、マニューシャの記憶がどれほど優れているかよりも、仕事に取り掛かり、仕事のために雇われているプロジェクトに価値のある方法で効果的に貢献できる候補者にはるかに興味があります。

そのため、候補者が難解なもの、めったに使用されないニュアンス、または作成されたインタビューの質問に関連する可能性があるが、実際の生活ではめったに関連しないエッジケースに引っかかっている場合、私は少しコーチします。特に、Googleで数分、便利なデスクリファレンスで得られるもの、または「設定して忘れる」タイプのものを入手できます。

ただし、現実世界の一般的な主流の基本的な1日の仕事については指導しません。これらは私が彼らに生得したいものです。

インタビューの状況と質問に依存していると思います。私は両方のテクニックを使用しました。

フォローアップの質問をしたくないのはなぜですか？ストレスに対するその人の反応を見つけようとしているとき。私は非常にストレスの多い環境にあるいくつかの仕事の人々にインタビューしましたが、彼らがストレスにどれだけうまく対処できるかは評価の重要な要因でした。

彼らの技術的な知識を見つけようとするとき、私が探しているものについてのヒントを含むかもしれないフォローアップの質問をします。公平を期すために全員に同じ質問をする必要があると言ったマネージャーの考えに反して、いくつかの条件が満たされている限り、これは公平だと思います。最初に、全員が同じ基本質問をされます。第二に、1人だけを助けるためにフォローアップの質問をするべきではありません。他の人が助けを借りずにヒラメさせた場合、助けを借りずにすべてのカレイを放つ必要があります。次に、質問に対する候補者のパフォーマンスを、最終的な回答だけでなく、候補から引きずるのがどれだけ難しいかという点でも比較する必要があります。このプロセスは、依然としてすべての人を公平に扱います。

プログラマーの種類に依存します。素晴らしい20行のコードを紙に書くことができる内向的な人は、上司によく似合います。優れたソフトウェアを効率的に作成するためにチーム内の数百万のラインコードベースで作業できるソフトウェア開発者は、おそらくあまりうまくいきません。候補者としてこの種のインタビューが大好きです。上司がスタッフをどのように扱っているのか、仕事の文化とは何かを教えてくれます。このようなケースでは、インタビューを辞めたとき、「ありがとう-少し時間を節約しましょう。私に電話しなくても電話しません」と言いました。理由を尋ねられたとき、私は失敗するように私を設定した会社のために働きたくないと指摘しました。

あなたのアプローチは、ソフトウェア開発のためのより良い選択肢を得る可能性があります。あなたの上司のアプローチは、ゴミ収集家や道路工事でストップ/ゴーロリポップを持っている人にとってはうまくいくでしょう。

ソフトウェア開発はチームの努力であり、ソロ/マインドリーディング/非インタラクティブゲームではありません。ソフトウェアが要求されたものではなく、要求されたものを実行するために失敗するプロジェクトの数。

私は最近、同様の状況にありました。上司と人事から得た方向性は、6人すべてのインタビュー対象者に対して完全に公平である必要があるということでした。したがって、各インタビュー対象者のパフォーマンスを確認するには、最小限の支援で同じ一連の技術的な質問をする必要がありました。時々、彼らは答えを知っていたが、専門用語や何かにこだわったとき、その用語に導くいくつかの質問で間接的に助けました。性格と行動特性に関する技術ラウンドの後に、彼らがなんとか第1ラウンドを通過できた場合、第2ラウンドのインタビューがありました。

従業員に望むのは、チームの他のメンバーとやり取りできる人です。必要なスキルを持つ人が必要です、本当です。しかし、あなたはまた、いつ助けを求める必要があるかを知っており、そのための自己知識と社会的スキルを持っている人が必要です。後者の敷居セットは、特定のコンピューター言語のデュジュールよりも長期的には会社をより良く築き上げるでしょう。

私の見方では、インタビューは試用ではなく試用のコワーキングセッションです。私は主に「この人と仕事をするのはどんな気分ですか？」という質問に答えようとしています。質問に対する答えを忘れてしまったように振る舞うこともあり、エクササイズをより協調的に感じさせます。

問題を話し合うたびに同じページにアクセスできなかった人と仕事をしたことはありますか？または、問題に飛び込んで解決するのではなく、あまりにも多くの質問をした人はいませんか？インタビューでは、私が話している人がそれらの人ではないことを主に確認しています。そこには化学の強力な要素があります。

もちろん、「きれいなコードを書いているか」、「必要な概念に精通している」、「問題を巧みに突いて洞察を得ることができるか」といったことも学びます。候補者は、引き続き「運転」し、コードを作成します。しかし、その過程で、彼女がよりリラックスして、同僚として私が実際に日々目にするものに近い彼女のバージョンが表示されることを願っています。