* 제 생각이 아닌, 책 내용을 정리한 글입니다.
면접장에서는 바로 답을 내어서는 안된다.
생각없이 바로 답을 내서는 좋은 점수를 받기 어렵다.
요구사항을 완전히 이해하지 않고 답을 내놓는 행위는 아주 엄청난 부정적 신호다. 면접은 퀴즈쇼가 아니며, 정답 따위는 없다는 걸 상기하자.
엔제니어가 가져야할 가장 중요한 기술 중 하나는 올바른 질문을 하는 것, 적절한 가정을 하는 것, 그리고 시스템 구축에 필요한 정보를 모으는 것이다.
이 과정은 면접관과 협력하며 진행하면 좋다.
일단 내가 처음으로 만든 설계안을 제시하고 의견을 구해보자!
핵심 컴포넌트를 포함하는 다이어그램을 그림으로 그린다.
이 설계안이 시스템 규모에 관계된 제약사항을 만족하는지를 개략적으로 계산해본다.
가능하면 시스템의 구체적 사용 사례도 살펴보면 개략적으로 설계하는 데에 도움이 될 것.
그리고 시스템의 규모에 따라 API 엔드포인트나 데이터베이스 스키마도 보여야할 수 있다. 면접관에게 물어보고 필요하면 함께 생각해보는 것도 좋을 것이다 :)
개략적인 설계를 마친 다음에 가장 먼저 해야할 것은 각 컴포넌트들 사이에서 어느것이 우선이 될지 결정하는 것이다. 이건 면접관과 함께 결정해보자
왜냐하면 우리의 역할에 따라 집중해야하는 컴포넌트가 달라질 수 있기 때문이다.
출제되는 문제에 따라 면접관이 주로 보고싶은 부분이 특정될 수도 있다.
이 마지막 단계에서는 면접관이 우리의 설계에 대한 follow-up question을 던질 수도 있고 우리 스스로 다시 설계를 돌아보도록 할수도 있다. 활용할 수 있는 지침을 보자.
시스템 병목 구간, 혹은 좀 더 개선 가능한 지점을 찾아보라고 할 수 있다. 이때 "설계가 완벽하다"거나 "개선할 부분이 없다"는 말은 하지 말자. 나의 설계도 비판적으로 바라볼 수 있는 능력을 보여줄 기회다.
우리가 만든 설계를 요약해줄 수 있는 시간이기도 하다. 특히 여러가지 솔루션을 답한 경우 요약이 중요해진다. 면접관들도 사람이니까 긴 면접시간동안 내가 얘기한 것을 잘 기억할 수 있도록 환기시켜주자.
오류가 발생하면 무슨 일이 생기는지 따져보자.
운영 이슈에 대해 논의해보자: 로그, 메트릭, 모니터링, 배포
미래의 규모 확장 요구에 어떻게 대처할지도 논의해볼만하다.
뇌피셜 안된다. 질문으로 확인하라. (clarification)
문제의 요구사항을 이해하라.
정답은 없음 상황과 맥락에 따른 최선을 찾는다!!
사고의 흐름을 일목요연하게 얘기하려고 한다. 면접관이 이해못하면 대단한 설계도 도루묵.
(가능하다면 ^^......) 여러 개의 솔루션을 찾아보자.
개략적 설계 -> 컨펌 -> 우선순위 체크 -> 컴포넌트 구체적 설계!!!
포기하지 말라.
전형적인 면접 문제들을 대비하지 않은 상태에서 면접장에 가지 말자
요구사항이나 가정들을 분명히 하지 않은 상태에서 설계를 제시하지 말자
처음부터 특정컴포넌트 세부사항을 깊이 설명하지 말자
막히면 힌트를 청해보자!! 주저하지 말자.
소통을 주저하지 말자. 침묵 속에 설계를 진행하지 말자.
설계안을 내놓는 순간 면접이 끝난다고 생각하지 말자. 면접관이 끝났다고 말하기 전까지는 끝난 것이 아니다. 의견을 일찍, 그리고 자주 구하라.
3분~10분
10~15분
10~15분
3분~5분