프론트엔드 코딩 테스트 채점 기준은 뭘까?

반응형

취업을 준비하면 원서접수 이후 코딩 테스트를 보는 경우가 있습니다.

대부분 자료구조, 알고리즘 등을 통해서 코딩 테스트를 보는데

 

그 외에도 간단한 요구사항을 주면서

취업을 준비할 때 프로젝트를 만들어 보라는 코딩 테스트도 두 번 정도 본 적이 있습니다.

프론트엔드의 경우 실무에서 알고리즘을 잘 사용하는 경우는 없어서 더욱 이런 코딩테스트를 많이 하는 것 같습니다.

ex) 버스 예약 시스템

기능 : 예약하기 / 예약 조회하기 / 취소하기 등등

6년전 코딩 테스트... 결과물...

 

최근 저희 회사에서 지원한 분들의 코딩 테스트 결과물들을 검토한 적이 있습니다.

제가 누굴 평가할 수준은 아니지만,

어떻게 하면 지원자들이 제출한 코딩테스트들을 검토하면서 좋은 개발자를 뽑을 수 있을까 고민해 봤습니다.

1.  요구사항대로 기능 구현을 잘하였는가? (필수)

가장 중요한 점입니다.

 

클린 코드, 좋은 성능, 최신 라이브러리, 안정적인 테스트 코드 등으로 프로젝트를 만들었다고 하더라도

요구 사항에 대해서 제대로 동작하지 않는 결과물을 제출한다면 좋은 결과물이 아닙니다.

 

제대로 동작하지 않은 결과물을 제출하면, 테스트를 제대로 해보지 않았구나 라는 생각이 들게 됩니다.

 

스타일도 요구 사항과 동일하게 나왔는가도 봅니다.

1px, 색깔이 다르거나 이런 부분도 누군가에게는 사소할지 모르지만,

프론트엔드 개발자라면 이런 부분을 캐치하고 디자인과 최대한 동일하게 구현할 수 있어야 합니다.

2. 적재적소에 라이브러리를 잘 사용하였는가?

프론트엔드 개발을 하면 정말 많은 라이브러리가 있습니다.

적절하게 라이브러리를 잘 선택을 했는지도 중요한 것 같습니다.

 

프로젝트를 화려하게 보이기 위해서 최신 라이브러리, 다양한 라이브러리를 사용하지만

적장 불필요하거나, 오히려 성능을 악화시키거나, 제대로 된 사용법으로 사용하지 않는다면

쓰지만도 못할 수가 있습니다.

3. 코드를 깔끔하게 작성하였는가? (불필요한 코드, 테스트 콘솔 등)

자바스크립트 코드를 적절하게 사용하였는가를 보고 ECMAScirpt 6 문법을 잘 사용하였는가

개발 중에 작성했던 테스트 코드들, 브라우저에 찍히는 불필요한 콘솔 등이 없는지 확인합니다.

4. Readme.md 파일을 자세히 잘 적었는가? (프로젝트 구성, 설치 방법, 사용법 등)

Readme에 프로젝트 구성과 설치방법, 사용법 등을 자세히 적지 않으면

제대로 설치와 실행을 못 하게 되는데, 검토부터가 상당히 어려워지고, 짜증이 나기 시작합니다.

 

Readme에 기능들과 개발에 관련된 내용들을 작성하면 프로젝트에 대해서 쉽게 파악할 수 있습니다.

5. Git Log를 잘 작성하였는가?

Git으로 히스토리를 남기게 되면, 어떻게 개발을 하였는가 머릿속으로 그려지게 됩니다.

커밋 히스토리를 자세히 잘 작성하면 아빠 미소가 흐뭇 납니다.

 

하지만 커밋 내역에 작업 중... 나 죽어... 등 무슨 내용인지 모르게 작성을 해놓으면 히스토리를 알 수가 없어서 보기가 힘듭니다.

 

개발을 하다 보면 정말 2~3년 전에 개발한 커밋 메시지 하나로 문제를 파악하고, 히스토리를 알게 되는 경우가 많은데

커밋 메시지 하나하나를 대충 적게 되면 추후에 문제 파악 및 유지보수가 힘들어지게 됩니다.

 

마무리

저는 약간 이런 기준들을 보면서 코딩테스트 결과물을 검토하려고 합니다.

저 또한 많은 고수분들의 결과물들을 보면서 항상 많이 배우고 있습니다.

728x90
반응형