독서의 시간

최근에 개발 관련된 글을 많이 보면서 그 동안 읽지 않았던 책을 읽어 나가고 있다.

- 폴리글랏 프로그래밍

- 익스트림 프로그래밍

- 프로그래밍 심리학

- 유니티로 만드는 게임 개발 총론

- 3D MAX 2014 기초부터 활용까지

물론 읽고 있는 책은 프로그래밍 심리학이고, 어제 다 읽은 책은 폴리글랏 프로그래밍이라는 책이다.

주말에 와이프한테 우리 책 읽는 시간을 가져보는게 어떻겠냐고 제안했는데

자기도 남편이랑 주말에 커피숍 같은데서 책 읽고 커피 마시고 얘기하는 거 좋아한다고 해서 가자고 했다.

- 응? 여태까지 그런 적은 별로 없었던 것 같은데...?

저녁 시간.

집 근처 커피숍에 갔는데 내 신용카드로 할인 받을 수 있는 곳으로 가자고 해서 투썸플레이스로 갔다.

<투썸플레이스 사진, 출처: http://claire244.egloos.com/viewer/5095238>

폴리글랏 프로그래밍은 JAVA와 C#, Scala라는 프로그래밍을 통해 프로그래밍 언어라는게 어떻게 발전을 해 오고 문제를 해결해 나가고 있는지에 대한 얘기를 풀어놓은 책이다. Scala는 경험이 없지만 JAVA와 C#은 알고 있기에 재밌게 읽었다.

<개발 경험이 많고 언어 자체에 관심이 많을 수록 재미있게 읽을 수 있는 책.
출처: http://www.yes24.com/24/Goods/12204890?Acode=101>

책 내용이 중요한 건 아니고...
사실 책은 읽어야 하는데 집에서 읽으려고 하면 TV 보고 싶고, PC로 게임하고 싶은 유혹을 뿌리치고 책을 읽을 수 있는 환경이 되지 않아 내 스스로의 변명을 방패 삼아 나가게 된 것도 있고

더 중요한 이유 중 하나는 이제 책 읽는 습관을 조금씩 들여서 앞으로 태어날 우리의 2세에게 모범적인 모습을 보여주는게 좋을 것 같아서인 이유도 있다.

서울에 이사오기 전에는 출퇴근 시간에 책을 읽었는데, 모바일 게임에 빠지다 보니 책 읽는 걸 좀 등한시 한 것 같다. 어떻게든 1주일에 한번이라도 책을 읽고 싶다는 생각이 든다.
이제 다시 독서의 시간으로 빠져들 때인 듯.

C++ STL 프로그래밍 책을 읽고

http://www.yes24.com/24/Goods/13563034?Acode=101

해당 책은 위의 링크를 참조

최근에 위의 제목을 가진 책을 읽었다.
C++ 언어 자체를 코딩 안한지는 거의 3년이 되어 간다.
하지만 읽는데 큰 어려움은 없었다.
코딩이야 해보진 않았지만 개념은 알고 있었기 때문이다.

이 책을 읽는데 2시간 정도 걸렸는데 (코드 예제는 생략하고)
예전의 나와 지금의 나는 STL을 경험하는 자세가 다른 것 같다.

STL을 처음 접했을 때가 2002년 학부 시절에
STL 프로그래밍 책을 읽고 많은 부분을 이해하고 따라하려던 때가 있었다.

Linked list도 제대로 몰라 후배꺼 대충 베껴서 과제 제출 했던 적이 있었는데, STL을 하겠다고 덤볐던 것 부터가 어려웠던 것 같다.
- 솔직히 고백하지만 베끼긴 했어도 내가 이해하고 다시 만들긴 했다. 어쨌든 내가 처음부터 만든 건 아니었으니 코딩을 잘 하는 학부생은 아니었다.

지금은 STL이 어렵고 쉽고를 떠나서
그냥 알게된 기술이 된 것 같다. 언제 부터 잘 알았는지도 기억이 희미하다.
코드는 보면 이해가 되고 설명이 가능하기 때문에 굳이 타이핑 해 보지 않아도 된다고 생각한다.

이유는 실무에 자주 썼고, 내 스스로 미션을 세워서 코딩 연습을 하는데 많이 사용했었기 때문이다.

그래서 리뷰 형태로 읽었다는 생각이 들고
다 읽고 괜히 읽었다는 생각도 든다.
이미 알고 있는 걸 보는게 리뷰 그 이상 그 이하도 아니기에.

내 스스로 이걸 코딩할 수 있냐 없냐가 중요한 게 아니라
이걸 어떤 시스템을 만드는데 쓰고, 같이 일하는 사람들이 이걸 알고 있는지, 만약 모르는 사람이 있다면 이걸 어떻게 알려줘야 하는지 그런게 더 생각나는 것 같다.

결국 일이 떨어지면 같은 기술을 공유하고 같이 일하는 건 내가 같이 일하는 사람이니까 그 사람이 중요한 것 같다. 이걸 내가 아냐 모르냐가 아니라.

책 읽고 난 후기가 좀 뜬금없네.

개발자 면접 코딩 테스트 과연 옳은 일인가?

개발자를 채용하는 과정에 있어서 능력을 측정하는 방법은 여러가지가 있는 것 같다.
구글의 화이트보드 pseudo code 테스트라던가 일부 회사들의 코딩 테스트에 대한 이야기는 뭐 검색만 조금 해봐도 유명한 방법 중에 하나일 것이다.

그런데 난 여기서 조금 문제가 있다고 본다. 그 이유는

경력의 경우 대체로 경력이 많을 수록 더 많은 언어와 더 많은 프레임워크 더 많은 개발 도구를 경험했을 터인데 그런 사람들에게 고작 테스트 한다는게 소트 알고리즘 아나 모르나 칠판에 써가면서 혹은 종이에 펜으로 써가면서 그걸 지켜보고 있는게 과연 옳은가? 이다.

물론 언어가 중요하지 않고 문제 해결 능력만을 본다고 했을 때 좋은 테스트 방법이라고 생각하는 사람이 있을 수는 있다.
하지만 요즘 같은 시대에 소트 알고리즘을 만들어서 쓰는 사람이 과연 얼마나 되는지 묻고 싶다. 알고리즘이야 검색만 하면 다 나오고, 심지어 알고리즘 코드를 만들지 않고 인터페이스 구현 (IComapre 같은) 후 알고리즘 함수 호출 한번으로 해주는 방법도 있는데 굳이 그런걸 평가하는건 옳은 건 아닌 것 같다. (오히려 C++의 STL이라던지, C#의 Sort 하기 위한 인터페이스 구현 방법 등을 물어 보는게 나은 거 같다)

여기에 수긍이 가는 좋은 글이 있어 링크를 걸어 본다.
Putting Developers to the Test

요지는 개발자들이 개발을 하는데 화이트보드에 써서 개발하지 않고 최적화된 개발툴과 거기에 맞는 OS, Framework, 개발 언어를 적절하게 선택해서 빠른 시간에 개발할 수 있는 능력을 테스트 하는게 맞다고 하는 글이다. 마치 화이트보드 코드 테스트는 잘못된 거라고 비웃듯(?) 써 놓은 글이다.

나도 면접 때 종이에 버블 소트 알고리즘에 대해 구현해 보라고 했던 적이 있었는데, 적잖이 당황했었다. 버블 소트 알고리즘을 알고 구현하는 과정이 옳은가? 에 대한 걸 평가하는 거라면 뭐라 할 말은 없지만, 버블 소트 알고리즘을 코드로 구현 가능한가?에 대한 평가라면 잘못된 평가라고 본다.

그때는 내가 당황에서 역공격을 하지 못했는데, 만약 지금 다시 그런 식으로 면접보는 곳이 있다고 했을때는 난 확실히 역공격을 하고 싶다.
"면접관님은 혹시 알고리즘 짜실 때 화이트보드에 직접 짜시는지요? 그러면 퀵 소트 알고리즘 부터 화이트보드에 보여주시면, 제가 버블 소트 알고리즘 테스트에 응해보도록 하겠습니다. 아! 만약 못하시겠으면 PC를 주세요. 어차피 저희들 다 PC에 앉아서 개발하잖아요?" 라고 말이다.

정말 면접자에게 필요한 코딩 테스트는 알고리즘 코딩 따위가 아니라

• 면접자가 실제 진행했던 프로젝트의 개발 환경 (OS, Development tools, Framework, Language)에 대해 물어보고 왜 그런 환경으로 개발을 하는지에 대한 이해도 측정 질문
• 이슈 관리 시스템(redmine, trac 등등), 버전 관리 시스템(svn, git 등등), 빌드 관리 시스템(jenkins, maven 등등) 등 개발에 필요한 시스템 구축에 대한 이해가 되어 있는지(이런 시스템의 필요성 정도만, 허접한 회사가 아닌 이상 사용은 해봤을테니), 그리고 이런 시스템을 사용하면서 느꼈던 에피소드 등을 유도하는 질문 (항상 빌드를 깨뜨리는 친구가 있었는데 벌금을 물게 했다던지 하는 그 사람만의 이야기)
• 사용했던 라이브러리가 있었다면 그걸 설치해 보라고 하고 어떤 기능을 만들기 위해 썼는지에 대해 보여주는 정도 그리고 여러웠던 점이 무엇이었는지 - 실제로 면접자가 이 라이브러리에 대한 이해도가 어느정도 인지를 측정하는 것으로 본인이 필요에 의해서 쓴 라이브러리라면 코딩이 절로 나올 수 있다.

이런 것들이 되야 하지 않을까 싶다.

그래서 PC를 주고 코딩을 시키는게 아니라 저런걸 찾고 설명해 줄 수 있는 능력?

어차피 시키는 일만 열심히 했던 개발자였고 본인 능력 안키웠으면 저런거 설치해 본 적도 없을 테고, 왜 필요한지도 모를 것이기 때문에 설명을 할 수 없을 것이다.

설마 설명을 했다 한들 본인의 에피소드 얘기를 들어보면 시키는 대로 했는지 본인이 해결하려 했는지 정도는 파악되지 않을까?

회사에서 바로 써먹어야 하는 경력자는 알고리즘을 코딩할 수 있냐 없냐로 측정하는 개발자가 아닌, 개발 환경에 대한 이해를 정확히 하고 본인이 경험했던 이야기를 끄집어 내서 이런 시스템이 왜 필요한지, 문제가 뭐였는지, 어떻게 해결했는지에 대한 진솔한 얘기를 할 수 있는 개발자여야 할 것 같다.

만약 위의 것들을 할 수 있는 개발자라면 당장 내일 출근하라고 해서 개발 환경 세팅하라고 하면 별 다른 문제 없을 할 수 있을 것이다. 게다가 어차피 회사에서 시킬 일은 그 사람이 알고 있던 개발 지식과는 무관할 수 있다. 지원하려는 회사에서 만들어야 하는 시스템의 도메인 지식은 (정말 똑같은 사업을 하는 회사가 아니라면) 새로 배워야 할 가능성이 매우 높기 때문에 어차피 그럴 꺼면 툴 깔고 개발 환경이 뭔지 아는 개발자 데려오는게 시간 낭비를 덜 하는 방법일 것이다.