과도 공학은 경고 표시입니까? [닫은]

그래서 우리는 잘 정의 된 요구 사항을 가진 새로운 후보자에게 간단한 코딩 연습을 제시합니다. 때때로 우리는 실제로 당면한 문제를 해결하지는 않지만, 종종 운동의 범위를 벗어나는 인식 된 문제를 해결하기 위해 과도하게 설계되었습니다.

이제 내 질문은 경고 표시입니까?

편집 : 상당히 많은 토론은 결함이있는 테스트를 기반으로합니다. 주석에서 설명했듯이 테스트의 기본 전제는 파일에서 데이터를 합리적인 방식으로 읽을 수있는 방법과 다양한 방법에 놀라는 방법을 보여주는 것입니다. 업데이트 간의 대기 시간을 계산하기 전에 이제 이것이 작동하기 위해서는 데이터에 대한 특정 가정이 이루어져야하며, 이러한 가정을 찾고, 우리가 취한 접근 방식 (OO 접근 방식 등)을보고 싶다고 명시 적으로 언급합니다. 시간 프레임.

IMHO, 내가 인터뷰를 할 때 내가 만난 가장 완벽한 운동이었다.

내가 생각하고있는 특정 시나리오는 파일에서 읽지 않고 후보가 멀티 스레드 응용 프로그램에서 "네트워크"입력을 수락 한 경우이며 범위가 명확하지 않습니다.

문제는 테스트가 치우친 것입니다. 몇 분만에 간단한 연습을 통해 복잡한 엔터프라이즈 급 소프트웨어를 작성할 수있는 능력을 보여달라고 누군가에게 요구하고 있습니다. 다른 회사의 다른 면접관들이 후보자들이 이러한 연습을 통해 객체 지향 디자인에 충분한 기술을 보여주지 못한다고 불평하는 사람들이 있기 때문에 사람들은 과도하게 보상하는 경향이 있습니다. 그렇다고해서 후보자가 상황에 따라 더 간단한 코드를 사용할 수 없다는 것을 의미하지는 않습니다.

후보자에게 해당되는지 알고 싶으면 다시 실행하도록 요청하고 구체적인 지침을 제공하십시오. "객체 지향적 인 디자인 기술을 보여주고있는 것을 볼 수 있지만, 간단한 문제로 인해 과잉 인 것 같습니다. 두 개의 작은 함수 만 사용하여 다시 작성할 수 있습니까?"

나는 이것이 명백한 경고 신호라고 말하지만 후보자를 반드시 실격 시키지는 않는다.

응시자가 갖는 두 가지 별도의 문제가 있습니다.

1. 운동의 요점을 놓치십시오 -이것은 상당히 놀랍습니다. 누군가가 제대로 풀고있는 문제를 해결할 수 없다면 세계의 모든 프로그래밍 기술이 좋은 결과를 내지 못할 것입니다. 나는 가장 생산적인 엔지니어가 문제가 정확히 제기되지는 않았더라도 해결해야 할 실제 문제를 식별 할 수있는 엔지니어라는 것을 알았습니다. 묻는 질문에 대해 비판적으로 생각하고 해결하기가 더 쉬운 것으로 재구성 할 수있는 능력이 매우 중요합니다. 문제가 명확하게 언급 된 시점을 놓치면 큰 적기가되어야합니다.
2. 솔루션 오버 엔지니어링 -이는 2 차 문제이며 종종 첫 번째 문제의 결과입니다. 이 결과를 얻을 수있는 몇 가지 다른 병리가 있습니다. 먼저, 문제를 제대로 이해하지 못하거나 너무 광범위하게 캐스트하면 솔루션이 너무 복잡해질 수 있습니다. 이것은 위의 첫 번째 요점과 분명히 관련이 있습니다. 둘째, 실제로 관련이 없을 수도있는 미래 시나리오를 통해 생각하여 "보여주기"를 시도합니다. 이는 후보자가 솔루션의 단순성의 가치를 이해하지 못하고 실제로 필요할 때까지 복잡성을 연기한다는 것을 나타 내기 때문에 문제가 될 수 있습니다. 이것은 좋은 지침으로 해결할 수는 있지만 누군가를 조직에 데려 올 때주의해야합니다.

과정이 진행되는 동안 응시자와 함께 답변을 제안합니다. 단순히 결과를 보지 말고 결과로 이어진 이유를 확인하고 어떻게 응답하고 응답을 바꿀지에 대한 지침을 제공하십시오. 이것은 아마도 문제에 대한 직접적인 반응보다는 그들의 능력에 대해 더 많이 드러날 것입니다. 그들의 접근 방식의 "이유"는 그들이 단지 그것을 얻지 못하고 있는지 또는 그들이 응답하기로 선택한 방식에 대한 이해가 약간 벗어난 지에 대한 감각을 줄 수 있습니다. 이러한 종류의 후속 조치는 또한 문제 해결에 대한 전반적인 접근 방식에 대해 더 많이 알 수 있습니다.

또한 문제 자체를 다시 검토하고 명확하지 않은지, 사람들이 답변을 작성할 때 잘못된 길을 찾는 지 확인하십시오.

아니요, 면접 중에는 아닙니다. 너무 많은 면접관이 의도적으로 요구 사항을 과소 평가하거나 면담 관이 추가 질문을하거나 명시 적으로 언급되지 않은 실제 문제에주의를 기울이는 것과 같은 일을합니다.

내 머리 꼭대기에서 요구 사항에 언급되지 않은 사항이 있습니다.

• 코딩 표준

• 코멘트

• 예외 처리

• 변수, 클래스, 메소드의 설명 적 이름

• 언어의 관용어에 따라

• 적절한 객체 지향 디자인

• 가능한 동시성 문제에 대한주의

• 코드에 대한 테스트 사례 작성

명시 적으로 언급하지 않고 이러한 것들 중 하나에 주의를 기울 였습니까? 응시자는 자신이 관심있는 대상과 그렇지 않은 대상을 어떻게 알 수 있습니까?

인터뷰는 매우 인공적인 환경입니다. 면접관은 종종 인터뷰 대상자가 듣고 싶은 말을하기가 어려워 지도록 후보자를 조금“트릭”하려고 노력하고 있으며, 면담자는 면담자가 실제로 원하는 것을 추측하려고한다 .

일반적으로이 추측에 실수를하는 것은 실제 디자인 결정에 실수를하는 것과는 다릅니다. 만약 누군가가 오버 엔지니어링을하고 있는지 알고 싶다면, 매우 인공적인 코딩 연습보다는 디자인에 대해 이야기해야 할 것입니다.

IMHO 대답은 분명히 그렇습니다 . 경고 표시입니다.

• 코딩 연습은 분명한 임무를 수행했습니다
• 잘 정의 된 (잘 작성된) 요구 사항
• 응시자는 올바른 문제를 해결하기 위해 질문을 할 기회가있었습니다.
• 당신은 건축 우주 비행사가 아닌 당신의 팀에서 똑똑하고 일 을하는 사람들을 원합니다 .

문제를 해결 하지 못하는 것만 큼 큰 경고 신호는 아닙니다 . 그가 퀴즈에 실패하고 올바른 해결책을 제공하지 않았다는 사실은 경고 신호입니다. 그가 올바른 솔루션을 제공하지 않은 방법과 이유에 따라 다르므로 반드시 진행해야 할 시나리오는 아닙니다.

많은 경우 질문은 완전하지 않고 단순히 대답 할 수 없습니다. 면접관이 결코 실수하지 않는 척하지 마십시오. 왜 그 질문이 엉뚱한지를 고소하는 것은 여전히 ​​실패한 일입니다. 요구 사항을 작성하는 데 도움이 될 엔지니어를 고용하는 경우 이는 문제입니다. 코더를 고용하고 있다면 그렇게 할 것이라고 기대하지 않습니다.

코딩 연습이 끔찍하게 엉망이 아니라고 가정하면, 그가 실패한 방식으로 문제를 잘못 해석하고 거기에 없었던 문제를 해결하기 위해 잡초로 갔다. 예, 이것은 경고 신호입니다.

아마도.

문제를 해결하지 않는 것은 물론 무언가 잘못되었다는 분명한 경고 신호입니다. 무엇이 잘못 되었나요? 그들은 문제를 잘못 이해했거나 나쁜 해결책을 만들었습니다. 간단한 것에 대한 나쁜 해결책은 후보자가 가난하다는 명백한 신호입니다.

그들이 문제를 오해했다면, 당신의 요구 사항을 오래 살펴보십시오. 당신에게 명백하게 보이는 것조차도 도메인에 익숙하지 않거나 다른 배경 (로케일, 나이, 육성)에서 다른 사람들에게는 명확하지 않을 수 있습니다. 응시자가 당신과 함께 방에 있었거나 질문을 할 기회를 제공했지만 여전히 실패했다면, 나는 그들이 실패했다고 생각할 것입니다. 요구 사항이 벽에 던져지면 의심의 이익을 얻을 수 있습니다 (면접 과정 수정에 대해 생각하십시오).

솔루션이 정확하면 덜 명확 해집니다. 개인적으로 많은 사람들이 YAGNI를 너무 많이 . 복잡성을 높이거나 유지 관리 성을 해치지 않으면 서 특정 문제를 겪고 일반적인 솔루션을 만들 수 있다면 일반적인 솔루션을 만들어보십시오. (줄을 뒤집는 것과 컬렉션을 뒤집는 것을 생각해보십시오.) 그런 종류의 "과도한 공학"은 제 생각에는 분명히 좋습니다.

그 밖의 모든 것은 회색 중간 지대입니다. 솔루션이 변경 축을 해결합니까? 솔루션이 복잡성을 추가하거나 유지 관리 성을 손상합니까? 약간의 복잡성을 추가하여 거의 승리를 보장하는 미래의 문제를 해결합니다. 전혀 가능성이없는 것을 설명하기 위해 유지 관리 성을 크게 손상시키는 것은 아닙니다.

훌륭한 소프트웨어 엔지니어가된다는 것은 올바른 균형을 유지하는 것을 의미합니다. 좋은 면접관이된다는 것은 응시자가 어떻게 그리고 왜 균형을 선택했는지에 대한 올바른 판단 / 추론을하는 것을 의미하며, 종종 면담의 다른 부분을 사용하여 평가합니다.

아마도 다음을 고려하십시오.

• 인터뷰는 어렵다 : 사람들은 스트레스를 받고있다. 이것은 당신이 누군가에게주는 문제에 크게 고려되어야합니다.

• 요구 사항 길이 : 요구 사항은 얼마나 오래 걸리나요? 당신이 모든 것을 포함시킬 수 있도록 여분의 단어를 만들었습니까? 결과적으로, 그들은 당신에게 분명 할 수 있지만 요구 사항은 너무 설계되었습니다! 나는 비교적 간단한 문제에 대해 약 3 페이지의 텍스트로 한 시간 동안 한 번 면접을 보았습니다. 때때로 모든 텍스트는 인터뷰에서 읽고 해석하기가 어려울 수 있으며 잘못 해석 될 수도 있습니다.

• 때때로 Less is More : 몇 가지 주요 요점, 문장 및 / 또는 주요 요구 사항을 보여주는 예제와 필요한 경우 누군가에게 질문을하고 연락을 취할 수있는 방법에 대한 토론을하고 싶습니다. 내가 말하려는 것은 먼저 테스트 요구 사항이 간단한 문제로 지나치게 복잡하지 않은지 확인해야한다는 것입니다.

• 의사 소통 기술 : 먼저 문제에 대한 지능적인 질문을하고 의사 소통을 할 수있는 응시자 능력을 테스트해야합니다. 일단 문제를 이해했다는 것을 알게되면 구현에 설정할 수 있습니다.

• 결론 : 문제를 이해했는지 확인하지 않은 경우 실제로 오버 엔지니어링으로 무엇을 만들어야할지 모르는 것보다. 다른 사람들이 말했듯이 그것은 좋거나 나쁠 수 있지만 문제에 대한 이해를 확인하거나 후보자와 의사 소통하지 않으면 문제에 대한 전반적인 이해와 문제를 이해하는 것이 더 어렵습니다.

이것의 많은 부분은 질문을하는 방법과 전체 인터뷰를 관점으로 만드는 방법에 기인합니다.

"당신의 창의력을 봅시다. 2 + 2 란 무엇입니까?" 네? 당신이 생각해 낼 수있는 것은 가장 간단하고 명백하며 정확한 대답입니까? 인터뷰 중 감동을 받고 싶어하는 젊은 / 초급 레벨 개발자는 "우리는 코딩 기술을 테스트하거나 프로그래머의 능력을 평가하고자합니다." "매우 정교한 것을하십시오"를 의미합니다. 우리는 일이 더 어려워 질 때를 제외하고는 단순하다고 생각합니다.

누군가가 항상 과도하게 엔지니어링하는 경향이 있는지 확인하는 방법이 있습니다. 너무 복잡한 코드 예제를 제공하고 더 간단한 솔루션을 요청하십시오. 누군가가 당신이 생각하지 않을 해결책을 제시 할 때, 그들이 비판에 어떻게 반응하는지 볼 수있는 좋은 기회입니다. 개인적으로, 나는 누군가가 새로운 아이디어에 열려 있고 동일한 실수를 반복해서 반복하는 사람보다 더 나은 해결책을 인식하고 싶습니다.

실제로 코드가 작동하지 않을 때 코드를 변경할 수있는 기회가 항상 있습니까? 초기에 설계 또는 초과 설계를 할 수 있습니다. 간단한 솔루션을 알고 나면 구현하기가 쉽지 않습니까?

그것은 달려 있지만 일반적으로 아닙니다.

일반적으로 디자인은 경험을 통해 배운 기술입니다. 마르 얀과 연결된 진보에 대한 아론 노트의 설명 은 일반적으로 좋은 것입니다.

어떤 형태의 의사 소통도 상황에 따라 크게 좌우됩니다. 한 맥락에서 한 가지를 의미하는 것이 완벽하게 분명해 보이는 것은 다른 맥락에서 다른 것을 분명히 의미 할 수 있습니다. 어떤 질문을해야하는지 아는 것도 경험과 함께 제공되는 것입니다.

그들의 사고 과정과 그들이 결정에 대해 추론하는 방법은 그들의 해결책보다 훨씬 중요합니다. 솔루션과 의사 결정을 검토하지 않으면 개발 환경을 완전히 평가할 수 없습니다.

위의 진행 상황을 감안할 때, 과도하게 설계된 솔루션을 가진 후보자는 단순한 솔루션을 가진 후보보다 훨씬 더 나을 수 있습니다.

또한 : 어떤 직급을 고용하고 있습니까? 엔트리 레벨 또는 중간 레벨 후보에서 오버 엔지니어링하는 것은 상급 레벨 후보에서 오버 엔지니어링하는 것보다 덜 중요합니다.

프로그래머가 문제를 해결하지 못하면 모든 추가 코드는 코더가 답을 모호하게 만드는 것입니다. 주제에 대해 잘 모르는 학생이 수필 시험에서 사용한 것과 동일한 기술입니다. 그 또는 그녀는 설득력있는 것에 대해 논할 것이지만, 그의 무지가 단어 수에 의해 가려지기를 바랍니다.

프로그래머가 문제를 해결했지만 더 많은 코드를 추가 한 경우, 프로그래밍의 일부 영역은 다른 영역보다 더 큰 공차가 필요하므로 프로그래머의 배경을 고려하십시오.

예를 들어, 상용 여객기에서 자동 조종 장치를 실행하는 코드는 무료 Android 게임보다 고장에 대한 허용 오차가 훨씬 적습니다. 도달하기 어렵고 업데이트가 거의 불가능한 임베디드 디바이스를 프로그래밍하는 데 익숙한 개발자는 하루에 15 개의 업데이트를 푸시 할 수있는 개발자보다 더 많이 코딩하는 경향이 있습니다.