지원자는 당신의 회사를 QA 합니다
내 팀으로 새로운 사람을 영입하기 위해, 내가 다른 팀에 영입되기 위해 인터뷰를 진행하는 사람이 될 때도 있고, 지원자를 대하기도 해 본다. 나는 개인적으로 지원자로서 까탈스러운 사람이라고 생각한다. 요새는 새로운 팀원들을 채용하느라 정신이 없다. 채용 전체 프로세스는 처음부터 끝까지 회사의 첫인상이 된다고 생각한다. 그러므로 허투루 해서는 안되며, 나 또한 나에게 그리 대하는 회사는 거절한다. 입사 후 나에게 대하는 태도가 이미 보이기 때문이다.
보통의 채용 순차는 서류전형 - 스크리닝 - 과제 - 테크니컬 인터뷰 - 컬처 인터뷰 형식이다. QA는 꼼꼼하고 디테일을 잘 보는 사람을 선호한다. 중요한 스킬이기 때문이다. 좋은 QA라면, 이러한 부분이 채용과정에서도 자연스럽게 나타날 것이며 그렇기 때문에 각 채용 스텝에서 말 한마디, 내용 하나하나까지 매우 세심하게 준비해야 한다고 생각한다.
과제는 이 회사에서 QA에 대해 제대로 파악을 하고 있는지, 또한 QA 업무 내에서 무엇을 중요하게 생각하는지, 기대하는 역량 등을 찾아볼 수 있다. 과제의 목표는 확실하다. 지원자의 역량을 확인하는 것. 하지만 의외로 많은 회사들이 이 목표를 제대로 이해하지 못한 채 과제를 만드는 경우가 있다. 예를 들어 본사의 제품을 이용해 보고 리뷰를 하라던지 등의 과제다. 이러한 과제는 QA의 역량을 측정할 수 없고, 이를 역량으로 측정해서는 안되며, 이러한 수치로 QA의 자질과 팀의 퍼포먼스를 계산해서는 더더욱 안된다고 생각한다. QA를 이처럼 제대로 이해하지 못하고 있는 회사라면, 지원자로서는 믿고 거른다.
과제는 시간적 제한이 명확하기 때문에, 주어진 시간 내에 지원자에 대해 최대한 많은 부분을 알아볼 수 있는 과제를 내야 한다. 테스트 케이스를 작성하는 방식을 보고 싶다면, 테스트 케이스 작성의 기본 틀을 주어줘야 한다. 어떻게 테스트 케이스들을 구성하는지를 보고 싶으면, 구성해 볼 부분을 특정해서 전달해 주어야 한다. 과제를 하는 시간에 온전히 내가 지원자에게서 보고 싶은 부분만 집중할 수 있도록 해야, 그 사람을 역량이라는 것을 더 확실하게 알 수 있을 것이다. 과제가 핵심 부분 이외의 파트를 찾고 해결하는 데에 허비할 수도 있도록 구성된다면, 지원자의 역량을 정말로 발휘할 수 있도록 환경을 조성해주지 못했기 때문에, 지원자를 배려해주지 못한 팀이라고 생각한다.
내가 지원자에게서 어떤 역량을 원하는지, 어떤 스킬을 보고 싶은지부터 확실하게 파악해라. 테스트 자동화를 하기를 원한다면, 코딩 과제를 내놔라. 기본적인 자동화 프레임워크 셋업 같은 과제로 그 사람의 테크니컬 한 역량을 확인할 수 있을 것이다. QA라면, 내가 받는, 내가 내는 과제의 퀄리티 또한 확인하기 바란다.
테크니컬 인터뷰라고 해놓고, 전혀 테크니컬 하지 않은 질문을 하는 곳이 많다. "현 회사 제품 총사용자가 몇 명인가요?", "지금 회사에선 어떤 식으로 이 일을 진행하시나요?" 등 오히려 내 경험보다 내가 재직하는 회사의 정보를 알고 싶은 질문들이 많을 때가 있다. QA에도 개발과 디자인처럼 수많은 기술들이 존재하며, 기술 트렌드도 존재한다. 자동화 쪽으로 가면 개발자와 같은 프로그래밍 스킬 또한 요구된다. 테크니컬 한 질문은 수 없이 많은데, 정작 받는 것은 정보 빼내기식 질문이거나 내 경험담이 대부분일 수 있다.
단순한 용어 정의에 대한 질문도 불필요하다. 사용해봤던 자동화 프레임워크의 장단점 비교, 프로그래밍 관련 질문들, 탐색적 테스팅 등의 방법론에 대한 토론 등의 질문으로 지원자의 경험을 바탕으로 한 역량을 확인하는 시간으로 사용되어야 한다. 혹은 해외에서는 많이 사용하는 방식의, 상황을 주고 대처방식에 대한 의견을 듣고 토론하는 형식 또한, 그 사람의 성향과 critical thinking 역량을 확인해 볼 수 있다.
이 모든 건 인터뷰를 진행하는 사람이 충분한 트레이닝과 준비가 되어있어야 한다. 생각보다 이러한 준비가 되어있지 않은 사람들이 많아서, 본인이 그냥 하고 싶은 질문, 알고 싶은 것들만 물어보고 옆길로 새어나가게 되기도 하며, 이는 지원자에게 전혀 좋은 인상을 남기지 않는다. 본인이 갑이라 생각하는 사람들도 있어, 중요한 회사 정보들을 캐물으면서 똑같은 질문을 지원자가 하면 그것은 회사 기밀로 말해줄 수가 없다고 한다. 이걸 모르고서 질문하는 사람들이 대부분이다. 예를 들어 "이 프로그램을 왜 사용하시나요?"라는 질문을 한다. 질문자의 의도는 정확히 알 수가 없지만, 이러한 것들은 회사의 재정, 기술 스택 등이 연관되어 있다. 이를 다 설명할 수는 없다. 프로그램의 장단점을 알고 싶다면, 알고 싶다면 장단점을 알고 있는지 물어보고, 다른 프로그램 대신 사용한 이유를 알고 싶다면, 명확하게 질문해라. 준비가 안된 인터뷰 진행자는, 쉽게 넘어서는 안 될 선을 넘을 수 있다. 질문은 명확하되, 맥락은 제한적으로 주어 지원자가 여러 방향들을 고려하는지 파악할 수 있을 것이다.
인터뷰 진행자는 갑이 아니다. 좋은 사람을 모시기 위해서는 배려할 줄 알아야 하고, 인터뷰를 진행하고 질문하는 스킬 또한 갖춰야 한다. 지원자는 을이 아니다. 이 회사가 나에게 어떻게 대할 곳인지, 나와 같이 일할 수도 있게 될 이 사람들이 나를 어떻게 대하는지를 여러 방면으로 파악하는, 내가 회사를 테스트하는 시간이다. QA는 이런 쪽으로는 너무 잘하지 않는가? 이 회사의 채용 시스템을 QA 해보자.