기술 인터뷰는 퍼즐로 유명합니다. 화이트 보드에 이진 트리를 작성하거나 정렬 알고리즘을 설명하거나 10 줄 이하로 FizzBuzz를 구현하라는 요청을받는 경우 평균 인터뷰에서 기술 프로그래밍 질문을 준비해야합니다.
그러나 이것이 당신이 준비해야 할 유일한 것은 아닙니다.
현실은 많은 개발자들이 일반적인 프로그래밍 인터뷰 질문을 답 사이의 차이가 거의없이 해결할 수 있다는 것입니다. 그렇다면 다음 후보와 다른 점은 무엇입니까? 이것이 바로이 다섯 가지 팁에서 중점을 두게 될 내용입니다.
1. 추론과 문제 해결 과정에 대해 이야기하십시오.
어려운 질문을 할 때 할 수있는 최악의 일은 완전히 말을하지 않는 것입니다. 불행히도 우연히이 작업을 수행하는 것은 매우 쉽습니다. 상당한 정신 에너지와 집중력이 필요한 문제가 발생하면 첫 번째 성향이 마음에 퇴각하는 것일 수 있습니다. 이것은 자연 스럽지만 면접관에게는 그다지 도움이되지 않습니다.
기술적 인 문제는 부분적으로 문제 해결에 대한 귀하의 생각을 밝히는 것입니다. 당신의 프로세스는 무엇입니까? 다른 구성 요소를 어떻게 분류합니까? 어떻게 솔루션에 도착합니까? 작동하지 않는 것을 시도 할 때 어떻게 반응합니까? 코드를 실험하거나 화이트 보드에서 무언가를 스케치하는 것이 더 낫습니까?
문제를 해결할 때 머리에 무슨 일이 일어나고 있는지 설명하십시오. 다른 사람이 그 문제를 해결하는 방법을 가르치기 위해 온라인으로 출판하기 위해 음성을 녹음하는 것처럼 행동하십시오. 면접관이 조용히 생각할 수있는 공간을 주더라도, 그렇게하지 않아도 사고 과정을 설명하는 것이 도움이 될 수 있습니다. 이것은 그들이 당신의 기술과 비판적 사고를보다 철저히 이해하는 데 도움이 될뿐만 아니라 당신을 더욱 기억에 남게 만듭니다.
2. 기술 면접에서 문제를 해결하는 것보다 낫다? 그것을 두 번 해결
하나의 솔루션 만있는 문제는 거의 없으며 모든 문제에는 무한한 잘못된 해결책이 있습니다. 따라서 문제를 해결하는 한 가지 방법에만 집중하면 유연성과 기술을 입증 할 수있는 주요 기회가 없습니다.
잘 알려진 솔루션을 사용하거나 단일 언어로 작업하는 대신 해당 특정 문제에 대한 토론을 열고 다양한 시나리오에서 해결하십시오. 예를 들어, FizzBuzz를 프로그래밍하라는 요청을 받으면 두 가지 언어로 또는 두 가지 다른 패러다임을 채택하거나 한 솔루션에 대한 성능 제약과 다른 솔루션에 대한 미적 제약을 취하도록 제안 할 수 있습니다.
문제에 여러 가지 솔루션이있을 수 있음을 검증함으로써, 적응성, 유연성 및 인식을 보여 주므로, 인터뷰 담당자에게 다양한 가능성 중에서 올바른 솔루션을 선택할 수 있다는 신뢰를 심어줄 것입니다.
물론, 여러 가지 해결책으로 질문에 대답 할 때 읽는 것이 너무나 기쁘거나 행복하게 받아 들여지는 기술이 있습니다. 의심스러운 경우, 보조 옵션을 사용하여 솔루션을 확장하는 데 시간이 걸리는지 면담 관에게 물어 보는 것을 두려워하지 마십시오.
3. 해당되는 경우 의견 공유를 두려워하지 마십시오
때로는 문제를 해결하면서 자신의 취향과 의견에 따라 결정을 내릴 수도 있습니다. 그리고 괜찮습니다. 고용주는 여러분의 의견에 관심이 있습니다! 상황에 대해 생각하고 반응하는 방식은 회사의 문화에 큰 차이를 만듭니다. 의견을 갖는 것은 개발자로서의 리더십과 기술적 성숙의 표시입니다. 자신의 의견에 대해 토론하려면 주어진 주제에 대한 다른 입장을 평가해야합니다.
그러나 의견은 매우 밀접하게 유지 될 수 있습니다. 특정 주제에 대해 면접관과 의견이 일치하지 않으면 해당 정보를 공유 할 때 가볍게 밟습니다. 관점을 갖는 것이 좋지만 공유하는 것이 항상 필요한 것은 아니며 전투를 선택하는 방법을 아는 것도 중요합니다. 좋은 경험 법칙 : 요청이 없으면 의견을 말하지 마십시오.
4.“모름”으로 답을 끝내지 마십시오
"Kobayashi Maru"시나리오에 직면하지 않는 한 "알지 못합니다"라는 인터뷰 질문을 끝내지 마십시오. 이는 작업에 대한 옵션이 아니므로 인터뷰에서 옵션이되어서는 안됩니다.
물론, 나는 당신이 모든 것을 알아야한다고 말하는 것이 아닙니다. 불가능합니다! 그러나 일을 완수하기 위해 알아야 할 것을 배우는 전략이 있음을 보여 주어야합니다. "어떻게해야할지 모르겠지만 여기에이를 알아내는 방법이 있습니다."라고 대답 해보십시오.이 답변은 "Google이라고합니다"라고 말하는 것보다 더 나아갈 것입니다. 조사 할 가능성이 가장 높은 방향을 설명하는 것이 좋습니다.
무엇보다도 부끄러워하지 마십시오! 학습은 주로 당신이 모르는 것을 알아내는 과정입니다. 고용주는 당신이 완벽하기를 기대하지는 않지만 부지런하고 똑똑하며 문제를 결코 끝내지 않기를 기대합니다.
5. 항상 팀을 위해 경기
프리랜서 개발자가 아닌 한, 업무는 항상 팀 내에서 이루어지며 팀의 성공은 항상 자신의 것입니다. 따라서 인터뷰에는 주어진 날에 문제를 해결하는 데 관심이있는 것이 아니라 팀이 성공하기 위해 필요한 모든 일에 집중하고 있음을 반영해야합니다.
인터뷰에서 어떻게 이것을 전달할 수 있습니까?
마치 진공 상태 인 것처럼 문제를 논의하지 않습니다
거의 모든 프로젝트에는 실제로 자원 요구 사항과 제한이 있으므로 문제의 상황에 대한 인식을 보여주십시오. 잘 해결되었지만 예산을 초과 한 문제는 실제로 가장 큰 해결책은 아닙니다.
기존 팀에 대한 전문 지식 인식
질문에 대한 가장 좋은 대답은 팀의 다른 사람들에게 귀하와 협력하도록 요청하는 것입니다. 기술적 인 질문에있는 사람들을 언급 할 수도 있습니다.“저희 팀의 맥락에서이 문제가 제시된 경우 검토를 요청합니다 내 솔루션도 마찬가지입니다.”이것은 다른 사람들의 전문 지식에 기꺼이 의존하고 있으며 귀하의 목표가 최상의 솔루션에 도달하는 것임을 보여줍니다.
팀 중심의 가치를 명시 적으로 전달
이것은 당신이 바로 나와서 말해야 할 중요한 문제입니다. 하루 종일 책상에 앉아 코드를 작성하는 것이 아니라 회사의 성공을 돕는 것이 회사의 목표라는 사실을 고용주가 완전히 인식하도록하려고합니다.
궁극적으로 개발자로서의 업무는 코딩 만하는 것이 아닙니다. 팀 플레이어, 리더, 그리고 문제를 결코 포기하지 않는 사람이어야합니다. 기술 인터뷰의 기회는 목표를 달성하거나 알고리즘을 작성할 수 있음을 보여줄뿐만 아니라 경쟁에서 우위를 점하고 고용주에게 더한 가치를 보여줄 수있는 기회입니다.
