[인터뷰 후기] 사전과제로 75:1 경쟁률 뚫기

16 Jul 2020 |  iOS 인터뷰 • 인터뷰 팁 • 사전과제

사전과제로 75:1 경쟁률 뚫기

들어가기 전..

해당 후기는 1년 전에 채용형 인턴 전형에 합격 후, 사전과제 전형에서 제가 어떤 포인트를 강점으로 갖추기 위해 노력했는지, 그 포인트 들을 정리한 글입니다. 당시엔 XXIT 커뮤니티에만 공개했는데 1년 전과 지금의 제 자신을 돌아보는 겸 공개합니다.

매우 저의 주관적인 의견과 경험이 담겨있을 수도 있으니 감안하고 봐주시길 바랍니다. (제목 및 내용에서 어그로가 굉장히 많음😅)

---

저는 컴퓨터 과학을 복수전공했지만 여러 과목(네트워크) 등 부족한 점이 많았고, 제가 개발자로 취업한 분야는 4-5개월 정도밖에 공부한 정말 말그대로 무.경.력 상태였습니다.

채용 전형은 사전과제 - 1차면접 - 2차면접으로 이루어졌고

사전과제에 있어서 제가 확실히 강점을 가지고 구현한 점을 공유하고자 합니다.

 

최근엔 코딩테스트도 많이 보지만 실무 능력을 보고자 사전과제를 주는 기업도 많습니다.

제가 경쟁력을 갖출 수 있었다고 생각하는 포인트 3가지는 다음과 같습니다.

 

1. 사전과제는 github 에 올리기

사전과제는 회사마다 요구사항이 다르겠지만 일단 무조건 github 에 올려서 repository 링크로 제출하세요.

이유는 다음과 같습니다.

• git 사용할 줄 안다는 점을 어필
  • 특히 기능별로 branch 를 따서 구현해서 master 에 반영하는 식으로 사전과제 하시는 것을 추천드립니다.
  • 혼자 하는 과제라도 이렇게 하면 얘가 이런 개념을 알고 있구나 알 수 있습니다. 또 실제 개발도 이렇게 feature 별로 브랜치를 다서 master 에 반영하므로 경험해볼 기회도 생깁니다.
• 떨어져도 나중에 포트폴리오로 쓸 수 있다
  • 사전과제 레벨마다 다르겠지만, 주로 실제 있는 서비스나 앱을 비슷하게 구현하는 스타일이 많습니다.
  • 따라서 탈락한다면 탈락한 후에도 좀 더 발전시켜서 포트폴리오로 쓸 수 있습니다.
  • “나는 포트폴리오가 없는데…” → 사전과제 있는 회사가 기회가 될 수 있습니다.

 

2. README 를 적극 활용하기

이 점은 제가 제일 경쟁력을 갖춘 부분이라고 생각합니다.

Readme-Driven-Development 라는 말도 생겨났듯이, GitHub repo 딱 처음에 들어가면 나오는 것이 readme 입니다.

면접장에 그냥 아무 말 안하고 있는 지원자보다는 뭐 하나라도 더 답해보겠다고 노력해보이는 지원자를 더 뽑고싶겠죠? readme 도 그런 개념이라고 생각합니다.

저는 사전과제 제출까지 일주일의 시간이 주어졌고, 제출 마감날 마감시간 전 3시간은 오로지 readme 에 정말 혼을 쏟아 부었습니다. 제가 readme를 강조하는 이유는 다음과 같습니다.

• 내 코드의 얼굴
  • 면접관도 사람인데 모든 코드를 다 읽진 못합니다. 따라서 전체적인 구조, 어떤 기능을 넣었는지 정도를 깔끔하게 정리한 readme 가 있다면 훨씬 이해하기 쉽겠죠?
  • 내가 강조하고 싶고, 잘 구현한 부분을 어필할 수 있습니다.
  • 제가 사용자일 때, readme 에 잘 설명된 라이브러리가 항상 더 끌려서 이부분에 신경을 많이 쓰기도 했습니다.
• 나중에 면접 때, 사전과제 기반 면접에 활용 가능
  • 수시채용이라도 사전과제 제출 이후에 면접까지는 시간이 뜰 수 밖에 없습니다. 어제 내가 짠 코드도 왜 이런지 기억이 안날 때가 가끔 있는데 복잡한 구조라면 기억나기 더 힘들겠죠? 미래의 나를 위한 준비라고 생각하시면 됩니다.

 

저는 readme 구성을 다음과 같이 했습니다.

• 기능
  • 클라이언트, 프론트 쪽이라면 스크린샷이나 gif 파일로 기능을 어필하는게 좋습니다.
• 전체 앱 구성
  • 여기서는 도표나 마인드맵 툴 등을 활용하여 전체 구조를 한번 도식화, 추상화 해주면 좋습니다.
  • 저는 여기에 각 클래스별 역할도 넣었습니다.
• 트러블슈팅
  • 과제하면서 부딪혔던 문제와 이를 어떻게 해결했는지에 대한 내용을 담습니다.
  • 왜 그렇게 해결했는지에 대한 나름의 타당한 이유도 넣는 것이 좋습니다.
• 과제 하면서 배운 점/느낀 점
  • 이부분은 나중에 없애긴 했지만 또 다른 어필 포인트라고 생각하여 넣었습니다. 실제로 저는 사전과제 하면서 많이 배웠고, 제가 제출할 정도로 구현한 것이 너무 뿌듯하여 넣기도 했습니다.
• 과제 하면서 공부한 내용 (optional)
  • 저는 과제하면서 찾아보는 내용, 링크 등을 항상 마크다운에 복붙 혹은 정리해뒀는데 그걸 그냥 copy & paste 했습니다.

 

3. 단순 기능 구현보다 왜 그렇게 구현했는지 이유에 대해 생각하기

이건 나중에 사전과제 기반으로 면접 볼 때 빛을 발하게 됩니다.

개발이란게 상황에 따라서 정답이었던게 다시 오답이 되기도 합니다. 따라서 지속 가능한, 유연한 구조의 소프트웨어를 만드는 게 중요합니다. 그런 고민에서 디자인 패턴도 개발자들이 많이 고민하는 부분 중에 하나죠.

단순히 과제에서 “A란 기능을 구현하세요~” 라고 했다고 돌아가기만 하는 코드를 짜지 마시고, 이렇게 짜게 된 이유, 더 효율적인 방법에 대해 한번은 생각해 보시고 코드를 짜시길 바랍니다. 이런 고민을 앞의 readme 에 정리할 수 있어서 더 좋습니다.

특히나 디자인패턴이나 메모리 등에 대해 많이 고려해보시길 바랍니다. 이건 분야에 따라 다르긴 하지만 각 분야별로 개발에서 우선순위로 고려하는 요소들이 있을 겁니다. 그런 부분에 대해 알고 있다고 어필하시는게 강점이 될 수 있습니다.

그리고 면접에서 과제를 왜 이렇게 만들었는지에 대해 물어볼텐데 그때 그 이유에 대해 대답할 근거가 됩니다. 저는 readme 로 먼저 구조를 설명하고 특징적인 기능에 대해 설명할 거리가 많아져서 좋았습니다. 관련된 개념을 면접관이 물어보기전에 제가 먼저 알고있다고 어필할 수 있는 기회이기도 합니다.

면접은 그냥 코드리뷰를 받고 피드백을 받으며 내가 더 성장할 수 있는 기회라고 생각합니다. 저는 개인적으로 코드리뷰를 받는 것이 좋아서 사전과제 기반 1차 면접은 피드백을 받을 수 있어서 정말 좋았습니다. 초보자 입장에서 현업 개발자에게 돈 안주고 그렇게 리뷰를 받는 기회가 드물기도 하기 때문입니다.

 

부수적으로 제가 합격할 수 있었던 포인트는 성장에 대한 제 가치관이 확실하게 서 있었고, 그 부분을 면접관에게 잘 어필했기 때문이라고 생각합니다.

 

저는 사실 이 기업에 지원하지 않으려고 생각했지만 일단 과제나 받아보자는 마음으로 지원했습니다. 그리고 한달 뒤 제가 그 회사의 개발자로 입사했죠. 제!발! 여러분 자신감을 가지시고 할 수 있습니다. 무조건 많이 도전해보시고 자신을 PR 하세요.