• Google's "Director of Engineering" Hiring Test

  • 구글의 "엔지니어링 디렉터" 면접 문제

  • Recently, I have been interviewed over the phone by a Google recruiter. As I qualified for the (unsolicited) interview but failed to pass the test, this blog post lists the questions and the expected answers. That might be handy if Google calls you one day.
  • 최근에 나는 구글 리크루터로부터 전화 인터뷰를 했다. (신청하지도 않은) 인터뷰 기회를 잡는데는 성공했지만 테스트를 통과하지는 못한 바, 이 포스트에서 질문들과 답변들을 나열해 보고자 한다. 당신에게 구글이 어느날 전화를 하게 되면 유용할지도 모르겠다.
  • For the sake of the discussion, I started coding 37 years ago (I was 11 years old) and never stopped since then. Beyond having been appointed as R&D Director 24 years ago (I was 24 years old), among (many) other works, I have since then designed and implemented the most demanding parts of TWD's R&D projects* – all of them delivering commercial products:
  • 일단 얘기하자면, 나는 37년전(11살때) 코딩을 시작했고 그때부터 멈춘 적이 없다. 24년 전(24살때)에 R&D 디렉터가 되었고 TWD의 R&D 프로젝트들* - 모두 상용화 제품들을 위한 것이었다 - 의 가장 중요한 부분을 디자인하고 구현해 왔었다.
  • - G-WAN (a 200 KB application server with 17 scripted programming languages C/C++, C#, Objective-C, Java, Go, PHP, etc.)
  • - G-WAN (17개의 언어를 지원하는 200KB 용량의 어플리케이션 서버)
  • Google's representative stated that both management and up-to-date coding skills were required (a rare mix). But having exercised the former for more than 2 decades and the latter for almost 4 decades was not enough: I failed to give the "right answers". Is Google raising the bar too high or is their recruiting staff seriously lacking the skills they are supposed to rate?
  • 구글쪽 사람은 관리능력과 최신 코딩 스킬이 필요하다고 했다. (다 가진 사람은 흔치 않을 것이다) 한편 20년 넘는 관리능력과 40년 넘는 코딩 경력은 충분하지 않았던 것으로 보인다: 나는 "정답"을 말하는 데에 실패했으니까. 구글이 허들을 너무 높여놓은 것일까, 아니면 진지하게 저 리크루팅 담당자에게 평가하는 스킬이 결여되어 있는 것일까?
  • Let's have a look!
  • 한번 보자!
  • GOOGLE'S "DIRECTOR OF ENGINEERING" Q&A TEST

  • 구글의 "엔지니어링 디렉터" 문답

  • Here are the "highly technical" questions and their answers – until the test was interrupted as it was obvious that I did not fit the task:
  • 이것들은 "고도의 기술적인" 질문과 답변들이다 - 내가 별로 맞지 않는다고 판단하고 테스트가 중단되기까지.
  • 1. What is the opposite function of malloc() in C?
  • 1. C에서 malloc()의 반대 기능을 하는 함수가 무엇인가요?
  • Me: free().
  • 나: free()요
  • Recruiter: right.
  • 리크루터: 정답입니다.
  • Thought: I imagine that in these rare moments you are supposed to feel proud of your 35 years of programming in the 40-year old C.
  • 생각: 나는 이런 흔치않은 순간에 당신이 40년된 C를 35년간 코딩해왔다는걸 자랑스럽게 생각해야 된다고 본다.
  • 2. What Unix function lets a socket receive connections?
  • 2. 유닉스 함수중에 어떤게 소켓 통신을 받게 해 주나요?
  • Me: listen().
  • 나: listen()이요.
  • Recruiter: right.
  • 리크루터: 정답입니다.
  • Thought: Does this make me really qualify as a network guru?
  • 생각: 이런 질문이 진짜 내가 네트워크 구루임을 검증해 주나?
  • 3. How many bytes are necessary to store a MAC address?
  • 3. MAC주소를 저장하려면 몇바이트가 필요한가요?
  • Me: six.
  • 나: 6이요.
  • Recruiter: right.
  • 리크루터: 정답입니다.
  • Thought: I figure I just earned the [Ethernet] badge...
  • 생각: 내가 방금 "[이더넷] 배지"을(를) 딴 것 같다!!
  • 4. sort the time taken by: CPU register read, disk seek, context switch, system memory read.
  • 4. 다음중 시간이 짧게 걸리는 순서대로 나열하시오: CPU 레지스터 읽기, 디스크 탐색, 컨텍스트 스위치, 시스템메모리 읽기
  • Me: CPU register read, system memory read, context switch, disk seek.
  • 나: CPU 레지스터 읽기, 시스템메모리 읽기, 컨텍스트 스위치, 디스크 탐색.
  • Recruiter: right.
  • 리크루터: 정답입니다.
  • Thought: Typical Computer Science University (1st year) lectures.
  • 생각: 학부 전산과 1학년 강의에서 가르칠 내용이군.
  • 5. What is a Linux inode?
  • 5. 리눅스 inode가 뭔가요?
  • Me: a unique file identifier for any given file system.
  • 나: 파일시스템상에서 파일을 가리키는 유일한 지시자입니다.
  • Recruiter: wrong, it's file metadata.
  • 리크루터: 틀렸습니다. 정답은 파일 메타데이터입니다.
  • Me: the inode is an index uniquely identifying a file on a given filesystem, and you can lookup this index to fetch file attributes like size, time, owner and permissions; you can even add your own attributes on some file systems.
  • 나: inode는 파일시스템에서 파일을 알아보는 유니크한 인덱스고 그 인덱스를 가지고 우리가 사이즈나 생성시간이나 소유자나 퍼미션같은 여러가지 파일 속성을 알 수 있잖아요; 심지어 어떤 파일 시스템에서는 자기만의 속성을 넣을 수도 있고요.
  • Recruiter: wrong, not "attributes", it's "metadata".
  • 리크루터: 틀렸습니다. "속성"이 아니고 "메타데이터"입니다.
  • Thought: "Metadata" is more informative than "file attributes", really?
  • 생각: "메타데이터"가 "파일 속성"보다 더 유용한 단어라고? 레알?
  • 6. What Linux function takes a path and returns an inode?
  • 6. 리눅스 함수중 어떤게 파일 경로와 inode를 반환해 주나요?
  • Me: I wrote a custom LIBC for G-WAN, our app. server, but I can't remember any syscall returning an inode.
  • 나: 제가 우리 앱이자 서버인 G-WAN을 만들려고 커스텀 libc를 만들어봤는데, syscall중에 inode를 리턴하는게 있다는 소리는 못들어봤는데요?
  • Recruiter: stat().
  • 리크루터: 정답은 stat()이었습니다.
  • Me: stat(), fstat(), lstat(), and fstatat() all return an error code, not an inode; they fill a stat structure holding the file attributes discussed previously and not only the file's inode index.
  • 나: stat(), fstat(), lstat(), 그리고 fstatat() 모두 에러코드를 리턴하는거지 inode를 리턴하는게 아니잖아요; 파일의 inode 인덱스 뿐만 아니라 방금 얘기한 파일 속성을 담고 있는 stat 구조체를 채우는 것일 뿐이지.
  • Recruiter: that's not the answer: the inode contains all the metadata.
  • 리크루터: 정답이 아닙니다: inode는 모든 메타데이터를 담고 있습니다.
  • Thought: Could Google have secretly licensed the nefarious Microsoft Tay AI bot?
  • 생각: 구글이 비밀리에 그 악명높은 Microsoft Tay AI bot을 사왔나???
  • 7. what is the name of the KILL signal?
  • 7. KILL 시그널의 이름이 뭔가요?
  • Me: SIGKILL which #define is set to 9.
  • 나: SIGKILL이고 9로 #define 되어 있죠.
  • Recruiter: no, it's "TERMINATE".
  • 리크루터: 틀렸습니다. 정답은 "TERMINATE"입니다.
  • Me: SIGTERM (15) is different from the KILL signal (9).
  • 나: SIGTERM(15)은 KILL(9)와 다르죠.
  • Recruiter: that's not the answer I have on my sheet of paper.
  • 리크루터: 말씀하신건 제 종이에 써있는 내용과는 다릅니다.
  • Thought: I guess that's what happens when AI bots discover recreational drugs.
  • 생각: AI봇이 약 빨면 이렇지 않을까??
  • 8. Why Quicksort is the best sorting method?
  • 8. 퀵소트는 왜 최고의 정렬 알고리즘인가요?
  • Me: It's not always the case, nor even suitable.
  • 나: 항상 최고인건 아니라서 적절한 질문이 아닌것 같은데요.
  • Recruiter: Quicksort has the best big-O.
  • 리크루터: 정답은 "퀵소트의 Big-O가 제일 낫기 때문"입니다.
  • Me: "big-O" ignores data storage latencies, topology, volume, available memory, and even the computational cost of every CPU instructions involved in a given implementation – instead, it merely counts the number of algorithmic operations! Big-O can be a valuable indication when designing algorithms but the best performing and scaling solution depends on the particular constraints of any specific problem and environment.
  • 나: "big-O"는 저장공간의 지연이나 구조, 크기, 가능한 메모리, 심지어 수행하기 위한 CPU 명령의 실제 비용을 감안하지 않아요 - 그 대신 알고리즘 연산의 숫자만 세잖아요! Big-O는 알고리즘을 디자인할때는 유용할지 몰라도 실제 스케일 되는 솔루션을 만들때 최고인가 하는건 각각의 문제와 환경같은 제약조건에 달려 있는거죠.
  • Recruiter: wrong, you had to give me the Quicksort big-O score.
  • 리크루터: 틀렸습니다. 당신께서는 퀵소트의 big-O를 말씀해 주셨어야 됩니다.
  • Thought: When will the OMS will recognize the tobacco-scandal patterns in the damages caused by Academia to public mental health? The Linux kernel (that Google relies on) opted for Heapsort rather than Quicksort... for its lower memory usage and more predictable execution time.
  • 생각: 대체 OMS(가 뭔지 모르겠습니다/역자주)는 언제쯤에야 tobacco-scandal pattern같이 아카데미아가 공공 정신건강에 미치는 피해를 알아채게 되는건가. 리눅스 커널(구글이 쓰고 있는)조차도 좀 더 예측가능한 수행시간이나 적은 메모리 사용 등의 이유로 퀵소트 대신 힙소트를 쓰는데..
  • 9. There's an array of 10,000 16-bit values, how do you count the bits most efficiently?
  • 9. 만개 짜리 배열에 16비트 값들이 존재합니다. 가장 효율적으로 비트를 세려면 어떻게 하면 좋을까요?
  • Me: you shift the bits right on all the 64-bit words, the Kernighan way.
  • 나: 오른쪽부터 비트를 제거하는 식으로 세면 됩니다 - Kernighan 알고리즘입니다.
  • Recruiter: no.
  • 리크루터: 틀렸습니다.
  • Me: there are faster methods processing 64-bit words with masks but I can't explain it over the phone, I must write code.
  • 나: 마스크를 가지고 64비트 word를 처리하는 좀 더 빠른 방법이 있긴 한데 전화로는 설명하기 어려워요. 코드를 직접 써야 합니다.
  • Recruiter: the correct answer is to use a lookup table and then sum the results.
  • 리크루터: 정답은 룩업 테이블을 만들고 결과를 모두 더하는 것입니다.
  • Me: on which kind of CPU? Why not let me compare my code to yours in a benchmark?
  • 나: 어떤 종류의 CPU에서요? 제 코드랑 당신이 가진거랑 벤치마크 해볼까요?
  • Recruiter: that's not the point of this test.
  • 리크루터: 그건 이 질문의 요점이 아닙니다.
  • Me: what's the point of this test?
  • 나: 요점이 뭔데요?
  • Recruiter: I have to check that you know the right answers.
  • 리크루터: 당신이 정답을 알고 있는지를 체크하는게 요점입니다.
  • Thought: How long is this crap going to last? A 8-bit lookup table can process bytes one after another, while the 64-bit mask-based method processes 8-byte words at a time (on top of that, modern CPU instructions even let you process 128-bit words with a 10x speed gain if portability is not a concern). As a 64-bit lookup table is out of reach for today's computers, there's no doubt on what is faster.
  • 생각: 이 지랄을 언제까지 해야 되지? 8비트 룩업 테이블은 바이트를 하나씩 셀텐데, 64비트 마스킹으로 8바이트 word를 처리(게다가 호환성을 좀 더 포기하면 최신 CPU 명령들은 128-bit word를 한번에 10배 속도로 처리할 수도 있고)하는 동안에 말이지. 지금의 컴퓨터에서 64비트 룩업 테이블을 만들수 있는게 아닌 한 뭐가 더 빠른지는 당연하지 않나?
  • 10. what is the type of the packets exchanged to establish a TCP connection?
  • 10. TCP 연결을 맺기 위해 필요한 패킷은 무엇인가요?
  • Me: in hexadecimal: 0x02, 0x12, 0x10 – literally "synchronize" and "acknowledge".
  • 나: 16진수로 0x02, 0x12, 0x10 이고요, 얘네들은 "synchronize"와 "acknowledge"죠.
  • Recruiter: wrong, it's SYN, SYN-ACK and ACK; if Google is down you will need to know this to diagnose what the problem is. We will stop here because it's obvious that you don't have the necessary skills to write or review network applications. You should learn the Linux function calls, how the TCP/IP stack works, and what big-O means to eventually qualify if you are interviewed at a later time. Good luck, bye.
  • 리크루터: 틀렸습니다. SYN, SYN-ACK, ACK입니다; 구글이 다운되면 이걸 알아야 어떤게 문제인지 알 수 있을거에요.

    일단 여기서 인터뷰를 끝낼텐데요, 당신은 네트워크 어플리케이션을 리뷰하거나 만드는데 필요한 스킬이 없다는게 명확한 것 같습니다. 리눅스 함수 콜이랑 TCP/IP 스택이 어떻게 동작하는지, big-O가 뭔지 같은걸 좀 공부하시면 다음에 인터뷰 하실 때는 도움이 될 것 같네요. 행운을 빕니다. 안녕히 계세요.
  • Thought: When you have to read hexadecimal packet dumps to find what's happening, 3-letter mnemonics won't help you to troubleshoot a dead network service. Maybe Google should have stated that practice is not necessary for the job.
  • 생각: 무슨일이 난건지 알기 위해 16진수 패킷덤프를 알아봐야 할 때, 3글자짜리 약자는 죽은 네트워크 서비스를 살리는데에 별 도움이 되지 않을거에요. 아니면 그런 연습(3글자 약자<->16진수 숫자 인듯? / 역자주)같은건 별로 일하는데 필요 없다고 구글이 미리 말해 주던가..
  • On another hand, my score is four on ten, that's better than my best Google pagerank** ever!
  • 여튼간에 내 점수는 4/10 이었고 내 최고의 "구글 페이지랭크"** 보다 더 나았다!
  • (*) Google and TWD were both founded in 1998.
  • (*) 구글과 TWD는 둘 다 1998년에 창립되었다.
  • (**) Google pagerank: the ultra-secret mathematical formula demonstrating that sponsored search results rank higher than reality can.
  • (**) 구글 페이지랭크: 돈 낸 검색결과가 실제 검색결과보다 위에 있게 해 주는 극비의 수학 공식.
  • Tip: hiring people that know things that you don't know helps more than hiring people who merely know what everybody knows.
  • 팁: 당신이 모르는걸 아는 사람을 뽑는 것이, 세상 모두다 아는 것만 아는 사람을 뽑는거보다 나을겁니다.
0 Comments