인터뷰 과정에서 과도하게 프로그래밍 된 과제를 걱정해야합니까? [닫은]

최근에 회사와 전화 인터뷰를했습니다. 그 전화 인터뷰 후, 나는 짧은 프로그래밍 과제 (작은 프로그램; 3 시간 이상 걸리지 않아야 함)를 완료하라는 지시를 받았다. 과제를 완료하고 코드를 제출하도록 직접 지시 받았습니다. 원하는 언어를 사용할 수있는 자유가 주어졌으며 코드를 켜는 방법을 정확히 알지 못했습니다.

즉시 Github에 던지고 테스트 스위트를 작성하고 Travis-CI (공용 Github 리포지토리에 대한 무료 연속 통합)를 사용하여 테스트 스위트를 실행하고 CMake를 사용하여 Travis-CI 용 Linux makefile을 빌드 할 계획이었습니다. 이렇게하면 Git, CMake, Travis-CI 사용 방법 및 테스트 작성 방법을 이해하고 있음을 보여줄뿐 아니라 Travis-CI 페이지에 연결하여 테스트 결과를 볼 수 있습니다. 나는 그것이 면접관에게 조금 더 편리 할 것이라고 생각했다.

이러한 기술을 잘 알고 있기 때문에 과제에 시간이 전혀 필요하지 않습니다.

그러나 비교적 간단한 작업을 위해이 모든 작업을 수행하는 것이 나빠 보일까 걱정됩니다. 그것은 나를 위해 더 많은 시간을 추가하지는 않지만, 나는 그들이 단순한 일에 너무 많은 시간을 보낸다고 생각하고 싶지 않습니다.

면접관으로서 나는이 접근법에 의해 입증 된 소프트웨어 개발 과정에 대한 지식을 보게되어 기쁘다. 코드 작성과 반대로.

특히, 매우 간단한 문제에 대한 테스트 스위트를 보유하는 것은 좋은 신호입니다 (FizzBuzz 레벨조차도). 후보자들이 문제를 해결하지 못한 솔루션을 제출하는 것을 보았고 간단한 테스트 세트가이를 보여주었습니다. 또한 커밋 기록을 통해 응시자가 솔루션을 얻는 데 사용한 사고 과정에 대한 아이디어를 얻을 수 있습니다.

다른 한편으로, 나는 일부 엔지니어링 프로세스의 초기 단계에서 일부 회사에 의해 사람들이 거부되는 것을 알고 있습니다. 그러나 대부분의 경우 이는 사용 된 프로세스가 아니라 솔루션을 과도하게 엔지니어링했기 때문입니다.

인터뷰 대상자로서 버전 관리, CI, 단위 테스트 등과 같은 것을 이해 한 사람이 있으면 내가 일반적으로 보는 것에 대한 단계가 될 것입니다.

나에게 가장 중요한 것은 문제가 해결되고 잘 해결된다는 것인데, 후보자가 결과물의 품질을 향상시키는 방법을 이해했다는 사실을 알면 분명히 관심을 끌 것이다.

내가 일반적으로 보는 것은 문제를 이해하지 못했을뿐만 아니라 문제를 해결하는 방법을 이해하지 못하는 사람들입니다. 프로세스에서 사용하는 추가 도구의 수에 관계없이 무시됩니다.

시간 제한이 있습니다. 면접관은 이것을 알고 있으므로 (면접관이라면) 그는 당신이 정해진 시간 안에 문제를 해결할뿐만 아니라 금도금을 위해 시간을 남겼다는 것을 곧 알게 될 것입니다. 문제 해결 능력과 엄격하고 근면함에 대한 감사

오버 엔지니어링은 FizzBuzz를 해결하기 위해 BuzzManager와 FizzManager를 배포하기 위해 연결되는 AbstractFactoryManagerAdaptors를 만들 때 나쁜 단어입니다.

당신이하고있는 것은 과실입니다.

즉, "시간을 전혀 추가하지 않는다"고 주장하는 엑스트라에 시간을 사용했기 때문에 시간이 지남에 따라 또는 반 해킹 된 솔루션으로 끝나는 경우, 이는 얼마나 작은 것으로 보이는지에 대한 이해가 매우 부족한 것처럼 보입니다. 할 수있는 일. 이것은 엔지니어에게는 위험한 특성이며 후배들에게는 너무나 흔한 일입니다. 필요한 솔루션 을 완료 한 후에 만 적절하게 우선 순위를 정하고 여분의 신용 거래를 하십시오 .

고려해야 할 또 다른 견해는 귀하의 접근 방식이 좋지도 않다는 것입니다. 나는 그것을 너무 많이 생각하는 면접관을 상상할 수 있고 더 많은 공학을 사랑하는 면접관을 상상할 수 있습니다.

너무 걱정하지 마십시오. 대신 최선을 다하는 방식으로 문제를 해결하면 나와 동의하는 사람들로부터 구인을받을 수 있습니다. 생산적인 작업 환경을 향한 첫 걸음입니다. 인터뷰는 두 가지 방식으로 진행됩니다. 귀하의 솔루션에 대한 면접관의 답변은 그들에 대해 많은 것을 알려줄 것입니다. 개발 본능과 철학이 잘못되었다고 생각하는 사람들과 협력하고 싶습니까?

실제로, 후보자가 git repo를 만들거나 서둘러 makefile을 만들 수 있는지 여부는 아무도 신경 쓰지 않습니다. 왜냐하면 그것이 rote가 배운 것을 회상하기 때문입니다. 인터뷰 문제의 실제 문제 해결 및 디자인 측면에서 보조 기술입니다.

따라서, 후보자가 프로젝트 골격을 만들기 위해 몇 가지 암기 된 명령과 패턴을 역설 할 수있는 사람이 인상적인 소프트웨어 기술을 가지고 있다고 믿는 것처럼 보일 수 있기 때문에 직감은 잠재적으로 나빠 보일 수 있습니다.

솔루션의 테스트 스위트 측면은 좋습니다. 회귀 테스트 스위트로 답변을 제공하면 포인트를 얻을 수 있습니다. 테스트 스위트가 코드에서 두드러진 사례를 연습하면 더욱 그렇습니다. 테스트 스위트는 공식적인 트래핑이 많지 않아도 툴에 의존 할 필요가 없습니다. 당신이 어떻게 든 거기에 하나가 있다는 사실은 인터뷰에 충분합니다. 면접 퀴즈에서 임시 단위 테스트를 구성 할 수 있다면 실제 프로젝트의 도구를 사용하여이를 수행 할 수 있다는 것이 다소 분명합니다.

최근에 회사와 전화 인터뷰를했습니다. 그 전화 인터뷰 후, 나는 짧은 프로그래밍 과제 (작은 프로그램; 3 시간 이상 걸리지 않아야 함)를 완료하라는 지시를 받았다.

조심스럽게 진행하겠습니다. 직무에 대한 도전과의 관련성을 평가하고, 고용주로부터의 향후 상환이 귀하의 시간을 3 시간 동안 가치있게 할 것임을 확인하십시오.

나는 이런 유형의 시험에서 가치에 의문을 품고 오히려 과거의 성취에 대해 누군가를 판단 할 것입니다. 미리 정의 된 짧은 작업은 고용주에게 귀하가 할 수있는 일에 대해 아무 것도 알려주지 않습니다. 당신이 할 수없는 것, 그리고 그것은 전화를 통해 몇 가지 질문으로 신속하게 결정될 수 있습니다.

테스트는 그 자리에 있습니다. 테스트에 대해 다음과 같은 질문을하고 이에 따라 응답하십시오.

1. 시험 박람회에 현재의 경력 수준이 있습니까?
2. 시험에 명확하게 정의 된 정답이 있습니까?
3. 면접관은 개인으로서의 잠재력에 관심이 있거나 시험 결과에 더 많은 관심을 보이고 있습니까 (즉, 고용 기관이 끔찍합니다).
4. 시험은 당신이 즐기는 일의 종류를 나타내거나 모호한 기술 검증 (예 : Java 구문을 알고 있다면 시험)입니까?

과제를 완료하고 코드를 제출하도록 직접 지시 받았습니다.

당신은 당신의 자신의 질문에 대답했습니다.

즉시 Github에 던지고 테스트 스위트를 작성하고 Travis-CI (공용 Github 리포지토리에 대한 무료 연속 통합)를 사용하여 테스트 스위트를 실행하고 CMake를 사용하여 Travis-CI 용 Linux makefile을 빌드 할 계획이었습니다.

아뇨, 그건 그들이 당신에게 요청한 것이 아닙니다.

이렇게하면 Git, CMake, Travis-CI 사용 방법 및 테스트 작성 방법을 이해하고 있음을 보여줄뿐 아니라 Travis-CI 페이지에 연결하여 테스트 결과를 볼 수 있습니다. 나는 그것이 면접관에게 조금 더 편리 할 것이라고 생각했다.

인터뷰 과정에서 너무 일찍 또는 너무 늦게 기술을 시연 할 때주의해야합니다. 인터뷰에서 자신이 좋지 않다고 생각하고 보상을 시도하고 있다면 효과가 없을 것입니다. 반면에 묻지 않을 때 너무 많이하는 것은 열심을 나타냅니다. 이로 인해 고용주는 더 낮은 임금 제안으로 대응할 수 있습니다.

그러나 비교적 간단한 작업을 위해이 모든 작업을 수행하는 것이 나빠 보일까 걱정됩니다.

예, 안 좋아 보입니다. 한 줄의 코드로 문제를 해결하는 것은 완전히 플러시 된 프로젝트보다 훨씬 인상적입니다.

내 경험상 이것은 면접에서이기는 방법이 아니지만, 직업을 잃는 한 가지 방법입니다. 코드 테스트는 품질 관리 문제입니다. 사람들을 고용 할 때 코드 테스트를 사용하는 모든 회사는 이전에 코드 테스트를 사용하지 않았기 때문에 그렇게했습니다. 그들은 인터뷰 과정의 균열을 통해 누군가가해서는 안되는 나쁜 경험을했습니다.

그들은 소스 코드를 가져 와서 사무실로 전달합니다. 사람들은 그것에 대해 언급 할 것이며, 당신이 말하고 싶지 않은 것은 "그는 실수를 했습니까? Git, CMake 및 Travis-CI를 사용하여 시간을 보냈습니다.이 실수를 놓친 바보는 무엇입니까?"입니다.

그게 다야. 졌어요

그들은 당신에게 그것을 가르 칠 수 없기 때문에 코딩 할 수 있다는 것을 알고 싶어합니다. 힘내, CMake 및 Travis-CI를 쉽게 가르 칠 수 있습니다.

나는 당신의 접근 방식 자체가 좋지도 않다고 생각합니다 . Github과 다른 도구를 사용해도 괜찮은지 면접관에게 물어볼 것입니다. 의견에서 @Izkata가 지적했듯이 솔루션을 공개하고 있습니다.

면접관으로서, 나는 몇 가지 사항을 명확히하려고 노력하는 후보자에게 해가 없다는 것을 알고 있었다. 또한 이해하지 못한 일을 서두르지 않기 때문에 한두 가지 질문을하는 것이 좋은 징조가 될 수 있습니다.

그러나 가장 중요한 것은 문제가 해결되고 잘 해결된다는 것입니다. 그런 점에서 모두 테스트 스위트가 도움이된다는 데 동의합니다. 그러나이를 위해 프로젝트 / 솔루션과 함께 몇 가지 테스트 클래스를 보내야 할 수도 있습니다.