오랜만에 올리는 입사후기다.
결론은,
탈락. Orz.
그래도 이번에는 지난 C사 때와는 달리 충분히 납득하고 스스로 이해할 수 있었기에 차분하게 글을 쓴다.
2016년 목표 중 하나는 어느정도 규모를 가지고 있는 회사로 이직을 하는 것이다.
그런 맘이었으면 열심히 했어야지.
우아한 형제들에 입사지원 해보는 것이 어떻겠냐는 이야기를 들은 것은 크리스마스 직전이었다. 회사에는 이야기 하지 않았지만 이미 주변에 이직을 준비한다는 분위기를 잡아놓은 상태였다. 같은 팀원에게는 솔루션(스프링부트를 기반으로 만든 ETL 스케줄링 웹애플리케이션)에 대한 GS(Good Software 인증, TTA 발급)인증을 마치는 대로 떠나겠다는 이야기를 해놓은 상태였다.
개발을 하면서, 나보다 잘하는 사람(훌륭한 개발자는 꾸준하게 학습하고 익히며 실력을 키워야 한다)과 일하고 싶다, 갈증이 더 심해져간다.
기본적으로 알려진 우아한 형제들의 입사지원에 대한 처리절차는
- 서류전형
- 서류전형 중 코딩테스트 진행
- codility.com 를 이용한 코딩테스트를 하기 전에는 회사에 면접자가 방문하여 손코딩을 했다고 한다.
@_@)> 개인적으로는 손코딩이 참 힘들다. 의사코드로 코드를 작성하는 것도 대학교때 해본 이후에는 딱히 종이에 적어본 적이 없다.- 컴퓨터 앞에 앉아있으니 에디터에 적어서 하지. 타이핑과 손으로 쓰는 건 느낌이 많이 다르다.
*
- 서류전형 통과 후 실무면접
- 임원면접
의 절차로 진행된다.
아는 분의 추천으로 우아한 형제들 CTO 김범준님과 연락을 하여 입사절차를 진행하기에 앞서 오리엔테이션이 있었다. 만나 뵙기전 인터넷을 통해서 관련된 기사와 영상을 살펴봤다. 현재 우아아한 형제들과 관련된 기술적 이슈는 '기술부채techincal debt' 일 것이다. 한국의 대표적인 스타트업으로서 성장한 우앙한 형제들은 그 폭발적인 성장을 지원할 수 있는 기술적인 한계에 다다랐다고 한다. 그 한계를 넘어서기 위해 새로운 준비를 하고 있다. 이를 위해서 시니어Senior 개발자들을 모집하고 있다는 이야기와 함께 현재 W.B. 의 문화에 대해 소개받았다. 성장가능성과 대기업과는 다른 문화를 가지고 있는 기업의 매력을 충분히 느낄 수 있었다. 입사지원을 하겠다고 하면서 입사절차가 진행된다.
입사지원을 위한 서류전형(이력서 제출)과 함께 코딩테스트가 온라인으로 진행되었다.
입사절차는 대략 3주 정도 걸린다고 보면 된다. 이력서를 제출하면서 서류전형이 시작되고 온라인 코딩테스트를 마치면 일주일 이내에 W.B. 실무 개발자들과 실무면접이 진행되고 그 결과 일주일 이내에 임원면접이 진행된다. 이런 입사절차는 대부분의 기업들과 유사하다.
최근 C사의 경우에는 지원개발자 인력풀을 보고서 각 팀별로 자신이 필요한 개발자인 경우에 팀에서 지원하여 입사절차를 진행하는 형식이라고 한다.
온라인 코딩테스트는 codility.com 기업 테스트를 통해 진행되었다. 총 4개 문제를 3시간 안에 풀어서 제출하는 것이었다. 3개는 정규식과 자바 API를 활용한 문제풀이였고, 하나는 SQL 풀이였다. SQL 문제는 못 풀었다.
ㅡ_-);; JPA를 사용하면서 SQL을 사용하지 않은 지 꽤 된지라 SQL은 당장은 못 풀겠더라.
나머지 문제는 충분히 준비만 해두면 풀 수 있지 싶다. codility.com 은 문제를 풀고 나면 평가를 하는데 그 중에 성능에 대한 평가도 포함되기 때문에 이를 고려해서 작성해야 한다. ㅡ_-);; 내가 잘 했는지는 잘 모르겠다.
앞으로의 추세는 이 codility.com 에 기업에서 링크를 던져주면 개발자가 그 링크로 접속하여 문제를 풀어 제출하고 그 평가점수를 가지고서 추후 입사 진행여부를 결정하는 흐름이 될 것으로 보인다. 그러니 https://codility.com/programmers/ 에서 많이 풀어보고 익숙해지길 바란다.
복.붙(Ctrl + C & Ctrl + V) 신공은 통하지 않는다.
내가 푼 문제의 평가점수도 바로 보여주면 좋을텐데... ㅡ_-);; 그건 안알려주더이다. https://codility.com/programmers/ 에서 풀면 각 영역별 평가점수를 알려준다.
온라인 코딩테스트를 준비한다면 알고스팟 에 가입해서 문제를 풀어보거나, 인사이트의 프로그래밍 대회에서 배우는 알고리즘 문제 해결 전략 을 구매해서 차근차근 준비하는 것이 좋다. 대부분의 기업들이 온라인 코딩테스트를 보는 형태로 갈 것이 분명하니까.
어쨌든... 손코딩보다는 온라인 코딩이 그나마 낫다. @_@);; 의사코드도 손으로 많이 작성하지 않는데 말이지...
온라인 코딩테스트가 끝나고 현 개발자들의 실무면접이 이튿날 잡혔다.
시간을 좀 넉넉하게 잡았으면 좋았을텐데, 이 때는 아무런 생각없이 후딱후딱 일정을 잡았다.
붙을 것이라는 안일한 생각을 가지고 있었는지도 모른다. 그러기 위한 준비가 부족했지만...
퇴근 후 석촌호수 부근에 있는 우아한 형제들 건물을 방문했다.
하필이면 무지 추운 날이었다. 거기다 새로운 건물로 이사한지 얼마 안되어서 어수선한 분위기.
3명의 면접관과 마주앉아서 면접을 진행했다.
면접은 이력서에 등록되어 있는 경력 위주로 질문하고 그에 대해 답변하는 식으로 진행되었다. 내가 했던 일들에 대해서 상세히 설명하면서 이야기를 나누었다. 면접자의 감정을 상하게 하거나 하는 분위기는 딱히 없었다.
만약 그랬다면, 아주 격하게 씩씩거리면서 글을 썼겠지.
어찌보면 자바와 관련된 기초적인 질문들에 대해서 답변을 못했다. ㅎㅎ...
String, StringBuffer와 StringBuilder 의 차이(<- 링크를 클릭해서 API를 보라~)
- 곁들여서 불변객체 와 가변객체 의 차이, 스레드와 프로세서의 차이, 자바의 메모리 구조: Heap, Perm...
위의 String 과 관련된 질문에 대한 힌트라고 봐도 무방하겠다. 면접 때는 여기에 생각이 미치지 않았었는데, 면접 끝나고 나서 '아, String 은 불변객체였지. 그래서 String에 문자열을 붙이는 식으로 변경을 하게 되면 불변객체를 새로이 생성하면서 비용이 많이 들고 이를 피하기 위해 StringBuffer 를 써서 append() 로 문자열을 구성한 후에 마지막에 toString() 으로 결과를 반환받았지. 그런데 이 StringBuilder가 스레드세이프thread safe 하지 않단 말이야. 그래서 스레드 세이프한 StringBuilder 를 쓰게 되었지. 그런데 쓰레드세이프란 뭔고 하니, 멀티스레드 상태가 되어서 StringBuffer 인스턴스에 접근해서 조작을 해도 그 값에 대한 접근을 제어해주기 때문에 최종결과가 우리가 예상했던 대로 나오는거지. 그렇다면 스레드와 프로세스의 차이는 뭔가... '
라며 생각의 끈이 이어졌지만, 이미 게임오버. 라고 정리를 했는데, 글을 다시 보니... @_@)> StringBuffer와 StringBuilder를 반대로 알고 있었네. 흠.... 사실 이런 부분은 Java API 문서를 찾아봐야한다. 음트트.... 부끄부끄.
![]()
면접이 끝나고 돌아가려는 내게 '작은 선물 세트'를 건네주면서 면접과정에서 진행한 '온라인 코딩테스트'의 문제는 적절했는지 여부 등을 묻는 세심함을 보였다.
아, 내 코드 결과를 알려달라고 할 것을!! 깜빡했다.
아쉬운 마음으로 집에 돌아왔다.
다음날 오후 김범준님이 직접 전화를 주셨다.
지금 W.B. 에는 많은 주니어 개발자가 있다. 새로운 전환을 하는 과정에서 주니어들을 이끌어줄 경험이 풍부한 시니어 개발자를 뽑고 있는 중이다. 그런 요구사항에는 부합하지 못했다. 지금 찾고 있는 상황과 맞지 않은 것 뿐이다. 다른 기회가 있을 때 만날 수 있으면 좋겠다.
이야기를 들으면서 충분히 수궁할 수 있었다. 면접 후에 여러가지 생각을 하게 되었던 계기가 되어주었기에 나쁘지 않은 면접이었다.
현재 회사에서 팀원들과 함께 만들고 있는 솔루션은 스프링부트를 근간으로 해서 스프링프레임워크, 스프링 데이터 JPA, 타임리프, 그리고 기타 등등을 사용하여 만들고 있다. 그런데, 여기에 사용한 기술들에 대해서 문서로 정리하고 별도의 교육을 진행하고 했지만 제대로 이해하지 못하는 부분들이 많은 아쉬움(혹은 답답함)을 느끼고 있는 상황이었다.
그런 내가, 누군가를 가르치면서 이끌어가야 한다는 것은... 제대로 수행하지 못할 가능성이 높다. 주니어들을 이끌면서 그 과정에서 발생하는 다양한 문제들을 해결하고 이를 정리해서 알려주는 역할을 해줄 사람을 필요로 하고 있다.
그냥 다니면 그냥 다닐 수 있는 회사다. 그런 회사를 나오려고 하는 건 '보다 잘하는 사람들'과 일하면서 그들에게서 자극받고 공부하면서 일하고 싶은 욕심이 들었기 때문이다. 나는 취미생활을 즐긴다. 개발을 위해 많은 시간을 투자하기 보다는, 근무시간 안에 해야할 일들을 처리하고 그 이외의 시간에는 '클라이밍', '라이딩, '여행' 등을 즐기며 지내고 싶은 욕구가 강하다. 그 외의 시간에는 개인적인 공부와 커뮤니티 활동을 하면서 보내고 있는 '내성적인' 성격의 월급쟁이형 개발자다. 나이가 들어서도 이런 생활을 유지하기 위해서는
'늘어나는 경력 만큼 실력도 뒷받침이 되어야 한다'
라는 결론을 내렸다. 그 준비를 해야할 때가 되었다고 본다.
스프링 프레임워크를 사용하기 시작한건 '모바일 교보문고' 프로젝트에 참여하면서 부터였다. 스프링만 6년 정도를 사용해 왔다. 초창기에는 누군가가 구성해진 환경안에서 비즈니스로직을 구성하는 역할이었다면, 이제는 내 스스로 프로젝트를 구성하고 그 안에서 필요한 기능들을 추가하고 그에 대한 교육을 할 수 있는 수준에 이르렀다. 그 후로 지속적으로 스프링프레임워크를 공부하고 스프링프레임워크를 기반으로 프로젝트를 진행해왔다. 지금은 스프링부트를 열심히 이용하고 있다. 현재 내가 가장 잘 사용할 수 있는 도구가 스프링인 것이다. 이 스프링 프레임워크의 틀 안에 갇혀 있을지도 모른다는 이야기도 있었다. 그 이야기를 듣고 새로운 능력을 갖출 필요가 있겠다 싶어 함수형 프로그래밍 언어에 대한 학습을 시작했다. 우선은 하스켈Haskel 을 시작으로 해서 스칼라로 넘어갈 계획이다. 그리고 웹 애플리케이션 개발에서 벗어나 애플리케이션 아키텍처를 구성하는 시도를 해보려고 한다.
W.B. 의 면접을 통해서 이런저런 많은 생각을 했다.
아 이제 나도 시니어 개발자Senior Developer 의 계열에 들어섰구나.
늙었구나.
그렇다면 시니어 개발자란 뭘까?
난 그냥 비즈니스로직 개발하는데 집중하고, 필요하다면 아키텍처 구성하는 정도의 일이면 충분한데... 누군가를 가르쳐야하는 것인가? 이건 팀원들과 함께 프로젝트를 진행하면서 드는 의문이다. 프로젝트에 사용한 기술들에 대해서는 내가 전파교육을 하는 것이 맞다고 본다. 이를 위해서 프로젝트 초기에 매주 1~2시간씩 교육을 하고 필요한 내용을 문서로 정리해서 공유하고 질문에 대응도 해줬다. 그리고 매주 2시간씩 책을 읽으면서 스터디도 진행했다. 그 이상을 더 해줘야하는 것인가?
하는 의문이 든다. ㅡ_-)> 내 계약서 상에는 직원 교육이 있는 것도 아닌데... 회사에서는 신입사원에 대한 교육도 요구하기 시작했다. 흠... 어찌되었든, 스쿠버다이빙 강사 자격도 획득했지만 그 교육을 받으면서 드는 생각은 '내가 누굴 가르치면 안되겠다' 였다.
주어진 일을 완수하기 위해 노력하고 완수해내는 것만으로 내 역할은 부족한 것인가?
기업들의 입사프로세스도 비슷해서, 실무면접에서 나올 수 있는 Java API 관련한 질문들을 정리한 자바실무면접정석을 하나 뽑아내도 되겠다 싶어졌다.
사실 짧은 면접절차동안에 면접자가 '어떻게 코드를 작성하고 이를 확인하고 구현하는지'를 모두 알아볼 수는 없다. 그래서 그 절차를 위한 통과규정을 잡고 그 규정을 통과한 사람만이 거길 통과하여 입사에 성공할 수 있게 된다. 7년 동안 5번 이상의 이직을 하면서 얻은 결론은 그렇다. 면접은 '복불복'성이 짙은 편이다. 서류전형, 코딩테스트, 실무면접과 임원면접에 이르기까지 사람과 사람이 연관되어 함께 일할 사람을 뽑아 가는 과정이기 때문이다. 이 과정은 많은 연습과 실전을 통해서 어느정도 익숙해지기 마련이다.
동물은 자신의 서식지를 옮길 수 있다.
개발자는 자신의 근무지와 환경을 옮길 수 있다. 잘 옮길 수 있다. 여전히 개발자를 찾는 곳은 많기 때문이다. 문제는~ 그 찾는 곳에 들어갈 수 있는 준비가 되었느냐 하는 것이다. 대부분의 기업들의 입사절차가 비슷해져 갈 것이다. 이력서를 받아 서류전형을 거치고 온라인 코딩사이트에서 코딩테스트를 진행하고 그 결과를 보고 실무면접을 진행하고 임원면접을 거쳐 채용을 결정하고 그 후에 연봉을 조정한 후에 입사 여부를 결정한다.
2016년 계획 중 하나는, '이직'이다. 웹 애플리케이션 개발에서 조금 더 나아가서 아키텍처를 설계하고 이를 구현하는 '아키텍트' 단계로 나갈 포석을 깔 수 있는 곳을 찾는 것을 목표로 하고 있다.
자랑할 만한 이야기는 아니지만, 여전히 자신의 자리를 찾아 방황하는 많은 이들을 위해 계속 작성해보려 한다.
읽을꺼리
