FizzBuzz에 실패했습니다. 저를 고용 하시겠습니까? [닫은]

저는 CS 학위를 가진 개발자이며 거의 3 년 동안 여러 언어로 개발 한 경력이 있습니다.

오늘 저는 인터뷰를했습니다. 전반적으로 꽤 잘 진행되었고 대부분의 질문에 대비하고 준비가 된 것 같습니다. 인터뷰가 끝나면 FizzBuzz와 같은 문제가 하나의 프로그래밍 질문이었습니다. 나는 내가 너무 많은 실수를했다고 생각하여 "실패"했다. 모든 희망이 저를 잃어 버렸습니까?

내 코드는 다음과 같습니다.

  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";
     }
  }
 }

보시다시피 나는 구문을 가져야하는 부울을 엉망으로 만들었다. 질문을 올바르게 기억하고 있다면 isThree && isFive를 사용하여 elseif 대신 else를 입력하십시오. 나는 스트레스를 많이 받았지만 간단한 문제를 놓친 것에 대한 변명은 아닙니다.

문제는 경험과 성격과 같은 다른 요소들에 비해 현장에서 작업 코드를 생성하는 것이 얼마나 중요합니까? 예를 들어 위의 코드가 거래 차단기입니까?

FizzBuzz의 요점은 당신이 실제로 있음을 보여주는 것입니다 프로그램 방법을 알고 그 문제는하지만 그들이 어떻게 경험이 알고 싶다면, (, 당신은 당신이 프로그램에 물어 봤는데 언어의 모든 미세한 구문 규칙을 기억 한하지 않는 것이 당신은 언어에 있습니다).

인터뷰 환경의 스트레스에이 문제가 생겼고 자신이 저지른 오류를 이해하고 있음을 보여줄 수 있다면 통과했다고 말할 수 있습니다.

예

내가 인터뷰 한 대부분의 사람들은 사소한 구문이나 코드에서 약간 벗어난 코드 연습 부분에 실패 했으므로 더 나은 직원이되었습니다.

논리에 대한 핵심 아이디어를 똑바로 (당신이 한 것) 이해하고 코드 관점 (주로 생각하는 것)에서 간결하고 간결한 것으로 변환하는 것이 절대적으로 완벽 해지는 것보다 훨씬 중요합니다.

나는 구문 검사를 위해 IDE를 구입하여 개발자를 고용하지 않으며 첫 번째 디버그 순간에 다른 실수를 깨달았을 것입니다.

귀하는 초기 요구 사항에서 첫 번째 시도로 공정하고 직접적으로 끔찍한 일을하지 않았습니다. 그것은 많은 환경에서 더 가치가 있으며 피드백이 없으면 완벽합니다. 고용주가 당신이 놓친 세부 사항에 매달린 경우 어쨌든 환경의 표시 일 수 있습니다.

작업이 인쇄 번호 변형 인 경우 세부 사항을 누락하면 약간 나빠 보일 수 있지만 다른 위치에서 당신을 좋아한다면 내 결정을 바꿀만한 무게가 충분하지 않습니다.

Alex가 지적한 것처럼 반응과 평정 측면도있다. 개인적으로 나는 인터뷰 대상자를 경험 밖에서 약간 구석에 놓아서 실제 연습을 시작하기 전에 그 길을 벗어나려고하지만 일부는 두 가지를 결합하도록 선택할 수 있습니다. 나는 가끔 교과서 지식 만있는 사람을 만났으며 이론적 배경 지식과 배경 문제를 겪고 있지만 실제 운동을 시작할 곳을 심각하게 생각합니다. 어떤 사람들은 어디서부터 시작해야할지 알 수 없습니다.

이 사람들은 내가이 운동으로 걸러 내고 싶은 것입니다.

따라서 면접관이 요구 사항을 명확하게하는 데 20 분이 걸리지 않았다면, 해결책은 몇 가지 수정을 시도한 첫 번째 시도라고 생각합니다. 당신이 5 분 안에 위에 넣은 것을 얻었다면 당신은 내 표준에 대해 충분히 생각할 수 있음을 보여주었습니다.

위의 코드는 다른 일이 없다면 아마도 거래 차단기 일 것입니다. 그들이 Microsoft 인터뷰 스타일을 따르는 경우,이 질문을 한 사람이 아마 당신을 차단할 것입니다.

내가 당황하는 것은 면접관이이 코드에 대해 묻지 않았다는 것입니다. 좋은 면접관은 사람들이 실수를 저지르는 것을, 특히 서둘러야 실수를한다는 것을 알기에 충분한 자체 코드를 보았습니다. 보통 그들은 "이 코드에 문제가 있습니까?"라고 말합니다. "아니요? 테스트 해보자". 결과 집합을 찾은 다음 함수를 통해 실행합니다. 그런 다음 "오 똥, 그것은 작동하지 않았다"고 말합니다. "좋아, 어떻게 고치 겠니 ..."등등. 해당 대화 상자에서 살아남는다면 실제로 매우 인상적이며 비판적으로 사고하고 테스트 사례를 제시하며 자신의 코드를 디버깅하는 능력을 보여줍니다.

또한 그들은 일반적으로 "작업 코드"를 찾지 않습니다. 어쨌든 첫 번째 시도는 누가 생산합니까? 그러나 오류 처리 및 올바른 테스트 세트로 논리적으로 올바른 것이 좋은 목표입니다.

또한, 이것은 당신을 놀라게 할 수 있지만, 피즈 버즈를 시작할 수없는 많은 사람들과 경쟁하고 있습니다. 우리는 다른 모든 사람들이 자신의 수면에서 b + 나무를 가로 지르고 있다고 가정하는 경향이 있지만 실제로는 3과 5의 배수를 알아낼 수없고 계수 연산자를 사용할 수도 없습니다. 당신은 다른 후보들보다 얼마나 잘했는지 놀랍게도 놀라실 것입니다.

내 충고, 그냥 닦으십시오. 최근에 대규모 소프트웨어 회사 (Microsoft, Amazon 등)에서 인터뷰를했으며 처음으로 철저한 인터뷰 프로세스를 거쳤습니다. 신경 때문에 주로 Microsoft 현장 인터뷰에서 바보가되었지만, 또한 무엇을 기대해야하는지, 정확히 무엇을 찾고 있는지 몰랐습니다. 나는 가장 간단한 경로 문제를 해결하기 위해 최단 경로 문제를 해결했습니다. 스택의 잘못된 끝에서 값을 팝하여 int atoi(char* value)구현 에서 잊어 버렸습니다.int val = value[i] - '0';문자의 정수 값과 다른 어리석은 실수를 줄 것입니다. 나는 인터뷰에 대해 대부분 기뻐했지만, 왜 제안을받지 못한 지 이해했다. 나는 이것이 내 능력을 반영하지는 않았다는 것을 깨달아야했다. 그것은 내 신경을 습득 할 수있을 때까지 계속 시도해야한다는 지표였다. 결국 나는 훨씬 더 어려운 질문으로 인터뷰를하고 내 꿈의 직업을 찾았습니다. 실제로 무엇을하고 있는지를 아는 대부분의 사람들에게 그것은 면접관이 원하는 것을 알아 내고, 자신을 확신하며, 그들에게주는 것입니다. 시간이 걸립니다.

나는 거절해야하지만 당신이 준 이유는 아니지만 FizzBuzz 섹션을 마지막에 놓았습니다. 코드 작동 방식에 따라 FizzBuzz는 예상대로 인쇄되지 않습니다. Lee가 언급했듯이 3 또는 5로 나눌 수 없는 모든 값에 대해 인쇄합니다 .

그러나 요점은 당신이 그것을 배우는 것입니다. 나는 당신이 여기에 당신이 어떻게 더 잘할 수 있었는지 묻는 사실을 좋아합니다. 코드 퍼즐을 만들고 일반적인 인터뷰 질문을 조사하십시오. 또한, 자신의 타이밍을 맞추거나 압력을 증가 시켜서 인터뷰에서 느끼는 느낌을 모방하려고 할 수있는 다른 일을 시도해보십시오. 인터뷰를 준비하고 준비하고 더 많은 준비를한다면 정말 공원에서 쫓아 내고 싶을 것입니다.

FizzBuzz의 요점은 모든 경우를 다루는 기본 조건부 논리를 해결할 수 있는지 확인하는 것입니다. 일부 사람들의 의견과 달리 FizzBuzz는 3 항 op 또는 부울 피연산자를 아는 모듈러스 연산자가 아닙니다. 조건부에서 간단한 운동이며 실패했습니다.

문제는 모든 "우아한"코드가 적어도 하나의 사례를 다루지 못하도록 구성되어 있습니다.

허용되는 답변 :

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. 지원자가 최소한 하나의 프로그래밍 언어에 능숙합니까?
3. 응시자가 부울 논리를 파악하고 있습니까?
4. 응시자는 솔루션의 품질을 보장하기 위해 무엇을해야합니까?
5. 응시자는 코드에 대한 피드백에 어떻게 응답합니까?

-

# 1에 말하기 어렵다. 귀하의 질문에 귀하의 문제에는 "인쇄 번호"부분이 포함되어 있지 않으며 귀하의 솔루션에는 실제로 포함되지 않습니다. 나는 당신의 말을 받아 들일 수밖에 없지만 실제로는 어느 것도 나눌 수없는 숫자를 인쇄하는 것을 포함하는 고전적인 FizzBuzz 문제라면 요구 사항을 완전히 이해하기 전에 솔루션으로 뛰어 들었던 것처럼 들립니다. 마크 오프 될 것입니다.

# 2와 # 3에 부분 크레딧을드립니다. 모듈러스 연산자를 사용하는 것을 알고 작업 솔루션의 구조를 가지고 있었지만 두 부분 모두를 놓쳤습니다.

당신이 # 4를하지 않은 것처럼 들리면 표시가 끊어집니다. 앞으로 화이트 보드에서 한 걸음 물러서서 솔루션을 살펴보기 전에 솔루션을 살펴 보는 것이 좋습니다. 또한 솔루션에 대한 몇 가지 단위 테스트를 단계별로 수행하여 엉망이 된 부분을 신속하게 시연했습니다.

그들은 당신에게 # 5에 기회를주지 못했습니다. 불행합니다. 그러나 요점은 그들이 작성한 모든 코드 줄이 개선 될 수없는 순수한 금이라고 생각하는 사람을 원하지 않고 오히려 솔루션에 대한 피드백을 받아들이고 그의 접근 방식에 대한 대화에 기꺼이 참여하는 사람을 원하지 않는다는 것입니다. .

-

따라서 이것만으로 평가한다면 "No Hire"로 투표 할 것입니다. 이와 같은 것들은 프로그래밍 능력보다는 공연 예술 을 측정하는 일종 이지만, 그것을 마스터하면 여전히 경력에 도움이 될 수 있습니다. 미래의 기술 인터뷰에 대한 권장 사항은 다음과 같습니다.

1. 면담 전에 가능한 한 적은 수의 외부 자원을 사용하여 이러한 유형의 운동 중 몇 가지를 연습하십시오. 솔루션을 암기하는 것이 아니라 선호하는 언어에 익숙해야합니다.

2. 가정에 대한 검증을 위해 문제에 대해 질문하십시오.

3. 솔루션 완료를 알리기 전에 화이트 보드에서 물러나서 살펴보고 몇 가지 간단한 단위 테스트 사례를 살펴보십시오.

솔루션에 대한 피드백을 얻을 수있는 능력을 부여하지 않고 문제를 해결하도록 누군가에게 요청하는 것은 의심스러운 접근 방식입니다. 개선이 불가능하기 때문입니다.

이 모든 테스트는 귀하가 "최상급"문제 해결 기술을 잘 보여주지 못했다는 것을 알려줍니다.

이것은 당신을 고용하기로 한 결정의 요소 중 하나 일 수 있지만, 나에게 반드시 유일한 것은 아닙니다.

그들이 단위 테스트 또는 실행 환경을 제공했을 경우, 실수는 덜 변명 할 수있을 것입니다.