Cracking the Coding Interview, 6th edition, Introduction, 3. Special Situations

Cracking the Coding Interview, 189 Programming Questions & Solutions, Grale Laakmann McDowell

이 책으로 이끄는 다양한 상황이 있을 수 있습니다. 아마 더 많은 경험을 가지고 있지만 이러한 유형의 면접을 한 적이 없는 것일지도 모릅니다. 아마 테스터나 PM일 수도 있습니다. 또는 실제로 면접을 더 잘 보기 위해 이 책을 사용하는 것일 수도 있습니다. 이러한 “특별한 상황”에 대한 약간의 도움말을 제공해 드리겠습니다.

Experienced Candidates

이 책에 나오는 알고리즘 스타일의 질문은 주로 졸업생을 대상으로 한 것으로 생각하는 사람도 있습니다. 그러나 이는 전적으로 사실이 아닙니다.

더 경험이 많은 엔지니어들도 약간 덜 중점을 둔 알고리즘 질문을 볼 수 있지만, 이것은 오직 약간에 불과합니다. 만약 어떤 회사가 경험이 부족한 지원자에게 알고리즘 질문을 한다면, 경험이 많은 지원자에게도 똑같이 묻는 경향이 있습니다. 옳든 그르든, 이러한 질문에서 보여주는 기술들은 모든 개발자에게 중요하다고 여기는 것 같습니다.

일부 면접관들은 경험이 많은 지원자들에게 다소 낮은 기준을 적용할 수 있습니다. 결국, 이러한 지원자들이 알고리즘 수업을 들은 지 오래됐습니다. 실전 경험이 없습니다.

다른 사람들은 경험이 많은 지원자들을 더 높은 기준으로 측정합니다. 왜냐하면 더 많은 경험 년수가 후보자로 하여금 더 다양한 유형의 문제를 접할 수 있게 해주기 때문입니다.

평균적으로는 균형을 이룹니다. 이 규칙의 예외는 시스템 디자인 및 아키텍처 질문과 이력서에 관한 질문입니다. 일반적으로 학생들은 시스템 아키텍처를 많이 공부하지 않으므로, 이러한 도전에 대한 경험은 전문적으로만 얻을 수 있습니다. 이러한 면접 질문에 대한 성과는 경험 수준을 고려하여 평가될 것입니다. 그러나 학생들과 최근 졸업생들에게도 이러한 질문이 물어지며, 최대한 잘 대답할 준비가 되어야 합니다. 또한 경험이 많은 지원자들은 “가장 어려웠던 버그는 무엇이었나요?”와 같은 질문에 더 깊고 인상적인 답변을 제공할 것으로 기대됩니다. 당신은 더 많은 경험을 가지고 있으며, 이러한 질문에 대한 답변은 그것을 보여주어야 합니다.

Testers and SDETs

SDET (소프트웨어 디자인 엔지니어 테스트)는 기능을 개발하는 대신 기능을 테스트하기 위해 코드를 작성하는 역할을 합니다. 따라서 그들은 훌륭한 코더와 훌륭한 테스터가 되어야 합니다. 이중으로 준비해야 합니다!

SDET 역할에 지원하는 경우 다음과 같은 접근 방식을 취할 수 있습니다:

핵심 테스팅 문제 준비: 예를 들어 전구, 펜, 현금 등을 어떻게 테스트할지 고려해보세요. 이러한 문제에 대한 백그라운드 정보는 Testing 챕터에서 얻을 수 있습니다.

코딩 질문 연습: SDET가 주로 거부되는 이유 중 가장 큰 것은 코딩 스킬입니다. 코딩 표준은 전통적인 개발자에 비해 SDET에게는 일반적으로 덜 엄격하지만, SDET는 여전히 코딩과 알고리즘에서 매우 강한 역할을 기대합니다. 일반 개발자가 받는 모든 코딩 및 알고리즘 질문을 해결하는 연습을 반드시 하세요.

코딩 질문 테스트 연습: SDET 질문의 매우 인기 있는 형식 중 하나는 “X를 수행하는 코드를 작성하라”이며, 그 뒤에 “이제 이것을 어떻게 테스트하겠습니까?”가 따릅니다. 질문이 명시적으로 이를 요구하지 않더라도 “이것을 어떻게 테스트할 것인가?”라는 질문을 자주 스스로에게 던져보세요. 기억하세요, 어떤 문제든 SDET 문제로 바꿀 수 있습니다!

강한 커뮤니케이션 스킬 연습: 테스터로서 여러 다른 사람들과 협력해야 하므로 강력한 커뮤니케이션 스킬도 매우 중요할 수 있습니다. 행동 질문 섹션을 소홀히하지 마세요.

SDET 역할은 코딩 능력과 테스팅 능력을 모두 요구하기 때문에 이러한 측면을 모두 고려하여 준비하세요. 강한 커뮤니케이션 스킬도 필요하므로 면접 준비에 이 부분을 간과하지 마세요.

Career Advice

마지막으로, 경력 조언을 하나 드리겠습니다. 많은 지원자들처럼 SDET 포지션을 기업에 쉽게 진입하는 방법으로 생각하고 있다면, SDET 포지션에서 개발자 포지션으로 전환하는 것이 매우 어려운 경우가 많다는 점을 인지해야 합니다. 이러한 이동을 희망한다면 코딩과 알고리즘 스킬을 매우 날카롭게 유지하고, 가능하면 1~2년 이내에 전환을 시도하세요. 그렇지 않으면 개발자 면접에서 심각하게 대우받기 어려울 수 있습니다. 코딩 스킬을 약화시키지 말아야 합니다.

Product (and Program) Management

이 “PM” 역할은 회사마다, 심지어 회사 내에서도 크게 다양합니다. 예를 들어 Microsoft에서 일부 PM은 고객 대표 역할로 고객과 경계에 위치하여 마케팅에 가까운 역할을 수행할 수 있습니다. 그러나 캠퍼스 내에서 다른 PM는 하루 대부분을 코딩하는 경우도 있습니다. 후자 유형의 PM은 일부 코딩을 시험받을 가능성이 높으며, 이것은 그들의 직무 기능 중요한 부분입니다.

일반적으로 PM 포지션의 면접관은 다음 영역에서의 역량을 시험자로부터 확인하기를 기대합니다. • 모호함 처리: 일반적으로 가장 중요한 영역은 아닙니다. 그러나 면접관들은 이러한 기술을 찾습니다. 면접관들은 모호한 상황에 직면했을 때 당황하거나 멈추지 않는 것을 보고 싶어합니다. 문제를 구조화된 방식으로 해결하기 위해 새로운 정보를 찾고 가장 중요한 부분을 우선적으로 다루며, 문제를 해결하려고 하는 것을 보고 싶어합니다. 이러한 측면은 일반적으로 직접 시험되지는 않을 것입니다 (하지만 가능합니다), 그러나 면접관이 문제에서 찾고있는 요소 중 하나일 수 있습니다. • 고객 중심 (태도): 면접관들은 당신의 태도가 고객 중심인지 확인하려고 합니다. 당신은 모든 사람이 제품을 당신처럼 사용할 것이라고 가정합니까? 아니면 당신은 고객의 입장에서 제품을 어떻게 사용하려고 하는지 이해하려고 하는 유형의 사람입니까? “시각 장애인을 위한 알람 시계를 디자인하라”와 같은 질문은 이 측면을 검사하기에 적합합니다. 이러한 질문을 들었을 때 제품을 사용하는 고객이 누구이며 제품을 어떻게 사용하는지 이해하기 위해 많은 질문을 하십시오. Testing 섹션에서 다루는 기술들과 관련이 깊습니다. • 고객 중심 (기술 스킬): 더 복잡한 제품을 가진 일부 팀은 PM이 직장에서 이러한 지식을 습득하기 어려운 경우가 있기 때문에 제품에 대한 깊은 기술 지식을 갖추어야 할 필요가 있습니다. 모바일 전화의 깊은 기술 지식은 안드로이드 또는 Windows Phone 팀에서 일하기 위해 꼭 필요하지 않을 것입니다 (그럼에도 불구하고 가지고 있으면 좋을 것입니다), 반면 Windows Security에서 일하기 위해 보안에 대한 이해가 필요할 수 있습니다. 일반적으로 특정 기술 스킬이 필요한 팀과 면접을 보지 않을 것입니다 (하지만 필요한 기술 스킬을 주장해야 할 것입니다). • 다수의 수준에서의 커뮤니케이션: PM은 회사 내 모든 수준의 사람들과, 다양한 포지션과 기술 스킬 범위를 가진 사람들과 커뮤니케이션할 수 있어야 합니다. 면접관은 당신이 커뮤니케이션에서 이러한 유연성을 가지고 있는지 확인하려고 합니다. 이것은 종종 질문에 직접적으로 시험되며, “할머니에게 TCP/IP를 설명하라”와 같은 질문으로 이 측면을 평가할 수 있습니다. 또한 이전 프로젝트에 대한 토론 방식으로 당신의 커뮤니케이션 스킬을 평가할 수도 있습니다. • 기술에 대한 열정: 행복한 직원은 생산적인 직원이므로 회사는 당신이 직무에 만족하고 업무에 열정을 갖고 있을 것이라고 확신하려고 합니다. 기술에 대한 열정, 그리고 이상적으로는 회사나 팀에 대한 열정이 당신의 답변에서 나와야 합니다. 직접적으로 “왜 Microsoft에 관심이 있나요?”와 같은 질문을 받을 수도 있습니다. 또한 면접관들은 당신이 이전 경험을 어떻게 논의하고 팀의 과제를 어떻게 논의하는지에 열정을 찾으려고 합니다. 그들은 당신이 직무의 과제에 대해 열정적으로 대응할 것이라고 보고 싶어합니다. • 팀워크와 리더십: 이것은 아마도 면접과 실제 직무에서 가장 중요한 측면일 수 있으며, 당연히 직무 자체입니다. AM 면접관은 다른 사람들과 잘 협력할 수 있는 능력을 찾고 있을 것입니다. 가장 흔한 경우에는 “동료가 자신의 할 일을 못하는 경우에 대해 얘기해보세요.”와 같은 질문으로 이를 확인합니다. 면접관은 당신이 충돌을 잘 처리하고, 주도적으로 일하며, 사람을 이해하며, 사람들이 당신과 일하는 것을 좋아할 것입니다. 행동 질문에 대비하는 데 투자한 시간은 이 측면에서 매우 중요할 것입니다.

위에서 언급한 모든 영역은 PM이 습득해야 하는 중요한 기술이며, 따라서 면접의 주요 초점 영역입니다. 각 영역의 가중치는 실제 직무에서의 중요성과 대략 일치할 것입니다.

Dev Lead and Managers

개발 리더 포지션에서는 강력한 코딩 스킬이 거의 항상 필요하며, 관리 포지션에서도 종종 필요합니다. 직무에서 코딩을 수행할 경우 개발자와 마찬가지로 코딩 및 알고리즘에 대해 매우 강력해야 합니다. 특히 Google은 코딩에 관한 관리자에게 높은 기준을 적용합니다.

또한 다음 영역에서의 역량을 시험받기 위해 준비하십시오:

팀워크/리더십: 관리자와 유사한 역할을 하는 사람은 사람들을 리드하고 협력해야 합니다. 이러한 영역에서 명시적으로나 암시적으로 평가될 것입니다. 명시적 평가는 이전 상황에서 어떻게 대처했는지와 같은 질문 형태로 나타날 것입니다. 암시적 평가는 면접관들이 당신이 어떻게 상호 작용하는지 관찰하는 형태로 나타날 것입니다. 너무 오만하거나 너무 수동적으로 나오면 면접관은 당신이 관리자로서 능숙하지 않다고 판단할 수 있습니다.

우선 순위 설정: 관리자는 종종 팀이 어려운 마감일을 충족시키는 방법과 같은 어려운 문제를 다루게 됩니다. 면접관들은 적절하게 프로젝트에 우선 순위를 설정하고 중요하지 않은 부분을 제거할 수 있는 능력을 확인하고자 할 것입니다. 우선 순위 설정은 중요한 부분과 합리적으로 달성 가능한 부분을 이해하기 위해 올바른 질문을 하는 것을 의미합니다.

커뮤니케이션: 관리자는 그들 위와 아래의 사람들과 소통해야 하며, 고객 및 기술적으로 훨씬 덜 숙련된 사람들과도 소통해야 할 수 있습니다. 면접관들은 여러 수준에서 소통할 수 있는 능력과 친근하고 매력적으로 소통할 수 있는 능력을 확인하려고 할 것입니다. 이것은 어느 정도 당신의 성격을 평가하는 것입니다.

일 처리하기: 관리자가 할 수 있는 가장 중요한 일은 “일을 처리하는” 사람이 되는 것입니다. 이것은 프로젝트를 준비하고 실제로 구현하는 사이의 적절한 균형을 유지하는 것을 의미합니다. 프로젝트를 구조화하고 팀의 목표를 달성하기 위해 사람들을 동기화하는 방법을 이해해야 합니다.

이러한 대부분의 영역은 당신의 이전 경험과 성격과 관련이 있습니다. 면접 준비 그리드를 사용하여 매우 철저하게 준비하십시오.

Startups

스타트업의 신청 및 면접 과정은 매우 다양할 수 있습니다. 모든 스타트업에 대해 자세히 다룰 수는 없지만 몇 가지 일반적인 조언을 제공할 수 있습니다. 그러나 특정 스타트업에서의 과정은 이와 다를 수 있음을 이해하십시오.

The Application Process

많은 스타트업이 구인 공고를 게시할 수 있지만, 가장 핫한 스타트업에서 일하려면 종종 개인 추천을 통하는 것이 가장 좋은 방법입니다. 이 추천은 반드시 가까운 친구나 동료가 아니어도 됩니다. 종종 관심을 표현하고 누군가가 당신의 이력서를 확인하여 당신이 적합한 후보인지 판단하도록 부탁하면 됩니다.

Visas and Work Authorization

안타깝게도, 미국의 많은 작은 스타트업은 외국인에게 작업 비자를 스폰서해 줄 수 없습니다. 그들도 이 시스템을 싫어하며, 당신을 고용하도록 설득할 수 없을 것입니다. 비자가 필요하고 스타트업에서 일하고 싶다면, 전문적으로 다수의 스타트업과 협력하는 인재 모집 업체에 연락하거나 (비자 문제를 다루는데 더 능숙한 스타트업을 파악할 수 있는) 이러한 업체의 도움을 받는 것이 가장 좋은 방법일 수 있습니다. 또는 대규모 스타트업에 중점을 두어 검색하는 것도 고려할 수 있습니다.

Resume Selection Factors

스타트업은 똑똑하고 코딩을 할 수 있는 엔지니어 뿐만 아니라 기업가적인 환경에서 잘 작동하는 사람을 원합니다. 이력서는 이러한 적극성을 보여주어야 합니다. 어떤 종류의 프로젝트를 시작했나요? 빠르게 적응할 수 있는 능력 또한 매우 중요합니다. 스타트업은 이미 회사의 언어를 알고 있는 사람을 원합니다.

The Interview Process

큰 회사와 달리 스타트업은 종종 개인의 성격, 기술 스킬 및 이전 경험을 자세히 살펴보는 경향이 있습니다.

• 성격 적합성: 성격 적합성은 일반적으로 면접관과의 상호작용을 통해 평가됩니다. 면접관과 친근하고 매력적인 대화를 나누는 것이 많은 취업 제안을 얻을 수 있는 열쇠입니다.
• 기술 스킬: 스타트업은 빠르게 적응할 수 있는 사람들을 필요로 하기 때문에 특정 프로그래밍 언어의 기술을 평가할 가능성이 높습니다. 스타트업이 사용하는 언어를 알고 있다면 세부 사항을 복습하세요.
• 경험: 스타트업은 경험에 대한 많은 질문을 할 가능성이 있습니다. 특히 행동 질문 섹션에 주의를 기울이세요.

위의 항목 외에도 이 책에서 볼 수 있는 코딩 및 알고리즘 질문들도 매우 일반적입니다.

Acquisitions and Acquihires

많은 인수 과정에서 기술적인 심사가 진행되며, 많은 스타트업 직원들이 면접을 보게 됩니다. Google, Yahoo, Facebook 및 다른 많은 회사들이 많은 인수 과정에서 이를 표준 절차로 갖고 있습니다. 어떤 스타트업이 이 과정을 거치는가요? 그리고 왜 그럴까요? 이 과정의 일부 이유 중 하나는 스타트업 직원들이 이 과정을 거쳐 고용된 것이기 때문입니다. 이들은 인수를 기업에게 쉬운 길로 여기지 않으려고 합니다. 그리고 인수의 핵심 동기 중 하나가 팀이기 때문에 팀의 기술을 평가하는 것이 합리적이라고 생각합니다. 물론 모든 인수가 이런 식은 아닙니다. 유명한 몇몇 십억 달러 규모의 인수는 일반적으로 이 과정을 거치지 않았습니다. 그런 인수들은 일반적으로 사용자 베이스와 커뮤니티에 관한 것이므로 직원이나 기술에 대한 것이 덜 중요합니다. 팀의 기술을 평가하는 것은 덜 필수적입니다. 그러나 이것은 “인수에게는 면접이 있고, 전통적인 인수에는 없다”는 단순한 문제가 아닙니다. 인수의 목적과 기술 뒤에있는 아이디어를 기반으로 한 아이디어를 가진 팀이 많이 있습니다. 인수 기업은 제품을 중단할 수 있지만 팀을 비슷한 작업을 하도록 유도할 수 있습니다. 당신의 스타트업이 이 과정을 거친다면, 일반 지원자가 경험하는 것과 매우 유사한 면접을 받을 것으로 기대할 수 있습니다(따라서 이 책에서 볼 수 있는 것과 매우 유사할 것입니다). 이러한 면접은 얼마나 중요한가요? 이러한 면접은 엄청나게 중요할 수 있습니다. 이러한 면접은 세 가지 다른 역할을 합니다. • 인수를 성사시키거나 망치는 데 기여할 수 있습니다. 종종 기업이 인수를 받지 못하는 이유가 되기도 합니다. • 어떤 직원들이 인수 기업에 합류 제안을 받을지 결정합니다. • 인수 가격에 영향을 미칠 수 있습니다(일부 직원이 합류하는 수에 따라 일부로 인해). 이러한 면접은 단순한 “스크린” 이상의 의미가 있습니다. 어떤 직원들이 면접을 봐야 하나요? 기술 스타트업의 경우 일반적으로 엔지니어들이 인수의 핵심 동기 중 하나이므로 모든 엔지니어가 면접을 봐야 합니다. 또한 영업, 고객 지원, 제품 관리자 및 기타 모든 역할이 이를 거칠 수 있습니다. CEO는 일반적으로 현재 역할에 가장 가까운 제품 관리자 면접이나 개발 관리자 면접에 배치됩니다. 그러나 이것은 절대적인 규칙이 아닙니다. CEO의 현재 역할 및 CEO의 관심에 따라 다릅니다. 내 클라이언트 중 일부는 CEO가 면접을 보지 않고 인수 시 회사를 떠나기로 선택한 경우도 있습니다. 면접에서 성적이 좋지 않은 직원들은 일반적으로 인수 기업에 합류 제안을받지 못합니다(많은 직원이 성적이 좋지 않은 경우 인수가 진행되지 않을 가능성이 높습니다).

면접에서 성적이 좋지 않은 직원의 경우 종종 “지식 이전”을 목적으로 계약 직위를 얻게 됩니다. 이들은 종종 6개월 동안 계약이 종료되면 직원이 나가기를 기대하는 일시적인 직위입니다. 그러나 때로는 직원이 계속 유지될 수도 있습니다. 다른 경우에는 성적이 좋지 않았던 이유가 직원의 잘못된 배치로 인한 것입니다. 이는 두 가지 일반적인 상황에서 발생합니다. • 때로 스타트업은 전통적인 소프트웨어 엔지니어가 아닌 사람을 소프트웨어 엔지니어로 레이블링합니다. 이런 일은 데이터 과학자나 데이터베이스 엔지니어와 같은 경우에 자주 발생합니다. 이러한 사람들은 실제 역할에 다른 기술이 필요하므로 소프트웨어 엔지니어 면접에서 성적이 낮을 수 있습니다. • 다른 경우에는 CEO가 주니어 소프트웨어 엔지니어를 실제보다 더 고위로 소개합니다. 그는 고위 기준에 불합리하게 높은 기준으로 성적이 낮게 나올 수 있습니다. (이러한 경우 중 일부에서는 직원이 더 적절한 위치를 위해 다시 면접을 볼 수 있습니다. 그러나 다른 경우에는 직원이 운이 없을 수도 있습니다.) 드물게 CEO는 면접 성적이 이를 반영하지 않는 특히 강한 직원의 결정을 무시할 수 있습니다. “최고” (그리고 최악)의 직원은 때로는 놀라울 수 있습니다. 최상의 기술 회사에서 진행되는 문제 해결/알고리즘 면접은 그들의 관리자가 직원을 평가하는 방식과 완벽하게 일치하지 않을 수 있는 특정 기술을 평가합니다. 저는 많은 기업들과 함께 일하면서 면접에서 가장 강력하고 가장 약한 성능을 보이는 직원이 누구인지에 대해 놀란 경우가 많았습니다. 아직 전문 개발에 대해 많이 배워야 할 주니어 엔지니어가 이 면접에서 훌륭한 문제 해결자가 될 수도 있습니다. 아무도 제외하거나 포함하기 전에 직원을 그들의 면접관이 그렇게 평가하는 방식과 동일하게 평가하십시오. 직원들은 일반 지원자와 동일한 기준에 따라 평가되나요? 기본적으로 그렇습니다만, 약간의 유연성이 더 있습니다. 대형 기업들은 고용에 대해 보수적인 접근을 취하는 경향이 있습니다. 누군가가 기준에 미묘하게 미묘하게 속해 있는 경우, 그들은 종종 무공개 쪽으로 기울어집니다. 인수의 경우, “미묘한” 직원은 팀의 다른 멤버의 강력한 성과로 인해 이동될 수 있습니다. 직원들은 인수/인수에 대한 소식을 어떻게 받아 드리나요? 이것은 많은 스타트업 CEO와 설립자들에게 큰 걱정입니다. 직원들은 이 과정에 대해 화가 나게 될까요? 또는 희망을 키우지만 그렇게 되지 않을 경우 어떻게 할까요? 내 클라이언트들과 함께 한 결과로는 리더십이 이에 대해 과도하게 걱정하는 것보다 더 걱정됩니다. 확실히 일부 직원들은 이 과정에 대해 화가 나는 경우도 있습니다. 그들은 다양한 이유로 큰 기업 중 하나에 합류하는 것에 흥미를 느끼지 않을 수 있습니다. 그러나 대부분의 직원들은 이 과정에 대해 조심스럽게 낙관적입니다. 그들은 그것이 성사되기를 희망하지만 이러한 면접이 그렇지 않을 수 있다는 것을 알고 있습니다.

인수 후 팀은 상황에 따라 다릅니다. 그러나 내 클라이언트 대부분은 팀으로 유지되거나 기존 팀에 통합되는 경우가 많습니다.

팀을 인수 면접에 어떻게 준비해야 하나요? 인수 면접을 위한 인터뷰 준비는 기본적으로 인수 대상자의 전형적인 면접과 매우 유사합니다. 차이점은 회사가 이를 팀으로 수행하며 각 직원이 개별적으로 자격에 따라 면접에 선택되지 않는다는 것입니다. 함께 이것을 하고 있습니다. 내가 함께 일한 일부 스타트업은 “실제” 업무를 일시 중단하고 팀을 다음 두 ~ 세 주 동안 면접 준비에 시간을 할애했습니다. 물론 이 선택을 할 수 있는 모든 기업이 아니지만, 인수가 이루어지길 바라는 관점에서는 결과를 상당히 높일 수 있습니다. 팀은 개별적으로, 두 ~ 세 명의 팀으로 또는 서로의 모의 면접을 통해 개별적으로 공부해야 합니다. 가능하다면 이 세 가지 접근 방식을 모두 사용하십시오. 일부 사람들은 다른 사람들보다 덜 준비될 수 있습니다. 스타트업의 많은 개발자들은 대부분 중요한 개념인 big O 시간, 이진 검색 트리, 너비 우선 검색 및 기타 중요한 개념에 대해 대략 들어 본 것일 수 있습니다. 그들은 추가적인 시간이 필요할 것입니다. 컴퓨터 공학 학위가 없는 사람들 (또는 오래전에 학위를 받은 사람들)은 먼저 이 책에서 논의된 핵심 개념, 특히 big O 시간 (가장 중요한 중 하나)을 배우는 데 집중해야 합니다. 좋은 연습은 기본 데이터 구조와 알고리즘을 모두 처음부터 구현하는 것입니다. 인수가 회사에 중요하다면 이러한 사람들에게 필요한 시간을 제공하십시오. 그들은 그것이 필요할 것입니다. 마지막 순간까지 기다리지 마세요. 스타트업은 계획 없이 일을 처리하는 것에 익숙할 수 있습니다. 이런 식으로 인수 면접을 다루는 스타트업은 일반적으로 잘하지 않습니다. 인수 면접은 종종 매우 갑작스럽게 발생합니다. 회사의 CEO가 인수자 (또는 여러 인수자)와 이야기하면서 대화가 점점 진지해집니다. 인수자는 언젠가 면접의 가능성을 언급합니다. 그런 다음 갑자기 “이 주 말에 와 주세요”라는 메시지가 옵니다. 면접 날짜가 확정될 때까지 기다린다면 엔지니어들이 핵심 컴퓨터 공학 개념을 배우고 면접 문제를 연습하는 데 필요한 시간이 거의 없을 것입니다. 그것은 당신을 위험에 빠뜨릴 수 있습니다.

For Interviewers

마지막 판을 쓴 이후로, 많은 면접관들이 Cracking the Coding Interview를 면접을 배우기 위한 도구로 사용하고 있다는 사실을 알게 되었습니다. 그것은 책의 원래 의도는 아니었지만, 면접에 대한 일부 지침을 제공하는 것도 좋을 것 같습니다.

여기서 실제 질문을 직접 묻지 마십시오. 첫째로, 이러한 질문은 면접 준비에 좋은 질문으로 선택되었습니다. 면접 준비에 좋은 질문이 항상 면접에 좋은 것은 아닙니다. 예를 들어 이 책에는 때로는 면접관들이 이러한 유형의 질문을 묻기 때문에 이러한 유형의 뇌 미스터리 질문이 포함되어 있습니다. 이러한 질문을 좋아하는 회사에서 면접을 본다면 후보자는 연습하는 것이 유용합니다. 비록 개인적으로 이러한 질문을 좋아하지 않지만 말이죠. 둘째로, 후보자들도 이 책을 읽고 있습니다. 이미 해결한 질문을 후보자에게 묻고 싶지 않습니다. 이와 유사한 질문을 할 수 있지만, 이 책에서 직접 질문을 선택하지 마십시오. 목표는 후보자의 문제 해결 능력을 테스트하는 것이며, 이들의 암기 능력을 테스트하는 것이 아닙니다. 중간과 어려운 문제를 물어보세요. 이러한 질문의 목표는 누군가의 문제 해결 능력을 평가하는 것입니다. 너무 쉬운 질문을 묻게 되면 성적이 모여버립니다. 미세한 문제들이 후보자의 성적을 크게 낮출 수 있습니다. 이는 신뢰성 있는 지표가 아닙니다. 여러 개의 장애물, 통찰력 또는 최적화를 가진 질문을 찾으세요. 일부 질문은 “아하!” 순간을 갖고 있습니다. 특정 통찰력에 따라 쉽게 성공하거나 실패할 수 있습니다. 만약 후보자가 그 한 부분을 이해하지 못하면 그들은 성적이 나쁠 것입니다. 그것을 얻으면 갑자기 많은 후보자를 앞서갑니다. 비록 그 통찰력이 스킬의 지표일지라도 여전히 그것은 하나의 지표에 불과합니다. 이상적으로는 여러 개의 장애물, 통찰력 또는 최적화를 갖는 질문이 좋습니다. 여러 데이터 포인트가 단일 데이터 포인트보다 낫습니다. 다음 테스트를 해보세요: 후보자의 성능에 상당한 영향을 미칠 힌트나 조언을 제공할 수 있다면, 그것은 아마도 좋은 면접 질문이 아닐 것입니다. 어려운 질문을 사용하되 어려운 지식을 사용하지 마세요. 어떤 면접관들은 질문을 어렵게 만들려고 하면서 그 과정에서 지식을 어렵게 만들기도 합니다. 물론 성적이 정확하게 보이도록 많은 후보자가 잘하지 않을 것이므로 통계가 올바르게 보입니다. 그러나 이러한 이유로 후보자들의 스킬에 대해 많은 것을 알 수 없습니다. 후보자들이 갖고 있어야 할 지식은 기본적인 데이터 구조와 알고리즘 지식이어야 합니다. 컴퓨터 과학 전공자가 큰 O와 트리의 기본을 이해하는 것은 합리적인 것입니다. 대부분은 Dijkstra의 알고리즘이나 AVL 트리의 작동 방식과 같은 세부 사항을 기억하지 않을 것입니다. 면접 질문이 모호한 지식을 기대한다면 다음을 생각해보세요: 이것은 실제로 중요한 스킬인가요? 이것은 스킬의 중요성을 줄이거나 문제 해결 또는 기타 스킬에 집중하는 정도를 줄이고 싶다는 정도로 중요한가요? 평균적으로, 모든 새로운 스킬 또는 특성을 평가하면 제공되는 제안 수가 줄어듭니다. 다른 스킬에 대한 요구 사항을 완화함으로써 이를 상쇄시킬 수 있습니다. 모든 것이 동일하다면 아마도 두 인치 두께의 알고리즘 교과서의 세부 사항을 외우고 있는 사람을 선호할 수 있습니다. 그러나 모든 것이 동일하지 않습니다.

“무서운” 질문을 피하세요. 어떤 질문은 후보자들이 특정한 전문 지식이 필요한 것처럼 느껴질 때 후보자들을 겁내게 만들 수 있습니다. 이러한 질문은 주로 다음과 같은 내용을 다루는 경우에 해당합니다. • 수학 또는 확률. • 저수준 지식 (메모리 할당 등). • 시스템 디자인 또는 확장성. • 자체 시스템 (Google Maps 등). 예를 들어, 가끔 나는 1,000 이하의 모든 양의 정수 해를 찾는 질문을 합니다. 많은 후보자들은 처음에 이 문제를 해결하기 위해 어떤 고급 수학이나 인수 분해가 필요하다고 생각할 수 있습니다. 하지만 실제로 그런 것은 필요하지 않습니다. 이 문제를 해결하려면 지수, 합, 그리고 등호의 개념만 이해하면 됩니다. 이 질문을 할 때, “이것은 수학 문제처럼 들릴 수 있습니다. 걱정하지 마세요. 그렇지 않습니다. 이것은 알고리즘 질문입니다.”라고 명시적으로 말합니다. 후보자가 인수 분해와 같은 방향으로 진행하려고 하면 그들을 멈추고 이것이 수학 문제가 아니라고 다시 상기시킵니다. 다른 질문들은 확률을 약간 포함할 수 있습니다. 이 질문은 후보자가 분명히 알고 있을 것인 내용을 다룰 수 있지만 (예: 다섯 가지 옵션 중 하나를 선택하려면 1에서 5까지의 임의의 숫자를 선택하라), 확률이 포함되어 있기만 하면 후보자들을 겁내게 만들 수 있습니다. 겁나게 들릴 수 있는 질문을 하기 전에 후보자들에게 꼭 알려주어야 합니다. 이 질문이 그들이 생각하는 것처럼 특정한 지식이나 기술을 필요로하지 않는다는 것을 확실히 안내해야 합니다. 이것은 이미 후보자들에게 매우 겁나는 상황입니다. “무서운” 질문을 더하면 후보자를 혼란스럽게 만들고 성적이 낮아질 수 있으므로 주의해야 합니다. “무서운” 질문을 하려면 후보자들에게 실제로 그들이 생각하는 지식이 필요하지 않다는 것을 확실히 안심시켜야 합니다.

긍정적인 강화를 제공하세요. 일부 인터뷰어는 “올바른” 질문에 너무 많은 중점을 두어 자신의 행동을 생각하는 것을 잊어버립니다. 많은 후보자들은 인터뷰에 불안해하며 인터뷰어의 말 한 마디 한 마디를 깊게 읽으려고 합니다. 그들은 어떤 말 한 마디에도 긍정적이거나 부정적일 수 있음을 계속해서 곰곰히 생각합니다. 예를 들어 “행운을 빕니다”라는 작은 댓글이 무엇을 의미하는 것처럼 해석할 수 있습니다. 하지만 그 댓글은 실제로 모든 후보자에게 무엇이든 상관없이 말한 것입니다. 후보자들이 경험, 인터뷰어, 그리고 자신의 성적에 대해 긍정적으로 느끼도록 해야 합니다. 그들이 편안함을 느끼도록 해야 합니다. 긴장한 후보자는 성적이 낮아질 가능성이 있으며, 이는 그들이 좋지 않다는 것을 의미하지 않습니다. 더구나, 좋은 후보자가 인터뷰어나 회사에 부정적인 반응을 보이면 제안을 수락할 가능성이 줄어들고, 그들은 자신의 친구들이 인터뷰를 보거나 제안을 받지 않도록 하기도 할 수 있습니다. 후보자에게 따뜻하고 친근하게 대하려 노력하세요. 이것은 어떤 사람에게는 다른 사람보다 쉽습니다만, 최선을 다해 노력할 수 있습니다. 심지어 따뜻하고 친근하게 대하려는 것이 당신에게 자연스럽지 않더라도 인터뷰 중에 긍정적인 말을 조금씩 뿌릴 노력을 할 수 있습니다: • “맞아요, 정확히 그래요.” • “좋은 포인트에요.” • “잘 했어요.” • “좋아, 그건 정말 흥미로운 접근 방식이에요.” • “완벽해요.” 후보자가 얼마나 성적이 낮더라도 항상 어떤 부분에서 옳은 것이 있습니다. 인터뷰에 긍정적인 요소를 살려내는 방법을 찾아보세요.

행동 기반 질문에서 깊게 파고들어보세요. 많은 후보자들은 자신의 구체적인 성과를 표현하는 데 어려움을 겪습니다. 여러분이 도전적인 상황에 대한 질문을 하면, 그들은 팀이 어려운 상황을 겪었다고 말합니다. 그들이 실제로 많은 일을 하지 않았다고 생각될 수 있습니다. 하지만 너무 빨리 결론을 내리지 마세요. 후보자가 자신에게 집중하지 않을 수도 있습니다. 그들은 자신을 칭찬하거나 자랑하지 않도록 훈련받아왔을 수 있습니다. 특히 리더십 역할을 하는 사람들이나 여성 후보자에게 흔한 일입니다. 후보자가 어떤 상황에서 별다른 일을 하지 않았다고 생각하기 전에, 그들이 어떤 역할을 했는지 구체적으로 물어보세요. 상황을 구체적으로 설명하지 않았다고 해서 그들이 훌륭한 후보가 아니라는 것은 아니며, 그들이 훌륭한 직원이 아닐 수도 있습니다. 좋은 인터뷰 후보가 되는 것은 자체적인 기술입니다(이 책이 존재하는 이유 중 하나이기도 합니다), 그리고 이를 평가하고 싶지 않을 것입니다.

지원자들을 지도하세요. 지원자들이 어떻게 좋은 알고리즘을 개발할 수 있는지에 대한 섹션을 읽어보세요. 이러한 팁 중 많은 것들은 어려움을 겪는 지원자들에게 제공할 수 있는 것들입니다. 이를 통해 당신은 “시험 공부를 가르치는” 것이 아니라, 인터뷰 스킬과 직무 스킬을 분리하고 있습니다. • 많은 지원자들은 인터뷰 질문을 해결할 때 예제를 사용하지 않거나(또는 좋은 예제를 사용하지 않음) 사용하지 않습니다. 이로 인해 해결 방법을 개발하는 것이 상당히 어려워집니다. 그러나 이것은 그들이 좋은 문제 해결자가 아니라는 것을 의미하지는 않습니다. 후보자가 직접 예제를 작성하지 않거나, 우연히 특수한 경우를 작성했다면 그들을 안내하세요. • 일부 지원자들은 버그를 찾는 데 시간이 오래 걸리는데, 이는 그들이 코드를 개념적으로 분석하는 것이 더 효율적일 것을 깨닫지 못했거나 작은 예제가 거의 동일하게 작동할 것이라고 인식하지 못했기 때문입니다. 그들을 안내하세요. 만약 그들이 최적의 솔루션을 찾지 못했다면, 알고리즘에 중점을 두도록 도와주세요. 그들이 실제로 그렇게 할 시간이 없었다면, 그들이 “절대 최적의 솔루션을 찾지 못했다”고 말하는 것은 공평하지 않습니다. • • 만약 그들이 실수를 할만한 곳이 명확하게 있는데, 긴장하고 막혀서 어떻게 해야 할지 모르는 경우, 그들에게 무차별 대입 솔루션을 따라가며 최적화할 부분을 찾도록 제안하세요. 만약 그들이 아무 말도 하지 않고 꽤 명백한 무차별 대입이 있는 경우, 그들에게 무차별 대입으로 시작할 수 있다고 상기시켜주세요. 그들의 첫 번째 솔루션이 완벽하지 않아도 괜찮습니다. 하나 이러한 영역 중 하나에서 후보자의 능력이 중요한 요소라고 생각하더라도, 이것은 그들의 역량을 평가하는 데 유일한 요소가 아닙니다. 항상 후보자가 이러한 문제를 해결하는 데 실패했다고 표시할 수 있지만 동시에 그들을 이것을 안내하여 이것을 극복할 수 있도록 도와주세요. 이 책은 지원자들을 인터뷰를 통해 지도하는 데 도움이 되지만, 당신의 역할 중 하나는 준비하지 않은 영향을 줄이는 것입니다. 물론, 일부 지원자들은 인터뷰를 위해 공부하고 일부는 그렇지 않을 것이며, 이는 그들의 엔지니어로서의 역량에 대해 많이 드러내지 않을 것입니다. 이 책의 팁을 사용하여 지원자들을 지도하세요 (물론 합리적으로 - 지나치게 문제를 풀기 위해 지원자들을 지도하면 문제 해결 능력을 평가하지 않게 될 수 있습니다). 하지만 주의하세요. 지원자들에게 위협적으로 보이는 경우, 이러한 지도가 오히려 상황을 악화시킬 수 있으며, 후보자들에게 나쁜 예제를 만들거나 올바른 방식으로 테스트를 우선 순위로 두지 않는다는 메시지로 받아들일 수 있습니다. 만약 후보자가 고요한 시간이 필요하다면 그 시간을 제공하세요. 지원자들이 고요한 시간을 갖기 위해 외치는 인터뷰어와 대화하기를 원하지 않는다면 그들에게 고요한 시간을 주세요. “내가 막혀서 어떻게 해야 할지 모르겠다”와 “고요한 시간에 생각하고 있어”를 구별하는 법을 배우세요. 지원자가 이를 필요로 한다면 고요한 시간을 주세요. 그들에게 생각할 시간을 제공하고, 그들을 평가할 때 이들이 다른 지원자들보다 더 적은 지도를 받았다는 것을 고려하세요.

지원자를 평가할 때 네 가지 모드를 고려하세요: 상식 검사, 품질 검사, 전문가 질문 및 프록시 지식. • 상식 검사: 이러한 질문은 종종 쉬운 문제 해결이나 설계 질문입니다. 문제 해결 능력의 최소한의 수준을 평가합니다. 이러한 질문은 “괜찮은”과 “훌륭한”을 구별하지 않으므로 이렇게 평가하지 마세요. 이러한 질문은 프로세스 초반에 사용할 수 있습니다 (최악의 후보자를 걸러내기 위해) 또는 최소한의 능력이 필요할 때 사용할 수 있습니다. • 품질 검사: 이러한 질문은 더 어려운 문제 해결이나 설계 질문으로, 후보자를 진정으로 생각하게 만들도록 설계되었습니다. 알고리즘 및 문제 해결 기술이 중요한 경우에 사용하세요. 여기서 가장 큰 실수는 사실 좋지 않은 문제 해결 질문을 하는 것입니다. • 전문가 질문: 이러한 질문은 Java 또는 기계 학습과 같은 특정 주제에 대한 지식을 테스트합니다. 직장에서 빠르게 배울 수 없는 능력에 대한 기술을 검사해야 합니다. 이러한 질문은 진정한 전문가를 위해 적합해야 합니다. 불행하게도 10주간의 코딩 부트캠프를 마친 후보자에게 Java에 대한 상세한 질문을 하는 상황을 본 적이 있습니다. 이것은 무엇을 나타냅니까? 그녀가 이러한 지식을 갖고 있다면, 그런 지식을 최근에 습득했을 가능성이 높으며, 따라서 쉽게 습득할 수 있을 것입니다. 쉽게 습득할 수 있다면 고용할 이유가 없습니다. • 프록시 지식: 이것은 전문가 수준이 아니지만 후보자가 그들의 수준에서 알아야 할 지식입니다. 예를 들어 후보자가 CSS 또는 HTML에 대해 알고 있어도 그리 중요하지 않을 수 있습니다. 그러나 후보자가 이러한 기술을 깊이 이해하고 표 그리고 그것이 좋은지 아닌지에 대해 이야기하지 못한다면 이것은 문제가 있다는 것을 시사합니다. 그들은 그들의 직무에 핵심적인 정보를 습득하지 못하고 있습니다. 기업이 문제에 빠지는 경우는 이러한 것을 혼합하거나 매칭하는 경우입니다: • 전문가가 아닌 사람들에게 전문가 질문을합니다. • 전문가가 필요하지 않은 전문가 역할을 고용합니다. • 전문가가 필요하지만 매우 기본적인 기술만 평가하고 있습니다. • 상식 검사 (쉬운) 질문을 하지만 품질 검사 질문을 하고 있다고 생각합니다. 따라서 아주 작은 세부 사항이 이들을 분리했을 수 있음에도 불구하고 “괜찮음”과 “훌륭함” 사이에 강한 차이를 해석합니다. 사실, 제가 다양한 소규모 및 대규모 기술 회사와 협력하여 그들의 채용 프로세스를 개선한 경험을 통해 대부분의 기업이 이 중 하나를 잘못하고 있다는 것을 발견했습니다.