[번역] 비개발자 출신이 개발자를 인터뷰하는 방법
No Technical ,How To Interview Engineers
https://www.greghausheer.com/articles/how-to-interview-engineers-when-youre-not-technical
(요약정리 참고 사이트 https://news.hada.io/topic?id=1885&utm_source=weekly&utm_medium=email&utm_campaign=202016)
https://fullscale.io/wp-content/uploads/2019/10/full-scale-blog-web-developer-interview-questions.jp엔지니어를 고용하고 있지만 기본 기술 능력을 평가할 수 없는 경우에 과연 어떻게 할 건가 고민 입니다. 그 기본 중에 기본은 그 사람의 캐릭터 및 개발 프로세스에 대해 문의하십시오.
창업자와 함께하는 가장 일반적인 고용 문제는 기술 공동 창립자, CTO 또는 최초 엔지니어를 찾는 것입니다. 채용은 이미 충분히 어렵다. 그리고 당신이 기술적이지 않다면, 최고의 인재를 모집하려는 다른 창립자들의 끝없는 공급과 경쟁하고 있습니다. 어떻게 든지 눈에 띄어야 합니다. 당신의 생각만으로는 충분하지 않습니다.
그것은 A 등급의 훌륭한 개발자가 될 수있는 좋은 시간입니다.
그러나 고용 문제를 복잡하게 만드는 것은 기술 인재를 평가 한 경험이 없다는 것입니다. 문화, 태도, 선별을 통해 과거 고용주로부터 정보를 얻을 수 있습니다. 그러나 후보자가 실제로 소프트웨어 엔지니어링에 능숙한 지 알 방법이 없습니다 .
찾고있는 개발자 유형에 관계없이 비 기술적 설립자가 후보자를 인터뷰 할 때 사용할 수있는 질문 목록을 만들었습니다. 그러나 코딩 과제 나 화이트 보드 연습은 아닙니다. 그것들은 실제로 작동하지 않습니다. 왜냐하면 나는 다른 시간을 탐구 할 것입니다. 대신 이것들은 소프트웨어 프로세스, 경험 및 판단 기반 질문입니다. 엔지니어의 성숙도와 건전한 SDLC 프로세스를 생성 할 수있는 능력을 측정하고 제공 할 수있는 코딩 퍼즐보다 장기적인 성공을 예측할 수 있습니다.
내가 왜 이것을 썼습니까?
Lightmatter 의 공동 창립자로서 저는 지난 6 년간 엔지니어링 인재를 모집하고 유지하기 위해 노력해온 회사와 기업가를 보았습니다.
실수는 양쪽에서 이루어집니다. 인터뷰에서 주니어 개발자는 종종 자신이 할 수있는 일을 과장하고 있으며 초기 창업자는 누군가를 녹색으로 고용하는 실수를 저지를 수 없습니다. 그리고 비 기술적 인 창립자들도 인터뷰 할 때 잘못된 질문을합니다. 경험이 풍부한 개발자는 자신이“기술적으로 충분”하다고 생각하는 설립자가 시간을 낭비하고 싶어하지 않습니다. 엔지니어링 리더십과 멘토링이 부족하면 스타트 업의 고용 능력이 저하 될 수 있습니다.
올바른 질문을하는 법을 배우면 소프트웨어와 전반적인 개발자 문화에 대해 스스로 교육 할 수있는 시간을 가졌다는 것을 알게됩니다. 그런 다음 귀 기울일 올바른 답변을 알게됩니다.
다음은 내가 물어볼 인터뷰 내용입니다.
1. 귀하가 참여했던 이전 소프트웨어 팀의 규모는 어느 정도입니까? 가장 큰 규모와 가장 작은 규모는 어느정도 였나요?
첫 번째 개발자를 고용 할 때는 모두 하나의 질문으로 이어집니다. 어플리케이션 앱의 첫 번째 빌드로 달성하려는 것은 무엇입니까? 처음에는 프로토 타입 일 뿐이며 나중에 버리고 다른 프로그래밍 언어로 다시 작성할 수 있습니까? 또는 이미 아이디어를 테스트했으며 이제 실행할 때가 되었으므로 처음으로 기술 플랫폼을 확보해야합니까?
첫 번째 옵션 인 경우 이전에 솔로로만 일한 엔지니어와 함께 고용하십시오 (또는 더 좋은 방법으로 계약을 체결하십시오). 테스트 범위, 적절한 코드 버전 제어 또는 지나치게 철저한 QA 수행과 같은 문제에 대해 걱정하지 않아도됩니다. 다른 엔지니어의 작업에 대해 걱정할 필요가 없으며 배송 코드에만 집중할 수 있습니다.
그리고 당신을 위해 재미, 그들이 당신이 요구하는 일을 할 자격이 있다고 보장하지 않습니다. 바라건대 친구를 통해 찾거나 이전에 함께 일한 적이 있지만 올바른 도구를 사용하거나 올바르게 작성했는지 확실하지 않습니다. 단점입니다.
그러나 올바른 코드를 찾으면 짧은 시간에 엄청난 양의 코드를 제공 할 수 있습니다. 그것은이 반드시 아니다 점에 유의하는 것이 중요합니다 부족 그렇게 빨리 작업에 솔로 엔지니어 수 있습니다 팀의 경험은. 단기적으로 프로젝트 속도를 늦추고 다른 사람을 위해 프로그래밍해야 할 부담이없는 것보다 소프트웨어의 협업 측면을 무시할 수있는 자유가 더 많습니다. 프로그래밍에서 코드를 작성하는 것보다 (다른 사람의) 코드를 읽기가 어렵다는 오래된 말이 있습니다.
두 번째 옵션 인 경우 실제 엔지니어링 팀에 경험이있는 개발자를 고용하십시오. 그리고 네, 그것은 단지 두 팀으로 구성됩니다. 다른 사람이 코드를 작성하는 순간 개발자는 프로세스 문제를 겪습니다.
아직 다른 사람이 없어도 버전 관리 및 지점 관리의 중요성을 알 수 있습니다. 제품 백 로그를 정리하고 특정 기술 결정의 장단점을 평가하는 데 시간을 소비합니다. 호스팅에 어떤 클라우드 공급자를 사용해야합니까? Ruby 또는 Node 대신 Python을 선택하는 이유는 무엇입니까? 배포로 인해 자체 테스트 적용 범위가 줄어들면 화를 내며 코드에 주석과 많은 문서를 남길 수 있습니다. 그들은 다른 엔지니어들이 놀랍도록 빠른 속도로 참여하고 기여할 수있는 제품을 당신과 함께 만들고 있습니다.
2. 30 명 이상의 엔지니어와 같은 대기업에서 근무한 경우 스프린트 전체에서 팀이 어떻게 분할했으며, 작업에 대한 위임과 스프린터는 어떻게 관리되었나요? 그 회사의 프로세스에 대해 좋았던 점과 싫었던 점은 무엇인가요?
팀 경험이 풍부한 엔지니어와 채팅하는 경우 회사 내의 다른 엔지니어링 그룹 중 소규모 3-5 인 팀에 속할 가능성이 있습니다. 한 팀은 데이터베이스 팀일 수 있습니다. 다른 하나는 모바일 앱을 담당합니다. 보안을위한 또 다른 하나는 프런트 엔드를위한 것일 수도 있습니다.
그렇다면 좋은 신호입니다. 많은 팀이 각자 고유의 코드를 작성하고 통합 및 릴리스함으로써 소프트웨어 프로젝트 관리에 대한 감각이 있습니다. 그들에게 더 큰 회사에서 팀이 어떻게 기능했는지 물어보십시오. 애자일, 칸반 또는 스크럼을 사용 했습니까? 스프린트 얼마나 되었습니까?
응시자는 핵심 응용 프로그램 논리에 인접한 소프트웨어 인프라에 대한 경험이있을 것입니다. 이 인프라는 개발 프로세스를 원활하게 실행하는 데 필요합니다. 지속적인 통합 및 배포 파이프 라인 또는 테스트 범위를 측정하기위한 테스트 스위트와 같은 구성 요소입니다. 그것들은 팀이 좋은 작업을 수행 할 수 있도록하는 도구 및 구성이며, 문제가 발생했을 때 인생을 더 쉽게 디버그 할 수있는 기술 기반입니다.
훌륭한 인프라 게임을하는 것은 회사가 이와 같은 엔지니어링 문화를 우선시 할 때 강력한 채용 도구입니다. 엔지니어는 멋진 것을 만드는 다른 사람들과 함께 일하기를 원합니다. 그렇게 간단합니다. 소프트웨어 프로세스를 최상으로 유지하는 것이 바로이를 입증하는 방법입니다.
전반적으로 팀 관리에 대해 말할 때 옳고 그른 대답은 없습니다. 응시자를들을 기회가 더 많습니다. 이전 회사에 프로세스가 있었지만 후보자가 프로세스를 무시하기로 선택한 경우 유일한 위험 신호가됩니다.
3. 이전 회사의 소프트웨어 개발일정에 대한 예측은 어떻게 진행했나요? 또 그것이 얼만 정확한지에 대해서 어떻게 평가 했습니까?
소프트웨어 엔지니어링의 일반적인 고정 관념은 프로젝트가 항상 뒤처져 있다는 것입니다. 시작시 지연은 몇 주에서 한 달이 걸릴 수 있습니다. 엔터프라이즈 수준에서는 몇 년이 걸릴 수 있습니다. 이것은 몇 가지 이유로 발생합니다.
엔지니어는 낙관적입니다. 우리는 문제 해결사입니다. 코드로 무엇이든 고칠 수 있습니다 . 이를 통해 우리의 추정치도 낙관적입니다. 지속적으로 범위를 변경하는 강력한 관리자와 결합 된 이러한 열망은 치명적인 조합입니다.
늦은 프로젝트는 Brooks Law와 같은 규칙이 존재하는 엔지니어링 문화의 일부입니다. 이미 늦은 프로젝트에 더 많은 엔지니어를 추가하면 더 늦게됩니다. 세계 최고의 컴퓨터 과학자들이 소프트웨어 추정 및 타임 라인을 연구했으며이를 계획하는 방법에 대한 정답은 없습니다.
엔지니어는 일반적으로 지연에 대한 책임을 져야하지만 결코 흑백이 아닙니다. 타임 라인을 추정하는 것은 본질적으로 복잡한 작업입니다. 내가 전문적으로 한 가장 어려운 일입니다. 관리자가 비현실적인 기대를하거나 지나치게 정확한 견적을 요구할 때, 적의가 생길 수 있습니다.
관리자와 비 기술적 창립자들이 6 개월 이상 걸릴 것으로 예상되는 프로젝트에 대한 시간당 견적을 요구하는 것을 보았습니다. 어떻게 현실적으로 그것을 요청할 수 있습니까?
절대 안돼. 아니요 괜찮습니다. 저 창업자가되지 마십시오. 당신의 팀에게 그렇게하지 마십시오. 엔지니어를 종료시키는 가장 빠른 방법입니다. 아무도 시간과 같은 프로젝트의 모든 작업을 추정 할 수 없습니다. 2 주간의 프로젝트조차도 어렵습니다.
엔지니어가 몇 가지 기능에 대한 견적을 작성하거나 일련의 사본 업데이트를 생성 할 수 있지만 예상 시간이 1 시간으로 단축되지는 않습니다. 최소한 반나절 정도 의 변화를 생각하십시오 . 그러나 "4 시간"및 "8 시간"이라는 단어는 사용하지 마십시오. 반나절과 하루를 사용하십시오. 그렇지 않으면 몇 시간 안에 일을 생각할 수 있습니다.
인터뷰중인 엔지니어가 회사에서 시간별 견적을 받았다고 언급 한 경우 이전에 CTO가 아니라면 해당 엔지니어의 잘못이 아닐 수 있습니다. 그리고 괜찮습니다. 그들에게 영웅이되어 주제가 떠오를 때 더 큰 시간 블록으로 작업 범위를 좁히는 것이 편하다고 언급하십시오.
더 큰 청크에서 작업하거나 포인트 추적 시스템을 사용한 경험이 있다면 정확성에 대해 문의하십시오. 그들에게 성공을 공유 할 수있는 기회를 제공하고 추정 실수에 겸손을 표현하십시오. 엔지니어가이 두 가지 상황에 대해 긍정적으로 이야기 할 수 있다는 것은 좋은 신호입니다.
전반적으로, 응시자는 실제로 일정대로 정확한지 평가하는 것이 아니라 소프트웨어의 범위를 정하고 평가하는 프로세스가있는 팀에서 일하는 것이 더 중요합니다.
4. 관리자와 관련하여 어떤 문제에 직면 했습니까? “Second-System” (기존 시스템 재개발) 문제가 있는 회사에서 일을 진행해 본 적이 있나요?
엔지니어링에는 개발자, 프로젝트 관리자 및 임원이 실수로 믿을 수있는 또 다른 패턴이 있습니다. 기존 플랫폼으로는 충분하지 않습니다. 교체가 필요하며, 대단한 방식으로 모든 소프트웨어 문제를 해결합니다. 이 '제 2 시스템'은 일반적으로 일단 구축 된 후에는 제공되지 않으며 실제로는 첫 번째 시스템보다 더 복잡하고 더 나쁩니다.
동료들이 "우리는 처음부터 더 좋고 빠르며 우아하게 앱을 재 구축하고있다"고 말합니다. 또 다른 하나는 "만약 [새롭고 반짝이는 프로그래밍 프레임 워크, 언어 또는 데이터베이스를 삽입 할 수 있다면 ] 앱의 성능이 10 배 향상되고 이탈률이 낮아 성장 목표를 달성 할 수있을 것입니다."
이것을 조심하십시오. 설립자로서 모든 프로젝트에서 작업을 수행하기 위해 새로운 도구 나 프레임 워크가 필요하다고 생각하지 않도록하십시오. 스프레드 시트와 이메일을 사용하여 구축 한 7 개의 숫자로 수익을 올린 수익성있는 회사의 설립자를 만났습니다. 제로 코드 회사.
후보자와 관리자에게 경험 한 좋고 나쁜 상황에 대해 물어보십시오. 그들이 소프트웨어의 죽음의 행진에 있었는지 또는 두 번째 시스템 사건을 목격했는지 물어보십시오. 스코프 크립은 어떻습니까? 그들은 어떻게 반응 했습니까?
이 질문들은 어려운 상황에서 어떻게 반응 하는지를 강조합니다. 그들이 그만 뒀습니까? 그래서 그들이 당신과 인터뷰하고있는 이유입니까? 그들은 그것을 통과 했습니까?
면접관으로서 엔지니어가 소프트웨어 팀의 범위를 정하고 이끌 수 있는 능력을 평가할 수 있는 순간입니다 . 마감일을 맞지 않는 것에 대한 것보다 기대나 제품 선택에 비현실적인 것에 대해 더 걱정할 것입니다.
5. 오픈 소스 프로젝트에 기여하고 있는 부분이 있습니까? 그렇다면 어떤 것이며 왜 참여하게 되었나요? 어떤 라이브러리와 개발 도구를 자주 사용하십니까?
오픈 소스 소프트웨어에 대해 알고있는 창립자에게는 매우 중요합니다. 사실, 앱으로 대부분의 앱을 구축 할 가능성이 높기 때문에 매우 중요합니다. 이것이 기술적이지 않은 설립 자라는 것은 당신에게 분명하지 않을 수도 있지만, 높은 수준에서는 다른 사람들이 작성하고 라이센스를 부여 받았으며 인터넷상의 모든 사람이 무료로 적합하다고 생각하는 경우 사용할 수있는 코드입니다.
후보자가 오픈 소스 프로젝트를 수행 한 것은 중요하지 않습니다. 보너스로 생각하십시오. 오픈 소스 코드베이스를 개발하거나 유지 관리하는 데는 많은 자유 시간이 필요하며 고맙게 여겨 질 수 있습니다. 거의 지불하지 않았습니다.
여기서 중요한 것은 응시자가 오픈 소스 도구 및 프레임 워크에 대한 실무 지식을 갖추고 있으며 자유롭게 사용할 수있는 오픈 소스 소프트웨어를 사용하여 기능을 완전히 사용자 정의하는시기를 알 수 있다는 것입니다.
사용자가 구축하는 내용에 따라 사용자가 로그인 및 로그 아웃해야하는 경우 엔지니어가 자체 사용자 지정 인증 시스템을 개발하지 않아야합니다. 또는 앱에 캘린더 또는 일정 기능이 필요한 경우 날짜 및 시간대와 관련된 까다로운 규칙을 모두 관리하는 많은 오픈 소스 라이브러리가 있습니다. 날 믿어. 처음부터 이것을 구축하고 싶지 않습니다.
수많은 창립자들이 모든 것을 커스텀해야한다고 생각하는 엔지니어를 고용하는 것을 보았습니다. 그건 실수 야 엔지니어는 자신이 얼마나 훌륭한 지 자랑하고 무엇이든 만들 수 있으며 설립자는 펀치를 마시고 앱이 방탄이 될 것이라고 생각합니다. 그들은 "사용자 정의 코드"가 많을수록 더 많은 IP를 의미한다고 생각합니다.
앱의 핵심 비즈니스 로직과 관련이없는 기본 기능에 대한 사용자 지정 로직이있는 코드 기반을 상속 받으면 슬프다. 이미 존재하는 기능을 다시 빌드 할 이유가 없습니다!
대부분의 웹 및 모바일 기반 소프트웨어 엔지니어링은 코드를 복사, 붙여 넣기 및 수정하는 중입니다. 처음부터 글을 쓰지 않습니다. 다른 사람의 코드 통합 및 사용에 대해 지능적으로 이야기 할 수있는 후보를 찾으십시오.
결론
이러한 질문의 목표는 자아, 프로세스 및 전략을 측정 할 수 있도록 하는 것입니다. 후보자가 버그 코드를 푸시하지 않았거나 모범 사례를 위반했거나 누군가를 차단 한 적이 없다고 언급 한 경우 이는 적기입니다. 당신은 그 후보와 함께 앞으로 나아가서는 안됩니다.
훌륭한 엔지니어 (및 캐릭터)는 자신의 실수에 대해 공개적으로 이야기합니다.
그리고 첫 고용은 큰 위험이 있다는 것을 기억하십시오. 그것은 당신과 당신의 회사뿐만 아니라 그들에게도 위험합니다.
그들은 당신을 신뢰하고 있습니다. 당신의 개념이나 사업은 아직 입증되지 않았습니다. 시장에 출시 된 제품이나 시제품이 없을 것입니다. 그리고 당신은 당신이 거기에 도착할 수 있도록이 첫 번째 엔지니어에 의존하고 있습니다.
관대하고 적절하게 보상하십시오.
