아는 것과 해본 것의 차이

안타까운 포트폴리오

요새 아는 지인들에게 많이 제가 다니고 있는 회사에 지원할 것을 권유하고 있습니다.

물론 레퍼럴에 대한 보너스를 저도 받기는 하지만, 제가 대부분 추천을 제공하는 지인분들은 제가 지금 다니고 있는 직장에서 더 성장할 수 있고, 최소한 현 직장보다는 (제 주관적인 의견에 따라서) 더 업무 환경이나 문화가 괜찮다고 생각하기 때문입니다. (물론 이부분의 논란의 여지가 있지만, 저는 제 주관대로..)

그런 지인들에게 공통적으로 안타까운 부분이 있습니다. 바로 포트폴리오의 다양성 부재인데요.

무슨말이냐 하면, 추천을 받아 지원하고자 하는 대부분의 사람이 포트폴리오가 참 한결같다는 점입니다. 모두 동일하게 본인의 직장에서 해왔던 일만 주구장창 적게 되는 점입니다.

아니 그게 무슨 소리에요! 직장에서 열심히 일을 했으니 당연히 직장의 업무가 포트폴리오에 포함되어야죠!

워워 진정하십시요. 당연히 여러분의 말씀이 맞습니다. 하지만 제가 이야기 해드리고 싶은 부분은 너무 회사의 일 밖에 포트폴리오에 없다는 점입니다. 포트폴리오에는 내가 이 회사에 이직을 하고 싶은데, 그 자리에 맞도록 이렇게 준비해 왔다는 사실 (찡긋)) 을 보여줘야 한다는 점입니다.

아니 그걸 어떻게 해요?!

네 어렵습니다. 물론이죠. 하지만 그래서 그 유명한 존 손메즈나 (소프트 스킬, 커리어 스킬의 저자, 꼭 읽어보세용), 여러 선배 개발자 분들이 사이드 프로젝트, 흔히 말하는 갠프를 하라고 충고하는 이유입니다.

예를 들어 봅시다.

똑같은 회사에서 나온 이직 지원자 A와 B가 있습니다. A는 열심히 해온 회사 업무를 포트폴리오에 한가득 담아왔고, B는 조금 회사의 일은 적게 담았지만, 그 동안 이 직군에 관심이 있어서 배우고 연습삼아 작성한 개인 프로젝트에 대한 내용을 포트폴리오에 담았습니다.

이 경우 열에 아홉은 B 지원자를 선호합니다.

A도 다른걸 많이 공부했다구요!

네, 하지만 면접을 보는 사람들, 흔히 면접관들은 (기술직군에 한해서는) 입으로 열심히 자신의 지식을 뽐내는 사람보다 하나라도 더 만들어서 실체가 있는걸 보여주는 사람을 좋아합니다.

이는 곧 실제로 배운 것을 곧잘 응용 할 수 있다는 증거이기도 하지요.

그러니 해서 손해볼 것 없지않습니까?

게다가 덤으로 이러한 작업을 수행하면서, 지식으로만 알 수 없는 내용들을 실제로 습득할 수 있습니다.

예를 들어, 사이드 프로젝트를 자바로 작성하던 도중, 애플리케이션의 성능을 향상시키기 위해서 JVM을 튜닝해봤다는 경험은 튜닝을 통한 파라미터를 이것저것 바꿔보는 과정에서 ‘아 이 때는 힙 사이즈를 이렇게 조정하고 GC policy를 G1GC로 하는 것이 좋구나’ 라는 것과 이 이론에 대하여 더 바싹 알 수 있겠지요. 이러한 점들이 다 쌓여서 면접에서도 하나의 경험담과 기술적 담론을 얻어낼 수도 있겠지요. (단순히 GC는 ~~한 방법으로 동작합니다 보다는요!)

그렇다면 어떻게 시작해야하죠?

사이드 프로젝트에서 가장 어려운 점입니다. 이러한 것은 높은 저자의 권위를 빌리는 것이 가장 좋다는 중론을 따라서..

  1. 2주, 한달 안에 만들기 좋은 것부터 시작하세요! 너무 거창한 것은 안됩니다.
  2. 책이 있다면, 책의 예제에서 발전한 내용을 만들어보세요. 예를 들어 게시판이 책의 프로젝트로 나왔다면, 이 게시판에 동영상 첨부, 좋아요 버튼, 정렬 등등 다양한 Feature를 추가하는 것이죠.
  3. 배포하여 사람들의 눈에 보이도록 합시다. 꼭 누군가에게 보여주지 않더라도 무언가 마무리하는 작업은 성취감을 더 올리고 더 고도화된 사이드 프로젝트를 수행할 원동력이 됩니다.

이렇게 하나하나 준비하다 보면 어느새 멋진 포트폴리오가 완성되고 누가봐도 매력적인 포트폴리오가 될것이라 생각합니다. ㅎㅎ

오늘은 그럼 이만 여기서 줄이도록 할께요! 우리 모두 화이팅 합시다!

태그: ,

업데이트:

댓글남기기