어렵게 딴 두번째 애플 인터뷰에서, 그것도 아주 초보적인 실수를 저질렀다.
지난주 애플로부터 메일이 왔다. 몇주전에 만났던 애플의 시니어 엔지니어 D 님이 레퍼럴을 해줬으니 리크루터가 연락을 할 거라는 메일을 받았다.
그리고 얼마 뒤 리크루터가 나에게 포지션을 제안했고 인터뷰 일정을 잡았다.
지난번에 싱겁게 끝난(포지션이 안맞아서 10분만에 끝난) 애플 인터뷰를 만회할 절호의 찬스였다.
지난 월요일과 목요일에 아마존과 하이파이브와 인터뷰를 봤는데 분위기도 나쁘지 않았고 한시간 이상 인터뷰를 했으니 온사이트 인터뷰까지 갈 수 있을 거라는 기대감에도 젖어 있었다.
하지만 일주일이 시작되는 월요일날 두 회사로부터 모두 다음 인터뷰 진행을 하지 않겠다는 메일을 받았다. 최고의 생일 선물이다. ㅅㅂ
아마존 리젝 메일
Hi Steve,
I am sorry for the delay in getting back to you.
Thank you very much for your time and interest in Lab126. Our hiring manager is going to continue with other candidate interviews for this position but we wish you all the best success and hope you remain enthusiastic about Lab126. As a company policy, we don’t offer any feedback to candidates, after interviews. Thank you for understanding.
Should another opportunity become available that strongly matches your background and interests, we’d like to contact you, at that time.
Truly,
하이파이브 리젝 메일
Hello Seunghwa,
We would like to thank you for your interest in career opportunities at Highfive. After careful consideration, the team has decided not to move forward with your candidacy. This was a very difficult decision for us. We decided to move forward with another candidate who's skill-set is more in-line with our current needs. However, we would like to remain in contact with you as our needs are always changing and we are continuing to scale our organization. If another position becomes available that is a better match for your background we will definitely reach out to you directly!
Thank you again for your interest in Highfive and I wish you the best of luck in your future endeavors.
Best regards,
The Highfive Recruiting Team
그래서 이번 애플 인터뷰가 신경이 많이 쓰였나 보다.
나는 내 방에서 이어폰과 노트북을 펴놓고 대기중이었고, 아침에 약속한 시간에 전화가 왔다.
최대한 긴장을 풀려고 노력 했는데도 컨디션도 꽝이었고 이래저래 기분이 별로다.
인터뷰어는 역시 인도인이다. 하...
(인도인들이 큰 회사를 선호한다고 한다. 그래서 애플같은 회사에 많다.)
인도인 인터뷰어의 말은 여전히 알아듣기가 어렵다. 어렵게 주고 받는 대화들 중에 놓치는 부분이 많아서 수시로 pardon? excuse me? 를 말하며 되물어야 했다.
통상적인 인사와 테크니컬 질문들이 이어졌다.
예전 회사에서 무슨 일을 했어?
gdb 써봤어? gdb가 동작할 때 어떻게 디버거가 해당 코드 위치에 CPU 동작을 멈추지?
gdb를 쓰면 실제 돌아가는 코드의 실행 속도에 영향을 미칠까?
코드 최적화를 했다고 했는데, 가장 잘 했던게 뭐고 어떻게 했어?
임베디드 시스템에서 RISC를 사용했을 때 왜 Power 소모가 덜하지?
ARM 아키텍쳐에서 NEON 명령어를 썼다고 했는데, 어떻게 사용했는지 설명해 줄래?
그리고 바로 코딩 인터뷰를 들어갔다.
그동안 구글 스타일(?)의 알고리즘 문제들에 주력했는데, 이 인터뷰어는 그냥 단순히 memcopy 함수 API를 보여주고 이걸 구현하라고 했다.
void memcopy(void *pSource, void *pDest, unsigned int numBytes);
이때까지도 출제자의 의도를 파악 못했을 뿐더러, 나는 여기에 무슨 함정이 있을까 라는 생각에 별에별 생각이 다 들었다. 문제가 너무 간단했기 때문이었다.
어차피 컴파일도 안되는 환경이고 대충 아래와 같은 코드를 보여줬다.
void memcopy(void *pSource, void *pDest, unsigned int numBytes)
{
numBytes--;
do{
*(pDest + numBytes) = *(pSource + numBytes));
numBytes--;
}
while (numBytes >= 0);
}
인터뷰어는 계속 컴파일러가 어떻게 사이즈를 아느냐고 물었는데 그때 void포인터가 보였고, 나는 그래서 explicitly 하게 타입 캐스팅을 해줘야 한다고 설명했다. 그리고 아래와 같이 타입 캐스팅을 해놨다. (정말 초보적인 실수다 ㅠㅠ)
void memcopy(void *pSource, void *pDest, unsigned int numBytes)
{
numBytes--;
do{
(char)*(pDest + numBytes) = (char)*(pSource + numBytes));
numBytes--;
}
while (numBytes >= 0);
}
인터뷰어는 데이터를 assign하는 라인을 가리키며 어떻게 컴파일러가 그 부분을 해석하는지 계속 물었고, 어떻게 타입을 알아내는지 물어보았다. 인터뷰는 그렇게 30분만에 쫑났다.
연락이 오든 안오든 상관없다. 그냥 인터뷰 자체가 물 흐르듯 진행되지 않았고 초보적인 실수를 했고, 내 대답이 맘에 안드는 인터뷰였다.
너무 자만한 것 같다.
전화 통화가 끝나고 코드를 본 순간 내가 굉장히 초보적인 실수를 했다는 사실을 알고 굉장히 쪽팔렸다.
파라미터의 타입이 void였기 때문에 아래와 같이 포인터의 타입을 명시적으로 해줬어야 했다. 값이 아니라..
*((char*)pDest + numBytes) = *((char*)pSource + numBytes));
보통 이런 실수를 해도 컴파일 에러가 나면 그때 알아채고 그냥 수정을 했을 것이다.
그래서 기본기가 중요하다...
너무 로직에만 치중했고
인터뷰를 위한 인터뷰 준비만 한 것이 화근이다.
오늘 인터뷰를 본 팀은 하드웨어 위에 바로 올라가는 커널이나 디바이스 드라이버, 그리고 각종 미들웨어 등을 지원하는 소프트웨어 스택을 책임지는 팀이었고, 시스템 소프트웨어 엔지니어를 채용하는 팀 이였기 때문에 인터뷰어는 시스템과 관련된 질문들, 그리고 코딩을 할 때 컴파일러와 포인터의 사용법, 코드를 정확하게 작성하는지 여부를 보려고 했던 것이다.
이래저래 출제자의 의도도 파악 못하고 준비가 부족했던 탓이다.
이제 예약된 인터뷰는 없다. 처음부터 다시 시작해야 한다.
선배의 의견을 듣고 글을 덧붙여 본다.
사실 처음에 memcopy 를 짜라고 했을 때 당황했는데 여기서 출제자의 의도를 파악했어야 했지 싶다.
실제 시스템 라이브러리 소스를 찾아서 memcpy를 구현한 코드를 직접 보면 엄청나게 복잡한 함수로 되어 있는 것을 알 수 있다.
단순히 메모리를 복사하는 함수를 짜라는게 출제자의 의도가 아니었던 것 같다.
메모리 카피를 하는데 어떤 요소를 고려해야 하고, 어떤 예외 상황이 발생하는지 고려해서 예외 처리를 해야 하고, 프로세서 등 시스템 환경의 특성이 무엇인지 등을 따져가면서 메모리 복사 함수를 설계해야 한다는 이야기들을 줄줄이 떠들었어야 했다.
그러니까 이런 식의 문제를 내면 인터뷰어의 의도가 무엇인지 계속 질문을 해야 한다.
전화 인터뷰에서 내가 알고 있는 배경 지식과 경험들을 바닥까지 긁어내서 인터뷰어 한테 어필을 해야 한다.
처음부터 정답은 없다. 인터뷰어는 코드가 돌아가는지 아닌지 여부는 관심이 없다. 내가 무슨 생각을 하고 무슨 말을 하는지 궁금해 하는 것이다.
그래서 인터뷰어가 몇줄 안되는 내 코드를 보고 딴지를 걸고 따져봤던 것이다. 3줄짜리 코드로는 내 지식 수준을 알 수 없었으니까.
쟤 코드좀 봐 ㅋㅋㅋ
선배의 의견을 듣고 글을 덧붙여 본다.
사실 처음에 memcopy 를 짜라고 했을 때 당황했는데 여기서 출제자의 의도를 파악했어야 했지 싶다.
실제 시스템 라이브러리 소스를 찾아서 memcpy를 구현한 코드를 직접 보면 엄청나게 복잡한 함수로 되어 있는 것을 알 수 있다.
단순히 메모리를 복사하는 함수를 짜라는게 출제자의 의도가 아니었던 것 같다.
메모리 카피를 하는데 어떤 요소를 고려해야 하고, 어떤 예외 상황이 발생하는지 고려해서 예외 처리를 해야 하고, 프로세서 등 시스템 환경의 특성이 무엇인지 등을 따져가면서 메모리 복사 함수를 설계해야 한다는 이야기들을 줄줄이 떠들었어야 했다.
그러니까 이런 식의 문제를 내면 인터뷰어의 의도가 무엇인지 계속 질문을 해야 한다.
전화 인터뷰에서 내가 알고 있는 배경 지식과 경험들을 바닥까지 긁어내서 인터뷰어 한테 어필을 해야 한다.
처음부터 정답은 없다. 인터뷰어는 코드가 돌아가는지 아닌지 여부는 관심이 없다. 내가 무슨 생각을 하고 무슨 말을 하는지 궁금해 하는 것이다.
그래서 인터뷰어가 몇줄 안되는 내 코드를 보고 딴지를 걸고 따져봤던 것이다. 3줄짜리 코드로는 내 지식 수준을 알 수 없었으니까.