FizzBu​​zz以降の有効性[終了]

面接プロセスの一環として、最初に候補者に「FizzBu​​zz」を行うように依頼します。今日では、FizzBu​​zzに正しく答えることができる候補者の割合が劇的に増加しています。これはWebでの人気による可能性があります。

約1年前、2番目の質問として、元のFizzBu​​zzと非常によく似た質問をし始めました。質問は、元のFizzBu​​zzと同じくらい単純になるように設計されており、候補者の特定の能力、具体的には、いくつかの「ビジネスルール」で意味のある論理的な方法で順序付けおよび優先順位を付ける能力も評価する任意の順序。質問の文言は最初は少し曖昧に見えるので、英語を母国語としない人にとっては難しいかもしれませんが、考え抜かれた問題を正しく解決できる場合は、候補者に明確化のための質問をする機会を与えます。これは常に良いことです。

ソフトウェア開発は通常、時間の経過とともに特定の順序で導出されない機能要件に基づいているため、開発者としてこれは非常に重要なスキルであることがわかります。少なくとも、実装に関する潜在的な問題と競合を調査する鋭い開発者の仕事。

FizzBu​​zzに合格した候補（サンプルサイズ38）の65％を少し超えると、FizzBu​​zz v2.0に完全に失敗することがわかりました。早い段階で。

私の質問は、FizzBu​​zzが古くなっているかどうかではなく、FizzBu​​zz v2の質問に合格しなかった候補者が非常に多いのにどのような要因が関係しているのかということです。

• 質問は曖昧すぎますか？
• 面接環境のストレスは、そのような些細なタスクを完了できないという点まで批判的に考える能力を低下させますか？

質問：

入力として文字列のリストを使用するお気に入りのプログラミング言語でルーチンを作成し、リスト内の各文字列に対して次のいずれかを実行します。

1. 文字列に文字Aが含まれる場合、Fizzのみを印刷します
2. 文字列に文字Bが含まれる場合、バズのみを印刷します
3. 文字列にAとBの両方が含まれる場合、BuzzBuzzのみを印刷します
4. 文字列にAとBの両方が含まれていない場合は、FizzFizzのみを印刷します
5. 文字列に含まれるAとBがそれぞれ1つのみの場合は、FizzBu​​zzのみを印刷します

候補者からの典型的な質問は次のとおりです。

• 大文字と小文字を区別する必要がありますか？
• 「AとBを含む」は、AがBの前に来ることを意味しますか
• どのポイントも満たされない場合、何を印刷する必要がありますか？
• 複数の条件を満たせる場合はどうなりますか？

質問を無事に完了した圧倒的多数の候補者は、FizzBu​​zzのように何も質問しませんでした。

FIZZBUZZよりもはるかに優れたテストになる可能性がありますが、正解の概念がある場合、それは世界で最悪のテストです。これらのテストは、最初はインタビューではほとんど価値がありません。

候補者が質問をせずに「正解」と答えた場合、候補者の選択で間違った種類のプログラマーが選択されるという問題があります。 。プログラムがあらゆる面で技術的に完璧であるかどうかは問題ではありません。おそらく、彼は「あなたが望んでいるものではなく、それがあなたが求めているものだ」とソフトウェアを提供する人です。

ここでのテストの一部は、ルールの優先順位です。指定しません。入力「ABC」は、Fizz、Buzz、BuzzBuzz、またはFizzBu​​zzを印刷できます-これらのいずれかが正しい

私が取る候補者は、（ほとんど）正しいと思った候補者ですが、多くの質問をし、理想的にはホワイトボードで多くの「いじり」をしました。

たとえば、一連のサンプルテキストを提供し、印刷する内容とその理由を尋ねることで、これらの要件に対する理解を深めます。-私の「ABC」の例の入力に関する議論は、あなたにとっていくつかの有用なサイトにつながるはずです。

FIZZBUZZと同様に、このテストの結果は、結果がどのように得られたかについての観察と同じくらい良好です-結果は無関係です。

私はそれを少し微調整します-それをより面白くするために-「のみ」を取り出します。上記の行（「次のいずれかを印刷」）で説明されており、それについて多くの人が尋ねています。候補者が「唯一」を逃し、時間があれば、それを指摘し、何が起こるかを見てください。彼が「唯一」を扱う場合、要件からそれを削除し、コードを変更するように依頼します。

要件に「のみ」という言葉があると、すべての質問に矛盾が生じます。

したがって、あなたの質問は、プレッシャーがかかっている間に要件の収集をテストしますが、そのスキルの組み合わせをテストしてもよろしいですか？

要件の収集をテストする場合は、質問の1つを曖昧にすることをお勧めします。FizzBu​​zzの代替品が必要な場合は、あいまいさを取り除きます。

ビジネスルールの優先順位付けは、ドメイン固有の知識でのみ行うことができます-実行していることの単純なコンテキストを含めない限り（おそらく、それらはさまざまな価値と引き換えられるクーポンです）、開発者が自分で決定する根拠はありません。

しかし、それを行うことで望ましくない結果が生じるリスクが高い場合、誰かに明確化を要求することは、おそらく知識の限界を認識するスキルを評価する最良の方法ではありません。彼らは、あなたが要件を書くことに無能であることや、面接者が開発者でない場合、悪い態度を持っているとラベル付けされることを指摘するよりも、推測して間違った方が安全であると考えるかもしれません。

質問を無事に完了した圧倒的多数の候補者は、FizzBu​​zzのように何も質問しませんでした。

要件があいまいであるため、質問をせずにv2.0を正しく終了することはできません。

あいまいさを削除する場合は、要件を次のように変更できます。

入力として文字列のリストを使用するお気に入りのプログラミング言語でルーチンを作成し、リスト内の各文字列に対して次の操作を実行します。

1. 文字列に文字「$」が含まれ、「？」が含まれない場合は、「Fizz」を出力します。
2. 文字列に文字「？」が含まれる場合、「バズ」を出力します 「$」は含まれません。
3. 文字列に「$」と「？」がそれぞれ1つだけ含まれている場合、「FizzBu​​zz」を出力します。
4. 文字列に正確に1つの「$」と複数の「？」が含まれる場合、「BuzzBuzz」を出力します。
5. 文字列に '？'が1つだけ含まれている場合、「BuzzBuzz」を出力します および複数の「$」。
6. 文字列に「$」が含まれておらず、「？」が含まれていない場合は、「FizzFizz」を出力します。

質問は曖昧すぎますか？

はい、質問は明確にせずに答えるには曖昧すぎます。ただし、複数のルールが適用される場合、プログラムは最も具体的なものを選択し、あいまいさを排除する必要があるという追加のルール。

面接環境のストレスは、そのような些細なタスクを完了できないという点まで批判的に考える能力を低下させますか？

これは、候補者がFizzBu​​zzを「詰め込んでいる」ことを示している可能性があります。ストレスの有無にかかわらず、プログラムは非常に単純です。

私は、その理想的なソリューションが異なるため、変性FizzBu​​zzは、オリジナルのものと同等ではないと思う：の鎖がif-then-else許容されるままであり、Iは、と思わテーブルベースのソリューションは、この問題のために、より適切です。

static string[,] FB = new string[3,3] {
    {"FizzFizz", "Buzz", "Buzz"}
,   {"Fizz", "FizzBuzz", "BuzzBuzz"}
,   {"Fizz", "BuzzBuzz", "BuzzBuzz"}
};
static string FizzBuzz(string str) {
    return FB[
        Math.Min(str.Count(c => c == 'a'), 2)
    ,   Math.Min(str.Count(c => c == 'b'), 2)
    ];
}

問題空間のサイズは3x3でなく2x2であるため、元のFizzBu​​zzよりもはるかに簡単にテーブルにマッピングされます。実際、私は元のFizzBu​​zz問題に対するテーブルベースのソリューションを理解するのが難しいと感じています。

private static string[] FB = new[] {"{0}", "Fizz", "Buzz", "BizzBuzz"};
public static void Main() {
    for (var i = 1 ; i <= 100 ; i++) {
        Console.WriteLine(FB[(i%5==0?2:0)+(i%3==0?1:0)], i);
    }
}

ここで2つのこと：

1. はい、私はほとんどの人がフィズバズをグーグルで検索し、それを拡張しようとするとつまずくと思います
2. チェックアウト：http : //dave.fayr.am/posts/2012-10-4-finding-fizzbuzz.html 適切な抽象化を使用してフィズバズを解決する方法を説明しています。

質問を無事に完了した圧倒的多数の候補者は、FizzBu​​zzのように何も質問しませんでした。

プログラマーが声を出して考え、質問をして思考プロセスを確認することを奨励するインタビュープロセスを見てきました。このプロセスのほうが好きです。

私はこのfizzbuzz v2.0を読んで、そこで＃3と＃5の要件について尋ねました。私は他の人については知りませんが、エンジニアリングでは曖昧さを望まないので、質問します。後で（コード化されたものとすべてのもの）を見つけたくないので、私は仮定をしなければならず、それが間違っていたことを知りたくありません。

おそらく、あいまいさを回避する最も簡単な方法は、いくつかの例を示すことです。

「A」は「Fizz」を返します「aAbA」は「Fizz」を返します「B」は「Buzz」を返します「aBbB」は「Buzz」を返します「AB」は「FizzBu​​zz」を返します」は「FizzFizz」を返します

候補者に矛盾した/不明確な要件を与えるのではなく、それらの状況をどのように処理するかを尋ねてください。さもなければ、「このインタビューの質問またはそれを尋ねる人が愚かであるということを暗示することなく、どうすれば必要な答えを得ることができるか」という有能な人々を無能に見せる、または悪化させます。

いずれにせよ、それはすべての逃走として刺激的です。インタビューはマッチングプロセスであり、それによって、私は双方向の道を意味します。直接的な質問と意図の明確さは、圧力鍋（IMO）の下に候補者を置くよりもはるかに重要です。FizzBu​​zzは短くて甘いので、コーディングの質問の良い例です。直接再利用しないでください。そのモデルに従うような簡単な質問を書いてください。

しかし、FFSについては、賢くならないで、実際のテストを別のテストの後ろに隠さないでください。いまいましい問題をどのように処理するかを人々に尋ねてください。経験豊富な開発者はあいまいな要件に繰り返し対処しており、その戦略を喜んでお伝えします。あなたも何かを学ぶかもしれません。

そして、誰もがホワイトボードを使いたいと思っているとか、手書きの期間が快適だと思い込まないでください。私たちの何人かは、12歳の頃からタイピングを続けてきました（スペースクエストのおかげです）。ペンやマーカーを手に持ってまっすぐ考えることすらできません。20-freaking-13ですが、すでにホワイトボードには何が入っていますか？人々が私にペンと紙を渡し、コードテストをするように頼むと、笑いを抑えるのは難しいです。

いいインタビューの質問だと思います。現実によくあるように、要件は明確ではありません。候補者が（ストレス下でも）これを実現するのに十分な知性があるか、候補者が必要だと思う質問をすることを恐れず、要件を賢明な構造に入れることができるかどうかをチェックします。また、プログラミングの能力についても少し説明しますが、この問題は簡単すぎるため、再帰やポインターを含むより複雑な問題も提起する必要があります。

ただし、「成功した」候補者が質問をしていないことについて少し心配しています。場合によっては最大4つのルールを適用できることに気付いたかどうか、そしてその曖昧さを解決するような質問には何もないことを彼らが見つけようとし、彼らがそれをどのように扱ったかを説明してもらいたいと思います。たぶんあなたの質問は彼らに尋ねさせるほど曖昧ではないかもしれませんし、声を出して考えるように彼らに尋ねるべきかもしれません。

ところで：あなたが「正しい解決策」について話しているのは奇妙だと思います。そのような質問をした場合、「AB」と表示されたら「Fizz」、「Buzz」、「BuzzBuzz」または「FizzBu​​zz」のいずれかを印刷するのが妥当です。だから私見では、質問をせずに解決策はまったく間違っています。