면접관이 신청자에게 코드를 읽도록 요청하지 않는 이유는 무엇입니까? [닫은]

나는 내 인생에서 12 번의 인터뷰를 가졌고 (나는 졸업하려고한다) 왜 한 번만 코드를 읽고 설명하도록 요청 받았는지 궁금하다. 대략 90 %의 직업은 대부분 기존 시스템을 유지 관리하는 것입니다. 다른 사람의 코드를 읽는 IMO 능력은 중요한 기술입니다.

면접관이 확인하지 않는 이유는 무엇입니까? *

* _{내 친구 중 일부는 코드를 검토하도록 요청받은 유일한 사람입니다.}

인터뷰 질문을 할 때 처음에했지만 천천히 단계적으로 마무리했습니다. 인터뷰에서 코드를 잘 작성할 수있는 지원자는 인터뷰에서 코드를 잘 읽을 수 있습니다. 코드를 읽을 수없는 신청자는 코드를 작성할 수 없습니다. 코드 읽기와 관련된 질문은 실제로 신청자를 차별화하지 못했습니다.

짧은 버전

작업이 응용 프로그램을 유지 관리하는 것으로 구성된 경우 인터뷰 중에 테스트해야 할 기술은 다음과 같습니다.

• 문서, 단위 테스트 등으로 큰 코드베이스를 이해하는 기능

• 코드 를 리팩토링 하고 모든 것을 망가 뜨리지 않고 변경 사항을 가져올 수있는 기능 .

사람들에게 코드를 읽도록 요청해도 그러한 능력을 평가하는 데 도움이되지는 않습니다.

긴 버전

코드 작성을 요청 받았습니까? 그렇다면 Sign 이 그의 답변 에서 언급했듯이 이것으로 충분합니다. 우리가 조금 일반화하면 명확하고 이해하기 쉬운 소스 코드를 작성하는 사람이 다른 사람이 작성한 소스 코드를 읽을 수 있습니다.

코드를 작성하라는 요청을받지 않았다면 인사 부서 직원이 인터뷰 한 것일 수 있습니다. 이러한 면접은 너무 기술적이지 못하며 대부분의 가치가 없습니다. 왜냐하면 그들은 당신의 기술과 당신의 능력을 잘 발휘하지 못하기 때문입니다. 오히려 당신이 대학에서 일한 시간과 그 일과 관련이없는 다른 것들을 보냈습니다.

유지 관리 작업을 위해 코드를 읽지 않아도되는 몇 가지 이유가 더 있습니다.

1. 안정적으로하기가 어렵다

구체적으로 면접관이라면 어떻게하겠습니까? 응시자가 코드를 읽도록하십시오. 어떤 코드? 어떤 언어로? 얼마나 잘 또는 나쁘게 기록 되었습니까? 의견 유무? 문서 유무에 관계없이?

더 중요한 것은 후보에 대해 무엇을 알려줍니까? 코드베이스 자체와 얼마나 관련이 있습니까?

유지 관리 할 레거시 VB.NET 앱이 있다고 가정하겠습니다. 소스 코드가 대부분 추악하고 테스트되지 않았으며 일부 주석이 오래되었거나 오해의 소지가 있음을 알고 있습니다. 지난 3 개월 동안이 솔루션을 개발하는 숙련 된 개발자가있었습니다. 그는 애플리케이션의 가장 중요한 부분을 리팩토링하고 단위 테스트하고, 의견이 필요한 곳에 의견을 추가했으며, 가장 중요한 것은 전체 아키텍처, 중요한 부분 및 함정에 대한 자세한 문서를 작성했습니다.

이 코드베이스를 유지 관리하기 위해 개발자를 고용하고 있습니다. 인터뷰 중에 레거시 (추악한 테스트되지 않은) 코드 또는 이전 개발자가 리팩토링 한 코드를 제공 하시겠습니까?

문서를 제공 하시겠습니까? 서류를 읽으려면 응시자는 최소한 몇 시간을 소비해야합니다. 이것은 인터뷰 중에는 불가능합니다.

2. 짧은 코드를 읽는 것은 익숙한 프로젝트의 코드를 읽는 것과 다릅니다

임무는 프로젝트를 유지하는 것입니다. 프로젝트에 익숙하지 않은 첫 날 이나 몇 주 동안 큰 코드베이스를 유지 관리하는 것은 어렵습니다 . 모든 문서를 작성하고 전체 코드베이스를 명확하게 볼 수 있는 몇 개월 후에 훨씬 쉽게 수행 할 수 있습니다.

테스트해야 할 가장 중요한 것은 사람이 그 달에 효율적 일지 여부 입니다. 그 사람이 처음 이틀 동안 아무것도 이해하지 못할 지 걱정하지 않아도됩니다.

한 사람에게 짧은 코드 조각을 처음부터 읽도록 요청하면 이 사람이 수천 개의 LOC로 친숙하고 문서화 된 코드 처리를 어떻게 처리 할 수 ​​있는지 테스트하지 않습니다 .

3. 소스 코드를 유지 관리하는 것은 단지 그것을 읽는 것이 아닙니다

코드베이스를 유지 보수 할 때 이를 수정 합니다. 코드를 읽는 개발자는 회사에 유용한 것을 가져 오지 않습니다.

유용한 기술은 코드 를 리팩터링하고 , 단위 테스트 를 추가 하고, 변경의 영향 을 예측하는 등의 기능입니다. 인터뷰 중에 코드를 읽도록 요청하여 해당 기술을 테스트하지는 않습니다.

읽기는 쓰기 능력이 있다는 사실에 근거한 가정입니다. 어떤 언어로든 개념을 고려하십시오. 프로그래밍은 인간과 기계 사이의 통신을위한 언어 일뿐입니다. 인간과 인간의 의사 소통을 고려하십시오. 당신이 누군가를 일본어 통역사로 고용하고 있다면, 그들이 특정 주제에 대해 1,000 단어 에세이를 쓸 수 있다면 그들이 읽을 수 있다고 생각하지 않습니까?

프로그래머로서 우리의 주요 활동은 코드를 작성하고 추상 아이디어를 구체적으로 구현하는 것입니다. 이것은 일반적으로 글쓰기를 의미합니다. 나는 읽기도 마찬가지로 중요하지만, 쓰기 능력이있는 대부분의 경우 읽기 능력도 있다는 것에 동의합니다. 구별 할 수있는 차이를 볼 수있는 유일한 실제 사례는 시간이 지남에 따라 진화 된 매우 복잡한 사례가 많이있는 환경에있을 것입니다. 그럼에도 불구하고, 당신은 누군가가 적어도 약간의 연구없이 그것들을 읽고 이해할 수 있기를 기대하지 않을 것입니다.

또한 코드를 읽고 생각하는 내용을 설명한다고해서 면접관에게 비판적 사고 능력을 어떻게 사용하는지 표현할 수는 없습니다. 그것은 약간의 분석을 보여 주지만, 대부분의 고용주는 상자에 넣지 않고 생각할 수 있는지 알고 싶어합니다. 기존 코드의 이점 없이도 개념을 파악하여 어떤 작업을 수행하는 방법이나 방법을 알려줄 수 있는지 알고 싶어합니다.

과거에는 독서 코드가 인터뷰에서 입증되어야한다고 생각하는 데 사용했지만 시간이 지남에 따라 인터뷰 자와 인터뷰 대상자 모두에게 시간 낭비라는 것을 깨달았습니다. 왜? 나쁜 코더조차도 코드를 읽을 수 있기 때문입니다.

코드를 읽을 수있는 사람의 능력을 판단 할 수 있다는 것은 많은 클래스와 파일에 걸친 복잡한 코드 나 코드를 볼 때만 관련이 있습니다. 코드를 추적하여 수행중인 작업을 파악하는 것은 바람직한 특성이지만 누군가가 좋은 예제 (생산 코드가 아님)를 생각 해낼 시간이 충분하지 않거나 인터뷰에서 그러한 질문을 할 시간이 없습니다. .

따라서 나쁜 코더는 코드를 읽을 수는 있지만 코드를 제대로 작성할 수는 없습니다. 응시자가 작업 한 사례를 보거나 인터뷰에서 코드를 작성하도록 요청하는 것은 기술의 더 나은 지표입니다. 그들이 간결한 간결한 코드를 작성할 수 있다면, 코드를 읽을 수있을 가능성이 높습니다.

인터뷰하는 모든 후보자에게 FizzBuzz 문제 의 변형을 요청합니다 . 빠르고 간단하며 일반적으로 내가 찾은 것보다 훨씬 더 나쁜 코더를 더 빨리 선택할 수 있습니다. 좋은 프로그래머라면 매우 쉽고 빠르게 얻을 수 있으며 코딩 스타일과 사고 과정을 빠르게 살펴볼 수 있습니다.