ThoughtWorks에 입사한 방법이나 샘플 인터뷰

이직을 앞두고 면접에 합격해야 할 상황이 생겼을 때, 가장 먼저 “면접을 준비해야 한다”는 생각이 드는 것이 이상하지 않나요? HackerRank의 문제를 해결하고, 코딩 인터뷰 크랙을 읽고, ArrayList의 작동 방식과 LinkedList와의 차이점을 기억하세요. 아, 그렇습니다. 그들은 정렬에 관해 질문할 수도 있으며, 빠른 정렬이 최선의 선택일 것이라고 말하는 것은 분명히 비전문적일 것입니다.
하지만 잠깐만요, 하루에 8시간씩 프로그래밍하고, 흥미롭고 사소하지 않은 문제를 해결하고, 새 직장에서도 플러스 마이너스 마이너스 같은 일을 하게 될 것입니다. 그럼에도 불구하고 인터뷰에 합격하려면 일상적인 기술을 연마하는 것조차 아니라 어떻게 든 추가로 준비해야하지만 현재 직장에서 필요하지 않았고 다음 직장에서는 필요하지 않을 것 같은 것을 배워야합니다. 컴퓨터 과학이 우리의 피 속에 있다는 당신의 반대에 대해, 한밤중에 우리를 깨우면 우리는 눈을 감고 베갯잇에 의식을 회복하지 못한 채 나무 너비 주위를 산책하라는 글을 써야 합니다. 내가 서커스에 취직하면 나의 가장 중요한 비결은 바로 이것일 것이라고 대답할 것입니다. 그렇다면 아마도 예, 동의합니다. 이 기술은 테스트를 거쳐야 합니다.

그런데 왜 현재 직업과 관련 없는 기술을 테스트합니까? 단지 유행이 되었기 때문에? 구글이 이런 일을 하기 때문에? 또는 미래의 팀 리더가 인터뷰 전에 모든 정렬 방법을 배워야 했고 이제 그는 "모든 훌륭한 프로그래머는 문자열에서 회문을 찾는 구현을 암기해야 한다"고 믿기 때문입니다.

글쎄, 당신은 Google이 아닙니다 (c). Google이 감당할 수 있는 것을 일반 기업은 감당할 수 없습니다. 직원의 데이터를 분석한 Google은 올림피아드 배경을 가진 엔지니어가 특정 작업을 잘 처리한다는 결론에 도달했습니다. 더욱이, 선택 프로세스를 설계함으로써 수학 문제를 쉽게 풀 수 없기 때문에 좋은 엔지니어 몇 명을 고용하지 못할 수도 있는 위험을 감수할 여유가 있습니다. 하지만 이것은 그들에게는 문제가 되지 않습니다. Google에서 일하고 싶어하는 사람들이 많기 때문에 해당 직위는 종료될 것입니다.
이제 창밖을 내다봅시다. 사무실 앞에 당신을 위해 일하고 싶은 엔지니어가 아직 텐트 캠프를 설치하지 않았고 개발자가 다음 Spring 주석을 설치해야 할 것이 무엇인지 stackoverflow에서 더 자주 찾고 있다면, 순위 알고리즘의 복잡함보다는 그렇다면 이제 Google을 복사해야 하는지 생각해 볼 때입니다.

글쎄, 이번에 구글이 실패하고 답변을 제공하지 못했다면 어떻게 해야 할까요? 개발자가 직장에서 무엇을 할지 정확히 확인하세요. 개발자에게 무엇을 중요하게 생각하시나요?
채용하려는 사람에 대한 기준을 만들고 이러한 기술을 정확하게 테스트하는 테스트를 개발하십시오.

ThoughtWorks

ThoughtWorks는 이것과 어떤 관련이 있습니까? 여기에서 제가 직접 모델 인터뷰의 예를 찾았습니다. ThoughtWorks는 누구인가요? 한마디로 중국, 싱가폴부터 미주대륙까지 전 세계에 지사를 두고 있는 하이엔드 컨설팅 회사로, 약 25년 동안 개발 분야 컨설팅을 진행해 왔으며, 마틴을 필두로 하는 자체 사이언스 사업부를 두고 있습니다. 파울러. 소프트웨어 엔지니어가 꼭 읽어야 할 10권의 책 목록을 찾는다면 아마도 그 중 2~3권은 ThoughtWorks 직원이 쓴 것입니다(예: Martin Fowler의 Refactoring 및 Sam의 Building Microservices: Designing Fine-Grained Systems) 뉴먼 또는 혁신적인 아키텍처 구축
패트릭 쿠아, 레베카 파슨스, 닐 포드 지음.

회사의 비즈니스는 상당히 비싼 서비스 제공을 기반으로 하지만 고객은 전문 지식, 내부 표준 및 인력으로 구성된 경이로운 품질에 대한 비용을 지불합니다. 따라서 여기서는 적합한 사람을 고용하는 것이 매우 중요합니다.
어떤 사람들이 옳습니까? 물론 사람마다 다른 것이 있습니다. ThoughtWorks는 개발자 비즈니스 모델의 가장 중요한 기준을 다음과 같이 결정했습니다.

• 쌍으로 발전하는 능력. 경험이나 기술이 아니라 능력이다. 5년 동안 페어 프로그래밍을 해온 사람이 올 거라고는 누구도 예상하지 못하지만, 다른 사람의 의견을 수용하고 경청하는 능력은 꼭 필요한 능력이다.
• 테스트를 작성하고 TDD를 이상적으로 연습할 수 있는 능력
• SOLID와 OOP를 이해하고 적용할 수 있다.
• 귀하의 의견을 제시하십시오. 컨설턴트로서 클라이언트의 개발자, 다른 컨설턴트와 함께 일해야 하는데, 어떤 사람이 어떤 일을 잘하는 방법을 알고 있지만 그것을 나머지 팀원들에게 전혀 전달할 수 없다면 별로 이익이 되지 않습니다.

이제 후보자의 이러한 특정 기술을 평가하는 것이 중요합니다. 그리고 여기서 저는 ThoughtWorks에서의 인터뷰 경험에 대해 이야기하고 싶습니다. 바로 말씀드리자면 싱가폴에 가서 합격했는데 채용절차가 통일되어 있어서 국가별로 크게 다르지는 않을 것 같아요.

0단계. HR

흔히 그렇듯이 HR과의 20분 인터뷰입니다. 더 이상 깊이 생각하지 않고 회사의 개발 문화, 왜 TDD를 사용하는지, 왜 쌍 프로그래밍을 사용하는지에 대해 15분 동안 이야기할 수 있는 HR 담당자를 만난 적이 없다는 점만 말씀드리고 싶습니다. 일반적으로 HR은 이 질문에 시들고 개발자가 개발하고, 테스터가 테스트하고, 관리자가 운전하는 프로세스가 정상이라고 말합니다.

1단계. OOP, TDD에 얼마나 능숙합니까?

인터뷰 시작 1.5시간 XNUMX분 전에 화성탐사차 시뮬레이터를 만드는 임무를 맡게 됐다.

화성 탐사선 임무NASA는 로봇 로버 팀을 화성 고원에 착륙시킬 예정입니다. 묘하게 직사각형인 이 고원은 탑재된 카메라가 주변 지형을 완전히 볼 수 있도록 로버가 탐색하여 지구로 다시 보낼 수 있도록 해야 합니다. 로버의 위치와 위치는 x 및 y 좌표의 조합과 네 개의 기본 나침반 지점 중 하나를 나타내는 문자로 표시됩니다. 고원은 탐색을 단순화하기 위해 그리드로 나누어져 있습니다. 예시 위치는 0, 0, N일 수 있습니다. 이는 로버가 왼쪽 하단에 있고 북쪽을 향하고 있음을 의미합니다. NASA는 로버를 제어하기 위해 간단한 문자 문자열을 보냅니다. 가능한 문자는 'L', 'R', 'M'입니다. 'L'과 'R'은 로버를 현재 지점에서 움직이지 않고 각각 왼쪽이나 오른쪽으로 90도 회전시킵니다. 'M'은 한 그리드 포인트 앞으로 이동하고 동일한 방향을 유지한다는 의미입니다.
(x, y)에서 바로 북쪽에 있는 정사각형이 (x, y+1)이라고 가정합니다.
입력:
입력의 첫 번째 줄은 고원의 오른쪽 위 좌표이고, 왼쪽 아래 좌표는 0,0으로 가정됩니다.
입력의 나머지 부분은 배치된 로버와 관련된 정보입니다. 각 로버에는 두 개의 입력 라인이 있습니다. 첫 번째 줄은 탐사선의 위치를 ​​알려주고, 두 번째 줄은 탐사선에게 고원을 탐색하는 방법을 알려주는 일련의 지침입니다. 위치는 x 및 y 좌표와 로버의 방향에 해당하는 두 개의 정수와 공백으로 구분된 문자로 구성됩니다.
각 로버는 순차적으로 완료됩니다. 즉, 첫 번째 로버가 이동을 완료할 때까지 두 번째 로버는 이동을 시작하지 않습니다.
산출:
각 로버의 출력은 최종 좌표와 방향이어야 합니다.
참고 사항 :
위의 요구 사항을 구현하고 단위 테스트를 작성하여 진공 청소기가 작동하는지 증명하세요.
어떤 형태로든 사용자 인터페이스를 만드는 것은 범위를 벗어납니다.
TDD(Test Driven Development) 접근 방식을 따라 문제를 해결하는 것이 좋습니다.
짧은 시간에 완성도보다는 품질을 더 중요하게 생각합니다.
*저에게 보내주신 과제는 게시할 수 없습니다. 몇 년 전에 받은 오래된 과제입니다. 하지만 저를 믿으세요. 기본적으로 모든 것이 동일하게 유지됩니다.

특히 평가기준에 주목하고 싶습니다. 후보자에게 중요한 사항이 감사 중에 전혀 중요하지 않거나 그 반대의 경우가 몇 번이나 발생했습니까? 모든 사람이 당신과 같은 방식으로 생각하는 것은 아니지만, 당신의 가치관이 명확하게 명시되어 있다면 많은 사람들이 이를 받아들이고 따를 수 있습니다. 따라서 평가 기준을 보면 이 단계에서 가장 중요한 기술은 다음과 같다는 것이 즉시 명백해집니다.

• TDD;
• OOP를 사용하고 유지 관리 가능한 코드를 작성하는 능력
• 페어 프로그래밍 능력

그래서 저는 그 1.5시간 동안 코드를 작성하는 것보다 작업을 어떻게 수행할 것인지 생각하는 데 시간을 보내라는 경고를 받았습니다. 코드를 함께 작성하겠습니다.

우리가 전화를 받았을 때 사람들은 자신이 누구인지, 무엇을 하는지 간략하게 설명하고 개발을 시작하겠다고 제안했습니다.

인터뷰 내내 저는 단 한 번도 제가 인터뷰를 받고 있다는 느낌을 받은 적이 없습니다. 팀으로 코드를 개발한다는 느낌이 듭니다. 어딘가에 막히면 ​​최선의 방법에 대해 서로 도와주고, 조언하고, 토론하고, 심지어 논쟁까지 벌입니다. 인터뷰에서 JUnit 5에서 메소드가 예외를 발생시키는지 확인하는 방법을 잊어버렸습니다. 그들은 테스트 작성을 계속하겠다고 제안했지만 그 중 한 명은 어떻게 해야 할지 검색하고 있었습니다.

인터뷰 후 말 그대로 몇 시간 후에 나는 내가 좋아하는 것과 그렇지 않은 것에 대한 건설적인 피드백을 받았습니다. 내 경우에는 null 객체의 대안으로 Sealed 클래스를 사용했다는 점에서 칭찬을 받았습니다. 코드를 작성하기 전에 로버를 제어하는 ​​방법을 의사 코드로 작성하여 적어도 로봇의 API와 관련된 클래스의 스케치를 받았기 때문입니다.

2단계: 알려주세요

인터뷰 일주일 전에 나는 관심 있는 주제에 대한 프레젠테이션을 준비하라는 요청을 받았습니다. 형식은 간단하고 친숙합니다. 프레젠테이션 15분, 질문 답변 15분입니다.
저는 Bob 삼촌의 Clean Architecture를 선택했습니다. 그리고 다시 한두 명과 인터뷰를 했습니다. 이것이 나의 첫 영어 발표 경험이었고, 아마도 스트레스가 많은 상황에 있었다면 대처하지 못했을 것입니다. 그런데 또 한 번도 면접에 와 있다는 느낌을 받은 적이 없어요. 모든 것이 평소와 같습니다. 내가 그들에게 말하면 그들은주의 깊게 듣습니다. 전통적인 질문 및 답변 세션조차도 인터뷰와 같지 않았으며 질문이 "가라앉는" 질문이 아니라 내 프레젠테이션에 정말로 관심이 있는 질문이라는 것이 분명했습니다.

인터뷰 후 몇 시간 후에 피드백을 받았습니다. 프레젠테이션은 매우 유용했고 그들은 정말 즐겁게 듣고 있었습니다.

3단계. 생산 품질 코드

이것이 기술 인터뷰의 마지막 단계임을 경고한 후 집에서 코드를 프로덕션 준비 상태로 가져온 다음 검토를 위해 코드를 보내고 작업 요구 사항이 변경되고 코드가 변경되는 인터뷰 일정을 예약하라는 요청을 받았습니다. 수정이 필요합니다. 앞으로 코드 리뷰는 맹목적으로 수행되고 리뷰어는 후보자가 지원하는 직위를 모르고 이력서도 볼 수 없으며 이름도 볼 수 없다고 말할 수 있습니다.

전화벨이 울렸고, 모니터 반대편에는 또 두 명의 남자가 있었습니다. 모든 것이 첫 번째 인터뷰와 동일합니다. 가장 중요한 것은 TDD를 잊지 않고 자신이 하는 일과 그 이유를 설명하는 것입니다. 이전에 TDD를 연습해 본 적이 없다면 즉시 시작하는 것이 좋습니다. 회사에서 필요하기 때문이 아니라 삶을 크게 단순화하고 원할 경우 스트레스 수준을 줄일 수 있기 때문입니다. 브라우저를 통해서만 재현할 수 있지만 테스트로는 재현할 수 없는 오류를 디버거로 미친 듯이 검색해야 했던 것을 기억하십니까? 이제 인터뷰 중에 그러한 실수를 잡아야 한다고 상상해 보십시오. 두 개의 회색 머리카락이 보장됩니다. TDD로 무엇을 얻을 수 있나요? 코드를 변경하고 예기치 않게 이제 테스트가 빨간색이라는 것을 깨달았습니다. 그런데 처음에 알아낼 수 없는 오류는 무엇입니까? 좋아요, 면접관에게 "죄송합니다"라고 말하고 Ctrl-Z를 누르고 작은 발걸음을 내딛기 시작합니다. 그리고 그렇습니다. 스스로 TDD를 사용하여 개발할 수 있는 능력, "리팩토링이 많이 필요하기" 때문에 테스트가 반나절 동안 빨간색이 아닌 영구적으로 녹색이 되도록 목표를 향해 나아갈 수 있는 능력을 개발해야 합니다. 이는 유지 관리 가능한 코드를 작성하거나 생산적인 코드를 작성하는 것과 정확히 같은 기술입니다.

따라서 코드를 얼마나 잘 변경할 수 있는지는 처음부터 어떤 디자인을 염두에 두고 있는지, 얼마나 단순한지, 테스트가 얼마나 좋은지에 따라 달라집니다.

인터뷰가 끝난 후 몇 시간 안에 피드백을 받았습니다. 이 단계에서 나는 거의 끝났고 "파울러를 만나기" 전까지는 거의 남지 않았다는 것을 깨달았습니다.

4단계. 최종. 기술적인 질문은 충분합니다. 우리는 당신이 누구인지 알고 싶습니다!

솔직히 말해서 나는 이 질문의 공식화에 다소 당황했습니다. 한 시간의 대화로 내가 어떤 사람인지 어떻게 알 수 있나요? 그리고 더욱이 내가 모국어가 아니고 솔직히 말하면 매우 형편없고 혀가 묶인 언어를 말할 때 이것을 어떻게 이해할 수 있습니까? 이전 인터뷰에서는 개인적으로 질문에 대답하는 것보다 이야기하는 것이 더 쉬웠고, 억양이 탓이었다. 면접관 중 적어도 한 명은 아시아인이었고 그들의 억양은 유럽인의 귀에 다소 특이했습니다. 따라서 저는 적극적인 접근 방식을 취하기로 결정했습니다. 나 자신에 대한 프레젠테이션을 준비하고 인터뷰가 시작될 때 이 프레젠테이션을 통해 나 자신에 대해 이야기하겠다고 제안했습니다. 그들이 동의한다면 적어도 나에 대한 질문은 줄어들 것이고 그들이 제안을 거부한다면 글쎄요, 프레젠테이션에 소비하는 내 인생의 3 시간은 그다지 높은 대가가 아닙니다. 그런데 프레젠테이션에는 무엇을 써야 할까요? 약력 - 당시 그곳에서 태어나 학교에 다녔고, 대학을 졸업했습니다. 하지만 누가 신경쓰나요?

Thoughtworks 문화에 대해 Google에서 조금 검색하면 지속 가능한 비즈니스, 소프트웨어 우수성 및 사회 정의의 3가지 원칙을 설명하는 Martin Fowler의 기사 [https://martinfowler.com/bliki/ThreePillars.html]를 찾을 수 있습니다.

Software Excellence가 이미 확인되었다고 가정해 보겠습니다. 지속 가능한 비즈니스와 사회 정의를 보여주는 것이 남아 있습니다.

게다가 나는 후자에 집중하기로 결정했다.

우선 나는 ThoughtWorks를 사용하는 이유를 그에게 말했습니다. 대학 시절 Martin Fowler의 블로그를 읽었기 때문에 Clean 코드를 좋아합니다.

프로젝트는 다양한 각도에서 발표될 수도 있습니다. 그는 또한 환자의 삶을 단순화하고 심지어 한 명의 생명을 구했다는 소문이 있는 의학용 소프트웨어도 개발했습니다. 나는 또한 시민들의 삶을 더욱 편리하게 해주는 은행용 소프트웨어를 개발했습니다. 특히 이 은행을 전국 인구의 70%가 사용한다면 더욱 그렇습니다. 이것은 Sberbank에 관한 것이 아니며 러시아에 관한 것도 아닙니다.

나에 대해 알고 싶나요? 좋아요. 취미는 사진인데, 어찌됐든 카메라를 10년 정도 손에 쥐고 있는데, 보여주기에도 쑥스럽지 않은 사진이 있어요. 또한 한때는 고양이 보호소를 도왔습니다. 영구 집이 필요한 고양이의 사진을 찍었습니다. 좋은 사진을 찍으면 고양이를 배치하는 것이 훨씬 쉬워집니다. 아마 백 마리의 고양이를 찍었을 거예요 :)

결국 내 발표의 80%는 고양이로 채워졌다.

프레젠테이션 직후 HR에서는 인터뷰 결과를 아직 알지 못했지만 사무실 전체가 이미 고양이에 깊은 인상을 받았다고 나에게 편지를 보냈습니다.

결국 피드백을 기다렸습니다. 인간으로서 모두를 만족시켰습니다.

그러나 마지막 대화에서 HR은 사회 정의가 매우 좋고 필요하지만 모든 프로젝트가 이렇지는 않다고 재치 있게 말했습니다. 그리고 그는 그것이 나에게 겁이 났는지 물었습니다. 일반적으로 나는 사회 정의에 대해 약간 지나쳤습니다. :)

합계

그 결과, 나는 몇 달 동안 싱가포르의 Thoughtworks에서 일하고 있는데 여기 너무 많은 회사들이 Spring보다 더 많은 지식을 갖고 있음에도 불구하고 코딩을 위해 Leave와 Whiteboard를 사용하는 Google의 "모범 면접 관행"을 채택하고 있음을 확인했습니다. Symfony, RubyOnRails(필요한 부분에 밑줄 표시)는 작업에 필요하지 않습니다. 엔지니어들은 인터뷰를 하기 전에 일주일 동안 '준비'를 합니다.

Thoughtworks에서는 후보자에 대한 적절한 요구 사항 외에도 다음 원칙이 최우선입니다.
인터뷰의 즐거움. 게다가 양측 모두에게. 실제로 최고의 인력을 확보하고 싶다면 (누가 그렇지 않습니까?) 인터뷰는 노예를 선택하는 시장이 아니라 고용주와 후보자가 서로를 평가하는 쇼입니다. 그리고 후보자가 회사에 대해 유쾌한 감정을 연관시킨다면 그는 이 특정 회사를 선택할 가능성이 높습니다.

편견을 완화하기 위해 여러 면접관. Thoughtworks에서는 페어 프로그래밍이 사실상의 표준입니다. 그리고 이 관행이 다른 분야에도 적용될 수 있다면 TW는 그렇게 하려고 노력합니다. 각 단계마다 2명이 면접을 진행합니다. 따라서 한 사람당 최소 8명이 평가하며, TW는 다양한 배경, 다양한 방향(기술자뿐만 아니라), 성별을 가진 면접관을 선발하려고 합니다.

최종적으로 채용 결정은 최소 8명 이상의 의견을 바탕으로 이루어지며, 누구도 캐스팅 투표권을 갖지 않습니다.

속성 기반 채용 후보자가 좋아하는 것과 싫어하는 것에 따라 결정을 내리는 대신 평가되는 속성을 포함하는 각 역할과 각 단계에 대한 양식이 개발됩니다. 동시에 평가할 때는 특정 기술에 대한 경험이 아닌 적용 능력을 평가하는 것이 좋습니다. 따라서 후보자가 TDD와 같은 기술을 적용할 수 없었지만 그럼에도 불구하고 적용하려고 시도하고 올바르게 사용하는 방법에 대한 조언을 들으면 인터뷰에 합격할 수 있는 모든 기회가 있습니다.

교육 수료증이 필요하지 않습니다. TW는 컴퓨터 과학에 대한 자격증이나 교육을 요구하지 않습니다. 실력만 평가됩니다.

따로 준비하지 않고도 외국계 기업과 면접을 본 것은 이번이 처음이다. 각 단계가 끝날 때마다 피곤함을 느끼지는 않았지만 오히려 모범 사례를 적용할 수 있어서 모니터 반대편에 있는 사람들이 그것을 평가하고 매일 적용하고 있다는 사실이 기뻤습니다.

몇 달이 지나자 내 기대가 완전히 충족되었다고 말할 수 있게 되었습니다. ThoughtWorks는 일반 회사와 어떻게 다른가요? 일반 회사에서는 좋은 개발자와 좋은 사람들을 찾을 수 있지만 TW에서는 그들의 집중력이 차트에서 벗어났습니다.

ThoughtWorks 합류에 관심이 있다면 채용 공고를 확인하세요. 여기에
또한 흥미로운 공석에 주목할 것을 제안합니다.
수석 소프트웨어 엔지니어: 독일, 런던, 마드리드, 싱가포르
수석 소프트웨어 엔지니어: 시드니, 독일, 맨체스터, 방콕
소프트웨어 엔지니어: 시드니, 바르셀로나, 밀라노
수석 데이터 엔지니어: 밀라노
품질 분석가: 독일 중국
하부 구조: 독일, 런던, 칠레
(해당 링크는 추천링크임을 솔직히 말씀드리고 싶습니다. TW에 가시면 좋은 보너스를 받으실 수 있습니다.) 원하는 사무실을 선택하세요. 유럽에만 국한할 필요는 없습니다. 결국 2년마다 TW가 기꺼이 귀하를 다른 국가로 이전해 드릴 것입니다. 왜냐하면... 이는 ThoughtWorks 정책의 일부이므로 문화가 확산되고 균질화됩니다.

댓글로 궁금한 점을 질문하시거나 추천을 요청해 주세요.
주제가 흥미로워 보인다면 ThoughtWorks에서 일하는 것이 어떤 것인지, 싱가포르에서의 생활이 어떤 것인지에 대해 글을 쓸 것입니다.

출처 : habr.com