미국 데이터 사이언스 인턴 구직기-3. 테크니컬 테스트
가장 확실한 절차, 테크니컬 테스트
데이터 사이언스 인턴, 정규직을 지원했던 기업 중 서류 통과 뒤에 테크니컬 테스트를 하는 기업이 더러(한 20% 정도) 있었다. 인터뷰를 몇 번 해보고 테스트를 주는 기업도 있고, 레주메를 내자마자 테스트부터 주는 기업도 있었다.
지원자에게 테크니컬 테스트는 번거로운 일이다. 왜냐하면 인터뷰가 길어봤자 반나절이면 끝나는데 테크니컬 테스트는 짧으면 하루, 길게는 일주일을 붙잡고 있어야 하는 개인과제이기 때문이다. 다른 회사에도 지원하고 있고, 학교도 다니고 있는데 시간을 내어서 합격할지도 모르는 회사의 채용 프로세스에 지나치게 많은 시간을 쓰고 있는 건 아닌가 하는 생각도 들기도 했었다.
그렇지만 기업에게는 테크니컬 테스트만큼 지원자의 실력을 평가하기에 좋은 기회는 없을 것이다. 물론 인터뷰에서도 지원자의 사고력, 논리, 과거에 했던 데이터 사이언스 프로젝터 경험을 확인할 수 있지만 '우리 기업이 풀어야 하는 문제'에 정확히 어떻게 접근하는지, 어떤 결과물을 내는지 보기에는 테크니컬 테스트가 가장 적합한 방법이다.
지원자인 나 역시 테크니컬 테스트에 응할수록 스스로가 발전되는 것을 느꼈다. 학교 과제는 잘하면 잘하는대로, 못하면 못하는 대로 점수를 받지만 내가 입사하고 싶은 기업에서 준 과제는 대충 할 수가 없다. 내가 쓴 글과 코드가 제대로 이해되도록, 그리고 그들이 필요한 설루션을 줄 수 있도록 최선을 다해야 한다. 이 과정에서 좀 더 효율적인 코드를 쓴다든가, 이전에 잘 몰랐던 알고리즘을 공부해서 적용해본다든가, 더 효과적인 시각화를 시도해본다든가 하면서 내가 보여줄 수 있는 결과물의 수준 자체가 향상되었다. 학과 친구들도 '기업에서 내준 테크니컬 테스트를 하면서 많이 배웠다'는 것에 크게 동의한다.
무엇을, 어떻게 테스트하는가
일단 데이터 사이언스의 테크니컬 테스트는 소프트웨어 엔지니어 포지션의 테스트와 다르다. 소프트웨어 엔지니어의 경우 보통 실시간으로 인터뷰하는 사람이 내 코드를 지켜보거나, 온라인 문제 은행(?) 같은 곳에 접속해서 주어진 시간 내에(예: 60분 동안 4문제) 문제를 풀어야 한다. 문제의 형태는 알고리즘 자체를 알고 있는지 평가하거나, 알고리즘을 이용해서 간단한 무언가를 만드는 것으로 알고 있다. 보통 Cracking the coding interview 같은 책으로 읽거나, CodeFight 같은 곳에서 실전 같은 문제들을 풀어보면서 준비한다.
반면 데이터 사이언스 포지션은 혼자서 문제를 풀 수 있는 시간을 최소 하루 이상 준다는 점에서 소프트웨어 엔지니어의 테크니컬 테스트와 다르다. 그리고 더 광범위한 테스트가 있다. 구체적으로
데이터베이스에서 원하는 데이터를 불러오고, 가공할 수 있는가
데이터에서 문제의 답을 정확히 찾을 수 있는가
데이터에서 흥미로운 인사이트를 도출할 수 있는가, 시각화할 수 있는가
주어진 데이터를 토대로 통계, 예측 모델을 만들 수 있는가
같은 것들을 테스트한다. 첫 번째 항목은 SQL 쿼리를 제대로 쓸 수 있는지, 두 번째 항목부터는 R이나 파이썬으로 데이터 분석, 시각화, 모델링을 할 수 있는지 테스트하기 위함이다.
각 항목을 내가 실제로 받았던 테스트 문제들을 바탕으로 하나씩 설명해보겠다.
1. 데이터베이스에서 데이터를 불러오고, 가공하기
한 인터넷 서비스 기업에서 냈던 SQL 테스트. 가상의 데이터베이스를 생성하고 거기에서 필요한 정보를 불러오게 하였다. MySQL 문법으로 써야 했다.
1) 테이블과 그에 필요한 컬럼 생성하기
Let's say you are designing the database for groups, collections of people who can communicate together just like Facebook groups. Please write the table name(s) and column name(s) that can contain information about which users are in which groups. Example: table1(column_relevant_to_this_question_1,...)
2) 위에서 만든 컬럼에서 필요한 정보 가져오기
Write a SQL query to get the number of users who don't belong to any group. Assume reasonable table names and column names.
추가적으로 쓰인 SQL 쿼리가 어떤 역할을 하는지 물어보기도 했다:
What is the result of this MySQL query?
select count(1) as ct from (select 131 as user_id union all select 132 as user_id) x;
2. 데이터에서 문제의 답 찾기
써치 엔진을 기반으로 하는 인터넷 기업의 테스트. 이 기업은 자사의 데이터 대신 위키피디아의 트래픽 데이터를 보냈다. 이 데이터는 위키피디아 페이지 별로 특정 날짜, 시간에 발생한 리퀘스트와 바이트 숫자가 정리되어 있었고, 해당 페이지의 언어도 있었다. 답은 단답형이다.
1) 리퀘스트가 가장 많았던 20가지 언어는?
Which 20 languages had the highest total number of requests?
2) 'Obama'라는 단어가 들어간 페이지의 총 리퀘스트 숫자는?
How many total requests were made to pages with names containing the substring “Obama”?
3) 몇 개의 영어 페이지가 스페인어 페이지와 같은 타이틀을 갖고 있는가? 그 페이지들 중 영어와 스페인어 바이트를 합친 숫자가 가장 큰 페이지는?
How many English pages have the same name as a Spanish page? Which of those pages had the most total English and Spanish bytes sent?
3. 데이터에서 인사이트 찾고 시각화 하기
2번 문제를 냈던 기업에서 추가로 냈던 문제들.
1) 페이지 타이틀의 단어 수와 리퀘스트 숫자의 상관관계를 보여주는 시각화
Construct one or more data visualizations which shows the relationship between the number of words in a page title and the number of requests.
2) 그밖에 흥미로운 시각화, 분석
Please include any other interesting analyses and/or visualizations that you have produced.
4. 통계, 예측 모델 만들기
이커머스 기업의 테스트. 기업에서 준 목표는 '회귀 분석을 이용해서 상품의 CTR(Click-through rate)을 촉진하는 요인 밝히기'였다. 이 기업의 실제 데이터로 보이는 도서 상품 데이터를 받았는데, 데이터의 컬럼으로 책 ID, 책 저자, 이 책을 평가한 독자 숫자, 발행일, 페이지 수, 시리즈인지 여부, 카테고리, CTR 등이 있었다.
1) 어떤 회귀 분석 테크닉을 사용했나? 종속 변수는 무엇이며 독립 변수들은 무엇이었나?
Which regression type did you use to solve this problem? More specifically, what are your dependent and independent variables?
2) 데이터 자체에 문제가 있진 않았나? 어떻게 해결하였나?
Did you encounter any data issues? What were they and how did you solve them?
3) 어떤 요인들이(독립 변수들이) 당신의 모델에서 가장 중요한가? 그것들이 왜 중요하며, 어떻게 중요성을 밝혀냈는가?
Which factors were the most important in your model? Why do you think they are important, and how does your model identify importance?
4) 주어진 데이터에 존재하지 않지만 당신이 모델에 포함하고 싶은 다른 요인들이 있는가?
Are there any other factors you'd want to have included in your data set that are not here?
통계, 예측 모델을 만드는 테스트는 단순히 모델링만을 요구하는 것이 아니라 모델링의 전 단계인 데이터 전처리와 탐색을 전제로 하기 때문에 가장 범위가 넓은 테스트였다.
테크니컬 테스트를 잘 보기 위한 지름길
보다시피 테크니컬 테스트는 데이터 사이언티스트, 애널리스트로 채용 후 실제로 맞닥들일 문제, 요청, 프로젝트의 소규모 버전이다. 그래서 테스트에서 사용되고, 보여주어야 하는 능력은 비단 채용만을 위한 것이 아니라 근본적으로 내가 데이터 사이언스 업무를 할 수 있느냐 자체를 가늠한다고 볼 수 있다.
올해 1월에 첫번째 테크니컬 테스트를 받았을 때 나는 학교 수업도 빠지고 정신나간 사람처럼 집에서 테스트에 몰두했다. 일단 이런 종류의 평가는 처음이었고, 더 큰 문제는 레주메에 파이썬을 할 줄 안다고 썼었지만 사실은 거의 못하는 상태였기 때문이다. 그래서 테스트에서 준 문제를 풀기 위해서 일단 파이썬을 벼락치기로 공부하고 (Dataquest가 큰 도움이 되었다), Jupyter notebook을 설치하고, 코드 2-3줄마다 발생하는 에러를 처리하면서 10일 정도를 보냈다. 그리고 그 단계에서 탈락했다.
1년 정도 지난 지금의 나와 그때의 내가 다른 이유는
- 파이썬과 R에 더 많은 시간을 들였기 때문에 그때보다 훨씬 능숙하게 코드를 쓸 수 있고
- 더 많은 머신러닝 알고리즘들을 이해하고 있고
- 무엇보다 더 많은 데이터를 접했기 때문이다. 학교 수업, 개인 프로젝트, 그리고 인턴십을 통해서.
결국은 게임 캐릭터처럼 스스로 경험치를 쌓아서 '실력'이라는 그 무형의 것을 만드는 수 밖에 없다. 기업에서 준 테스트를 보고 있거나 학교 수업 과제를 하고 있으면 항상 나 자신이 너무 작게 느껴졌던 것 같다. 과정이 너무 더디고, 결과물이 너무 형편없는 것 같아서 (던전을 헤매는 느낌이랄까). 피아노 치듯이 우아하게 코딩하는 친구나 인턴십 멘토를 옆에서 우러러 보기도 했었다. 돌아보면 그 순간들의 좌절과 노력의 무한반복 루프로 조금씩 성장한 것 같다. 아직도 한참 멀었지만.
