2017.10.24

현장 개발자의 구직 팁··· 기술 테스트 4종 대처법

Emily Green | Techworld
필자는 15년 동안 소프트웨어 개발자로 일했으며 이 직업을 정말 좋아한다. 다른 직업처럼 굴곡이 있지만 관심 분야를 확대할 수 있고, 계속 새로운 기술을 학습할 수 있다. 오늘은 그간의 경험을 통해 습득한 노하우를 공유하고자 한다. 기술 인터뷰를 ‘순항’하는 방법이다.

2003년, 처음으로 기술 테스트를 봤다. 그 결과, LAMP 개발자로 맞춤형 웹사이트를 만드는 ‘지루한’ 일자리를 얻었다. 다행히 얼마 지나지 않아, 이 지루한 일자리에서 다른 일자리로 옮겨갈 수 있었다. 이후 정말 수 많은 기술 테스트를 봤다.

먼저 짚고 넘어가야야 사실이 있다. 사람들은 개발자 채용을 두려워한다는 것이다. CV가 훌륭해도, 많은 경험을 갖고 있어도, 대화를 해서 이성적인 사람인 것을 알고 나서도 겁을 내고 걱정을 한다. 해야 할 일을 못할까 겁내는 것이다. 다시 말해 코딩에 능숙하지 않고, 문제 해결에 능숙하지 않을까 겁내는 것이다.

그래서 이들은 실제 해야 할 일을 해낼 수 있는지 판단할 수 있는 기술 테스트를 고안해 활용하고 있다. (실제 효과 여부는 논외로 둔다.) 테이크 홈 코딩 챌린지, 기술 퀴즈, 화이트보드 챌린지, 기술 인터뷰 등이 가장 많이 사용되는 기법들이다. 지금부터 이런 테스트 각각에 대해 조금 더 자세히 설명하고, 터득한 팁을 공유하겠다.

◆ ‘테이크 홈 코딩 챌린지(Take Home Coding Challenge)’는 개발자가 집에서 완수해야 할 과업(숙제)이다. 통상 문제와 기대사항을 설명한 문서 형태이다. 개발자는 코드를 작성해 제출해야 한다. 그러면 이를 평가한다. 평가자가 개발자와 코드에 대해 대화를 나누는 경우도 있다. 코드에 대한 대화가 코드만큼 중요하다는 사실을 명심해야 한다.

팁: 가장 먼저 ‘테이크 홈 챌린지’가 시간적인 문제라는 점을 고려해야 한다. 명확히 할 부분이 있다.

- 도전과제를 제출해야 할 시기.
- 해당 과제를 해결할 수 있는지 여부(일상이 바쁘다면 힘든 결정이 될 수도 있음).
- 도전과제 완료에 필요한 시간(통상 과소 추정할 수 있다는 점을 고려).

시간이 충분하지 않다면, 마감 기한을 다시 협상하는 것이 좋다. 그렇게 하지 않으면 도전과제에 실패할 것이기 때문이다.

◆ ‘기술 퀴즈’는 면접관이 개발자에게 답이 명확한 여러 질문을 묻는 테스트이다. 말 그대로 퀴즈 시험이다. 예를 들면, “HashMap과 연결된 리스트 요소 검색 때 차이는 무엇입니까?”, “Java에서 final, finally, finalize의 차이는 무엇입니까?” 같은 질문이다.

: 기업이 퀴즈 테스트를 실시하는 이유 중 하나는 쉽게 ‘표준화’해 비교할 수 있기 때문이다. 다시 말해, 모든 사람에게 동일한 질문을 물은 후, 가장 잘 대답한 사람을 쉽게 찾을 수 있다. 애석하게도 구직자에게 그리 유쾌한 경험이 아니며 때로는 지루하기까지 하다.

필자는 재미를 추구하는 경향이 있었고 이로 인해 실수를 몇 번 저질렀다. 가령 자바 개발자를 대상으로 한 퀴즈 동안, 필자는 자바의 ‘상속성(Inheritance)’을 없애고, 다형성 인터페이스를 사용하는 방법에 대해 이야기하기 시작했다. 또 디자인 패턴이 Language Smells라고 주장했다. 면접관은 당황을 했다. 또한 필자가 너무 도발적이라고 판단했다.

퀴즈 테스트 중 지루함을 느껴도 이런 시도를 하지 말라고 충고하고 싶다. 예의를 갖추고, 즐겁게 접근해야 할, 반드시 필요한 짧은 테스트로 받아들이는 것이 좋다.

◆ 다음으로는 화이트보드 챌린지가 있다. 면접관이 꽤 복잡한 문제를 제시하면, 개발자가 화이트보드에 문제에 대한 해결책을 설명하는 테스트다. 면접관은 개발자와 문제에 대해 대화를 하고, 힌트를 주고, 테스트가 진행되는 동안 아이디어를 제공한다. 통상 화이트보드에 코드와 다이어그램을 적고 그린다.

이와 유사한 ‘페어 프로그래밍 챌린지’는 화이트보드 대신 컴퓨터를 이용한다는 차이점이 있다. 화이트보드 챌린지와 마찬가지로, 면접관이 해결해야 할 문제를 설명한다. 그러면 개발자는 컴퓨터에 코드를 작성해 문제를 해결한다.

: ‘화이트보드 챌린지’ 테스트에 두려움을 느끼는 사람들이 많다. 업무와 직결된 실무적인 문제, 업무와 관련이 없는 실무적인 문제, 아주 추상적인 문제 등을 제시 받을 수 있다.

화이트보드가 두렵다면 연습을 해야 한다! 인터넷에서 퍼즐과 챌린지를 찾고, 친구에 면접관이 되어줄 것을 부탁하고, 벽에 큰 종이를 붙여 연습을 하는 것이 좋다. 가능한 예상되는 상황을 그대로 모방하려 시도한다.

가장 먼저 할 일은 질문을 명확히 이해하는 것이다. 질문을 이해하지 못하면 문제를 해결할 수 없다. 문제를 해결하는 동안 세부 사항이 명확해질 것이라고 생각한다면 실패할 것이다.

◆ 면접관이 대화를 통해 드러나는 개발자의 기술적 지식을 확인하는 테스트가 ‘기술 인터뷰’이다. 예를 들어, “Y라는 기술로 X라는 성과를 일궈냈군요. 지금 다시 결정을 내릴 수 있다면 어떤 일을 하시겠습니까?”라고 질문을 한다.

면접관은 이때 개발자가 Y라는 기술, 그리고 경쟁 기술에 대한 지식을 입증하기 기대한다. 전형적인 인터뷰와 기술 테스트가 혼합된 형태의 테스트이다. 기술적 지식에 추가, 더 많은 정보를 얻으려 시도하는 테스트이기 때문이다.

: 구직자인 개발자를 밀어 붙이고, 압박감을 주면서 능력을 표출하도록 유도하는 ‘구식’ 면접관들이 있다. 그러나 이런 형태의 면접이 점차 줄어들고 있는 추세이다. 아주 드물다. 무엇보다 유능한 개발자를 유치하려는 경쟁이 치열해졌기 때문이다. 통상 의사결정에 필요한 정보를 얻으려 시도하면서, 구직자인 개발자와 좋은 관계를 구축하고, 회사에 대해 좋은 이미지를 심어주려 노력한다.

이런 이유로 정보를 유도할 수 있는 질문을 사용하는 면접관이 많다. 또한 개발자가 스스로와 역량을 드러낼 많은 기회를 준다. 예를 들어, 구직자인 개발자의 강점에 대한 정보를 얻기 위해, 자부심을 갖고 있는 성과에 대해 이야기 해 달라고 요청할 수 있다. 또 열정을 갖고 있는 부분에 대해 이야기 할 기회도 준다.

경험이 많은 기술, 경험이 없는 기술에 대해 설명해 달라는 요청을 받았다고 가정하자. 면접관은 구직자인 개발자가 기술적 커뮤니케이션 스킬과 지식을 증명해 보이기 기대한다. 또한 친숙한 분야에서 자신을 빛낼 기회를 주는 것이다. 구직자인 개발자가 ‘가르침’을 전수할 수 있도록 유도해 좋은 관계를 구축하려 시도하는 것이다.

이런 질문들은 ‘선물’이나 마찬가지이다. 이런 질문을 인식하고, 자신 있는 분야, 관심 있는 분야에 대한 이야기를 할 기회로 활용해야 한다.

마지막으로 전하고 싶은 이야기는 자신의 정서를 다듬으라는 것이다. 기술 테스트는 구직자가 업무에 적합한지 판단하는 데 목적을 두고 있다. 여기에 실패하면 업무에서도 성과를 발휘하지 못할 가능성이 있다고 생각하기 마련이다. 앞서 설명한 여러 기술 테스트에 큰 영향을 주는 요소 중 하나가 자신의 ‘감정(기분)’이다. 이를 제대로 준비한 상태에서 인터뷰를 하면 큰 차이를 만들 수 있다.

* Emily Green,은 푸셔(Pusher)의 플랫폼 엔지니어다. 그녀는 빅데이터, 데이터베이스, 함수 프로그래밍, 프로그래밍 언어 분야에 관심이 높다. ciokr@idg.co.kr 



2017.10.24

현장 개발자의 구직 팁··· 기술 테스트 4종 대처법

Emily Green | Techworld
필자는 15년 동안 소프트웨어 개발자로 일했으며 이 직업을 정말 좋아한다. 다른 직업처럼 굴곡이 있지만 관심 분야를 확대할 수 있고, 계속 새로운 기술을 학습할 수 있다. 오늘은 그간의 경험을 통해 습득한 노하우를 공유하고자 한다. 기술 인터뷰를 ‘순항’하는 방법이다.

2003년, 처음으로 기술 테스트를 봤다. 그 결과, LAMP 개발자로 맞춤형 웹사이트를 만드는 ‘지루한’ 일자리를 얻었다. 다행히 얼마 지나지 않아, 이 지루한 일자리에서 다른 일자리로 옮겨갈 수 있었다. 이후 정말 수 많은 기술 테스트를 봤다.

먼저 짚고 넘어가야야 사실이 있다. 사람들은 개발자 채용을 두려워한다는 것이다. CV가 훌륭해도, 많은 경험을 갖고 있어도, 대화를 해서 이성적인 사람인 것을 알고 나서도 겁을 내고 걱정을 한다. 해야 할 일을 못할까 겁내는 것이다. 다시 말해 코딩에 능숙하지 않고, 문제 해결에 능숙하지 않을까 겁내는 것이다.

그래서 이들은 실제 해야 할 일을 해낼 수 있는지 판단할 수 있는 기술 테스트를 고안해 활용하고 있다. (실제 효과 여부는 논외로 둔다.) 테이크 홈 코딩 챌린지, 기술 퀴즈, 화이트보드 챌린지, 기술 인터뷰 등이 가장 많이 사용되는 기법들이다. 지금부터 이런 테스트 각각에 대해 조금 더 자세히 설명하고, 터득한 팁을 공유하겠다.

◆ ‘테이크 홈 코딩 챌린지(Take Home Coding Challenge)’는 개발자가 집에서 완수해야 할 과업(숙제)이다. 통상 문제와 기대사항을 설명한 문서 형태이다. 개발자는 코드를 작성해 제출해야 한다. 그러면 이를 평가한다. 평가자가 개발자와 코드에 대해 대화를 나누는 경우도 있다. 코드에 대한 대화가 코드만큼 중요하다는 사실을 명심해야 한다.

팁: 가장 먼저 ‘테이크 홈 챌린지’가 시간적인 문제라는 점을 고려해야 한다. 명확히 할 부분이 있다.

- 도전과제를 제출해야 할 시기.
- 해당 과제를 해결할 수 있는지 여부(일상이 바쁘다면 힘든 결정이 될 수도 있음).
- 도전과제 완료에 필요한 시간(통상 과소 추정할 수 있다는 점을 고려).

시간이 충분하지 않다면, 마감 기한을 다시 협상하는 것이 좋다. 그렇게 하지 않으면 도전과제에 실패할 것이기 때문이다.

◆ ‘기술 퀴즈’는 면접관이 개발자에게 답이 명확한 여러 질문을 묻는 테스트이다. 말 그대로 퀴즈 시험이다. 예를 들면, “HashMap과 연결된 리스트 요소 검색 때 차이는 무엇입니까?”, “Java에서 final, finally, finalize의 차이는 무엇입니까?” 같은 질문이다.

: 기업이 퀴즈 테스트를 실시하는 이유 중 하나는 쉽게 ‘표준화’해 비교할 수 있기 때문이다. 다시 말해, 모든 사람에게 동일한 질문을 물은 후, 가장 잘 대답한 사람을 쉽게 찾을 수 있다. 애석하게도 구직자에게 그리 유쾌한 경험이 아니며 때로는 지루하기까지 하다.

필자는 재미를 추구하는 경향이 있었고 이로 인해 실수를 몇 번 저질렀다. 가령 자바 개발자를 대상으로 한 퀴즈 동안, 필자는 자바의 ‘상속성(Inheritance)’을 없애고, 다형성 인터페이스를 사용하는 방법에 대해 이야기하기 시작했다. 또 디자인 패턴이 Language Smells라고 주장했다. 면접관은 당황을 했다. 또한 필자가 너무 도발적이라고 판단했다.

퀴즈 테스트 중 지루함을 느껴도 이런 시도를 하지 말라고 충고하고 싶다. 예의를 갖추고, 즐겁게 접근해야 할, 반드시 필요한 짧은 테스트로 받아들이는 것이 좋다.

◆ 다음으로는 화이트보드 챌린지가 있다. 면접관이 꽤 복잡한 문제를 제시하면, 개발자가 화이트보드에 문제에 대한 해결책을 설명하는 테스트다. 면접관은 개발자와 문제에 대해 대화를 하고, 힌트를 주고, 테스트가 진행되는 동안 아이디어를 제공한다. 통상 화이트보드에 코드와 다이어그램을 적고 그린다.

이와 유사한 ‘페어 프로그래밍 챌린지’는 화이트보드 대신 컴퓨터를 이용한다는 차이점이 있다. 화이트보드 챌린지와 마찬가지로, 면접관이 해결해야 할 문제를 설명한다. 그러면 개발자는 컴퓨터에 코드를 작성해 문제를 해결한다.

: ‘화이트보드 챌린지’ 테스트에 두려움을 느끼는 사람들이 많다. 업무와 직결된 실무적인 문제, 업무와 관련이 없는 실무적인 문제, 아주 추상적인 문제 등을 제시 받을 수 있다.

화이트보드가 두렵다면 연습을 해야 한다! 인터넷에서 퍼즐과 챌린지를 찾고, 친구에 면접관이 되어줄 것을 부탁하고, 벽에 큰 종이를 붙여 연습을 하는 것이 좋다. 가능한 예상되는 상황을 그대로 모방하려 시도한다.

가장 먼저 할 일은 질문을 명확히 이해하는 것이다. 질문을 이해하지 못하면 문제를 해결할 수 없다. 문제를 해결하는 동안 세부 사항이 명확해질 것이라고 생각한다면 실패할 것이다.

◆ 면접관이 대화를 통해 드러나는 개발자의 기술적 지식을 확인하는 테스트가 ‘기술 인터뷰’이다. 예를 들어, “Y라는 기술로 X라는 성과를 일궈냈군요. 지금 다시 결정을 내릴 수 있다면 어떤 일을 하시겠습니까?”라고 질문을 한다.

면접관은 이때 개발자가 Y라는 기술, 그리고 경쟁 기술에 대한 지식을 입증하기 기대한다. 전형적인 인터뷰와 기술 테스트가 혼합된 형태의 테스트이다. 기술적 지식에 추가, 더 많은 정보를 얻으려 시도하는 테스트이기 때문이다.

: 구직자인 개발자를 밀어 붙이고, 압박감을 주면서 능력을 표출하도록 유도하는 ‘구식’ 면접관들이 있다. 그러나 이런 형태의 면접이 점차 줄어들고 있는 추세이다. 아주 드물다. 무엇보다 유능한 개발자를 유치하려는 경쟁이 치열해졌기 때문이다. 통상 의사결정에 필요한 정보를 얻으려 시도하면서, 구직자인 개발자와 좋은 관계를 구축하고, 회사에 대해 좋은 이미지를 심어주려 노력한다.

이런 이유로 정보를 유도할 수 있는 질문을 사용하는 면접관이 많다. 또한 개발자가 스스로와 역량을 드러낼 많은 기회를 준다. 예를 들어, 구직자인 개발자의 강점에 대한 정보를 얻기 위해, 자부심을 갖고 있는 성과에 대해 이야기 해 달라고 요청할 수 있다. 또 열정을 갖고 있는 부분에 대해 이야기 할 기회도 준다.

경험이 많은 기술, 경험이 없는 기술에 대해 설명해 달라는 요청을 받았다고 가정하자. 면접관은 구직자인 개발자가 기술적 커뮤니케이션 스킬과 지식을 증명해 보이기 기대한다. 또한 친숙한 분야에서 자신을 빛낼 기회를 주는 것이다. 구직자인 개발자가 ‘가르침’을 전수할 수 있도록 유도해 좋은 관계를 구축하려 시도하는 것이다.

이런 질문들은 ‘선물’이나 마찬가지이다. 이런 질문을 인식하고, 자신 있는 분야, 관심 있는 분야에 대한 이야기를 할 기회로 활용해야 한다.

마지막으로 전하고 싶은 이야기는 자신의 정서를 다듬으라는 것이다. 기술 테스트는 구직자가 업무에 적합한지 판단하는 데 목적을 두고 있다. 여기에 실패하면 업무에서도 성과를 발휘하지 못할 가능성이 있다고 생각하기 마련이다. 앞서 설명한 여러 기술 테스트에 큰 영향을 주는 요소 중 하나가 자신의 ‘감정(기분)’이다. 이를 제대로 준비한 상태에서 인터뷰를 하면 큰 차이를 만들 수 있다.

* Emily Green,은 푸셔(Pusher)의 플랫폼 엔지니어다. 그녀는 빅데이터, 데이터베이스, 함수 프로그래밍, 프로그래밍 언어 분야에 관심이 높다. ciokr@idg.co.kr 

X