Karen
6k
2017-02-10 17:02:29.0 작성 2017-02-10 17:04:13.0 수정됨
6
3893

달달 맵싹! 양파의 개발 이야기 - 해외 개발자 코딩 면접에 관하여


해외 개발자 코딩 면접에 관하여 -

제가 경험했거나 친구들에게 주워들은 내용입니다.

--------

1. 자기소개


* 우선은 가볍게 자기 소개부터 시작한다. 지금 직장에서 하고 있는 일 얘기하고, 짧게 경력 얘기하고 등등. __짧게__ 해야 한다. 5분 이내.


- "제가 (큰 규모의 프로젝트를) 혼자 책임지고 구현해서..." => 안 좋아함.
소프트웨어에서 일이 년 있는 사람들도 아니고 어느 규모에 몇 명 들어가는지 대강 아는데 혼자 했다면, 겉핥기로 흉내만 냈거나, 프로토타입만 만들고 프로덕션 코드로 쉬핑 안 했거나, 아니면 잘났지만 성격 문제.
  • 1) 주위에 진짜 실력 없는 사람만 있어서 유아독존, 혼자 잘난 걸로 생각함
  • 2) 그러므로 우리 팀에 들어와도 지가 제일 잘났다고 생각할 수 있고, 리드 안 만들어 준다고 삐지거나 뭐 등등 부딪힐 가능성 큼
  • 3) 진짜 혼자 제일 잘나서 다 맡아서 일한 거 같으면, 다른 사람들이랑 일 할 줄도 모르고 기본적인 소프트웨어 라이프사이클 경험 못했을 가능성도 있음

- "요즘 업계 최고의 기술인 XX 를 도입해서 YY 를 구현하였는데 그것이 아주 성공적이어서 유저들에게 ZZ 한 반응과 함께 $$ 의 매출을..." => 이것도 좀.
말하는 게 우선 너무 매니저스러움.

개발자스러운 답변은
"아실지 모르겠지만 XX 라는 기술이 있는데 저희가 풀어야 했던 문제는 YY 였으므로 ZZ 방식으로 구현 시도를 했습니다. 그러면서 배운 거라면 AA 는 이런 면이 좋아서 어느 정도 좋은 결과였던 것 같고 BB 는 이러이러한 문제가 있어서 저러저러하게 대처를 하였음" => 이상적인 답변.
여러 각도로 문제를 바라볼 수 있으며 객관적으로 좋은 점 나쁜 점을 나열 할 수 있고, 나쁜 점은 어떻게 극복하였는지도 디테일 말할 수 있음 플러스.



2. Coding : 좋지 못한 Coding Test



* 그 다음은 코딩.


- 문제 내주니까 혼자 막 고민하다가 일필휘지, 파죽지세의 기세로 화이트보드에 쭉 써내려감 => 많이 안 좋음. 

- 아주 고수준의 수학을 이용하거나 복잡한 알고리듬 사용 => 이것도 사실 안 좋음. 박사학위 받은 사람들 안 될 때 보통 이 케이스. 

- 아무 질문 없이 그냥 풀어버림 => 역시 안 좋음. 

- 이렇게 저렇게 풀겠다고 말은 잘 하는데 정작 코딩은 손이 느려서 정해진 시간 내에 못 품 => 이건 뭐 당연히.



3. Coding : 이상적인 Coding Test


이상적인 코딩 풀기: 


- 문제를 냈으면 그것을 다시 정리해서 자기가 확실히 이해했는지 확인.
그리고 그 방면에 경험이 있음을 드러내는 질문을 함.
예를 들어 문제가 "퓨전 떡볶이 레시피를 써라" 라면, 혼자서 줄줄 써내려가는 것이 아니라,
"어떤 식당이죠? 다른 메뉴는 어떤 메뉴가 있지요? 어떤 손님을 예상하고 있나요? 부엌 구조는 어떻게 되어 있죠? 기본적인 재료중에 양념 ㄱ 은 가격이 어떻게 되나요? 기본 가격대를 얼마 정도로 생각하고 계시죠? 테이블 회전이 빠른가요? 반조리 해두고 최대한 빨리 내어 놓을 수 있는 것이 중요한가요?" 등등,
너무 길게 말고 최대한 효율적으로 문제를 풀 수 있을만큼의 질문을 딱딱 찍어서 하는 것. 질문 1-2분 내외로 끝냄.

- 그 다음에는
"그렇다면 제가 이해하기로는 한국 직장인 상대의 중저가 분식집에서 새로운 시도로 퓨젼 떡볶이를 낸다고 가정하고, 가격대는 일인분 3천원, 반조리 해두는 것이 가능하며 특히 고추장을 싸게 구입할 수 있다 치고 레시피를 이런 식으로 만들어 보겠습니다."
뭐 이런 식으로, 어떤 방식으로 문제를 풀 것인지 정리를 해서 말하고 면접관의 동의 구하기.

- 면접관이 그럼 그런 방식으로 해보세요 하면 보드에 문제 풀기를 시작하는데, 코딩 라인 한 줄 한 줄 하면서 설명하기.
"이건 이걸 하려는 거고, 저건 저거 하려고 하는 겁니다" 등등.
이 때 면접관이 잘못을 지적하면 어떻게 반응하는지도 중요. 다른 방법이 없느냐고 물어볼 때
"조금 비효율적이지만 이론적으로는 더 정확한 이런 방법이 있고, 훨씬 빠르지만 이런 문제가 있는 다른 방법도 있겠지만 저는 이러이러한 이유로 이 방법을 선택했습니다"
하면 오케.
믿기 힘들지만 면접관이 지적할 때 발끈하고 쌈붙어서 안 되는 친구들 꽤 있음.

- 다 풀었으면, 시간 제한으로 고려 못한 부분을 쭉 열거하면 플러스 점수.
레시피로 또 비교하자면 퓨전 떡볶이 반조리 준비 과정, 음식 낼 때의 디자인 뭐 등등 풍부한 식당 경험을 보여주는 면을 어필하면 플러스.



* 아무리 문제 잘 풀어도 설명 잘 못하면 풀어놓고 탈락 가능함. 다르게 푸는 방법 제시를 안하고 자기 방식이 옳다고 우기거나, 예외 상황을 열거 할 수 없거나 하면 그것도 안 좋음.

* 나는 이론적인 것을 주로 했다고 하면서 코딩 변명하면 노노. 확실한 코딩 실력 없으면서 디자인이나 설계 하겠다고 해도 안 좋음. 주방장 뽑는 면접에 와서 나는 메뉴 구상만 한다 하면 어쩌라고.

* 쓸데없이 화려한 알고리듬 쓰거나 아는 것 과시용 복잡 설계해도 안 좋음.

* 그 팀이 하는 일에 아주 큰 관심을 보이고, 그 분야에 대해서 잘 알고 있으며 최근에 나온 페이퍼도 쭉 꿰고 있음 합격에 많이 도움됨.

* 아주아주 공돌스러운 취미 있으면 가산점.
  • 비싼 오디오 기기 / 카메라 렌즈 수집 -> X
  • 로보틱스에 관심이 있어서 대회에도 참가 -> O
  • 전자기기에 관심이 아주 많고 최신 기기를 가지고 있음 -> X
  • 심심풀이로 Raspberry Pi 기반 시스템 몇 개 만들어봤음 -> O
  • 취미로 펑셔널 프로그래밍 언어로 프로젝트 몇 개 했음 -> O

* 아참. 경력 십오년 이상, 혹은 화려한 포트폴리오의 완전 고수 프로그래머 아닌 이상은,
"아 전 지금까지 자바 3-4년 했는데 뭐 프로그래밍 언어는 다 비슷하니까 님 회사에서 쓰는 C# 도 문제 안 되겠죠"
이런 소리 하면 괘씸죄 해당.
모범답안 =>
"제 주 언어는 자바이고 지금까지 자바를 주로 해서 C# 는 잘 모릅니다. 윈도 폰 앱 몇 개 만들어 본 적 있고, WCF 기반 웹 시스템 몇 번 구축해본 적이 있네요" => O.
비슷비슷하니 별 문제 안될거라는건 면접관이 할 수 있는 말이지 당신이 할 말은 아님.

* 학벌 이야기는, 어쩌다가 질문에 연결이 되어서 자기가 했던 연구나 과목 공부했던 거 말하는 상황 아닌 이상 나올 일이 없는데, 면접시에 학벌 어필할 일도 있나?? 이제까지 물어보지 않았는데 자기가 직접 학벌 어필한 사람은 없었음. 안물안궁.



4. 결론 및 덧글


결론:
  • 경험 많고,
  • 코딩 하는 거 좋아하고,
  • 내가 왜 이런 선택을 했는지를 잘 설명할 수 있고,
  • 코딩 시작하기 전에 점검 할 수 있는 거 하고 준비해야 하는 것이 뭔지 잘 알고,
  • 문제점 지적하면 수용할 수 있고,
  • 독불 장군 아닌 개발자면 보통은 통과.


덧1: Latex 로 이력서 쓰면 가산점 준다는 거 반만 거짓말입니다. 


덧2: 학벌이나 학점은 안 보는데, __인사과__는 봅니다. 인사과가 좋아하는 이력서는 구직광고에 나오는 키워드가 많이 들어간 이력서입니다. 


덧3: 아래 그림에는 블로그나 그 외 모임 활동 열심히 하는 데에 가산점 준다고 되어 있는데 안 그러는 사람이 더 많았던듯. 특히나 모임 주관하고 이런 건 별로. 개인 홈피도 뭐. 

덧4: 보시다시피 박사학위는 크게 플러스는 아니고, 쓸데없는 기술 넣으면 감점이며 (워드 엑셀 포샵 이런 거 넣지 마셈), 이력서 길어도 감점.
IT 자격증/ 코스 적어도 싫어하는 사람 많고 (할 게 없어서 자격증을 자랑하냐 느낌), (설마 그러겠냐마는) 비쥬얼 베이식을 넣거나 파스칼 넣어도 감점.
보는 사람에 따라서 PHP 나 자바스크립트도 감점 가능하나 펑셔널 랭귀지는 보통 가산점.

물론 최고의 벌점은 스페이스와 탭을 섞어 쓰는, 절대로 용서가 불가능한 도덕적 타락.


아래는 인사과가 이력서 보기 vs 개발자가 이력서 보기.
옛날 자료라 좀 오래된 티가 남. 한글 번역본도 있음.









4
5
  • 댓글 6

  • 줄줄
    28
    2017-02-11 19:23:37.0

    저기...

    "스페이스와 탭을 섞어 쓰는, 절대로 용서가 불가능한 도덕적 타락" <- 무슨 말인가요? 이해가 안되어서요;;

    1
  • 신입이지롯
    12
    2017-02-11 19:59:38.0

    줄줄 제 생각에는 코드작성시 들여쓰기 방식을 '텝'이나 '스페이스'중 하나만 사용하는게 보통인데 그 둘을 규칙없이 혼용하여 사용하는 것을 지적하는 것 같습니다.

    1
  • aselius
    5
    2017-02-14 06:00:12.0

    잘 정리 하셨네요 ㅎㅎ 다 맞는 말들 같습니다.

    1
  • 이민철
    373
    2017-02-15 05:06:25.0

    스페이스와 탭.. 갑자기 미드 실리콘밸리가 떠오르네요 ㅎㅎ

    1
  • 줄줄
    28
    2017-02-15 15:39:03.0

    신입이지롯  들여쓰기할때 보기만 편하면 되는거 아닌가요? 컴파일할때 문제가 발생되나요? 정말 몰라서 여쭙는거예요;;

    0
  • 개발자K
    149
    2017-02-24 17:32:51.0

    어떤 문제도 발생하진 않지만,

    보통 표준으로 코딩규약을 정할때는 들여쓰기는 어떻게 하자는 모종의 약속을 합니다.

    약속을 하지 않더라도, 코딩 리딩을 하는 대부분의 리더는

    약속된 들여쓰기를 하지 않는 것에 예민한 사람들이 많아요.

     

    전 리딩은 하지 않지만, 저 역시도 아주 예민합니다. 

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.