코딩 테스트 들여다보기

요구사항은 항상 변하는데, 요구사항을 기존 구현체에 반영하는 것은 쉽지 않다. 기능을 예상해서 미리 만든다고 해도, 그게 쓰이지 않으면 레거시가 될 뿐이다. 그래서 새로 잘 짜는 능력만큼 기존의 코드와 호환되게 짜는 능력 역시 중요하다.

코드를 작성할 때에는 사람의 관점이나 습관이 적나라하게 드러난다. 단순한 Button 컴포넌트를 만들어보라고 하면, 저마다 설계한 state와 props의 구조가 다르다. 정답에 가까운 것은 있어도 ‘골든 정답'은 없다. 그래서 물어봐야한다. ‘이렇게 작성하신 이유가 궁금해요’

<Button color='red'>가나다</Button>
<Button theme='red' label='가나다' />
<RedButton label='가나다' />

_{Button 컴포넌트의 예시들}

코딩 테스트를 설계하면서 설정한 면접 기조를 모두 반영하는 것은 ‘컴포넌트를 구현하는 과제’ 밖에 없다고 생각했다. 실제로 들어와서 비슷한 UI를 볼 것이고, 구현도 할 것이고, 상황에 따라 조금씩 바뀌는 것 역시 보게 될 것이다.

우리는 우리의 프로덕트에서 보이기는 간단하지만 내부는 복잡한 컴포넌트를 골랐다. 다른 프로덕트에도 ‘어렵게 느껴지는 컴포넌트’가 하나쯤은 있을 것이다.

그런 ‘어렵게 느껴지는 컴포넌트’의 기본적인 형태를 만든 뒤 스텝을 거치며 확장하게끔 코딩 테스트를 설계했다. 또한, 최종 구현체를 어렵게 설정하여 시간이 절대 남지 않도록 하는 것도 집중했다.

_{Table로 Step을 나눈다면?}

그리고, 진행 과정에서 몇 가지 조건과 내용을 추가했다.

• 스텝은 순서대로 진행하며, 다음 스텝의 내용은 확인할 수 없다
• 스텝 설명문 내에는 영상, 구현체 링크, 요구 및 고려사항, 힌트를 제공한다
• 지원자는 본인의 작업 화면을 실시간으로 공유해야한다
• 검색과 질문은 자유롭게 할 수 있다
• 모든 컴포넌트는 직접 만들어야한다 (Material UI, Bootstrap 등 사용 불가)
• 지정된 폴더 내에서만 작업을 할 수 있다 (다른 파일의 추가, 수정, 삭제 금지)

지원자는 제한적인 정보를 토대로 제한적인 구현체를 만들게 된다. 스텝을 진행할 수록 구현체에 더 많은 유연성과 확장성을 넣어야한다. 이 과정에서 본인이 직전에 떠올린 생각을 지속적으로 돌아보고, 의심하고, 깨트리게 된다.

실시간으로 작업 화면을 공유하면 물어볼 수 있는 것도 많아진다. 구현체 링크를 누르지 않고 영상만 보며 구현한다면? 검색을 통해 찾은 해답을 사용하지 않았다면? 가만히 있어도 궁금증이 쌓인다. 그러면 물어보면 된다. ‘이렇게 작성하신 이유가 있나요?'

질문과 답변을 통해 아래의 기준으로 기술적 역량을 충분히 검증할 수 있다.

• 전체 스텝 중 어느 정도까지 왔는지? (다 마쳤는지 확인하는 것이 아니다!)
• 작성한 코드에 의도가 있었는지? 그것이 합리적인지?
• 개선이 필요한 부분을 짚었을 때 대안을 생각해낼 수 있는지?

---

끝날 때까지 끝난 게 아니야

코딩 테스트 과제를 면접 후 하루 동안 보면서 마저 풀어볼 수 있도록 하고 있다. 끝까지 구현하면 내게 메일을 보내서 코드 리뷰를 요청할 수 있다. 이렇게 온 코드를 읽고 좋은 점, 아쉬운 점, 고려가 필요한 점을 정리해서 답장을 보내고는 한다.

Head, Lead 등 상위 조직장은 비효율적인 행위로 볼 수도 있다. 일말의 가능성도 놓치고 싶지 않다는 뜻으로 봐주었으면 좋겠다. 만에 하나 잘 해낸다면, 그래서 다시 인터뷰를 보고 조직에 들어와 기여한다면, 조직의 입장에서는 막을 이유가 마땅히 없지 않은가?

언젠가 조직의 규모가 커지고 일이 많아지면, 이런 창구를 열어두는 것이 어려워질지도 모른다. 하지만 분함과 아쉬움, 그를 넘어서는 호기심을 아니까. 가능한 계속 창구를 열어두고 싶다.