https://imch.dev/posts/2020-programmers-web-frontend-dev-matching/

위 링크의 글은 주의사항이자 프로그래머스의 추가 점수 조건이기도 합니다. 다른 문제에서는 특별히 표시되지 않았어도 잘 처리해두면 좋습니다. 다만, 레이지 로딩과 같은 경우에는 Selenium이나 CyPress로 채점을 할 경우에는 오히려 감점이 될 수도 있으니 주의해야 합니다. 또한 아래의 내용 중 플랫폼 사이트를 활용하여 채점을 하는 경우에는 정확하게 지시에만 따라야 합니다.

아래는 제 경험 상 주의해야할 사항 혹은 참고하면 좋을 사항을 추가한 내용입니다.

1. 회사에 따라서 코딩테스트의 진행 방식이 천차만별입니다. 대체적으로는 세 갈래로 나누어 볼 수 있습니다.

   • 코드와 문제를 메일을 통해 압축 형식으로 전달해 주는 회사
   • 깃 레파지토리 권한을 주고 일정 시간까지 branch를 따서 pull request 혹은 push 해야 하는 회사
   • 플랫폼 사이트를 활용하여 문제와 풀이를 제공하는 회사

2. 제한 시간과 난이도는 크게 상관이 없습니다.

   • 쉬운 문제라도 제한 시간을 많이 주는 회사도 있습니다.
   • 일단 문제를 푸는 것 자체가 중요한 것도 있지만, 어떤 경우에는 어떤 접근 방식을 이용했는지, 혹은 코드의 구조를 어떻게 구현했는지를 중요하게 보는 경우가 최근에는 늘고 있는 추세입니다.

3. 제출 방식에 따라 채점 방식도 다릅니다.

   • 플랫폼 사이트를 활용할 경우에는 일단 풀어내는 것에 점수가 매우 큰 편으로 보면 되고, 다수가 지원하여 테스트를 보는 경우 그 경향은 더 강해집니다. (반드시 그런 것은 아니니 참고만 할 것) 그 이유는 플랫폼 사이트의 경우에는 채점을 Selenium나 CyPress 등 테스트 코드를 통해 일괄 채점하는 방식을 채택하는 경우가 많기 때문입니다. 물론 회사가 원할 경우 코드를 열람할 수 있기 때문에 채용자의 의지가 강력하다면 코드 스타일을 볼 수 있기 때문에 참고만 하면 좋습니다
   • 반대로 1번 문항에서 1, 2의 케이스는 문제를 단순히 푸는 것보다 담당자가 직접 코드를 보겠다는 의지가 좀 더 강하다고 보면 됩니다.
   • 2번의 케이스에는 커밋을 어떻게 하는지도 보겠다는 의지가 강합니다. 따라서 2번의 경우가 가장 까다롭다고도 볼 수 있습니다.

4. 테스트 코드를 지원할 경우

   • 테스트 코드가 단순히 답을 채점해 주는 역할을 하기 때문에 테스트 코드를 소개하는 것만은 아닙니다. 그런 역할도 있지만. 테스트 코드를 짜면서 코드를 짜는 연습을 한다면, 자연스럽게 좋은 코드가 나올 것입니다.