'나쁜 코드'인터뷰를 처리하는 방법? [닫은]

'나쁜 코드'인터뷰는 인터뷰 대상자에게 '나쁜 코드'스 니펫이 표시되고이를 수정하거나 잘못된 점을 지적하도록 요청한 것입니다. 이 인터뷰는 코드를 읽고, 수행하는 작업을 파악하고, 결함을 지적하는 데 시간이 걸리기 때문에 문제가 있습니다. 시간 압력이있는 상황에서 나는 얼어 붙는 경향이 있으며 코드가 작동하지 않아도 코드가 작동해야한다는 것을 알 수 있습니다.

이런 종류의 인터뷰를 처리하는 좋은 방법은 무엇이며, 일반적으로 코드를 빠르게 읽고 이해하는 좋은 기술은 무엇 입니까?

잘못된 코드 인터뷰 (올바르게 완료된 경우)에는 다음과 같은 코드가 표시되어야합니다.

• 나쁜 언어 기술 ( using필요할 때 C # 에서 명령문을 사용하지 않거나 ) ArrayList대신List<T>
• (도대체 우리가 사방에 문자열을 전달하거나 사용하는 이유는 나쁜 디자인 결정 ref과 out너무 많은 매개 변수?)
• 구문 오류 (컴파일하지 않아야합니다!)
• 런타임 오류 (예 : C #에서 자신을 참조하는 속성으로 인한 스택 오버플로)

위의 각 사항에 해당하는 정신 점검표가 있습니다. 코드를보고 그렇게 할 수 없다면 그것은 개선점입니다. '숙련 적'이라고 주장하는 언어가 무엇이든 코드 블록을보고이 네 가지 유형의 오류를 지적 할 수 있어야합니다.

나는 최근에 이러한 모든 문제를 보여주는 코드 조각에 대해 블로그를 작성했다 . 그것은 동일한 정신 과정을 거치는 데 도움이 될 것이다.

Ayende는 그의 Wages of Sin 시리즈로 더 깊이 들어갑니다 .

빨리 이해하려고하지 마십시오. 여기서 목표는 전문가처럼 코드를 이해할 수 있는지 확인하는 것이 아니라 어떻게 생각하는지 확인하는 것입니다.

핵심 IMO는 단순히 큰 소리로 생각하는 것입니다. 그래서 당신이 얼어 붙어도 "나는 여기서 스트레스를 받고 있지만 천천히이 소리를 내도록하겠습니다"라고 말하면됩니다.

당신이 큰 소리로 생각하는 기술을 가지고 있다고 가정하면, 당신의 마음을 바르게하기에 충분히 느려질 것입니다. 면접이 충분히 정통하다면 상황을보고 명확하게 생각할 때까지 도움을 줄 것입니다. 그들은 당신을 바보처럼 보이게하려고 시도하지 않습니다. 당신의 생각을 보는 강력한 기술입니다.

이상하게도, 당신이 느끼는 '시간 압력'은 전적으로 스스로 부과됩니다. 그것은 자신의 불안감과 얼마나 관련이 있는지에 대한 걱정과 관련이 있습니다.

누구나 할 수있는 가장 좋은 조언은 다음과 같습니다. 시간을내어 코드를 살펴보고 코드가 보이는대로 이야기하십시오. 좋은 부분과 나쁜 부분에 대해 자유롭게 이야기하십시오. 그것은 당신의 긴장을 줄이는 데 도움이되며 내부는 너무 많은 시간이 지남에 대해 걱정합니다.

또한 다른 '패스'를 거치면 특정 세부 정보를 좀 더 쉽게 확인할 수 있습니다. 일치하지 않는 괄호 또는 오타가 있는지 한 번에 확인하십시오. 난독 처리 된 라인을 찾는 다른 패스를 가져 가십시오. 시맨틱 프레즐을 찾는 또 다른 것을 가져 가라. 한 가지 유형의 "잘못 된 것"에 초점을 맞추면 이러한 세부 사항을보다 쉽게 ​​파악할 수있을뿐만 아니라 빠르거나 충분히 잘 수행하고 있는지에 대한 내면의 목소리를 줄일 수 있습니다.

무엇보다도, 당신이하고있는 일과 생각을 통해 이야기하십시오-그것은 당신과 면접관 모두를 도울 것입니다.

나는 이런 종류의 인터뷰에 가본 적이 없지만 나쁜 것으로 의심되는 까다로운 코드를 작성하려고 할 때 때로는 조용히 이야기합니다. 발성으로 문제 해결에 도움이되는 경우가 있습니다. 또한 인터뷰에서 연필이나 종이로 다이어그램 또는 무언가로 실행 단계를 추적 할 수 있습니다. 이것은 학교에서 저를 위해 일했지만 여전히 직장에서 일하는 경우가있었습니다. 물론 YMMV ...

나는 시작하기에 좋은 장소 (명백한 것이 없다면) "디버깅"하는 것이라고 생각합니다. 박쥐에서 가능한 문제가 보이지 않는 한 작은 테스트 값 목록을 작성하는 것이 좋습니다. 좋은 값은 '행복한 경로'(일반) 값, '0'또는 '빈'값, null, 매우 작은 값 (1 자 문자열, int 1 등), 매우 크거나 길다 유형 및 특정 유형의 '이상한'값 (예 : 문자열의 유니 코드 문자, 정수의 음수 등) 일반적으로 코드를 테스트하기 위해 이러한 값을 사용하여 단위 테스트를 작성하고 함수를 확인하기 위해 해당 값을 실행한다는 점을 언급하는 것은 아프지 않습니다.

당신의 행복한 길을 따라 걸으십시오. 덧셈 함수의 경우 3 또는 4로 시작할 수 있습니다. 각 줄에 오타 및 논리 오류가 있는지 검사하고 로컬 변수의 값을 추적하십시오. 바라건대, 몇 가지 버그가 있습니다. 행복한 길을 다 마치면 코드에 대한 느낌이 좋아지고 다소 부담감이 줄어들 것입니다. "이 코드가 수행하는 작업에 대해 더 나은 느낌을 갖도록합니다. 한 걸음 물러서서 살펴보세요. "그런 다음에 그렇게하세요. 다른 디자인 (잘못된 디자인 결정, 잘못된 이름의 변수, 가능한 버그 조사 등)과 다른 것으로 눈에 띄는 것을 찾으십시오.

그것이 당신을 데려다 줄 수 없거나 말이 부족하다고 생각되면 테스트 값 목록으로 돌아가서 문제를 일으킬 것으로 생각되는 새로운 값으로 다시 살펴보십시오.

이것은 적어도 당신을 갈 것입니다.

Stephen Bailey가 말했듯이, 큰 소리로 생각하는 것은 면접관이 당신의 사고 과정을 볼 수있게하므로이 상황에서 훌륭한 기술입니다. 당신이 알아 내려고하려는 것을 설명하십시오. 다른 방법은 면접관에게 코드의 나쁜 점에 대한 진단을 제공하기 전에 코드를 올바르게 읽 겠다는 사실을 알리는 것입니다. 나는 테이블의 양쪽에 있었고 이러한 상황에서 양쪽 모두에게 좌절감을 줄 수 있음을 알고 있습니다.

필기 시험으로 압력을 덜받는다면 노트북을 꺼내서 필기를 시작하십시오. 나는 노트를 꺼내 인터뷰에서 사고 과정의 일부로 노트를 스케치하기 시작했습니다. 노트와 펜을 가지고 있으면 편성 된 모양이됩니다. 찾고자하는 몇 가지 요점, 구문, 논리 오류, 데이터 유형 불일치, 로컬 변수 값을 기록 할 수 있습니다 (목록은 가져온 코드 유형에 따라 다를 수 있음, 복잡한 SQL에 대한 내 목록은 프로세스 등을 진행할 때 데이터 중심이 아닌 코드를 가진 사람과는 다를 수 있습니다.이 중 몇 가지를 작성한 후에는 찾기 시작하십시오. 그렇게하면 면접관이 계속 진행하기 전에 모든 문제를 발견하지 못하더라도 검사 할 사항의 목록을 볼 수 있습니다. 찾고자하는 것들에 대해 미리 체크리스트를 작성하면, 보려고 계획 한 것을 알고 프로세스를 시작하는 것이 더 자신감이됩니다. 일반적으로 이러한 질문은 실제로 모든 오류를 찾는 것보다 오류를 찾는 방법에 대한 것입니다.

이 파티에 조금 늦었지만 사용할 수있는 기술 중 하나는 문제의 코드에 대한 단위 테스트를 작성하는 것입니다. 그런 다음 코드의 미묘한 문제에 집중하지 않고 원하는 결과에 더 집중할 수 있습니다. 차라리 코드에 문제가있는 것을 즉시 발견 할 수있는 사람보다 좋은 테스트를 작성할 수있는 사람을 고용하고 싶습니다.

두 가지 문제가있을 수 있습니다.

"스트레스 인터뷰" http://en.wikipedia.org/wiki/Job_interview#Stress 일 수 있습니다 . 면접관은 자신의 업무 환경이 스트레스이기 때문에 스트레스에 어떻게 대처하는지 살펴보고자합니다.

또는

스트레스를받을 수도 있습니다. 이 경우이 스트레스를 관리해야합니다 (예 : 내성적).