FizzBu​​zzに失敗しました。雇ってくれませんか？[閉まっている]

私はCSの学位を持つ開発者であり、ほぼ3年間、多数の言語で開発を行った実務経験があります。

今日は面接を受けましたが、全体的に非常にうまくいきました。ほとんどの質問に準備し、何に対してでも準備ができていると感じました。インタビューの終わりに、彼らは私にプログラミングの質問を1つ与えました... FizzBu​​zzのような問題（印刷なしで数字の部分）。私はあまりにも多くの間違いを犯し、それが「失敗」したと信じています。すべての希望が失われていますか？

ここに私のコードがあります：

  void FizzBuzz()
  {
    for(int i = 0; i <= 100; i++)
    {
      bool isThree = i % 3;
      bool isFive = i % 5;

     if (isThree)
     {
         print "Fizz\n";
     }
     else if(isFive)
     {
         print "Buzz\n";
     }
     else
     {
         print "FizzBuzz\n";
     }
  }
 }

ご覧のとおり、構文i％3 == 0;を持つboolsを台無しにしました。正しい質問を覚えている場合は、isThree && isFiveでelseifの代わりにelseを追加します。私はかなりストレスを感じていましたが、それは単純な問題を見逃した言い訳にはなりません。

質問は、経験や性格などの他の要因と比較して、その場で作業コードを作成できることがどれほど重要かということです。たとえば、上記のコードはディールブレーカーになりますか？

FizzBu​​zzのポイントは、実際にプログラミングの方法を知っていることを示すことではなく、プログラミングするように求められた言語のすべてのより細かい構文規則を覚えていることではありません（ただし、経験の程度を知りたい場合は重要です）あなたは言語にいます）。

あなたがインタビュー環境のストレスでこれまでのところに行き、あなたが犯した間違いを理解していることを示すことができたら、私はあなたが合格したと思います。

はい

私がインタビューしたほとんどの人々は、マイナーな構文またはわずかに論理的ではないコード実行部分に失敗し、最終的にはより良い採用となりました。

ロジックの核となるアイデア（あなたがしたこと）をまっすぐに取得し、コードの観点から適切で簡潔なものに変換すること（ほとんどあなたがしたと思います）は、完全に完璧にするよりもはるかに重要です。

IDEを購入するのは、そのための開発者を雇わない構文チェックのためであり、最初のデバッグの瞬間に他の間違いに気付いたでしょう。

最初の要件から最初の試行まで、ひどいことを何もせずにかなり直接的に行った。これは多くの環境で価値があり、フィードバックがなければ完璧です。雇用主があなたが見逃した詳細にこだわっていれば、とにかく来る環境の兆候かもしれません。

タスクが印刷番号のバリアントである場合、詳細の欠落は少し悪いように見えますが、それ以外の位置であなたが好きだった場合、私の決定を変更するのに十分な重みがありません。

[編集]アレックスが指摘したように、反応と落ち着きの側面もあります。個人的には、実際のエクササイズに進む前に、経験を少し外して何かをインタビューしようとすることで、それを邪魔にならないようにしていますが、この2つを組み合わせることもできます。時々、教科書の知識しかなく、理論と背景の問題を真っ直ぐに航行するが、実際の練習をどこから始めるべきかを真剣に考えている人に出会うことがあります。どこから始めればよいかわからない人もいます。

これらの個人は、まさにこの演習で除かれたいものです。

したがって、インタビュアーに要件を明確にするのに20分かかったのでない限り、あなたの解決策は多かれ少なかれあなたが行ったようにいくつかの修正を伴う最初の試みだったと思います。あなたが5分以内に上に置いたものを手に入れたなら、あなたは私の基準に対して十分に考えることができることを示しました。

上記のコードは、私が他に何もすることがなければ、おそらく私にとって契約違反になるでしょう。彼らがマイクロソフトのインタビュースタイルに従う場合、この質問をした人はおそらくあなたをブロックします。

私を困惑させるのは、インタビュアーがこのコードについて尋ねなかったことです。優れたインタビュアーは、特に急いでいるときに人々が間違いを犯すことを知るのに十分な独自のコードを見てきました。通常、彼らは「今、このコードに何か問題がありますか？」と言います。「いいえ？まあそれをテストしましょう」。いくつかの結果セットを考え出し、それを関数で実行します。次に、「ああ、それはうまくいきませんでした」と言います。「わかりました、どのように修正しますか...」など。そのダイアログを生き延びた場合、実際には非常に印象的であり、批判的に考え、テストケースを考え出し、独自のコードをデバッグする能力を示しています。

また、彼らは通常「作業コード」を探していないことに注意してください。とにかく最初の試行でそれを作成するのは誰ですか？しかし、エラー処理と適切なテストセットを使用して論理的に正しいことが目標です。

さらに、これはあなたを驚かせるかもしれませんが、あなたはfizzbuzzを始めることさえできない多くの人々と競争しています。私たちは、他の誰もが睡眠中にb +ツリーを走査していると仮定する傾向があります。他の候補者よりもはるかに優れていたことに驚くかもしれません。

私のアドバイスは、それをはがすだけです。最近、大規模なソフトウェア会社（Microsoft、Amazonなど）でインタビューを行いましたが、このような徹底的なインタビュープロセスを経験したのは初めてでした。マイクロソフトのオンサイトインタビューで、主に神経のために私は馬鹿になりましたが、何を期待しているのか、彼らが何を探しているのか正確に知りませんでした。本当に簡単な問題を解決するためだけに、最短経路の問題を特定しました。私はスタックの間違った端から値をポップし、int atoi(char* value)実装を忘れましたint val = value[i] - '0';文字の整数値、およびその他のいくつかの愚かな間違いを教えてくれます。私はインタビューの大部分で満足していましたが、申し出を受けなかった理由を理解しました。これは私の能力を反映したものではなく、神経をマスターできるようになるまで試してみなければならないことを示すものであることに気づかなければなりませんでした。やがて私はインタビューをもっと難しい質問で打ち、夢の仕事を見つけました。実際には、実際に自分が何をしているのかを知っているほとんどの人にとっては、インタビュアーが何を望んでいるかを把握し、自分に自信を持ち、それを与えるだけです。少し時間がかかります。

私はノーと言う必要がありますが、あなたが与えた理由ではありませんが、FizzBu​​zzセクションを最後に置くことです。コードが機能する方法では、期待どおりにFizzBu​​zzを印刷することはありません。Leeがコメントしたように、3または5で割り切れないすべての値に対して出力します。

しかし、主なポイントは、そこから学ぶことです。私はあなたがここにいて、どうすればもっと良くできたのかを尋ねているという事実が好きです。いくつかのコードパズルを行い、一般的なインタビューの質問を調査してください。また、自分でタイミングをとるか、面接で得ようとしている気持ちをまねることができるように、プレッシャーを高める何かをすることもできます。そして、もしあなたが本当に公園からそれをノックアウトしたいのなら、面接の準備、準備、さらに準備をしてください。

いいえ。FizzBu​​zzのポイントは、すべてのケースをカバーする基本的な条件付きロジックを実行できるかどうかを確認することです。一部の人々の意見に反して、FizzBu​​zzはモジュラス演算子ではなく、3項演算またはブールオペランドを知っています。条件付きの簡単な演習であり、失敗しました。

この問題は、すべての「エレガントな」コードが少なくとも1つのケースをカバーできないように構成されています。

受け入れられる答え：

if div3 print fizz
if div5 print buzz
if !div3 && !div5 print x


if div3 {
    print fizz;
    if div5 {
        print buzz;
    }
} else {
    if div5 {
        print buzz;
    } else {
        print x;
    }
}

私は、ホワイトボードでやるべき些細なプログラミングの問題を人々に与えます。結果のコードにバグがないかどうかは、決定点ではありません。代わりに、コードの作成中に示された多くの動作に関心があります。それはインタラクティブであり、私はそれが起こっている間、候補者について多くを学んでいます。

インタビュー中のホワイトボードの「テスト」で詳細に説明します：（ホワイトボード）コードをバックアップする正当な方法ですか？

もちろん、あなたのインタビュアーは私のようなものではないかもしれません。しかし、あなたが私とのインタビューに合格して、ほんの少しだけコードを作成し、同一のコードで失敗する可能性は完全にあります。

これを評価していた場合、次のものを探していました。

1. 候補者は、実装に進む前に要件を明確に理解しようとしますか？候補者は私の問題を解決しようとしていますか、それともプログラミングツールボックスでペットツールを使用しようとしていますか？候補者はどのように問題を解決しますか？
2. 候補者は少なくとも1つのプログラミング言語に堪能ですか？
3. 候補者はブール論理を把握していますか？
4. 候補者は、ソリューションの品質を確保するために何をしますか？
5. 候補者は自分のコードに関するフィードバックにどのように対応しますか？

-

＃1で言うのは難しいです。あなたの質問は、あなたの問題には「印刷番号」の部分が含まれていなかったと述べており、実際にはあなたのソリューションにはそれが含まれていません。私はそれを選択するしかありませんが、実際にはどちらでも割り切れない数字を印刷することを含む古典的なFizzBu​​zzの問題であれば、要件を完全に理解する前に解決策に飛びついたようですマークオフになります。

＃2と＃3の部分的なクレジットを提供します。モジュラス演算子を使用することは知っていて、実用的なソリューションの構造を持っていましたが、両方の一部を見逃していました。

＃4をやらなかったように思えます。将来的には、ホワイトボードから一歩下がって、解決策を呼び出す前にソリューションを確認することをお勧めします。また、（プロンプトが表示されることなく）ソリューションの単体テストをいくつか実行します。

彼らはあなたに＃5のチャンスを与えませんでした、それは残念です。しかし、ポイントは、これまでに書いたコードのすべての行は改善できない可能性のある純粋な金だと思っている人ではなく、彼の解決策についてのフィードバックを受け入れ、彼のアプローチについて何らかの会話をする人。

-

それで、もし私がこれだけで評価していたら、「No Hire」と投票するでしょう。このようなことは、プログラミング能力ではなくパフォーマンスアートを測定するようなものですが、それをマスターすることはあなたのキャリアを支援することができます。したがって、将来の技術面接に関する私の推奨事項は次のとおりです。

1. 面接の前に、できるだけ少ない外部リソースを使用して、これらの種類のエクササイズをいくつか練習してください。ソリューションを暗記するのではなく、好みの言語に慣れていることを確認する

2. 問題について質問して、仮定を検証します。

3. ソリューションの完了を発表する前に、ホワイトボードから戻って確認し、いくつかの簡単な単体テストケースを確認してください。

改善を許可されていないため、ソリューションに関するフィードバックを取得することなく問題を解決するように誰かに依頼することは疑わしいアプローチです。

このテストは、あなたが非常に優れた「トップオブザヘッド」問題解決スキルを実証しなかったことを示しています。

これはあなたを雇うかどうかの決定の要素の1つかもしれませんが、私にとってはそれが唯一のものではないことは間違いありません。

単体テストまたは実行環境が提供されたとしても、あなたが犯した間違いはあまり許されなかっただろう。