영상

• 내용 요약

  • 종류
    • 화이트 보드
      • 어떤 식으로 사고 하는지를 볼 수 있다.
      • 문제 자체를 맞추는 것은 중요하지 않다.
    • 직접 IDE로 코딩
      • 숙련도를 볼 수 있다.
  • 예를 들어 퀵소트 일 떄,
    • 퀵소트 자체를 못 짤 순 있다.
    • 그러나 퀵소트 관련된 힌트들을 알려주었을 때, 힌트를 통해 문제 해결을 할 수 있어야 한다.
  • 여러 질문을 하면서, 힌트를 주는 것은 플러스 점수를 주기 위한 질문 이다.

  느낀점

  • 이전까지 기준으로 면접에서 화이트 보드, 직접 IDE 코딩에 대해서 모두 두려움을 가지고 있었다.
  • 일단 화이트 보드는 내가 알고리즘을 잘 못하기 때문에 기본적으로 선호하지 않았고,
  • 직접 IDE 로 코딩 하는 것 역시, 내가 주로 코딩하는 방식이 공식 문서 같은 곳의 코드들을 그대로 보고 따라 적은 후 수정하는 코드들이 많았기 때문에 나 스스로 사고 하는 힘이 부족했었다.
  • 그러나, TDD 를 하고 나서는 문제를 정의하고, 정의한 문제의 조건을 정리하고 정리한 조건을 기준으로 테스트 코드를 만들면서, 문제를 풀어가는데 익숙해 지다보니, 위의 과정들에 있어서 어느정도는 예전보다 자신감이 많이 생겼다.
  • 코드워즈를 풀면서 늘 IDE를 활용해서 TDD로 문제를 풀기 때문에 혹시나 나중에 기회가 되면, 면접이 아니더라도 내가 올바르게 하고 있는 것인지에 대한 한번 평가를 받아보고 싶다.
  • 무튼 간에, 코딩 테스트에 대해서 나도 긍정적으로 생각한다.
  • 그러나, 특정 알고리즘을 알아야 풀 수 있는 문제 라던지, 지나치게 어려운 문제에 대해, 이걸 풀면 잘하는 것, 못풀면 못하는 것 식의 코딩 교육이 이루어지는 것 같아서 매우 안타깝다
  • 무엇보다 문제는 대부분의 현업 개발 회사들의 대부분이 위의 마인드를 가지고 시험 문제를 낸다는 것이다.
  • 이것은 매우 옳지 못하다고 생각하고 혹여나 저런 문제를 달달 외워서 맞춘다고 하더라도, 실무를 할 때 하나도 도움이 되지 않는다고 생각한다.
  • 오히려 쉬운 문제를 풀더라도, 클린한 코드를 작성하기 위해서 어떤 노력을 기울이는 지를 보는 것이, 경력자건, 신입이건, 더 좋은 개발자를 뽑는데 더 좋은 기준이 라고 생각한다.