FizzBuzz의 효과와 그 너머 [폐쇄]


38

인터뷰 과정의 일환으로 우리는 처음에 후보자들에게 'FizzBuzz'를 해달라고 요청합니다. 오늘날 FizzBuzz에 올바르게 대답 할 수있는 후보자의 비율이 급격히 증가했습니다. 이는 웹에서의 인기 때문일 수 있습니다.

약 1 년 전, 우리는 두 번째 질문으로 오리지널 FizzBuzz와 매우 비슷한 질문을하기 시작했습니다. 이 질문은 원래 FizzBuzz처럼 간단하고 후보자의 특정 능력, 특히 의미 있고 논리적 인 방식으로 일부에서 제공되는 일련의 "비즈니스 규칙"을 주문하고 우선 순위를 정하는 능력을 평가하도록 설계되었습니다. 임의의 순서. 질문의 문구는 처음에는 약간 모호해 보이므로, 영어가 모국어가 아닌 사람에게는 어려울 수 있지만, 생각을 제대로 해결할 수없는 경우-응시자는 설명을위한 질문을 할 수 있습니다. .

소프트웨어 개발은 ​​일반적으로 시간이 지남에 따라 특정 순서로 도출되지 않은 기능적 요구 사항을 기반으로하기 때문에 개발자에게있어 매우 중요한 기술입니다. 명시 적으로 표시하지 않고 소프트웨어의 다른 영역에 제약 조건을 적용 할 수 있습니다. 최소한 개발자의 업무는 구현과 관련하여 잠재적 인 문제와 갈등을 최소한 조사하는 것입니다.

우리가 발견 한 것은 FizzBuzz를 통과 한 후보 (표본 크기 38)의 65 % 이상이 FizzBuzz v2.0에서 완전히 실패했다는 것입니다. 일반적으로 이러한 후보는 프로세스에서 나중에 감지 될 것이지만,이를 감지하는 좋은 방법 인 것 같습니다. 일찍.

내 질문은 FizzBuzz의 구식 여부에 관한 것이 아니라 FizzBuzz v2 질문에 실패한 후보자들에게 어떤 요인이 기여할 수 있는지에 관한 것입니다.

  • 질문이 너무 모호합니까?
  • 인터뷰 환경의 스트레스가 사소한 과제를 완수 할 수 없을 정도로 비판적으로 생각하는 능력을 감소 시키는가?

질문:

문자열 목록을 입력으로 사용하는 좋아하는 프로그래밍 언어로 루틴을 작성하고 목록의 각 문자열에 대해 다음 중 하나를 수행하십시오.

  1. 문자열에 문자 A가 포함 된 경우 Fizz 만 인쇄
  2. 문자열에 문자 B가 포함 된 경우 버즈 만 인쇄
  3. 문자열에 A와 B가 모두 포함 된 경우 BuzzBuzz 만 인쇄
  4. 문자열에 A와 B가 모두 포함되지 않은 경우 FizzFizz 만 인쇄하십시오.
  5. 문자열에 A와 B가 하나만 포함 된 경우 FizzBuzz 만 인쇄

응시자가 묻는 몇 가지 일반적인 질문은 다음과 같습니다.

  • 대소 문자를 구분해야합니까?
  • "A와 B를 포함한다"는 A가 B보다 먼저 와야한다는 것을 의미 하는가
  • 포인트가 충족되지 않으면 무엇을 인쇄해야합니까?
  • 둘 이상의 조건이 충족 될 경우 어떻게됩니까?

우리는 문제를 성공적으로 완수 한 압도적 다수의 후보자들이 FizzBuzz처럼 아무 것도하지 않았다는 것을 발견했습니다.


26
질문을 조금 모호하게 남겨 두십시오. 그렇게하면 어떤 잠재 고객이 설명을 요구하기에 충분한 혹이 있는지 알 수 있습니다 (개발 자체의 핵심).
Thomas Eding

17
정답은 잠재적 개발자가 BA에게 '이 끔찍한 요구 사항을 수정'하도록 지시하는 것입니다.
Kirk Broadhurst

7
FizzBuzz를 사용자 정의하면 솔루션을 google로 검색 한 후보자를 필터링하는 것이 좋습니다. 더 어렵게 만들 필요조차 없습니다. 사실, 나는 오리지널 FizzBuzz가 지구상의 모든 회사에 의해 그대로 사용 된 것으로 의심됩니다. 회사에서 사용자 정의 하지 않는 게으름입니다 . 그들은 이미 문제 (프로그래밍 기술이없는 프로그래밍 후보자)를 알고 있지만 좋은 Google 기술을 갖춘 그러한 후보자가 통과 할 수없는 테스트를 구현하지 못했습니까? 이런 씨발?
Viliam Búr

13
@ GradeinarPfeffernüsse 질문을하지 않은 응시자는 어떻게이 시험을 성공적으로 완료 할 수 있습니까? 요구 사항이 모순되기 때문에 불가능합니다. 명확히하지 않으면이 운동을 단순히 수행 할 수 없습니다!
Andres F.

6
@MSalters 당신은 lex specialis가 현실 세계에서 합리적인 가정이 아니기 때문에 요구 사항의 저자가 원하는 것이라고 가정 할 수 없습니다. 따라서이 연습은 명백한 모순에 대한 질문 없이는 완료 될 수 없습니다. 질문을하지 않고 테스트를 완료 한 사람은 단순히 잘못했습니다.
Andres F.

답변:


31

그것은 FIZZBUZZ보다 훨씬 더 나은 테스트가 될 가능성이 있지만, 정답에 대한 개념이 있다면 세계에서 가장 나쁜 테스트입니다. 이러한 테스트는 우선 인터뷰에서 가치가 거의 없습니다.

응시자가 질문없이 "정확하게"대답하는 경우 응시자 선택에서 잘못된 종류의 프로그래머를 선택할 수 있다는 문제가 있습니다. . 프로그램이 모든면에서 기술적으로 완벽한 지 여부는 중요하지 않습니다. "내가 원하는 것을 신경 쓰지 않습니다. 요청한 것입니다."

여기서 테스트의 일부는 규칙의 우선 순위입니다. 지정하지 않았습니다. 입력 "ABC"는 Fizz, Buzz, BuzzBuzz 또는 FizzBuzz를 인쇄 할 수 있습니다.

내가 취할 후보는 (대부분) 옳았지만 많은 질문을했고, 이상적으로 화이트 보드에서 많은 "유아"를 한 사람입니다.

예를 들어, 일련의 샘플 텍스트를 제공하고 인쇄 할 것으로 예상되는 내용과 그 이유를 물음으로써 이러한 요구 사항에 대한 이해를 탐구합니다. - "ABC"예제 입력에 대한 토론은 유용한 사이트로 이어질 것입니다.

FIZZBUZZ와 마찬가지로이 테스트의 결과는 결과를 얻은 방법에 대한 관찰 결과만큼이나 우수합니다. 결과는 관련이 없습니다.

좀 더 재미있게 만들기 위해 조금만 조정할 것입니다. 위의 줄 ( "다음 중 하나를 인쇄하십시오")에 나와 있으며, 얼마나 많은 사람들이 그것에 대해 묻는 지보십시오. 응시자가 "만"을 놓치고 시간이 있다면, 그것을 지적하고 어떻게되는지보십시오. 그가 "만"을 다루는 경우 요구 사항에서 제거하고 코드를 변경하도록하십시오.


16
OP 가이 테스트로 너무 많은 것을하려고하는 것처럼 들립니다. FizzBuzz는 응시자가 최소한 코드로 무언가를 작성할 수 있음을 보여주기위한 빠른 테스트입니다. 이것은 그렇게하려고 노력하고 있으며 후보자가 모호한 요구 사항으로 프로세스를 설계하는 방법을 살펴 보려고합니다.
jk.

6
"이러한 시험은 우선 인터뷰에서 가치가 거의 없습니다." 만약 내가 프로그램이 모든면에서 기술적으로 완벽한 지 여부는 중요하지 않습니다. 그는 "나는 당신이 무엇을 좋아하지 않든 상관없이 소프트웨어를 제공 할 사람 일 것입니다." "당신이 원했던 것입니다."
Shivan Dragon

7
이 테스트가 쓸모가 없다고 생각하는 사람들은 모두 너무 많은 노력을 기울이고 있습니다. FizzBuzz와 그 대응 대상은 한 가지 목적으로 만 존재 합니다 .
Robert Harvey

@RobertHarvey : 프로그램을 할 수는 있지만 어느 시점에서 FizzBuzz에 여러 가지 이유로 어려움을 겪었을 것입니다. (자신은 그들 중 하나입니다).
James P. Wright

3
@ JamesP.Wright false negatives는 인터뷰 대상자가 아닌 인터뷰 대상자에게 문제가됩니다. 오 탐지 수가 적 으면 FizzBuzz와 같은 테스트는 면접관에게 유용 할 수 있습니다.
jk.

27

요구 사항에서 "단독"이라는 단어는 모든 질문에 모순을 만듭니다.

따라서 귀하의 질문은 압력을받는 동안 수집 요구 사항을 테스트합니다. 해당 기술 조합을 테스트 하시겠습니까?

요구 사항 수집을 테스트하려면 질문 중 하나를 모호하게 만드는 것이 좋습니다. FizzBuzz를 교체하려면 모호성을 제거하십시오.

비즈니스 규칙의 우선 순위 지정은 도메인 별 지식을 통해서만 수행 할 수 있습니다. 수행중인 작업에 대한 간단한 컨텍스트를 포함하지 않는 한 (아마도 다양한 값으로 교환 할 수있는 쿠폰 일 경우) 개발자가 자신의 결정을 내릴 근거가 없습니다.

그러나 원치 않는 결과를 초래할 수있는 중대한 위험이있는 경우 누군가에게 청산을 요구하는 것은 지식의 한계를 인식하는 데있어 기술을 측정하는 가장 좋은 방법이 아닐 수 있습니다. 그들은 당신이 요구 사항을 작성하는 데 무능하다고 지적하거나 개발자가 인터뷰에 참여한 사람이 아무도 없다고 지적하는 것보다 잘못 추측하고 잘못하는 것이 더 안전하다고 생각할 수 있습니다.


6
질문을함으로써 누군가를 성가 시게하기 때문에 불명확 한 요구 사항을 명확히하지 않는 사람을 고용하고 싶습니까?
Hans-Peter Störr

2
@ hstoerr, 아마도 그렇지는 않지만 인터뷰는 합리적으로 압력을받는 상황입니다.
A. Gilfrin

3
@ hstoerr : 문제는, 정답은 없지만, 면접관이 싫어하는 것이 무엇이든 분명히 틀린 대답입니다. 인터뷰 대상이 질문을하고, 다른 사람이 판단을하기를 원하지만, 다른 사람이 모호성을 전혀 보지 않고 간단한 지시를 이해할 수없는 것으로 질문하는 것을 볼 수 있습니다. 답변은 "대다수"가 제공 한 답변이며 질문은하지 않고 동일한 방식으로 답변한다고 들었습니다. 그런 다음 도움을받는 사람과 도움을받는 사람, 그렇지 않은 사람이 있습니다.
jmoreno

16

우리는 문제를 성공적으로 완수 한 압도적 다수의 후보자들이 FizzBuzz처럼 아무 것도하지 않았다는 것을 발견했습니다.

요구 사항이 모호하기 때문에 질문없이 v2.0을 올바르게 완료 할 수 없습니다.


2
+1… 요구 사항은 상호 모순되므로 최소한 어떤 종류의 타이 브레이크도 지정해야합니다.
Konrad Rudolph

4
흥미롭게도, 규칙은 (일반적인 경우에서 특별한 경우에 이르기까지) 질서에 영향을 미쳤으며 나는 거의 본능적으로 반대 순서로 그것을하기로 결정했습니다. 그런 시험을 받고 있다면 모호함을 느끼지 않고 본능을 따릅니다.
Codism

4
@Codism 불행히도 프로그래머로서의 본능은 사용자가 원하는 것과 정확히 반대가 될 수 있습니다.
Stefan

@ 스테판 : 확장하기 위해 설명에 끝이 없습니다. 모든 사람은 경험, 상식 등과 같은 일련의 요소에 근거하여 어떤 시점에서 추론을 멈 춥니 다. 지금 요구 사항을 명확히 할 수 있다고해도 내일 변하지 않도록 어떻게 보장 할 것입니까? 원래 요구 사항에 대해 제게는 충분합니다. 5 분 안에 구현할 것입니다.
Codism

1
@ KonradRudolph : "다음 중 하나"에 대한 비트를 해석하지 않으면 어떤 것이 중요하지 않습니다. 그것에 대해 생각할 때, 나는 실제로 그것을 수용 가능한 대답으로 볼 수 있습니다. 다른 코드도 코딩 할 필요가 없습니다. 다른 코드도 테스트 할 수 있습니다. 결국 하나의 솔루션을 다른 솔루션에 대해 실제로 만들 수있는 비즈니스 사례가 없으므로 인터뷰 질문은 표준 문자열 문제를 뒤집는 것보다 궁극적으로 유용하지 않습니다.
jmoreno

4

모호성을 제거하려면 요구 사항을 다음과 같이 변경할 수 있습니다.

문자열 목록을 입력으로 사용하는 선호하는 프로그래밍 언어로 루틴을 작성하고 목록의 각 문자열에 대해 다음을 수행하십시오.

  1. 문자열에 문자 '$'가 포함되고 '?'가 포함되지 않은 경우 "Fizz"를 인쇄하십시오.
  2. 문자열에 문자 '?'가 포함 된 경우 "버즈"를 인쇄하십시오. '$'를 포함하지 않습니다.
  3. 문자열에 정확히 하나의 '$'와 정확히 하나의 '?'가 포함 된 경우 "FizzBuzz"를 인쇄하십시오.
  4. 문자열에 정확히 하나의 '$'와 둘 이상의 '?'가 포함 된 경우 "BuzzBuzz"를 인쇄하십시오.
  5. 문자열에 정확히 하나의 '?'가 포함 된 경우 "BuzzBuzz"를 인쇄하십시오. 그리고 하나 이상의 '$'.
  6. 문자열에 '$'가없고 '?'가없는 경우 "FizzFizz"를 인쇄하십시오.

3

질문이 너무 모호합니까?

그렇습니다. 질문이 명확하지 않고 대답하기에는 너무 모호합니다. 그러나 여러 규칙이 적용되는 경우 프로그램에서 가장 구체적인 사항을 선택하고 모호성을 제거해야한다는 추가 규칙이 있습니다.

인터뷰 환경의 스트레스가 사소한 과제를 완수 할 수 없을 정도로 비판적으로 생각하는 능력을 감소 시키는가?

FizzBuzz 후보가 "크 래밍"할 가능성이 높습니다. 스트레스 여부에 관계없이 프로그램은 매우 간단합니다.

이상적인 솔루션이 다르기 때문에, 변형 FizzBuzz는 원래 비교 아니라고 생각 : 체인 있지만 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원래 FizzBuzz보다 훨씬 쉽게 테이블에 매핑됩니다. 사실, 원래 FizzBuzz 문제에 대한 테이블 기반 솔루션 을 이해하기가 더 어렵다는 것을 알았습니다 .

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 적절한 추상화를 사용하여 피즈 버즈를 해결하는 방법을 설명합니다.

그는 결코 올바른 추상화 수준에 도달하지 않는다는 것을 제외하고. 그는 모나드와 가장 가깝지만, 너무 복잡하다고 생각합니다. 간단한 키 / 값 목록은 끝에 직선 조건이 있으며 BrainFuck보다 복잡한 언어로도 쉽게 할 수 있습니다.
jmoreno

2

우리는 문제를 성공적으로 완수 한 압도적 다수의 후보자들이 FizzBuzz처럼 아무 것도하지 않았다는 것을 발견했습니다.

프로그래머가 큰 소리로 생각하고 그들의 사고 과정을 볼 수있는 질문을하는 인터뷰 과정을 보았습니다. 나는이 과정을 더 좋아한다.

나는이 fizzbuzz v2.0을 읽었으며 거기에서 # 3 및 # 5 요구 사항에 대해 물었습니다. 나는 다른 사람들에 대해 모른다. 그러나 나는 공학에서 나는 모호성을 원하지 않기 때문에 질문을한다. 나중에 줄을 코드로 작성 했으므로 (코드 및 모두), 나는 가정을해야했고 그것이 잘못되었다는 것을 알고 싶지 않습니다.


물론 "큰 소리로 생각하기"기술은 "큰 소리로 생각하기"를 원하는 프로그래머를 찾는 경우에만 유용합니다. 그것은 압도적 인 대다수의 프로그래머를 제거하고 논란의 여지없이 프로그래머보다 관리자로 더 적합한 프로그래머 만 남겨 둡니다. 결국, 뇌에서 "전기적인"속도로 생각하는 것이 말하는 "기계적"속도로 생각하는 것보다 훨씬 빠릅니다.
Dunk

2

모호성을 피하는 가장 쉬운 방법은 몇 가지 예를 보여주는 것입니다.

"A"는 "Fizz"를 반환합니다. "aAbA"는 "Fizz"를 반환합니다. "B"는 "Buzz"를 반환합니다. "aBbB"는 "Buzz"를 반환합니다. "AB"는 "FizzBuzz"를 반환합니다. "ABaabb"는 "BuzzBuzz"를 반환합니다. ""는 "FizzFizz"를 반환합니다. "ab "는"FizzFizz "를 반환합니다.


1
좋은 후보는 테스트 문자열과 예상 출력으로 시작한 다음 단위 테스트에 대해 이야기하거나 요구 사항을보다 공식적이고 모호하지 않게 다시 작성합니다. 그런 다음 명확한 요구 사항의 중요성과 구현 오류보다 요구 오류가 수정 비용이 얼마나 비쌀 수 있는지에 대해 이야기합니다.
John Lyon

2

후보자에게 모순되거나 불분명 한 요구 사항을 제공하는 대신, 해당 상황을 어떻게 처리하는지 물어보십시오. 그렇지 않으면 당신은 무능하거나 더 유능한 사람들을 위험한 균형 보에 놓는 것처럼 보일 것입니다.

어느 쪽이든, 그것은 모든 탈출구로 자극적입니다. 인터뷰는 어울리는 과정이며, 이는 양방향 거리를 의미합니다. 직접 질문과 의도의 명확성은 후보자를 압력솥 IMO에 두는 것보다 훨씬 중요합니다. FizzBuzz는 짧고 달콤하기 때문에 코딩 질문의 좋은 예입니다. 직접 재사용하지 마십시오. 해당 모델을 따르는 간단한 질문을 작성하십시오.

그러나 FFS는 그것에 대해 영리하지 않고 다른 테스트 뒤에 실제 테스트를 숨 깁니다. 사람들에게 빌어 먹을 문제를 어떻게 처리하는지 물어보십시오. 숙련 된 개발자는 모호한 요구 사항을 반복적으로 처리하고 전략을 알려줄 것입니다. 당신은 무언가를 배울 수도 있습니다.

모든 사람이 화이트 보드를 사용하고 싶어하거나 필기 기간이 편하다고 가정하지 마십시오. 우리 중 일부는 12 살 때부터 타이핑을 해왔습니다 (Space Quest 덕분에). 손에 펜이나 마커로 똑바로 생각조차 할 수 없습니다. 그것은 20- 괴물 -13입니다. 화이트 보드는 이미 무엇입니까? 사람들이 저에게 펜과 종이를 건네고 코드 테스트를 요청하면 웃음을 억누르기가 어렵습니다.


1

좋은 인터뷰 질문이라고 생각합니다. 요구 사항은 실제와 마찬가지로 명확하지 않습니다. 응시자가이 사실을인지하기에 충분히 지능적인지 (스트레스 하에서도), 필요하다고 생각되는 질문을하는 것을 두려워하지 않고 요구 사항을 합리적인 구조로 만들 수 있는지 확인합니다. 그리고 프로그래밍 능력에 대해 조금 이야기하지만 재귀와 포인터를 포함하는 더 복잡한 문제도 제기해야합니다.이 문제는 너무 쉽습니다.

그러나 나는 "성공적인"후보자들이 질문을하지 않는 것에 대해 약간 걱정한다. 나는 그들이 당신이 어떤 경우에는 최대 4 개의 규칙을 적용 할 수 있는지, 그리고 그 모호성을 해결할 수있는 질문이 없다는 것을 깨달았으며, 그것들을 어떻게 처리했는지 설명하도록하려고 노력했다. 아마도 당신의 질문은 그들에게 물어볼 정도로 모호하지 않거나 아마도 당신이 그들에게 큰 소리로 생각하도록 요구해야 할 것입니다.

BTW : "올바른 해결책"에 대해 이야기하고있는 것이 이상합니다. 그런 질문을한다면, "AB"를 받으면 "Fizz", "Buzz", "BuzzBuzz"또는 "FizzBuzz"를 인쇄하는 것이 합법적입니다. 따라서 질문하지 않은 솔루션은 IMHO가 잘못되었습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.