8 min read

읽어보면 당연한 실리콘밸리 원격 코딩 면접 팁

이 문서는 아래의 경험에 근거하여 작성되었음을 알립니다.

  • 제 구글 인턴을 위한 기술 면접을 준비하고 치렀던 경험
    • 소프트웨어 엔지니어 인턴이었고 캘리포니아 써니베일에서 일하다 왔습니다
    • 준비 시기는 2018년부터 2019년, 인턴 다녀온 건 2019년 7월-10월 (COVID 이전)
  • 지인 한 분의 구글 정직원 합격을 위해 모의 면접을 해드린 경험
    • 그분은 소프트웨어 엔지니어로 합격해서 잘 다니고 계십니다
    • 모의 면접을 봐 드린 시기는 2021년 상반기입니다 (COVID 팬데믹 중)

따라서 "실리콘밸리 코딩 면접 팁"이라기보다는 "구글 코딩면접 팁"에 가깝고 [1], 작성일 기준 2년 이상 오래된 경험을 바탕으로 쓰였음에 유의해 주세요. 경험의 폭이 넓지 않으므로, 다른 분들의 면접 후기나 관련 서적 등도 충분히 참고해 주세요. 아울러, 두 사례 모두 대면 면접이 아니고 원격 면접이었습니다.

그리고 이 글을 보는 "당신"에 대한 가정이 있습니다.

  • 자신이 주로 사용하는 언어를 메모장에 써가면서 사람이 알아볼 수 있게 코딩할 수 있을 정도로는 능숙합니다. (100% 문제없이 컴파일 또는 실행 가능한 결과물을 내놓지는 못하더라도)
  • 영어로 된 문서를 많이 읽어봐서, 활자로 쓰인 영어에는 어느 정도 익숙합니다.
  • 그러나 영어를 입에 담을 기회는 좀처럼 없어서, 말로 하는 영어는 서투릅니다.

이게 딱 제 상황이기도 했습니다. 그러면 어떤 마음가짐이 도움이 되었을까요?

공책에 쓰면서 말합시다

면접 시간이 되면 Google Meet 화상회의에 참여하고, 빈 Google Docs 페이지에 문제가 주어지며, 그 문서의 여백에 코딩하며 자신의 사고 과정을 설명해야 합니다.

활자로 쓰인 영어(Written English)에는 강하지만 말로 튀어나오는 영어(Spoken English)에는 약한 우리에게 가장 큰 난관은 Spoken English를 구사하기 위해 머릿속이 꽉 차버리고 본래 내가 발휘할 수 있는 깊은 사고력을 상실하는 현상입니다.

물리적인 공책을 일종의 "스왑 영역"으로 사용하는 것이 큰 도움이 됩니다. 노트와 펜을 준비하세요. 어차피 노트에 끄적이는 내용물을 원격으로 참여한 면접관이 볼 수 있는 것도 아니니까요.

입이 떨어지지 않을 정도로 나 스스로가 얼어 있다면, 말하고자 하는 문장을 대충이라도 써 내려간 후 따라 읽어도 좋습니다. (실제로 제가 면접 현장에서 그렇게 했습니다.) 당연히 써 내려가는 동안은 잠깐의 정적이 있겠죠. 그걸 무서워할 필요는 없습니다 [2]. 처음부터 끝까지 문장의 모든 단어를 적어 완성하지 않더라도, 조금 적다 보면 머릿속이 정리가 되고 말을 할 수 있는 상태가 되거든요. 그렇게 위기를 벗어날 수 있습니다.

공책은 깊은 사고력을 소환하는 데에도 의미가 있습니다. 예제를 떠올리고 이렇게 저렇게 대입해 볼 수도 있고, 트리나 그래프를 그려가며 문제를 시각화하는 데도 유용하고, 이전에 떠올랐던 생각으로 되돌아가는 데 쓸 수도 있습니다.

그렇다고 무언가를 끄적이는 것이 절대적인 건 아니에요. 입이 움직이는 상황에서는 입을 움직이면 되고, 손이 움직이는 상황이면 손이 움직이면 됩니다. 입과 손 모두가 얼어서 사고의 진행이 막혀버리는 현상만 방지해도 면접을 치명적으로 망쳐버리는 상황은 상당 부분 예방이 가능합니다.

예제를 넣어가며 문제를 이해합시다

"예제"에는 아래 3가지 기능이 있습니다.

  • 내가 문제를 잘 이해했는지 검증하는 데 사용됨
  • 로직을 짜 본 후 로직을 올바르게 작성하였는지 검증하는 데 사용됨
  • 발산적인 사고를 통해 예외적인 경우를 발견하는 데 사용됨

가령 product of last k 문제를 푸는 상황이라고 생각합시다 [3]. 문제의 설명을 읽은 후, 여러분은 Google Docs에 아래와 같은 예제를 들어 자신이 문제를 올바르게 이해했는지 확인합니다.

  • k=3 일때,
    • 5가 add 된 상황에서 getProduct를 하면 → 5
    • 여기에 8을 add하고 getProduct를 하면 → 40
    • 여기에 -4를 add하고 getProduct를 하면 → -160
    • 여기에 2를 add하고 getProduct를 하면 → -320이 아니라 -64

이 설명에 면접관이 동의하는지 확인하고 코딩으로 넘어감으로써, 여러분은 잘못된 이해를 바탕으로 코딩을 시작하여 시간을 허비하는 위험을 예방할 수 있습니다. 여기에 더하여, 여러분이 코드를 작성한 후에는 바로 완성을 선언하지 말고, 앞서 들었던 예제의 숫자를 실제로 대입해 봄으로써 로직이 의도한 대로 작동하는지 스스로 파악할 수 있습니다.

또한, 예제를 들기 위해 이런저런 입력값을 넣어보는 과정은 예외적인 경우를 발견하는 데 큰 도움이 됩니다. 가령 바로 위 product of last k 문제에서는, 0 이 add되는 경우를 생각하지 않으면 큰 문제가 됩니다. 이러한 예외적인 경우는 코딩에 돌입하기 전에 최대한 미리 파악하는 것이 좋습니다. 왜냐하면,

  • 예외적인 경우가 없다고 일단 가정하고 로직을 짠 후, 예외적인 경우를 방어하도록 로직을 개량하는 단계를 거칠 수 있습니다. 그런다고 하더라도, 예외적인 경우의 존재를 염두에 둔 상태에서 시간을 안배하는 것과 그렇지 않은 것의 차이는 큽니다.
  • 예외적인 경우를 발견하고 "혹시 이런 입력이 올 수 있나요?" 라고 clarification 질문을 하는 것 자체가 면접관 입장에서 가산점을 줄 이유가 되기도 합니다.

그 외 진짜 미세팁

면접 말미에 면접관이 "저에게 하고싶은 질문 있나요"라고 할 때가 있는데, 정말 궁금한게 있다면 그것을 질문하시되 딱히 할 질문이 떠오르지 않는다면

  • What's the best part of working for [회사이름]?
  • Tell me (more) about your role in your team.

같은 질문으로 넘기시면 됩니다. 면접관 입장에서 부담없이 답변하기 쉽고, 그 설명을 들은 내가 "Oh interesting, thank you"를 외치며 훈훈하게 빠이빠이 할 수 있는 질문이거든요.

[1] 심지어 면접을 보는 구글 직원들간에도 답안을 평가하는 시선이 제각각입니다. 가령 제가 인턴을 볼 때 면접에 들어왔던 분은 의사코드(pseudocode) 로 충분히 만족했지만, 저와 함께 인턴십을 수행했던 다른 분의 면접관은 컴파일 가능한 완전한 코드를 원했었거든요.

[2] 정 정적이 길어질 것 같다면 면접관에게 "give me a moment" 를 외치고 고민하는 시간을 요청할 수도 있겠죠.

[3] 이 문제는 너무 유명해져서, 더 이상 출제되지 않도록 구글 내부적으로 금지되었다는 이야기가 있습니다.

Jangho Seo