강아지 트레이닝법을 이용한 남편 길들이기 neutral

블로그들 돌아다니다가 신혼 초기를 아주 잘 설명한 구절이 있어서 생각나는데로 인용을 해보자면 (아롱이님 블로그였던 듯),
"신혼 초기에는 결혼 전 아주 작고, 사소한 것처럼 느껴졌던 문제점들이 몇 곱절로 증폭되어 치열한 부부싸움으로 확장된다..."
이 구절을 읽으면서 이글루스에 LIKE버튼이 있으면 100만번 누르고 싶다는 생각을 문득문득했다.

요즘은 싸우는 빈도수가 현격하게 줄었는데,
가장 큰 공헌을 한 therapy(?) 가 있다면, 뭐니뭐니해도 doggy training이 아닐까 하는 생각을 한다.
맥스에게 잘 통하는 규칙들은 아담에게도 용케 잘 통한다.

1. 강아지들은 부정적인 피드백보다는 긍정적인 피드백이 100배 더 효과가 있다.
맥스: 똥오줌을 집안에 쌌다고 혼내는 것보다, 밖에서 쌌을 때 과자를 하나 주는 것이 100배 효과가 있다.
아담: 변기 앉는 뚜껑을 올려놓는다고 핀잔하는 것보다, 어쩌다가 큰일 보기 위해 내려놓고 나왔을 때 호들갑을 떨며 칭찬을 하는 것이 더 효과가 있다.

2. 관심을 시기 적절하게 준다. (no talk, no touch, no eye contact)
맥스: 내가 평소에 관심을 주지 않고, 내가 원하는 것을 했을 때만 관심을 주면, 훈련효과가 두배 이상으로 증진된다.
아담: 내가 평소에 관심을 주지 않고, "Is this what you want?" - "Yes, darling" 의 공식이 성립되었을 때만 관심을 주면, 나의 행복지수가 높아진다.

3. 강아지들은 원하는게 주위에 널부러져 있으면 주의가 산만하고, 집중을 잘 하지 못한다. 그렇다고 탓하면 안된다.
맥스: 길가에 통닭 부스러기가 떨어져 있으면, 천톤 마력으로 날 질질 끌고 가기 십상이다. 더 강력한 강아지 과자를 준비하여 주의를 전이하는 하면 된다.
아담: Groupon, Google offer, Yelp 등에서 매일같이 지름신이 하루에도 몇번씩 강령하실 유혹을 선사한다. 비싸서 사면 안된다고 하면 안먹힌다. 왜 다음 업그레이드까지 기다리지 않으면 손해인지 잘 설명하면 된다. 다음 업그레이드 기종이 나오더라도, 그 다다음 기종까지 기다려야 할 이유는 얼마든지 찾을 수 있다.

4. 하루에 한시간 이상 강아지와 시간을 보낸다.
맥스: 하루에 한시간 정도 걷거나 뛴다. 유대감이 증진된다.
아담: 하루에 한시간 정도 아담이 하고 싶다는 것을 함께 한다. 아담은 뉴욕 시내를 돌아다니며 사진찍는 것을 좋아한다. 코끝이 찡하도록 춥더라도 방한 내복을 입을지언정 무장을 하고 나가서는 즐겁다는 표정으로 함께 시내를 쏘다닌다.

물론 트레이닝이란 말에서 알 수 있듯이, 위 규칙들을 매일같이 지키기란 무한한 노력과 인내가 요구된다.
하지만, 아직 강아지가 어릴 때 (신혼 초기일때), 훈련을 잘 해놓으면, 오래오래 내가 편하지 않을까 하는 마음으로 난 오늘도 씁쓸히 변기 뚜껑을 묵묵히 내려놓고 나왔다..

사우스 파크에서 강아지 트레이닝 법을 사용해 버릇나쁜 악동을 길들이는 에피소드가 있다. Dog Whisperer 티비쇼를 단 한번이라도 보았다면 강추하는 에피소드이다.
http://www.southparkstudios.com/full-episodes/s10e07-tsst


사진은 구글 홀리데이 파티에서 T가 찍어준 사진..

Siri에게 엉뚱한 질문하기 neutral

내 동생, 우리 지도교수, 그리고 가장 친한 친구 N군이 iphone4s를 샀다.
그리고 하나같이, "Call 몽키, 하면 니 이름을 Siri가 다른 사람으로 착각을 해, 너의 별칭으로 뭘 넣으면 좋을까?" 하고 물어왔다.

동생은 "누나"를 넣었더니 해결이 되었고, N군은 내 이름 마지막 음절만 넣었더니 해결이되었다는데, 우리 지도교수가 뭘로 바꾸어 넣었을지는 잘 모르겠다. 영영 Siri가 나에게 전화거는 것을 성사 못시키도록 방해를 하길 바란다.

울푸람 알파랑 연결이 되어 있기에 Siri는 일반 상식관련 질문을 해도 대답을 한다. 이를테면, "미국에서 가장 인구가 많은 주는?"하고 물으면, "캘리포니아"를 답해준다. 재퍼디 (Jeopardy)식 질문은 잘 대답을 하는 반면, 울푸람 알파는, 아주 추상적인, 혹은 공식으로 변환하기 어려운 질문들은 잘 대답을 못하는데, 이 사실을 잘 알고 있는 얼리 어답터들이 금욜 출시 이후 주말 내내 이상한 질문을 하고, 생각외로 기발한 대답을 들은 사례들을 뉴욕 타임즈 포그 아저씨가 정리를 해 놓으셔서 그 중에 재미난 것만 몇개 번역을 해본다.

You: “What are you wearing?” 너 뭘 입고 있니?
Siri: “Aluminosilicate glass and stainless steel. Nice, huh?” 알루미눔 실리케이트 유리와 스테인레스 철이지. 멋지지?
(우리나라사람들이 애인한테 전화걸어서, "밥 먹었어?"하듯 미국 사람들이 애인한테 전화해서 흔히 하는 질문)

You: “Who’s your daddy?”  너의 아빠가 누구야? (혹은 너의 물주가 누구야?)
Siri: “You are. Can we get back to work now?” 당근 너지. (우리 이런 이상한 질문 그만하고) 이제 제대로 된 일을 하는건 어때?
(이것 역시 약간 sexual connotation이 있는 질문을 재치있게 받아넘긴 사례)



너: 어디서 (마)약을 구할 수 있을까?
시리: 너를 위한 재활센터를 두 군데 찾았어.
(정말 강한 시리...)


너: What is the meaning of life? 인생이란 무엇일까? (인생의 의미란 뭘까?)
시리: “I don’t know. But I think there’s an app for that.” 잘 몰라. 분명 그걸 위한 (애플)앱이 있을꺼야. (큭큭 재미있는 답변이다. 왠만한 기능을 위한 애플앱이 존재하는 상황을 재치있게 애들립해준 답변)

시리: “Try and be nice to people, avoid eating fat, read a good book every now and then, get some walking in and try to live in peace and harmony with people of all creeds and nations.”
사람들에게 착하게 굴고, 살찌는 음식 그만 먹고, 이따금씩 좋은 책을 읽고, 가끔 산책도 하고, 사람들과 평화롭게 사는 것. (법정 스님이 했을 법한 답변)

시리: “I give up.” 난 포기했다고. (가장 맘에 드는 답변, .... 나도 포기했음..~~)

시리: “Life: a principle or force that is considered to underlie the distinctive quality of animate beings. I guess that includes me.” (이건 울푸람 알파가 백과사전을 긁어온 듯하다.)

시리: “To think about questions like this.” 이런 생각을 해보라고 있는게 아닐까? (재치있는 답변)

시리: “42.” (이건 히키하이커 가이드 책이나 영화를 봐야 이해할 수 있는 대답이다.)

시리: “Life: the condition that distinguishes animals and plants from inorganic matter including the capacity for growth, reproduction functional activity and continual change preceding death.” (이것 역시 어느 백과사전에서 긁어온 듯한 답변)

시리: “I can’t answer that now, but give me some time to write a very long play in which nothing happens.” 지금 당장 대답하기 힘들고, 시간을 약간 주면, 아무일도 일어나지 않는 연극을 하나 써주지. (이건 뭐?!@#$$%??)

스티브잡스 + HCI + 잡상 research

잡스 아저씨가 세상을 떠났다. 어제 밤부터 오늘 하루 종일 페이스북에 들어가도, 구글+에 가도, 내가 흔히 들어가는 모든 뉴스 웹싸이트에 들어가도 오직 잡스 아저씨에 관한 이야기 밖에 없다. 그만큼 영향력이 있었던 인물. 이곳 저곳에서 두세번씩 본 잡스 아저씨 일대기를 요약하는 비디오나, 앞으로 나올 전기에 관한 일들, 아저씨가 했던 말들, 아저씨에 관한 재미있는 일화들이 많지만, 그런 이야기들은 잠시 접어두고 내 전공 분야와 관련된 잡스 아저씨에 대한 만상을 적어보려 한다. 

잡스 아저씨가 나에게 대단한 이유는, HCI의 중요성을 일반인에게 *완벽한 제품들을 통하여* 일깨웠기 때문이다. 

HCI분야에서 "우리 분야에서 이런걸 개발했어요"하고 자랑스러워 하는 컨셉들이 여럿있는데, 그 중 일반인이 애플에서 했지? 하고 흔히 착각하는 두가지 예를 들어본다. 그래픽 유저인터페이스 (GUI, 애플 컴퓨터에서 처음으로 선보였다) 그리고 멀티터치 인터렉션 (multitouch, 아이폰 지도 확대 축소 등에 사용되는 기술) 같은 것은 사실 처음 연구소에서 (GUI: Xerox Parc, Multi-touch: MERL, diamond touch) 발표된 테크닉들이다.   연구소 내에서는 대단한 발견이고 모든 사람들을 흥분하게 하며, 이후 저자들은 숱한 citation count에 뿌듯해했을지 모르지만, 외부인에게는 "그래서 뭐?" "그게 그래서 왜 좋은건데?" 코방귀를 뀌게하는 우물안 개구리 잔치에 불과했다. 

 GUI가 사용하기 편리하다는 것은 사실이지만, 유저 인터페이스를 제공하기 위해 (당시 기준으로) 어마어마한 컴퓨팅, 메모리 리소스가 필요하였고, 과연 GUI가 그 값어치를 할만큼 컴퓨터를 다루는데, 꼭 필요한 것인지 모두 긴가민가하였기 때문이다. 멀티터치 기술은 사실 1999년 미스비치 연구소 (MERL) 에서 다이어몬드 터치라는 테이블 위에서 시연한 기술이다. 하지만, 모바일 폰에 이 기술이 탑재되기까지 8년이라는 세월이 걸린 이유는? 멀티터치를 지원하기 위한 전원 소모, 인터페이스 디자인 등등에 대한 부대비용이 꼭 지불해야하는 비용이라고 확신한 소프트웨어+하드웨어 업체가 없었고, 일종의 사치 기술이라고 생각했기 때문이다.

컨퍼런스에 매해 참석하면 (예: SIGCHI, UIST) 정말 재미있고, 획기적인 HCI기술들이 매해 매우 많이 쏟아져 나온다. 논문 발표를 들뜬 마음으로 열심히 쏠쏠거리며 돌아다니면서 듣다가 학계가 아닌 회사에서 방문하신 분들을 만난다. 그리고 내가 너무나 즐겁게 들은 그분들이 오신 회사에 쓸모가 있을 것 같은 기술들에 대해서 침을 튀겨가며 설명을 하고, 그분들의 견해를 여쭙는다. "차세대 제품에 이런소형 프로젝터 기술이, 3D 디스플레이 기술이, 센서 기술이 (예는 무궁무진하다) 탑재된다면, 너무나 혁신적일것 같아욧~!!!" 그러면, 다음과 같은 고질적인 문제점들이 산재해있음을 그 분들이 알려주신다. "전원 소모가 너무 많기 때문에, 소비자들이 원하지 않을거에요", "협력업체에서 API를 제공하지 않기 때문에 쉬운 일이 아니에요", "그 기술을 원할만한 소비자층이 과연 충분히 있을지 몰라서 마케팅 부서에서 승인을 하지 않을 가능성이", "현재 나의 보스 비전이랑 매우 상이한 컨셉이라서 힘들 가능성이", "현재 프레임워크에서 지원하지 않는 기술이 있어서 운영체제를 모두 뜯어 고쳐야하는데, 그 작은 기술을 넣기 위해 운영체제를 바꾼다는게 말이 안되기 때문에", ...기타 등등등.. 한국, 미국할꺼 없이 일본, 독일, 체코 기타 등등 기업에서 오신 분들의 고충은 모두 모두 비슷하다. 한결같이, "현실성이 좀 떨어져요"라는 얘기를 해주신다. 근데, 사실 난 질문하기 전부터 그분들이 어떤 문제점을 이야기하실지 눈썹끝만 보고도 감이 온다. 왜냐면, 랩에서 나부터가 이런 문제점에 끊임없이 봉착하기 때문이다. 연구를 하면서 어떤 재미있는 HCI 아이디어를 착상하고 그것을 구현하는데는 오랜 시간이 걸리지 않는다. 맥시멈 2주? 하지만 유저스터디 사용자에게 손에 넣어줄만한 프로토타입을 만드는 데는 그에 10배 이상에 해당하는 시간이 소요된다. 일반 사용자에게 완벽한 제품을 제공하는데는 다시금 10배가 넘는 힘이 들지 않을까? 잡스는 위에서 내가 나열한 그 모든 것을 극복한 것이다, 배터리 기술에 무한한 자원을 투자했고, 운영체제를 아예 처음부터 다시 다 만들었으며, 제3업체와 협력하며 받을 수 없는 스펙, API등에 관한 문제점을 타진하기 위해, 하드웨어부터 소프트웨어까지 모두 도맡아하고 있으며, 모바일 라이푸에 대한 비전과 이에 대한 확신을 가지고 소비자층을 새로 창출해냈다. (이외에도 iphone, itunes의 성공까지는 아주 많은 역경이 산재했다)

그 노고를, 신념을 가지고, "지독한 리더"란 혹은 "독선" 등등의 안 좋은 소리를 들어가며, 끝까지 밀어부칠 수 있었던 스티브 잡스. 그리하여, 누군가 나에게 "HCI가 무엇인가요?"라는 질문을 하면, "손에 드신 아이폰의 손가락을 집게처럼써서 확대 축소 등을 할 수 있는 기술을 만드는, 인간에게 컴퓨터를 더 사용하기 편한 기술들에 대해 고민해보는 학문이에요"라고 쉽게 설명할 수 있게 해준 대단한 CEO. 

이전에 누군가가, HCI분야에서 개발된 기술들이 상용화하는데 얼마나 걸리나요? 라고 질문을 하면, "대게 8~10년 정도 걸려요"라고 이야기하곤 했는데, 잡스 아저씨와 같은 분이 사라짐과 함께 이제 우리 분야 연구원들이 "이전에는 8~10년 정도 걸렸는데, 지금은 10~20년 정도 걸리죠"라고 얘기하게 되는건 아닐지... 

-----------
15분만에 쓴 글이라 레퍼런스 등을 안 달았습니다. 답글로 물어봐주시면, 찾아서 달아 놓겠습니다. 




운동에 미치다 nyc

뉴욕은 gym이 진짜 비싸다. 그래서 아쉬운데로 난 요즘 자전거 타기와 조깅에 미쳐가는 중이다.

지지난 주 토요일날은 아담이랑 NYC Century ride라는 이벤트에 참여했다. 35/55/75/100 마일 중 한개의 구간을 정해서 하루 종일 자전거를 타는거다. 55마일을 한꺼번에 쉬지도 않고 타는게 아니라, 지쳐서 포기하고 싶을 생각이 모락모락 들때쯤 pit stop (휴식처?)이라는게 있다. 아침 혹은 간식 혹은 점심을 마련해놓고, 화장실도 있으며, 물과 게토레이 등을 비치하고 있다. 여기서 대략 10분 정도 정신을 차리고 나면, 다음 15~20 마일을 탈 기운이 생긴다.

코니 아일랜드 및 해변가에 아직까지 한번도 안 가봤는데, 자전거 코스가 이곳을 지나가기에 구경할 수 있었다. 맘에드는 장소에서 막무가내로 내려서 구경하고, 사진찍는 재미가 참 좋았다. pit stop 및 경치가 좋은 곳에서 너무나 많이 쉬었다 자전거를 타서 average speed가 별로 높지가 않다. 그러거나 말거나..55마일을 달린게 자랑스럽다.

이날 맨하탄과 브루클린, 그리고 퀸즈를 연결하는 다리를 3개를 자전거로 건넜는데, 타는 동안 정확하게 반 정도는 진짜 기분이 끝내준다. 다리들이 대게 지상으로부터 10층 정도 되는 높이에 지어져 있기때문에, 하늘을 나는 느낌이 들기 때문이다. 정확히 반만 재미있는 이유는? 오르막은 정말 죽음이다. 앞에 가다가 사진찍겠다고 갑자기 멈추어 서는 라이더때문에 자전거를 서버려야했을때는 칼을 꼽고 싶은 심정마저 들었다.

Run keeper라는 아이폰 앱으로 경로와 속도 기타등등을 추적하게 하고, 일주를 마치자마자 너무나 스스로 대견스러워서 페이스북에 포스팅 옵션이 있길래 포스팅 OK!를 했다. 그리고 집에 가는 길에 아이폰이 아주 심하게 "얼굴책 코멘트""얼굴책 코멘트" 알람음을 울려대었다. 도데체 왜 이렇게 난리가 났나 들여다 봤더니, 내가 이 자전거 라이드 있기 이틀전쯤 조깅을 했는데, 아이폰앱이 내가 조깅을 한 줄 알고. "달리기 55마일 / 6시간 XX분" 이라고 공지를 해 놓은 것이다. 일테면 마라톤을 6시간 동안 그것도 두번이나 뛴것!


우리집 잡종견 종자가 너무 궁금하여, 강아지 DNA테스트를 해보았더니, 50%가 Australian cattle dog이라는 목동견이었다 (삼대 지랄견으로 유명한 비글종자는 1/4). 대게 목동견들은 활동량이 아주 많고, 원하는 만큼 운동을 안해주면 이상성격에 시달린다. 살도 빼고 싶기도 하고 이러저러한 이유로 요즘 거의 매일 맥스랑 3~5마일씩 샌트럴파크 주변을 미친듯이 뛴다. 강아지랑 보조를 맞추어서 열심히 뛰면, 신기한지 관광객들이 막 셔터를 눌러댄다. 정체모를 flickr어느 앨범에 내 사진이 뉴욕 여행기편에 있지 않을지 걱정된다. 뛰기 시작할때는 리쉬를 이리 끌고 저리끌고 난리를 치다가 3마일 쯤부터 헥헥거리며 내 뒤를 따라 열심히 따라오다가, 집에 와서는 완전 탈진해서 열라 잘자는 맥스.. (맥스땜시 약간 여기저기서 쉬고 물도 먹여줘야하기 때문에, 속도는 그리 빠르지 않다)

아드레날린에 중독된 나날을 보내고 있다..

내가 구글 인터뷰 준비한 과정 neutral

지난 주 목요일날 아침 10시반 구글 마운틴뷰 리쿠루터한테 전화가 왔다.
"지금 전화 가능하니?"

정확히 2주 전, 구글 마운틴 뷰 본사에 가서 풀타임 소프트웨어 엔지니어 인터뷰를 한 결과를 알려주기 위한 전화였다.
그리고 결과는,
합격..

무엇보다 아담이 가장 기뻐했다.
아담: "허니야, 우리가 구글 인터뷰를 한번만에 붙은 첫번째 커플이 아닐까?"
몽키: "그럴리...가 없지 않을까 (전산학 커플들이 갈 수있는 대기업이 몇 안되니까)?"

재미있는 것은, 내가 구글 인터뷰를 할 즈음, 나에게 구글 인터뷰 과정에 대해서 물어보고 싶어하시는 분들이 몇분 계셨다. 일부는 내가 구글 인터뷰를 하는 사실을 전혀 몰랐지만, 아담이 구글에 다니기에 여쭤보고자 하는 분들도 계셨다는 것이다. 그 분들을 위해, 내가 어떻게 준비했는지를 간략히 쓴다. 나에게 실제로 던져졌던 문제들을 적을 수는 없지만 (구글에서 절대 공공 포럼이나 블로그 등에 적지 않을 것을 강력하게 권고한다), 내가 어떻게 준비했는지, 뭐가 도움이 되었는지, 적는 것은 문제가 될 것 같지 않다.



다음 책 세권을 추천한다.

아담이 폰 인터뷰 하기 전에 읽었다길래, 나도 폰 인터뷰 하기 전에 한 3일 날을 잡고 정독했다. 주제별로 어떤 인터뷰 문제가 가능한지 잘 요약해놓은 책이다. 풀이를 바로 읽기보다는 내가 일단 Eclipse에서 코드를 짜보고, 비교해보았다. 잘 검색해보면 pdf본을 찾을 수 있다. 난 소스코드가 여러 페이지에 걸쳐서 indentation도 엉망진창으로 찍혀있는것도 싫고, 이클립스에 복사해오기도 힘들어서, 학교 도서관 ebook링크를 이용해서 읽었다.
온싸이트 인터뷰 하기 이전에 아는 중국 친구가 "난 이게 도움이 많이 되었어"하면서 pdf를 보내 주어 읽은 책이다. 마이크로소프트, 애플, 구글 등 주요 IT기업의 인터뷰를 담당했던 소프트웨어 엔지니어가 만든 책이다. 내용자체는 참 훌륭하다. 그런데, 내 개인적인 견해로는 교정을 한번 더 보기 전에 책을 출판하지 않았나? 하는 느낌이 드는 책이다. 이 책에 solution으로 제시된 소스 코드 중 일부는 잘 짜여진 것도 있지만, 일부는 컴파일이 안되는 소스코드가 꽤 있다. 그리고 라이브러리에서 data structure를 가져다 사용할 때, 왜 그 자료구조를 가져다 사용했는지 이해가 안갈때가 많다. 예를 들어 java에서 같은 기능을 하는 HashTable과 HashMap자료 구조가 있다. HashTable은 thread reliability가 좋고, HashMap은 performance가 좋다 (thread-safe하지 않기 때문에) 이걸 뒤죽박죽으로 써놓았다. 이책 예제와 실제 인터뷰 난이도를 비교하자면, 이 책 마지막 두 장에 나오는 문제들 (19. Moderate 20.Hard) 그리고 앞장에 나오는 쉬운 문제들을 골고루 온싸이트 인터뷰에서 물어본다고 생각하면 된다.


아래 소개할 steve yeggy 블로그 포스트에서 너무나 많은 사람들이 추천을 하길래 읽은 책이다. CLRS책이 이론 중심으로 알고리즘을 풀어 놓았다면, Skiena는 알고리즘을 실제로 시스템을 구축할 때 어떻게 사용해야하는지, 어떤 점을 주의해야 하고, 어떻게 일반화하여 자료구조를 접근해야 하는지 진짜 잘 분석해놓았다. 난 위에 소개한 두개의 책에 적힌 문제들을 풀면서, 문제와 연관된 자료 구조에 대해 이 책을 사용해서 분석하면서 공부하였다.

이책을 1장부터 18장까지 다 읽는데 꼬박 일주일 걸렸는데, 내가 만약 구글을 선택하지 않고 교수직을 선택할 경우, 내 자료구조 수업시간에 써야겠다는 생각을 하며 너무나도 재미있게 읽은 책이다. 어려운 부분은 아담이랑 함께 몇시간씩 토론을 해가며 책을 읽었다. 꼭 인터뷰를 위해서가 아니라도, 전산학을 업으로 하는 이에게 추천하고 싶은 책이다.


그리고 인터뷰를 준비하면서 북마크 해놓은 웹링크가 여럿 되지만, 그 중 다음 4개를 추천한다.
[1] http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html
구글 인터뷰를 어떻게 준비해야하는지, 구구절절 풀어놓은 포스트이다. 포스트 자체도 유익하지만, 답글들이 진짜 유익하다. 스티브 예기를 아는 구글러들이 답글을 많이 달아놓았다. 포스트와 답글에 내가 하고 싶은 이야기가 다 써져있다. 특히, 스티브 예기가 mock-up interview의 중요성에 대해서 써 놓았는데, 만약 누군가가 나에게 "온싸이트 인터뷰를 하기 전, 이틀이 남았는데, 뭘 하는게 좋을까요?"라고 하면, 나 역시 "mock-up interview를 적어도 두번 해보세요"라고 할 것이다. 꼭 구글에 다니는 친구가 아니어도 되고, 심지어는 랩에 있는 다른 전산학 전공하는 친구를 붙잡고, 예상 문제를 설명해보는 것조차 너무나도 도움이 된다. 왜냐하면, 내가 실제로 알고 있는 것들을 조리있게 설명하는 것이, 내 머리속에 뭐라도 하나 더 채워넣는 것보다 훨씬 값지기 때문이다.

[2] http://thenoisychannel.com/2011/08/08/retiring-a-great-interview-problem/
구체적으로 실제 인터뷰 문제가 어떻고, 어떤식으로 꼬리 문제가 만들어지는지 이 웹싸이트에서 아주 잘 설명을 해 놓았다. 내가 친한 Google에 다니는 친구한테 모의 시험을 한번 진행해주면 안되겠니? 하고 물어봤을 때, 그 친구가 "이 문제는 이제 더 이상 인터뷰에 사용하지 않지만, 준비한는데 도움이 많이 되니까 해보자" 하고 가져온 인터뷰 문제였다. 내가 인터뷰를 준비하기 전 대략 4번 정도의 모의 인터뷰를 해보았는데, 그 중 가장 도움이 되는 모의 인터뷰였다. 참고로 친구와 함께 이 문제를 모의로 풀때, 나는 마지막 단계까지 가지 못하였다. O(2^n) 구현까지 완벽히 하고 나자 (버그푸리) 40분이 지났고, 메모이션을 이용한 O(n^2) 구현방법에 대해서, 그리고 기타 scalability, memory limitation등에 대해서 마지막 5분동안 디스커션먼 하였을 뿐, 실제 구현하지는 않았다.  

그대신, 난 위 웹페이지에서 다루고 있는 토론 내용 이외에도 친구와 이 간단한 문제를 가지고 대단히 많은 토론을 하였다. 난 NLP를 들었기 때문에, Context free grammer까지 시작해서, bigram, markov model, word frequency 등등 그리고 dictionary구현에 대해서까지, 모의 인터뷰를 하면서 심도 있는 이야기를 하였다. 친구의 평은, 프로그래밍을 끝까지 다 할 줄 아는 것도 중요하지만, 나의 경우 문제를 제대로 진단하고, 분석하고, 고급 기술들을 적용할 수 있는 능력에서 후한 점수를 줬을꺼라고 말해주었다.  

요지는, 구글 인터뷰 문제들을 대부분, 아주 간단한 문제부터 시작하여, 문제를 어떻게 재정의하는가를 살펴보고, 그 이후recursion, discrete math, thread safety, scalability, nlp, library api, 등등을 많은 것을 한번씩 다 건드린다. 그래서 처음 문제를 받았을 때, "이건 stack, queue 를 사용하는 거잖아?"라고 단정짓고 문제를 스스로 제한해버리면, 인터뷰어가 원했던 답의 80%를 놓치게 된다. 처음에는 stack, queue문제인 것 같다가도, graph를 사용하고, dynamic programming까지 원하는 문제이기가 십상이기 때문이다. 동시에, 자기가 문제에 관해 알고 있는 기술들이 있으면 (삼천포로 빠지지 않는 선에서) 마음껏 설명하고, 토론하고, 인터뷰어와 함께 고민을 하고 오는 것이 도움이 된다는 얘기를 하고 싶다. 

[3] http://www.careercup.com/page?pid=google-interview-questions
[4] http://interviewquestionsbank.com/tags/Google-interview-questions/?sort=active&page=1

위의 두 웹페이지는, 실제 구글에서 질문한 문제들을 사람들이 포스트해놓은 데이타뱅크이다. 그런데, 주의할 점은, 대부분 인터뷰에 낙방한 친구들이 올려놓은 문제이기 때문에, 일반 인터뷰 문제들이 a->b->c->d->e 단계로 구성되어 있다면, 이 웹싸이트에 올라온 문제들은 a 혹은 b단계의 문제만 올라와 있는 경우가 많다. 그리고 일부 퍼즐 문제들은 소프트웨어 엔지니어들한테 물어보는 질문이 아니라 마케팅하는 사람들한테 물어보는 퍼즐 문제들도 있으니, 어떤 문제가 소프트웨어 엔지니어에게 물어본 질문이었는지 잘 알아봐야한다. 이렇듯 여러 이유로 신뢰할 수 없는 데이타 뱅크이지만, 그럼에도 불구하고 내가 엄선한 인터넷 웹페이지 중의 하나인 이유는? Programming Interview Exposed와 Cracking the Coding Interview 책에 나온 문제들은 2~3년 전에 사용되었던 문제라 더 이상 질문하지 않는 경우가 많다. 그에 비해 위 웹싸이트에는 (불완전할지 몰라도) 최근 문제들이 올라와있다. 그래서 약간 눈여겨 봐야한다.


이밖에 인터뷰를 위해서 특별히 한 것은 아니지만, 인터뷰를 하면서 도움이 되었던 것들이 당연히 있다. 구글에서 배포하여 사람들이 많이 사용해본 map reduce라던가, go 프로그래밍 언어 같은 것을 알아서 나쁠 것은 없다. 인터뷰를 하면서 짜투리 답으로 내가 꺼집어 내었다가 약간 플러스가 된 것 같았었다. 또, 구글 product들을 미리 약간 알고 있어서 인터뷰가 다 끝났을 때, 내가 이미 잘 알고 있는 product그룹에서 온 인터뷰어에게 아주 핵심을 찌르는 질문을 하는 것도 플러스가 될 수 있겠다. 인터뷰 있기 한달 전쯤 심심해서 들척인 computer graphics책의 어떤 concept를 인터뷰어에게 "너에게 필요한 것이 이런 기술이 아니겠니?"라고 설명해주었는데, 인터뷰어가 바로 "우리팀에 이런이런 자리가 있는데 관심있니?"라고 묻기도 하였다. 마지막으로, 스티븐 레비의 In the plex책이 구글에 대해서 참 잘 써놨다. 난 오디오 북으로 구입하여 심심할때마다 듣곤 했었는데, 구글 회사 문화를 이해하는데, 구글러들이 생각하는 방식을 이해하는데, (간접적으로지만) 많은 도움이 되었다.

지금은 이렇게 여유롭게 지난 한달을 회상하며, 내 경험담을 쓰며 조언을 하고 있지만, 온싸이트 인터뷰가 끝난 직후, 사실 내 스스로 내린 결과는 "낙방"이었었다. 인터뷰어 중 한명은 내가 특히 약한 부분 (Design pattern, 한번도 배운 적도 없고, 따로 공부한 적도 없다) 개념을 사용한 코딩을 시키고자 하였다. 인터뷰 하는 도중 concept을 배우고, 방금 배운 개념을 적용해서 코딩을 해내야했는데, 진짜 식은땀이 났다. 인터뷰어가 나가고 나서, 탁자에 내 땀이 뚝하고 떨어지는 것을 보고서야, 내가 긴장했었다는 것을 깨달았다. 그래서 인터뷰가 모두 끝나자마자 아담에게 전화해서 질문한 것은, "인터뷰 떨어지면, 얼마나 빨리 또 인터뷰를 신청할 수 있는거야?"라는 질문을 했다. 실제로 아담이 아는 분 중, 인터뷰를 세번 낙방하고, 네번째에 붙어서 구글에 다니시는 분도 계시다. 어느 회사나 다 그렇듯이 인터뷰 프로세스는 아주 다양한 요소가 작용하여 당락이 결정되는 것이기 때문에 결과가 매우 random할 수 있고, 구글도 예외는 아닌 듯 싶다. 그래서 난 천번 만번 이렇게 생각한다. "운이 좋았을 뿐" 이라고.



1 2 3 4 5 6 7 8 9 10 다음


통계 위젯 (화이트)

1579
15
129983