기업과제에서 중요한 점 - 코드 그 외

• 기업과제에서 채용담당자가 무엇을 중점적으로 보는지에 대해 강의를 들었다.
• 과제에서 파악하고자 하는 것에는 다음과 같은 사항들이 있다.
  • 기본적인 형태의 서비스를 만들 수 있는가?
  • 코드 스타일은 어떤가?
  • 프로젝트 구조를 어떻게 설계했는가?
  • 과제를 수행하는 기본적인 태도는 어떤가?
  • README는 잘 작성되었는가?
  • Git은 잘 활용되었는가?
• 사실상 위의 것들이 이번 포스팅에 핵심이 되는 부분들인데 좀 더 자세히 들어가보자.

기업의 관점에서 채용 과제

• 기업에게 채용은 중요한 일이다.
• 왜냐하면 채용에 있어서 만약 안좋은 사람을 뽑게 된다면
  • 그 사람 한명이 제 역할을 못하는 것 뿐만 아니라,
  • 주위의 다른 팀원들에게도 부정적인 영향을 주고,
  • 최악의 경우에는 기존에 있던 좋은 사람들이 퇴사하게 되는 원인이 되기 때문이다.
• 따라서 채용을 진행하는 기업입장에서는 방어적인 태도를 기본적으로 가지게 된다.
• 그럼 그 방어적인 태도를 뚫으려면 어떻게 해야 할까?

코드 그 외의 사항들

• 기업과제라 하면 혹여 코드만이 중요하다고 생각할 수 있지만 절대 아니다.
• 중요한점은 채용담당자가 봤을 때 내 코드를 보고싶은 기분이 들게 하는 점이다.
  • 왜냐하면 담당자에게는 많은 과제들이 계속해서 제출되고, 확인하는 시간은 곧 투자이기 때문이다.
• 그리고 그런 기분이 들게 하는 기본사항들에는 다음의 4가지가 있다.
  • README.md
  • commit message
  • 배포 또는 데모영상의 여부
  • 제출 링크
• 반대로 과제를 보고싶지 않게 하는 사항들 또한 존재한다.
  • 제대로 접근이 되지 않는 링크들
  • 작성되지 않은, 부실한 내용의 README.md
  • 기능이 돌아가는지 확인하기 힘든 과제
  • 허가되지 않은 라이브러리의 사용
  • 규칙성이 없는 코드의 포멧팅 및 변수명
  • 관리되지 않은 Git(commit history, branch)
• 자세히 보면 보고싶은 사항들과 보고싶게하지 않은 사항들은 동전의 앞뒷면 처럼 서로 대칭된다는 것을 알 수 있다.
• 그러면 과제를 보기 싫게 만드는 요인들을 통해 왜 코드 외의 사항들을 잘 챙겨야하는지 알아보겠다.

제대로 접근이 되지 않는 링크들

• 기본적으로는 제출한 깃헙이 프라이빗이라 접근하지 못하는 것부터
• 제출한 과제의 링크에 제대로 접속하지 못한다면 담당자 입장에서는 더이상 진행을 하고싶은 마음이 들지 않을 것이다.
• 또한 이 경우의 대표적인 케이스가 있는데
• 배포된 서버를 비용문제등으로 종료하는 경우이다.
• 이 경우에는 관련된 내용을 문서로 기록해서 차라리 접근이 안된다고 써놓는 것이 훨씬 좋다

작성되지 않거나 부실한 내용의 README.md

• 말콤글래드웰의 블링크라는 책을 보면
• 사람의 첫인상은 단 5초만에 결정되고
• 이 첫인상은 앞으로의 그 사람과의 관계에 지속적으로 막대한 영향을 미치며
• 첫인상을 바꾸기란 참으로 어렵다고 한다.
• README는 과제의 첫인상을 결정짓는 요소이다.
• 렌더링 최적화나 퍼포먼스 개선같은 사항들은 README에서 꼭 어필해야한다.
• 이걸 안한다면 내 과제에 대한 설명을 할 기회와 특정한 부분을 어필할 기회를 상실하는 것이다.

기능이 돌아가는지 확인하기 힘든 과제

• 과제 클론 받고, 패키지들을 설치하고, 로컬에서 서버를 실행하는 등의 복잡한 과정을 거쳐야하면 유쾌하지 않다.
• 내가 통제할 수 있는 환경에서 배포를 해두고 배포한 결과물에 접근을 가능하게 하는 것이 좋을 것이다.
• 이에 접근해서 테스트하는 방법이 README에 적혀있으면 더더욱 좋은 평가를 받는다.
• 예를 들면 이번 사전과제 제출의 경우(netlify를 이용한 react배포)
  • Route가 react에서 되기 때문에 redirect같은 기능들이 다 정상적으로 돌아가는 지 확인해야한다.

허가되지 않은 라이브러리의 사용

• 과제의 킬링파트를 라이브러리의 메소드로 해결하면 평가를 잘 할수 없다.
• 방어적으로 평가하게 된다.
• 과제를 평가하는 사람들은 지원자들이 어떤 부분을 고민하면서 코드를 작성하는지, 구조는 어떻게 잡는지 등의 실력을 보고 싶은 것이지
• 특정 라이브러리의 스펙과 사용법을 잘 알고 있는지를 보고자 하는 것이 아니다.
• 특정 라이브러리의 사용가능여부가 궁금하면 담당자에게 한 번 물어보고 답변이 안오면 쓰지마라

규칙성이 없는 코드의 포멧팅 및 변수명

• 내 코드를 처음 본사람들에게도 코드는 잘 읽혀야 한다.
• 채용을 진행하는 사람은 자신과 같이 협업을 하는 사람이거나
• 혹은 자신이 가르쳐야 하는 사람이다.
• 근데 변수명이 의미를 알 수 없는 형태의 이름이면 자신과의 협업이 원할하게 이루어질지 의문이 생길 수 밖에 없다.
• 변수명을 짓는 것이 정말 많이 어렵다는 것은 안다.
• 하지만 적어도 변수명을 이해하기 쉽게 만들어야 한다!!!

관리되지 않은 Git

• commit message가 “드디어 끝냈다.” 이런거면 안된다.
• Git의 History 관리가 되지 않고, Commit Message가 중구난방이거나 의미를 알수 없는 메세지들로 가득 차있다면
  • 지원자의 과제 관리 능력,
    • 나아가 협업 능력에 대한 의구심을 품게 될 것이다.
• 한글 변수명은 취향의 영역이지만 멘토님은 쓰지않는다.
• 한글 변수명 쓰지말라면 쓰지 말라

결론

• 위의 요소들을 모두 좋은 방향으로 잘 충족한 과제들은 일단 평가관이 좋은 인상을 가지고 과제를 들여다보게 될 것이다.
• 그리고 거기서 과제의 퀄리티가 좋다면 내가 진짜 좋은 지원자인지 파악하기 위해서 과제에서 발생하는 문제들을 어떤 방식을 통해서 해결했는지를 확인하고 코드를 점점 더 깊은 수준까지 확인하게 될 것이다.
• 그러고 나서 코드가 마음에 들면 내가 진짜 좋은 지원자인지 파악하기 위해서 다른 요소들을 확인해보게 될 것이다.
• 이러한 과정에서 내가 과제를 수행하면서 겪었던 문제들을 정리해두고,
• 이를 해결하기 위해서 어떤 고민과 시도를 해보았고 최종적으로 어떻게 해결했다는 자료들을 확인할 수 있고 확인한 내용이 좋다면 지원자에 대해서 어느정도 확신을 가지게 될 것이고 채용의 다음 스텝으로 이어지게 될 것이다.

추가 - 코드

• 추가로 코드와 관련된 사항들은 다음과 같다.
  • 다음에 기회가 된다면 이 부분도 공을 들여 정리해야겠다.
• 코드의 가독성
  • formatting
  • 불필요한 코드들
  • 변수명
  • etc
• 컴포넌트가 잘 분리되었는가?
  • 컴포넌트를 물리적으로 분리하는 것 ⇒ 진정한 의미의 컴포넌트 분리가 아님
  • 컴포넌트를 논리적인 단위로 잘 분해한다음 용도에 맞게 설계하는 것
    • 이 컴포넌트는 어디에 사용되는가?
    • 이 컴포넌트의 역할과 책임은 무엇인가?
• 관심사가 잘 분리되었는가?
  • 반복되는 코드들이 적절한 단위로 추상화되고 분리되었는가?
  • 각 모듈(함수, 클래스 등)의 역할과 책임, 동작이 명확하게 드러나는가?
  • 각 모듈들은 재사용 가능한 형태인가?
• 프로젝트의 아키텍쳐는 어떻게 설계되었는가?
  • 모듈간의 의존성은 잘 설계되어있는가?
  • 외부의 변화에 유연하게 대응할 수 있게 설계되어있는가?

출처

원티드 프리온보딩 인턴십 프론트엔드 노션페이지

https://pollen-port-115.notion.site/1-2-30e0e3bfca3544b3aaffe51fd8df2405