SW 엔지니어링 인터뷰가 왜 어려운가요 (연구 인터뷰와 비교)? [닫은]

첫째, 나에 대한 배경. CS에서 박사 학위를 받았으며 소프트웨어 엔지니어와 R & D 연구 과학자로 근무했습니다. 나는 최근에 직장을 바꾸고 두 가지 직책에 대해 인터뷰를했다 (과거에 한 것처럼).

저의 관찰 : SW 엔지니어의 면접은 CS 연구원 면접보다 훨씬 어렵습니다. 그러나 연구원의 직무는 임금이 높고 경쟁이 치열하며 보람이 많으며 흥미롭고 거꾸로 있습니다.

연구원의 일반적인 인터뷰 루프는 다음과 같습니다.

• 내 연구가 연구실의 연구와 일치하는지 확인하기위한 전화 인터뷰
• 직접 : 최근 1 시간 동안 (9 개월 분량의 일을 할 수 있음) 조사한 내용을 발표하고 청중의 질문에 답변
• 약 5 명의 연구원과의 일대일 인터뷰 : 기술 질문, 관련 작업에 적합한 작업, 작업을 확장 할 수있는 방법 등 내 작업 / 게시물 / 특허에 대해 매우 합리적인 질문을합니다. 새로운 지역

SW 엔지니어를위한 일반적인 인터뷰 루프는 다음과 같습니다.

• 알고리즘 질문을 받았으며 코딩이 필요한 전화 인터뷰. 꽤 표준입니다.
• 화이트 보드에서 난해한 C ++ Minutia (예 : 다형성 가상 함수 호출 작동 방식), 알고리즘 (1B 정점에 대해 모든 쌍 최단 경로 알고리즘 작동)에 대해 F ***를 드릴하는 인터뷰 시스템 설계 (데이터베이스로드 밸런서 설계) 등 6 ~ 7 번의 인터뷰가 진행됩니다. 어리석은.

왜 누군가가 이것을 기꺼이 견딜 것입니까? C ++ 퀴즈에 대해 묻거나 자신을 증명하는 코드를 작성하는 요점은 무엇입니까? SE 인터뷰를 연구원의 인터뷰와 같은 방식으로 수행하여 수행 한 작업에 대해 이야기하십시오.

물리, 화학, 토목, 기계 공학과 같은 다른 분야에 대한 기술 면접은 어떻습니까?

연구를 수행 할만큼 기술적으로 유능한 지 여부를 확인하는 것은 상대적으로 쉽습니다. 채용 관리자가 읽을 수있는 출판물이 있고 해당 출판물은 아마도 당신과 대화를 나눌 수있는 다른 사람들을 암시 할 것입니다.

반면에, 소프트웨어 엔지니어링은 실력이 부족한 공간 낭비로 가득 차서 많은 실사를해야하므로 고용하는 사람이 실제로 고용 할 코드를 작성할 수 있도록해야합니다.

여기 사지에 나가

박사 학위를 보유한 연구원으로서 이미 다수의 인정 된 조직이 연구원으로서 귀하의 가치와 최소 자질을 입증했습니다. 동료위원회 앞에서 논문을 성공적으로 변호했으며 적어도 한 명의 동료 검토 간행물로 작품을 게시하도록 설득했습니다.

반면에 소프트웨어 개발에는 자격 기준이 없습니다. 사람들은 일상적으로 지식 기반을 과도하게 팽창시킵니다. 결과적으로 소프트웨어 개발 인터뷰는 PhD 방어 및 동료 검토가 학계에서 수행하는 모든 작업을 수행해야합니다. 그들은 당신이 당신이 말하는 것을 정말로 알고 있음을 증명합니다.

이것을 잠시 고려하십시오.

이 CS 연구원 직업을 신청하려고하면 이력서 / 이력서가 보이지 않습니다. 나는 처음에 인터뷰를하지 않을 것입니다. 본인의 이력서를 살펴볼 자격이 없다는 표준화 된 "고급 학위 없음"서한을 받았습니다.

내 질문은 다음과 같습니다. "왜 박사 학위를받는 것이 어려운가요?" "CS 연구원이 되려면 왜 박사가 필요합니까?" "왜 장벽과 장애물이 많은가?"

왜 누군가가 이것을 기꺼이 견딜 것입니까?

모든 코스 작업을 수행하고 저널 및 컨퍼런스에서 연구를 인쇄하는 요점은 무엇입니까? 엔지니어링에 대한 것보다 연구 만하고 더 많은 돈을받을 수없는 이유는 무엇입니까?

자격 증명을 설정하기 위해 왜 대학원과 출판물에 의존합니까? 인터뷰하는 동안 지금 당장 기억할 수있는 모든 것에 달려있는 SE 인터뷰와 같은 리서치 인터뷰를 만들어보십시오.

글쎄, 나는 이론이있다. 연구는 일반적으로 보조금으로 지급되므로 현금 공급이 높습니다. 그들은 돈을 버는 돈을 가지고 있으며, 돈을 쓸 사람을 찾아야합니다. 실제로 그 위치에서 무엇을 달성하든 아니든, 회사 / 기관은 어쨌든 회계 비용이기 때문에 순 손실을 기록하지 않습니다. 잘못된 사람을 고용 할 위험이 거의 없습니다. 최악의 시나리오는 그들이 한 모든 것을 버리는 것입니다.

반면, 기존 제품의 성공 또는 실패는 일상 개발자의 어깨에 달려 있습니다. 특히 제품 개발을하고 있다면 회사의 수익 센터입니다. 좋고 나쁜 개발자는 월급보다 훨씬 큰 영향을 미칩니다. 나쁜 개발자는 실제로 손상을 일으 킵니다. 그들은 팀, 제품 출시 등을 되돌릴 수 있습니다. 나쁜 SW 엔지니어를 고용 한 결과는 훨씬 더 높습니다.

우리 회사는 또한 "많은 어려운 질문을합니다"그리고 나는 그 이유를 설명 할 것입니다. 우리는 가상 함수 호출이 어떻게 수행되는지 실제로 알고 있는지 여부를 관리하지만 수행하려는 작업에 매우 중요하기 때문에 아닙니다.

대신 기초 지식을 얼마나 빨리 배울 수 있는지 알아야하므로주의를 기울입니다. X 년의 경험을 주장하십니까? 알다시피, 우리는 당신이 확실한 지식을 가지고 있는지 찾기 위해 어려운 질문을 할 것입니다.

가상 함수 호출이 어떻게 수행되는지는 모르지만 프로파일 링 및 최적화에 대한 모든 것을 알고 있습니까? 한 분야에서 확실한 지식을 얻었으므로 다른 분야에서도 확실한 지식을 얻게 될 것입니다.

X 년의 경험으로 "C ++ 코드 개발, 디버깅 및 수정"을 주장했으며 포인터가 객체를 가리키는 방법을 평범한 단어로 설명 할 수 없습니까? 죄송합니다. 직원을 채용 할 수 없습니다. 그렇게 할 수없는 경우 복잡한 기술 결정을 내려야 할 때 더 어려운 문제를 어떻게 설명 하시겠습니까?

짧은 대답 : 시장에 프로그래밍을 알고 있다고 주장하지만 프로그래밍 할 수없는 사람들이 많이 있습니다.

사이드 비고 : 아무도 FizzBuzz 에세이 링크를 게시 한 사람이 없다는 사실에 놀랐습니다 .

나는 다른 길을 가고 소프트웨어 엔지니어링 인터뷰가 본질적으로 어려울 정도로 문제가 아니라 오히려 다른 분야가 인터뷰 스타일로 보이는 다른 것을 찾고 있다고 말할 것입니다.

저는 상당히 광범위한 분야 (예 : 신생 회사, 소규모 회사, 대기업, 내부 IT 부서, 소프트웨어 회사, 연구 조직)에서 인터뷰를했으며 모두 내가 보통 다른 방식으로 인터뷰하는 방식을 가지고 있습니다. 다음 패턴을 따르십시오.

• 신생 기업은 지금 코드 작성을 시작할 수 있고 빠르게 진행되는 환경을 처리 할 수 있다는 사실을 알고 싶어 합니다. 따라서, 그들은 "핵심"지식으로 간주되는 것을 찾는데 많은 시간을 소비하는 것을보고 싶지 않기 때문에 당신이 당신의 머리 위로 얼마나 많이 알고 있는지에 관심을 갖는 경향이 있습니다. 그들이 당신이 알고있는 것으로 예상된다면이 환경에서 무언가를 모른다는 것을 인정하는 것은 그렇게 좋은 것이 아닐 수도 있습니다.
• 소규모 회사는 사용자가 아는 것과 관련하여 신생 기업과 동일한 것을 찾는 경향이 있지만, 빠른 속도의 환경 (작업에 따라 다름)을 얼마나 잘 처리하는지, 어떤 종류의 소프트 기술에 더 관심이 있는지는 중요하지 않습니다. 회사와 잘 어울리도록
• 대기업과 내부 IT 부서는 주어진 표준 기술 지식을 확보하는 데 더 관심이있는 것처럼 보이지만, 일부 기술이있을 것으로 예상되므로 모든 정보를 알지 못한다면 걱정하지 않아도됩니다. 회사가 기대하는 것에 대한 훈련을받는 데 소요되는 시간. 따라서 이것은 당신이 무언가를 모르지만 배우고 기꺼이 배우는 것이 유익하다고 볼 수있는 환경입니다.
• 연구 환경 (예 : 내 경험에있는 과학자를위한 소프트웨어 개발 지원)에서는 소프트웨어를 작성할 수 있는지에 대해 관심을 갖는 경향이 있지만, 자신이하는 것을 배우기 위해 필요한 것을 기꺼이 수행하려는 경우 문제를 해결하려고 할 때 손을 잡을 필요는 없습니다. 또한 연구 환경이기 때문에 새로운 것을 배우는 데 관심이있는 것으로 보입니다.

이제는 소프트웨어 회사 (예 : Google, Microsoft)가 자신의 일을하는 경향이 있으며 회사의 성숙도와 인터뷰 대상 그룹에 따라 다른 것을 찾고 있다고 언급하지 않았습니다.

인생의 대부분의 경우와 마찬가지로 하루가 끝나면 모든 것이 달려 있습니다. 개인적으로 저는 일부 회사들이 "책 지식"에 매우 중점을 두는 것을 발견했습니다. "도서 지식"은 다른 회사들이 당신이 더 높은 수준의 문제를 얼마나 잘 처리하는지에 대해 매우 우려하는 것처럼 높은 수준의 문제를 실제로 해결할 수있는 비용을 초래할 수 있음을 발견했습니다 (즉, x에 대한 스키마를 설계 할 수 있으며) 생산성을 높이기 전에 3 개월에서 6 개월을 투자하여 최대한의 속도를 낼 수 있다는 가정하에 운영하십시오.

다시 기술 인터뷰는 임의적이고 변덕입니다.

사소한 사람을 그릴 때와 CS를 알고 있는지를 보는 것에는 큰 차이가 있습니다. 위에서 말했듯이 C ++에 대한 10 년 이상의 경험이 있지만 OOP / 상속성 문제를 폭파하는 경향이 있습니다. 왜? 템플릿에 대한 지원이 추가되었으므로 C ++을 거의 독점적으로 Generic Programming에 사용했습니다 .

I는 베이 지역 및 시애틀에서 여러 BigHouseHoldNameTech 회사와 인터뷰, 그리고 최고의 인터뷰 중 하나가 관여 한 실제 데이터 구조와 알고리즘을 [관련, 그들은 직장에서 다루는 했어 질문에 예 : 당신은 3000 억 개 데이터 포인트를 XYZ로 구성됩니다. 효율적으로 저장하고 검색하는 방법은 무엇입니까? ].

이를 통해 응시자가 어떻게 개입 하고 실제 문제를 해결할 수 있는지 알 수 있습니다 . 절대 더 나쁜 다른 BigHouseHoldNameTech 회사와도했지만, 그들은 매우 난해한 질문의 시간 가치를 묻는 당신은 정말 그냥 수동 [에서 찾아 볼 에게서는 그 즉 리눅스 대 윈도우에있는 PCB의 주요 차이점을 설명 - 그리고이 얻지 못한 ' 커널 레벨 위치의 경우 t ]

헤지 펀드는 고문의 의도로 기괴한 일입니다 . 화이트 보드에서 배낭 유형 문제를 해결하는 데 8 시간이 걸릴 것으로 예상 됩니다.

저는이 분야에서 20 년이 넘는 소프트웨어 개발자 (c / c ++)입니다. 우리가 일상적으로 보는 인터뷰 유형 (브레인 티저, 데이터 구조 구현, 화이트 보드에서 검색 알고리즘 등)은 신입생을 제외하고는 많이 사용되지 않았습니다. 어떤 사람이 평판 좋은 회사에서 합리적인 시간 동안 일했다면 그것은 코드 작성 능력의 증거로 간주되었습니다. 이제는 매우 교활 해졌고 왜 그런지 잘 모르겠습니다. 실제로, 그들이 코드를 요구하는 전형적인 것들, 암기 될 수 있습니다. 그래서 화이트 보드에서 그것을하는 것은 실제로 아무 것도 증명하지 못합니다. 작업 프로젝트에서는 인터넷을 사용하여 무언가를 조사하고 처음부터 btree 또는 링크 된 목록을 작성하지 않을 것입니다.

나는 스크럼과 마찬가지로 또 다른 관리 유행이 구글, 아마존, 마이크로 소프트에 의해 시작될 것이라고 생각한다. 다른 사람들은 Jack Welch의 직책과 같이 복사하고 GE를 기억합니까?

내 의견을 읽고있는 채용 관리자 인 경우, 후보자에게 특정 문제를 해결하는 방법은 무엇입니까? 해시 테이블을 코딩하도록 요청하는 대신 해시 테이블과 관련된 문제를 해결하고 해결 방법을 묻습니다.

또한이 게시물 위의 개발자가 "회사가 해결해야하는 실제 문제를 줘"라고 동의합니다.

"하지만 OOP / 상속성 문제를 폭파하는 경향이 있습니다. 왜? 템플릿에 대한 지원이 추가되면 C ++을 거의 독점적으로 Generic Programming에 사용했습니다."

또한 위의 내용에 동의합니다. 회사에서 일할 때는 THEIR 방식으로 코드를 작성하십시오. 나는 15 년 동안 일한 회사의 수석 건축가가 참조가 아닌 포인터를 사용하는 것을 선호했기 때문에 여전히 내 머리 꼭대기에서 참조 구문으로 C ++ 호출을 기억하는 데 어려움을 겪고 있습니다. 그는 당신이 보는 오래된 C 프로그래머였습니다. 그래서 우리 모두가 사용한 것입니다.