インタビューでは、難しい質問に対するブルートフォースソリューションをコーディングするのがよいのでしょうか、それともインタビューを注意深く質問を調べるのに費やすほうがよいでしょうか？[閉まっている]

インタビュアーが意図しているかどうかにかかわらず、インタビューの質問は難しい場合があります。限られたインタビュー時間を使用して、い、非効率的なブルートフォースソリューションをコーディングするか、インタビュアーで問題のあらゆる側面を理解する時間を費やすかを選択できます。

たとえば、Project Eulerの問題91は、可能性のあるすべての三角形を計算し、isRightTriangle（）テストを記述し、テストに合格するすべての三角形をセットにポップするというそれほど難しくないブルートフォースソリューションによって解決できます。しかし、X / Y座標の2つのペアにより、高い定数値を持つO（x ^ 4）解が作成されます。友人と私は、はるかにエレガントで効率的なソリューションを思いつきましたが、2人で3時間かけて数十個の図を描き、複数の数式をテストし、複数のアプローチを検討しました。

すべてのインタビューの質問が公正であるとは限りません。また、ある人にとって簡単なことは別の人にとっては難しいかもしれません。誰かが質問に苦労した場合、ブルートフォースのい解決策が効果的であることにもっと感心しますか？または、優れた問題理解とエレガントなソリューションへの道を歩んでいますが、コード化されたソリューションはありませんか？20分後には、何があってもコーディングを始めるべきというようなルールはありますか？

まず、経験豊富な2人の開発者がエレガントに最適化するのに3時間かかる質問は、インタビューの質問には適していません。あなたがそれを尋ねるなら、あなたは完璧な答えを期待すべきではありません。

その一方で、時には、限界に到達させたときに、その人について最も多くを学ぶことがあります。だからこそ、多くの大学のコースが難易度を上げてから、カーブで評価します。各試験で全員が100％採点する場合、多くの潜在的な学習を除外しています。

私の理想的な候補者は、おそらく最初に複雑さの計算を行い、「ああ、それはたったの600万回の反復で、それほど長くはかかりません」と言ってから、ブルートフォースソリューションをすばやく記述します。その後、インタビュアーが要求しない限り、必ずしも実装することなく、最適化するために取れるアプローチについて議論します。

部分的には、これは、現実の世界で発生するプロジェクトオイラータイプの問題の多くは、一度解決してからそれを忘れる必要がある一発的な問題であるためです。私が雇う誰かが書くのに2分、実行するのに10分かかるブルートフォースアルゴリズムを認識することができることを知りたい一度それを実行します。

雇用管理者として、目の前にあるコードの問題を解決するように頼む場合、コード自体を見るのはそれほど重要ではありませんが、方法と理由を確認するためにあなたがしたことをした。あなたがするかもしれないそれらのことの1つはコードではなく、代わりに問題をよりよく解決するために問題自体の側面について私に質問します。それは私にとって意味のあることであり、通常、コードに記載されているソリューションよりも意味があります。しかし、それは誰もがそれを行う方法ではなく、誰もが見たいものでもありません（実際、インタビューの設定でコードを書くように人々に頼むことはめったにありませんが、テーブルに問題を置いて話し合い、時々擬似コードが出現します、これは私にとっても良いことです）。

すべてのインタビューの質問が公正であるわけではなく、誰かにとって簡単なことは別の人にとっては難しいことです。その設定とそれらの制約があるため、通常はコードソリューションを探していないことを理解しているインタビューは（繰り返しますが、それは重要な役割を果たしますが、むしろ解決プロセスです。

「20分後には何でもコーディングを開始する必要があるようなルールはありますか？」私はこれに答えるために、問題について非常に短い時間内に、少なくとも何かをする必要があります-より多くの質問をする、ソリューションのフレームワークをスケッチする、またはあなたがただそれをできない/どこから始めればいいのか分からない。

私があなたの前に難しい問題を置き、あなたが提供した解決策-時間の制約とあなたが持っているものが与えられた-総当たりとandい場合、私はあなたにそれがなぜだったのかについて一連の質問をします、そして何がそれをよりエレガントなものに変えるのでしょうか：より多くの情報？より多くの時間？別の環境？自意識を持ち、自分がやったこと、やっていなかったことの理由に触れ、それを合理的に説明できることは、私の本では大きな金の星ですが、それは私が開発者のようなものです探す。だから、「優れた問題の理解とエレガントな解決への道」も私にとってはうまくいくだろうが、すべての人にとってはそうではない。

両方とも欲しいのですが、1つのソリューションで「機能するコード」を表示し、その1つまたは別の問題を改善するための潜在的なソリューションを議論する可能性があります。

誰かにコードを書くように頼み、彼らがゼロコードで可能な解決策について話したいだけなら、それは心配になるでしょう。

あなたが言ったように、誰かが何らかの理由で特定の問題に苦労するかもしれませんが、あなたは彼らがそれらを解決する方法を学ばなければなりません。彼らは幸運を得ることができ、すでに同様の問題の解決策について聞いたことがあるでしょう。それは起こります。

誰かが十分なコードを書いて議論するのを見てください。彼らが仕事にふさわしいかどうかを判断できます。

20分後には、何があってもコーディングを始めるべきというようなルールはありますか？

いいえ。ただし、業務に着手する前に問題の分析に20分を費やしている場合は、おそらくすでに問題に直面しているでしょう。あなたが引用したような質問をする雇用主は、あなたが問題にどのようにアプローチするかに主に興味を持っていますが、彼らがコーディングの問題としてそれを尋ねるなら、彼らもいくつかのコードを見たいでしょう。あなたの思考プロセスを通して彼らに話してください...

さて、ここでの明らかなアプローチは総当たりです。3つの頂点が与えられた直角三角形を認識する方法があれば、2つのポイントと原点が直角三角形を探しているすべての組み合わせを実行できます。それは難しくないはずです-ピタゴラスの定理を使用して直角三角形を識別する関数を書くことができます。それを簡単にするために、距離式を使用して2点間の距離を決定する関数も作成します...

これらの関数の作成には約3分かかります。質問のほんの数分で、基本的なジオメトリを覚えており、コードの作成方法を本当に知っていることを既に示しました。また、次のことも説明します。

したがって、明らかにisRightTriangle(p1, p2, p3)4つのforループの中央に関数を配置し、2つの変数ポイントのそれぞれについて可能なすべての選択肢を反復処理できます。見てみましょう...問題は、50x50グリッド上の原点を含む直角三角形の数を要求するため、ブルートフォースメソッドを使用して、各ポイントの各座標の50の可能性をチェックします。それは50 ^ 4チェックです...私たちはもっとうまくやれると確信していますが、コードは明らかなので、それを書き留めてください...

そのため、今度は、ネストされたforループを使用する関数と、isRightTriangle()先ほど作成した関数を作成します。問題は解決しましたが、面接官にあなたの行く先を見せてくれました。彼らの目標がコードを書くことができることを確認することだけだった場合、彼らはあなたにやめるように言うかもしれません。おそらく、彼らは彼らが何をしているのかを知っている誰かと話をすることをうれしく思います。それで…

私が書いているときに、対称性を利用できると思いました。45°の線の周りに与えられた直角三角形を反射することができるので、その線の片側でのみポイントの1つをチェックすることを選択した場合、2回見つかった直角三角形を数えることができます...三角形に対して1回と1回その反映のため。これにより、チェックの数が半分になります。また、今それを見て、2つの点の間の距離を見つけるために平方根を取っていますが、それをもう一度平方しisRightTriangle()ます...

等々。繰り返しになりますが、彼らは通常、完璧な解決策を見たくはありません。あなたの思考プロセスは、上記のようなものである必要はありません-大声で考える自信があるだけで、非常に重要です。間違えたとしても汗をかかないでください-「うーん、私はここでレールから外れたと思います-私は一歩戻ってみましょう...」

マネージャーとして、テストとしてコーディングするように頼む場合、私は最も興味があります：

• コードを書くことができるかどうか
• あなたのコーディングスタイル
• 選択したアルゴリズム
• この試みは、問題を理解したことを示していますか
• 特定の技術について本当に熱心なら、多かれ少なかれそれを知っていることを実証しましたか。

最初のアイテムはクレイジーに見えるかもしれませんが、驚くでしょう...

コーディングスタイル-それによって、ブレースを置く場所を意味するだけではなく、

• その問題を解決するために、構成または継承を選択しましたか？どうして？
• その値について、なぜ列挙型と文字列とint型（または適用される順列）を使用することを選択したのですか？
• その値にプロパティ、フィールド、またはget / setメソッドを使用しましたか？どうして？
• クラスの状態をどのように処理しましたか？
• 継承、インターフェース、ラムダがどのように機能するかを理解していますか？
• 言語のパラメーター規則を理解していますか（参照と値の関係は？）
• 単体テストの書き方を知っていますか？

私が本当に気にしないものは次のとおりです。

• コンパイルすること（メモ帳を渡しただけでコンパイラーがないと仮定）
• その1つの関数内のこれら2つのパラメーターの順序をメモリで知っていたこと
• SQL ServerまたはOracle接続文字列を暗記できること
• すべてのミスを見ながら肩越しに立ちながら、完璧にコーディングできること。

正直なところ、スタイルを分析するためのツールを除いて、コーディングテストはあまり好きではありませんでした。

その場合、洗練されたソリューションへの侵入は、悪いが完全なソリューションよりも優れています。どちらの場合も良いです。実際にプログラムをコーディングする時間がなかったとしても、問題とその解決方法を理解していることを示すpusdocodeを書き留めておけば、まったく問題ありません。

あなたは実際には答えがなく、「正しい」答えではない質問をしていると思います。私がこれを言う理由は、それは質問をしている人が何を評価するかに完全に依存するからです。

インタビュアーは、あなたが何かを素早く動作させ、残り時間があれば優先度の低いアクティビティとして最適化することを本当に見たいと思っている筋金入りのプラグマティストである可能性があります。同様に、インタビュアーがグーグルの雇用慣行について最高の印象を与えており、最もセクシーで最もエレガントなアルゴリズム以外には興味がなく、「ブルート」や「互いに5語以内の力」。また、インタビュアーが「インタビューの質問」をグーグルで検索して、あなたが入る5分前にインターネットでこの問題を見つけたので、彼が何を望んでいるかわかりません。

いずれの場合も、コンテキスト情報に基づいてインタビュアーが望んでいるものを推測できない場合は、おそらく明確化を求めることが最善の策です。すべてのインタビューの質問が公正であるわけではなく、実際、すべての質問が良い質問であるとは限らず、理にかなっている質問であるとは限りません。インタビューは本質的に還元主義的な活動であり、誰かと1時間か2時間過ごし、その時間に基づいて、次の時間に一緒に仕事ができるかどうかを推測しようとする「スピードデート」のようなものです。 5年かどうか。その観点から調べて、「ルール」についてのあなたの質問に対する答えが本当にないという理由がより明確であることを願っています。

誰かがあなたにあなたの能力についての洞察を与え、彼らのチームに合うと思う質問をしている あなたは彼らのチーム、彼らについて知っていること、インタビュアーの人格、および他の多くの要因を見て、彼らが価値があると思われる答え、アプローチ、およびプロセスについて最良の推測をしなければなりません。個人的には、最高のアイデアだと思う方法でアプローチする必要があると思います。彼らがあなたに同意しないなら、それはとにかく良いフィットであることを巻き上げなかったかもしれません-後でより早くそれを理解するのは簡単です。

インタビュアーは、とにかくあなたのソリューションを改善するように頼みます。

「ブルートフォースソリューションファースト」アプローチには、紛れもない利点が1つあります。理想的なソリューションを見つけることができなかったとしても、それを示すために何かを完成させる必要があります。