1️⃣ 뛰어난 의사소통 능력

1인 개발자가 아닌 이상 회사를 다니든 창업하든 상관없이 여러 사람과 함께 일하게 된다. 특히 연차가 쌓이고 기술 리더가 될 수록 많은 사람과 함께 해야 하고 그들을 이끌어야 하는데, 많은 사람들과 효과적으로 일하려면 의사소통 스킬이 뛰어나야 한다. 특히 가장 중요한 것은 문서나 특정 문제를 빠르게 이해하고 내용을 잘 정리할 줄 알아야 한다. 내용을 빨리 이해하는 건 효과적인 논의를 하고 중요한 질문을 던지기 위함이다.

정리된 내용은 여러 사람이 한 번에 알아들을 수 있게 간결하고 임팩트 있게 말해야 한다. 큰 프로젝트를 맡으면 서로 다른 이해 관계자 여러 명, 많게는 수십 명과 일하게 된다. 이해관계가 다른 사람은 가진 배경과 지식 그리고 기술 전문 분야가 다르기 때문에 한 번에 알아들을 수 있도록 말하는 것이 아주 중요하다.

그리고 마지막으로 중요한 질문을 던질 줄 알아야 한다. 중요한 질문이란 생각지도 못했던 점을 생각하게 만드는 것이다. 예를 들어 라지 시스템 설계의 '틈'을 빠르게 파악하고 설계자에게 되묻거나, 문제의 핵심이 될 수 있는 '포인트'를 물어 보는 것과 같은 것이다. 질문을 잘하는 것도 의사소통 잘하는 법에 포함된다. 중요한 질문을 머릿속에는 잘 정리했는데, 의외로 말로 잘 내뱉지 못하고 소통하지 못하는 경우가 있다.

2️⃣ '틈'을 재빠르게 파악하는 능력

당연한 이야기지만 기술이나 문제의 핵심을 재빠르게 이해하고 파악해야 한다. '틈'을 빠르게 파악하고 좋은 피드백을 주는 선임이 있는 팀과 그렇지 않은 팀의 효율성 차이는 아주 크다. 예를 들면, 예전에 <좋은 개발자가 되기 위한 버그 고치는 데 드는 비용>이라는 글을 포스팅했을 때, 개발 시작하기 전에 충분한 검토와 논의를 거쳐 설계의 틀을 잘 잡는 것이 중요한 이유에 관해 이야기 했다. 하지만 무조건 검토와 논의를 한다고 틀이 잘 잡히는 것이 아니다. 검토에 참여한 사람들의 검토 실력에 따라 이 과정이 효과적일 수 있고 아닐 수 있다. 예를 들어, 나는 예전에 주니어 시절 선임들이 조용히 설계 문서를 읽고 듣기만 하던 설계 검토 미팅에 참여했던 적이 있다. 결국 설계를 마치고 개발 단계를 마친 후 기존 설계의 흠을 발견했고, 코드 전체를 리펙토링하는 불상사가 발생했다.

또한 기술 이외 개발에 방해되는 요소의 틈을 빠르게 파악하는 것도 아주 중요하다. 단순히 코딩만 한다고 기술을 선보일 수 있는 게 아니다. 프로젝트 관리, 주니어 개발자 코칭 등등 여러 가지 요소도 함께 포함된다. 이러한 요소에도 '틈'이 발생할 수 있는데, 그 틈을 빠르고 자발적으로 캐치한 후 고칠 수 있어야 한다.

개인적으로 '틈'을 파악하는 건 쉽게 배울 수 없는 능력이라고 생각한다. 제일 좋은 방법은 '틈'을 잘 파악하는 선임과 함께 일하며, 그들을 롤모델로 삼고 따라해 보는 것이 많은 도움이 되었다. 그 외에도 빅픽처를 보는 능력을 키우면 확실히 틈을 파악하는 능력도 같이 느는 것 같다.

3️⃣ 빅픽처 보는 능력

알고리즘 문제를 풀 때 문제의 단편만 보고 바로 코드부터 쓰는 경우가 다반사다. 이렇게 문제의 한 부분만 보고 풀면, 틀린 답을 내리기 쉽다. 하지만 큰 그림을 먼저 보고 포괄적인 솔루션을 제공하면 좋은 답을 내릴 가능성이 높다. 단순히 코딩 문제에만 국한되지 않고 라지 시스템 설계 또는 비즈니스 관련 결정을 내릴 때도 빅픽처를 잘 볼 줄 알면, 퀄리티가 높은 결과물을 낼 수 있다. 큰그림을 독보적으로 잘 보는 선임이 있었는데, 아무리 머릿수가 많은 개발자들이 모여 결론을 내려도 찾을 수 없었던 답을 그 선임은 한 번에 찾아줬다. 일의 효율성도 높아지지만, 다음에 더 큰 문제(예: 잘못된 시스템 배포, 버그 배포 등등)를 막을 수 있다.

4️⃣ 프로젝트 관리 능력

많은 개발자는 코딩만 잘하면 된다고 생각한다. 하지만 개발자에게는 코딩뿐만 아니라 설계 실력과 프로젝트 관리 능력도 있어야 한다. 결국 모든 개발자는 특정 프로젝트를 완료해야 하고, 그 프로젝트를 진행하는데 프로젝트 관리는 필수 영역이다. 특히 기술 리더나 팀의 선임이 될수록 이 능력이 뛰어나야 한다.

5️⃣ 같이 일하고 싶은 동료가 되는 능력

팀에 같이 일하기 싫은 동료가 있으면 문제가 꼭 터진다. 같이 일하기 싫은 동료란 자기주장만 옳다고 여기거나, 남의 말에 꼬투리만 잡는다거나, 의사소통이 전혀 안 되는 사람 등 여러 부류가 포함된다. 이런 사람이 있으면 제일 큰 문제는 개발자들이 효율적인 논의를 하지 못하게 된다. 논의를 제대로 못 하면 틀린 답을 내리기 쉽고, 비즈니스에 안 좋은 영향을 미치는 결과를 내기 쉽다.

또한 모든 사람은 똑같이 하루에 24시간을 갖게 되고, 그중 적어도 8시간을 일하는 데 사용한다. 8시간 동안 함께 일하고 싶은 동료와 일할 수 있으면, 일하는 게 즐겁다. 일이 즐거우면 내 생활에 활력을 갖게 되고, 더 나아가 좋은 결과물을 낼 힘이 되기도 한다.

6️⃣ 라지 스케일 시스템 설계 능력

코딩 공부할 때 간과하는 것은 설계 공부다. 그중에서도 라지 스케일 시스템 설계 능력이 아주 중요하다. 근데 라지 스케일 설계는 학교에서 쉽게 배울 수 없고, 트래픽이 다량으로 발생하는 시스템을 다루어야지만 배울 수 있는 유용한 지식이다. 단순한 설계나 코드는 요즘 챗GPT가 쉽게 힌트를 줄 수 있지만, 라지 스케일 시스템 설계 능력은 단순하게 완성할 수 없다. 많은 아이디어를 검토하고, 절충점을 찾고, 다양한 전문가와 검토를 거쳐야 하는 복잡한 프로세스다.

개인적인 생각이지만 라지 스케일 시스템 설계 능력은 경험을 통해서만 배울 수 있다. 최대한 대량 트래픽이 발생하는 곳에서 일해보는 게 좋다. 하지만 대량 트래픽이 발생해도 설계할 기회가 없으면 아무짝에 쓸모없다. 따라서 라지 스케일 시스템 설계를 할 수 있고 배울 수 있는 팀에서 일해보는 게 좋다. 그 외 라지 스케일 시스템 설계 관련 책을 읽어보는 것도 도움 되었던 것 같다. 그런데 확실히 실무에서 경험해보고 책을 읽어보니 개념 이해가 훨씬 빨랐다.

7️⃣ 글 잘 쓰는 능력

"개발하는 데 코드만 잘 쓰고 의사소통만 잘하면 되지 않을까?"라고 할 수 있다. 코드만큼 중요한 것도 코드를 잘 설명하는 것이다. 아무리 가독성이 높은 코드를 작성해도 비즈니즈 로직이 복잡하면 추가 설명이 필요하다. 마찬가지로 설계만큼 중요한 것도 설계한 것을 잘 설명하고 새로운 팀원이 와도 쉽게 그 시스템을 이해할 수 있도록 전문 지식을 잘 문서화해야 한다. 무작정 문서를 작성하는 것보다 '내용 전달을 잘하는 문서'를 작성해야 한다. 내가 개인적으로 겪은 일인데, 새 팀원이 조인할 때마다 일대일 면담을 통해 일일이 시스템과 개념을 설명해야 했던 적이 있다. 지속할 수 없는 방법이라고 여기고 필요한 정보를 문서화를 했고, 똑같은 질문하는 팀원이 있으면 작성한 문서를 먼저 읽어보라고 했다. 그런데 팀원이 문서를 읽어도 이해를 못 해서 결국 다시 일대일 면담으로 불분명한 점을 확실히 해야 했다. 이 경험을 통해 '문서도 잘 적을 줄 알아야 하는구나'를 느꼈다. 그 후 좋은 문서를 많이 읽어보고 여러 사람의 검토를 걸쳐 최대한 많은 정보를 간결하고 쉽게 전달할 수 있도록 노력하고 있다.

👉 11월 멘토링 취업, 코딩테스트 관련 큐앤에이 모음 https://careerly.co.kr/comments/72886

👉 1월 멘토링 취업, 코딩테스트 관련 큐앤에이 모음 https://careerly.co.kr/comments/75888

1️⃣ 경력이 없는 학생에게 중요한 건 무엇일까

인턴십을 해보지 않은 멘티는 이력서에 뭘 적어야 할까? 간단하게 생각하면 고용주의 입장이 되어 이력을 보여줄 수 있는 다른 무언가가 무엇인지 생각해보는 것이다.

내가 생각하는 대안 이력은 다음과 같다.

• 컴공 전공와 대학 학위
• 컴공 전공 GPA (높다면 이력서에 포함하는 것도 좋다)
• 사이드 프로젝트 또는 학교 수업에서 한 과제
• 컴공 수업 리스트
• 과외활동

과외활동을 좀 더 파고 들자면 컨퍼런스 참석이나 자선 활동을 적는 것이 도움되나, 그냥 아무 활동만 적는 게 아니라 자기 영역에 관련된 점만 적는 것이 좋다. 컨퍼런스 참석도 그냥 "무슨 컨퍼런스 다녀옴"이 아니라 요점은 "컨퍼런스에서 주최하는 워크숍 맨토링하는 봉사활동 주도함“처럼 내가 보여주는 일을 한 것이다. 자선 활동도 "초등학생 모바일 어플 만드는 수업 가르치기" 등이 포함된다.

2️⃣ 키워드 사용이 아주 중요하다

이력서 작성할 때 항상 하는 피드백은 다음과 같다.

⚠️리쿠르터와 이력서를 읽는 사람 대부분 이력서를 꼼꼼히 읽어 볼 시간이 없다. 부족한 시간 내에 확실하게 당신의 이력을 알 수 있는 방법을 고안해내야 한다.⚠️

짧은 시간 내에 이력이 두드려지게 하려면 '키워드 사용'이 아주 중요하다. 간단하게 말하면 현업에서 자주 사용되는 단어를 최대한 사용하는 것이 문장을 풀어내는 것보다 효과적이다. 예를 들어 멘티는 단순하게 '사이드 프로젝트로 어떤 컴포넌트를 구현해냈다'라고 적었는데, 이건 내 이력을 전혀 보여주지 않는다. 사이드 프로젝트를 어떤 프레임워크(예: 리액트)를 사용해서 어떻게(예: 백엔드, 프론트엔드) 그리고 어떤식으로(예: 테스팅, 배포 도구 언급) 했는지 명확하게 말하자.

키워드는 파워풀한 도구다. 링크드인에서 검색할 때 키워드가 최적화되어 있으면 이점이 많으므로 링크드인이든 개인 이력서든 모두 키워드 사용하는 것이 좋다.

3️⃣ 이력서를 읽는 사람 입장에서 쓰자

정보관련 글 쓸 때 '내 입장'만 생각해서 쓰는 경우가 많다(다만 경험담과 하소연하는 글은 예외다). 예를 들면 사소한 것까지 하나하나 다 적으면서 내가 겪은 어려움과 감정들을 호소하는 것과 같다. 요즘처럼 정보가 넘치는 세상에서 가장 중요한 것은 '몇 초 안에 얼마나 많은 정보를 쉽게 캐낼 수 있냐'다. 간단하게 말해서 다른 사람이 입장이 되어 그 사람들이 원하는 인재상이 무엇이고 그 사람이 캐고 싶은 정보가 무엇인지 생각해낸 다음 그 점에 초점을 두고 이력서를 작성해야 한다.

4️⃣ 당연하지만 많은 사람들이 놓치는 점

4.1. 이력서는 한 장 또는 최대한 축소하기

20년 이상 경력이 넘쳐나는 사람이 아니라면 최대한 이력서는 한 장 또는 최대한 축소하는 것이 좋다. 특히 해외 취업의 경우 이력서는 한 페이지로 만드는 것이 보편화되어 있다.

4.2. 거짓말하지 말자

내 동료는 면접관이 되어 예전에 사이드 프로젝트를 같이 했던 사람이 이력서에 거짓말 한 것을 알아채고 관리자에게 보고한 것을 봤다. 세상은 좁고, 테크 세계는 의외로 (생각보다) 더 좁다. 거짓 이력은 적지 말자.

4.3. 부풀리지 말자

가끔 실제 직함이나 타이틀 그리고 맡은 일에 비해 과장해서 이력서에 적은 경우가 있다. 이건 득보다 실이 훨씬 많은게 테크 산업은 생각보다 작고 좁으며, 이력서 통과해서 행동 인터뷰에서 파고들면 갭 차이가 반드시 보인다. 웬만하면 실력과 이력 그리고 직함을 오해의 소지가 있도록 부풀리지 말고 본인의 경력에 맞게 적자.

5️⃣ Weak 단어 사용은 피하자

내가 사회 초년생시절 자주했던 실수고 그 당시 멘토에게 들은 조언인데, 특이 영문 이력서 작성에 아주 중요한 점이다. 그건 바로 약한 단어 사용을 금지하는 것이다. 약한 단어에는 "도와줌", "했음" 또는 "기여했음"과 같다. 좀 더 자신의 소유권을 보여주는 단어(예: owned, led, built)를 선택하는 것이 좋다.

함께 읽으면 좋은 글:

남들보다 앞서는 커리어 쌓기 위한 무료 템플릿

최종 면접 통과 준비를 위한 무료 노션 템플릿

자기 개발에 도움되는 개발 도서 효율적으로 읽는 법

💻 기술 소식: 커리어리 📄 무료 템플릿: 노션

주니어 시기에 좋은 관리자를 만나 코칭받는 것이 아주 중요합니다. 사회 초년생일 경우 관리자와 면담할 때 어떤 질문을 해야 하고 어떤 이야기를 해야 하는지 모르는 경우가 많습니다. 일 효율성을 높이고 커리어를 잘 쌓으려면 관리자와의 면담을 잘 이용해야 합니다. 실제 제가 1:1 매니저 면담 때 사용했던 템플릿은 회사 내부 문서 도구를 사용해서 만들었지만, 공유하기 위해 노션 템플릿으로 다시 만들어서 무료로 공유합니다.

📌 캘린더 캘린더 뷰에 모든 업무와 프로젝트의 마감일을 꼼꼼히 적어놓습니다. 만약 프로젝트 A를 2022년 2월 28일까지 완료해야 한다면, 2월 28일 날 캘린더 이벤트를 만들어서 한눈에 볼 수 있게 만들었습니다. 면담때마다 마감일을 관리자와 지속적으로 확인하고, 문제가 있다면 면담 때 피드백과 도움을 요청합니다. 어려운 점이 있다면 망설이지 말고 상사에게 보고하고 도움받아야 합니다.

📌 질문 면담 바로 직전, 약 15분 정도 시간을 투자해서 관리자에게 하고싶은 질문을 적어놓습니다. 가끔 업무 보다가 "이건 매니저랑 체크해봐야겠는데?"라는 생각이 들면 바로 템플릿 문서를 열어서 적어두곤 했습니다. 이렇게 하면 묻고싶은 점들을 다음 면담때까지 까먹지 않고 물어볼 수 있고, 일 효율성도 높아집니다. 물론 급한 일은 슬랙 메시지를 보내거나 이메일을 통해 바로 물어보면 되지만, 급하지 않고 개인적으로 물어볼 수 있는 건 템플릿에 적어둡니다.

📌 프로젝트 현재 맡은 프로젝트 리스트를 적어놓습니다. 여러 개의 프로젝트를 맡고 있다면 한눈에 볼 수 있도록 적어놓습니다. 프로젝트 리스트를 한눈에 볼 수 있으면 좋은 점은:

• 업무량이 많아 보일 경우, 관리자가 업무량을 줄여줄 수 있다.
• 현재 맡은 프로젝트가 본인의 성장과 승진에 도움되지 않을 경우, 관리자가 다른 프로젝트를 추천해줄 수 있다.

📌 우선순위 주니어 시절 가장 중요한 건 업무 우선순위를 정하기입니다. 성과가 없을 경우 커리어 쌓기가 힘들 수가 있고 심한 경우는 해고당할수도 있어요. 성과를 내는데 가장 중요한 건 업무를 잘 보는 것도 있지만, 우선순위 업무부터 빨리 해결하는 것이 가장 중요합니다. 아무리 열심히 일을 해도 불필요한 일부터 하면 아무도 알아주지 않습니다. 면담할 때 우선순위 3가지 꼭 적으세요.

📌 피드백 피드백은 자기 계발과 성장에 엄청난 도움됩니다. 특히 빠른 승진을 원한다면, 피드백이 중요한 역할을 합니다. 관리자와 면담할 때 본인의 "강점"과 "약점"을 의논해보고 약점을 개선할 수 있는 방법을 빨리 찾아야 합니다. 약점을 빨리 개선시키면, 자기 계발에 많은 도움이 됩니다. 실제로 비교적 다른 동료들에 비해 빨리 승진하는 친구들을 보면 피드백을 잘 수용합니다.

📌 Action Items 다음 미팅 전까지 해야 할 업무나 아이템을 적는란입니다. 회의 중에 관리자가 추천하는 업무나 Action Item을 까먹은 경우가 많아서 템플릿에 따로 적어놓습니다. 예를 들어 "현재 설계하고 있는 이 시스템의 디자인은 수석 엔지니어랑 검토해보는 것이 좋겠다"라는 피드백을 받았다면, 액션 아이템란에 까먹지 않도록 적어놓습니다.

📌 체크 리스트 - 질문 관리자에게 물어보면 좋은 질문 몇 가지 뽑아서 적어봤습니다. 실제 제가 주니어 시절 자주 했던 질문입니다.

📌 체크 리스트 - 토픽 "면담 시 어떤 이야기를 해야 할지 모르겠다"라고 하는 분들이 많습니다. 저의 경험을 바탕으로 제가 자주 커버했던 미팅 토픽 몇 가지 뽑아서 적어봤습니다.

무료 노션 템플릿 원문

함께 읽으면 좋은 글:

코딩 테스트 실력 향상시키기

취업 준비생 주목! 새로운 개발자 면접 유형

최종 면접 통과 준비를 위한 무료 노션 템플릿

자기 개발에 도움되는 개발 도서 효율적으로 읽는 법

💻 기술 소식: 커리어리 📄 무료 템플릿: 노션

미국과 캐나다에서 개발자로 근무하며 느낀 점

1️⃣ 시니어가 될수록 회화의 중요성이 커진다 시니어가 되는데 필요한 조건은 아니지만, 리더십 미팅, 컨퍼런스 프레젠테이션 및 트레이닝 세션 등등 미팅을 리드해야 하는 경우가 많아지기 때문에 회화를 잘하는 것이 아주 중요합니다. 일상 영어가 아닌 비지니스 영어를 잘 구사할 수 있는 것이 중요합니다. 듣고 빠르게 이해하고 깔끔하게 대답할 수 있는 연습을 많이 해야 합니다. 또한 스토리텔링을 잘하는 것도 큰 도움이 됩니다.

비지니스 회화 실력을 기르는 방법은?

첫 인턴십 때 50여 명 개발자 앞에서 영어로 데모해야 했었습니다. 당시 일상 영어는 문제가 없었는데, 비지니스 영어는 처음부터 새 언어를 배우는 것처럼 많이 생소했습니다. 버벅거릭며 한 두 마디만 제대로 하고 끝냈던 제가 많이 부끄러웠습니다. 현재는 큰 미팅을 이끌기도 하고 컨퍼런스에서 프레제테이션을 하는데, 가장 도움되었던 건 “연습”입니다. 주니어 시절 매니저에게 미팅을 리드할 기회를 달라고 했으며, 처음 수십 번은 어색하고 부끄럽지만 이런 경험들이 차곡차곡 쌓여서 큰 도움이 됩니다.

스토리텔링과 프레젠테이션 연습하는 법?

지난번 포스팅에도 언급했지만, 본인이 하는 말을 귀로 직접 들어보면 말하기 실수를 쉽게 캐치할 수 있습니다. 본인의 프레젠테이션과 스토리텔링을 녹음해서 들으면, “어? 이 부분은 말이 반복되는데?”, “이 발음은 어색한데?” 또는 “이 이야기는 순서가 안 맞네” 등등 객관적으로 판단하는 데 큰 도움이 됩니다.

2️⃣ 말을 조리 있고 깔끔하게 억양이 다른 직장 동료들과 일할 기회가 많은데, 최근에 느낀 점은 원어민 발음은 중요하지 않습니다. 대신 억양이 있더라도 말을 조리 있고 깔끔하게 하면 완벽한 발음을 구사하는 사람보다 훨씬 잘 들립니다.

3️⃣ 쓰기 실력은 아주 중요하다 Code comment와 서류 및 이메일 작성은 업무의 상당 부분을 차지합니다. 쓰기를 잘하는 사람의 서류와 이메일을 읽으면 일 효율성이 높아집니다. 더불어 팀의 업무 효율성까지 높아집니다. 여기서 말한 쓰기 실력은 “작문”과 “글쓰기”만 잘하는 것이 아니라, 읽는 사람에게 적합한 서류를 잘 작성하는 것도 포함됩니다.

4️⃣ 다양한 나라의 영어 억양을 잘 알아들을 수 있어야 한다 개발자 직업의 특성은 다양한 나라에서 이민 온 사람들과 일할 수 있는 것입니다. 예전에 일했던 팀원들은 총 7개국에서 왔으며, 억양이 다양했습니다. 그냥 원어민 영어 듣기를 잘해도 다른 영어 억양을 이해하기 어려울 수 있습니다. 마치 새 언어를 배우는 것 같은 경험을 하기도 했습니다.

다양한 영어 억양을 잘 이해하는 방법은?

영국, 호주와 뉴질랜드 등 영어권이라도 억양이 많이 다릅니다. 미드 보듯 호주, 영국 등등 리얼리티 쇼를 보며 억양을 익히는 것이 큰 도움이 됩니다. 그뿐만 아니라, 다른 억양을 가진 동료와 커피 타임 및 점심시간을 통해 대화하며 익히는 것도 좋은 방법입니다.

5️⃣ 자신감이 제일 중요하다 틀려도, 부끄러워도, 말하기 연습하는 사람이 듣기만 하는 사람보다 빨리 늡니다. 비지니스 영어는 일상 영어와 다릅니다. 일상 영어는 계속 실력을 향상할 수 있는 기회가 많지만, 비지니스 영어는 그렇지 않습니다. 스스로 기회를 만들어야 하며 미팅을 이끌어 보고 실패를 통해 배우는 것이 가장 좋습니다.

함께 읽으면 좋은 글:

[개발자 공부법] 영어 독해와의 싸움 1탄

[개발자 공부법] 뭘 공부해야 되지?

💻 기술 소식: 커리어리 📄 무료 템플릿: 노션

비자 문제와, 적성을 찾지 못해서 이직 때문에 수십 번 이상 면접을 밨던 것 같습니다. 이력서 넣은 것까지 합하면 숫자가 훨씬 더 커지겠네요. 영문으로 작성해서 한국 구독자를 위해 한국어로 번역해서 올립니다.

1️⃣ 첫 번째 단계: 채용 담당자와의 통화

이 단계에서 기술적인 이야기를 하지 않는다. 예컨대 채용 담당자가 알고리즘과 특정 알고리즘 문제의 시간 복잡도에 대해 물어보지 않는다. 하지만 전화 코팅 테스트 단계로 넘어가기 전에 채용 담당자가 컴공 지식을 테스트했던 회사가 지금까지 두 군데 있었다.

가끔 이 단계에서 예상하는 기대치 연봉 범위를 알려 달라고 하는데, 숫자를 먼저 제시하지 말자. 회사측에서 먼저 제공하도록 하자 (연봉 협상 관련 지난 글 참고).

일반적인 채용이 아니라 특정 포지션 채용이라면 자신의 배경에 가장 잘 맞는 팀과 면접보기 위해 본인의 강점과 엔지니어링 열정 그리고 경력에 대해 솔직하게 말하는 것이 중요하다.

해야 할 질문들:

• 코딩 테스트와 시스템 설계 면접 라운드는 총 몇 번 하는지
• 면접 포맷이 어떻게 되는지
• 각 면접마다 행동 면접 단계가 있는지? 그렇다면 행동 면접을 준비할 수 있는 자료를 공유해 줄 수 있는지
• 면접관 이름과 그들이 속한 팀 관련 정보를 알 수 있는지
• 회사에서 무료 면접 준비 자료를 보내줄 수 있는지

2️⃣ 두 번째 단계: 행동 인터뷰

먼저 대화 상대를 파악하자. 면접관이 개발자인가 하이어링 매니저인가? 누구와 이야기하냐에 따라 그들이 원하는 "합격 데이터 포인트"가 다르다.

그리고 많은 사람이 행동 인터뷰를 과소평가하는 경향이 있다. 코딩 테스트보다 안 중요하다고 생각하는데, 행동 인터뷰까지 잘해야 합격한다. 경력자의 경우 행동 인터뷰가 코딩 테스트만큼 중요하다. (직급 강등 관련 지난 글 참고)

1. 행동 면접 이해하기

두 가지 종류의 행동 면접이 있다.

• 첫 번째 방법: 60분 동안 관리자나 하이어링 매니저와 대화하기
• 두 번째 방법: 60분 동안 개발자와 면접 보는데, 그중 15분만 행동 면접 진행 (나머지는 코딩 테스트 단계)

특히 두 번째 방법이라면 시간 관리를 잘해야 한다. 코딩 테스트에 충분한 시간을 사용하는 것이 좋으므로 행동 면접 단계에서 너무 많은 시간을 낭비하면 안 된다.

2. STAR 형식에 맞추어 대답하기 - 원문에 있는 아티클 링크를 참고해 주세요.

3. 체크 리스트

• 행동 면접에 사용할 수 있는 예시 20~30개 미리 적어두기
• STAR 방식으로 위 예시에 대답하는 법 연습하기
• 특정 회사에 자주 출제되는 행동 면접 문제 검색해보기
• 면접관이 왜 이 질문을 했는지에 대한 의도를 파악하고 어떤 데이터 포인트를 찾고 있는지 생각해보자. 찾고 있는 데이터 포인트에 맞게 예를 조금 변경하자.
• 친구나 멘토와 모의 면접해 보기
• 할 수 있다면 온라인 모의 면접 플랫폼 이용해보기

4. 하면 안 되는 실수

• 쓸데없이 말을 길게 하는 것
• 면접관이 모든 전문 용어를 알고 있다고 가정하는 것
• 결과에 관한 이야기할 때 숫자나 통계 그리고 메트릭 넣기

3️⃣ 세 번째 단계: 코딩 테스트

원문과 다르게 한국어 버전 글 몇 가지 대신 포함합니다. 한국어 버전 글을 대신 읽어주세요.

1. 코딩 테스트 실력 향상시키기: 니트코드 150 https://careerly.co.kr/comments/69725

2. 코딩 면접을 위해 꼭 알아둬야 하는 알고리즘 패턴 8가지와 문제 유형 https://careerly.co.kr/comments/62250

3. 알고리즘 문제 풀기 공부하는 법 https://careerly.co.kr/comments/60668

4. 문제 해결 방식은 다음을 포함한다.

5. 문제를 명확하게 하는 것

6. 솔루션에 영향을 미칠 수 있는 엣지 케이스 찾는 것

7. 여러 옵션을 고안해내고 장, 단점 설명하고 그중에서 가장 좋은 옵션을 선택하는 것

8. 머릿속으로 생각해낸 알고리즘을 코드로 "번역"하는 것

9. 알고리즘을 테스트하기 위한 인풋과 아웃풋 예시를 대립해보는 것

10. 알고리즘에 있는 버그를 고치기 위한 테스트 케이스

11. 체크 리스트

• 40분 안에 중급 문제를 다 풀 수 있는가?
• 최적화된 솔루션으로 40분 안에 중급 문제를 다 풀 수 있는가?

4️⃣ 네 번째 단계: 시스템 설계 인터뷰

1. 시스템 면접 이해하기

두 가지 종류의 시스템 면접이 있다.

• 단순한 컴포넌트 시스템 설계 면접
• 라지 스케일 분산 시스템 설계 면접

면접 종류에 따라 커버해야 하는 주제가 살짝 다르므로 어떤 시스템 면접을 보는지 명확하게 하자.

원문과 다르게 한국어 버전 글 몇 가지 대신 포함합니다. 한국어 버전 글을 대신 읽어주세요.

2. 📚 시스템 디자인 해외 취업 인터뷰 책 추천 https://careerly.co.kr/comments/54566

3. [분산 시스템 공부법] 유튜브 채널 추천, 학습 효과 극대화 하기 https://careerly.co.kr/comments/67026

4. 시간 관리하기

내 경험에 의하면 시스템 설계 면접에서 가장 어려웠던 건 시간 관리하기다. 말을 너무 많이 해버리거나 생각이 정리 정돈되어 있지 않아서 제일 중요한 시스템 설계 주제를 커버하지 않게 되버린다. 마음 속에 타임라인을 미리 만들어 놓자.

Timeline 1:

1. 요구 사항 수집 (5 mins)
2. APIs (5-10 mins)
3. 데이터 모델 (10 mins)
4. back-of-the-envelop calculations (5 mins)
5. High-level Diagram (10 mins)
6. 설계 최적화하기 (10 mins)

Timeline 2:

1. 요구 사항 수집 (5 mins)

2. High-level Diagram (10 mins)

3. 최적화하기 (10 mins)

4. APIs (5-10 mins)

5. 데이터 모델 (10 mins)

6. back-of-the-envelop calculations (5 mins)

7. 해야 할 것

8. 문제에 접근하기 전에 요구 사항을 명확하게 할 것

9. 알고리즘이 어떻게 작동하는지와 같은 디테일은 뺄 것

10. 디자인 선택할 때 이유 설명하기

11. 하지말아야 할 것

12. 그냥 "여기에 캐시 넣을게요"라고 하지마라. 자체 기술 평가를 기반으로 왜 캐시가 필요한지 설명하기

13. 문제 범위 영역 내에 있는 요구 사항을 가정하지 말기

14. 정확하게 계산하려고 하지말기. 대략적인 숫자만 제시해도 좋다.

5️⃣ 다섯 번째 단계: 면접 후 해야 할 것

1. 최종 면접 통과했다면

연봉 협상에 대해 공부하자. 연봉 협상 반드시 해야 하는 이유: 업데이트 버전 https://careerly.co.kr/comments/67096

2. 최종 면접을 통과하지 못했다면

낙담하지 말고 다음 면접을 잘 볼 수 있도록 채용 담당자에게 피드백을 달라고 요청해보자.

무료 노션 템플릿 원문

함께 읽으면 좋은 글:

코딩 테스트 실력 향상시키기

취업 준비생 주목! 새로운 개발자 면접 유형

주니어 개발자 시절 멘토에게 들은 뼈때리는 조언들

자기 개발에 도움되는 개발 도서 효율적으로 읽는 법

💻 기술 소식: 커리어리 📄 무료 템플릿: 노션

1️⃣ 개발자는 평생 공부할 각오 해야 한다 주니어 시절 천진난만한 나에게 시니어 개발자가 해준 말이다. 당시에는 크게 와닿지 않았지만, 지금은 크게 와닿는 말이다. 취업 준비만 끝나면 공부에서 해방될 줄 알았다. 전공자인 나는 개발자가 된 후 더 많은 공부를 한다. 경력직이 알아야 할 지식도 있지만, 뒤처지지 않기 위해 더 앞서 나가기 위해 끊임없이 변화하는 테크 트렌트를 따라가야 한다. 굳이 트렌드가 아니라도 공부하면서 몰랐던 부분이 많았다는 것을 느낀다.

2️⃣ 안주하지 말고 배움에 집중하라 첫 직장을 6개월 만에 때려치웠다. 워리밸이 좋다고 해서 갔는데 어느 순간 코드를 복사해서 붙여 넣기 하는 나의 모습을 보았고 (기업 문화는 팀을 바꾼다고 달라지는 것이 아니므로) 경각심에 회사를 아예 옮겼다. 22살, 싱글, 미혼, 돈 걱정 없는 이때 최대한 많이 배우라고 했다. 지금 돌이켜 보면 이직하며 여러 곳에서 적성을 찾아보고 개인 시간까지 할애한 것이 다행이라고 생각한다. 지금 그때만큼 공부하라면 힘들 것 같다.

3️⃣ 말하지 않으면 아무도 알아주지 않는다 일은 그냥 주어지는 것이라고 여겼다. 개발은 코드라는 것을 보여주는 업무이기 때문에 코드만 잘 작성하면 다 알아주는 줄 알았다. 주니어 시절 승진이 빨랐던 친구들을 보면 당시 멘토가 해준 이야기가 기억난다. 조용히 일만 하면 안 된다는 것. 내가 한 일을 적당히 티 내면서, 간단한 질문이나 의견을 내며, 이루고자 하는 것 또는 원하는 것을 현명하게 말해야 한다.

실제로 이 조언을 반영했는데, 회사에서 많은 기회를 얻을 수 있었다. 다니던 회사에서 카운터 오퍼 없이 시기를 잘 맞춰 말한 덕분에 연봉 협상을 할 수 있었고, 덕분에 그해 현금 보너스와 함께 스톡옵션을 더 받았다. 남들이 하지 않은 것이나 출장을 갈 기회가 생기는 등, 말하기 덕분에 많은 것을 얻을 수 있었다.

4️⃣ 주니어 시절 많은 경험을 해야 한다 주니어는 시절 이직도 해보고 여러 전문 분야에 도전해보거나 스타트업에서 일해보는 것도 좋다. 가능한 많은 경험을 해보고 본인에게 맞는 커리어를 찾는 것이 좋다. 그렇지 않고 10년 후 적성에 안 맞아서 다시 도전하려면 불가능하지 않지만, 어렵다. 그러면 커리어 쌓기가 늦어질 수 있다. 이건 매니저가 해준 말이다. 매니저의 개발 경력은 13년이고 매니지먼트 경력은 3년이다. 본인보다 10살 어린 사람과 직급이 비슷하다. 조언해달라고 하니 “적성에 맞는 매니지먼트를 빨리 시작할걸”라며 후회한다고 했다. 한참 주니어 시절 코드 쓰기가 싫어서 적성에 안 맞는 줄 알았는데, 열심히 이직하고 경험해보니, 나에게 맞는 개발 분야가 따로 있었다. 현재는 코딩이 적성에 맞는다고 자신 있게 말할 수 있다. 이것도 주니어 시절 많은 경험을 해봤기 때문이다.

5️⃣ 마지막: 이 모든 조언을 해줄 수 있는 멘토가 필요하다 멘토가 한 말은 아니지만 지금 와서 생각해보니 멘토의 역할이 중요했다. 주니어 시절 제일 중요한 것은 여러 명의 멘토를 두는 것.

함께 읽으면 좋은 글:

“와 코딩 때려치우고 싶다”라는 생각 들 때

코딩 테스트 실력 향상시키기

자기 개발에 도움되는 개발 도서 효율적으로 읽는 법

💻 기술 소식: 커리어리 📄 무료 템플릿: 노션

전공 공부 시절 아무도 알려 주지 않은 적성에 대해 한 번 생각해봐야 했던 때가 있었다. 중학생 시절 검색으로 html / JavaScript 코드 복붙하며 이게 코딩인지도 몰랐고 (무지하게도 그래픽 디자인인 줄…) 그래서 대학생이 되어서야 본격적으로 코딩 공부를 시작했다.

대학 시절 사이드 프로젝트와 인턴십을 통해 백엔드를 할지 프론트엔드를 할지 결정했다. 백엔드 인턴십 경험이 그다지 긍정적이지 않았고 사이드 프로젝트를 하며 프론트엔드가 적성에 맞는 줄 알았다. 아무튼 코딩 공부하느라 바빠서 적성 생각할 겨를도 없이 졸업 후 프런트엔드 개발자가 되기로 했었다.

처음에는 프론트엔드 개발이 너무 즐거웠다. 눈앞에 내가 만든 것이 보이고 수만 명의 사람들이 볼 수 있고 사용한다니! 남들에게 보일 수 있는 코드 작성이 재미있었다. 해커톤에서도 뛰어난 감각으로 멋진 프론트엔드 코드를 작성하는 친구들이 너무 부러웠다. 하지만 이 재미와 부러움에 가려졌던 나의 고민은 바로 내가 하는 프런트엔드 개발이 적성에 맞지 않다는 것이었다. 어느 순간부터 코드 쓰는 게 극도로 싫었고, 개발이 적성에 안 맞는 줄 알았다. 지금 생각해보면 프런트엔드 코드를 작성하는 과정과 개발 도구 그리고 프론트엔드 개발 실무는 나와 전혀 맞지 않았다. 코딩이 적성에 안 맞는 줄 알고 정말 심각하게 프러덕트 매니지먼트나 아예 색다른 분야로 이직할까 고민했었다.

일단 몇 년 공들인 공부를 때려치우는 건 무섭고 비자 문제도 있었기에 쉽게 개발을 포기하지 않았다. 마침 다니던 회사에서 우연히 (라고 말하지만 강제로) 풀스택으 개발자로 일할 기회가 생겼다. 내가 맡은 프론트엔드 업무를 해외 외주에 넘겨버리는 바람에 나는 낙동강 오리알 신세가 되었다. 다행히도 회사에서 인사이동을 시켜줬고, 백엔드 개발을 접할 기회가 생겼었다. 백엔드 개발을 해보니, 코딩이 극도로 싫었던 내가 백엔드 개발을 즐기고 있었다. 나는 백엔드를 구축하고 특정 분야에 대한 문제를 분석하고 설계한 후 코드로 해석하는 것이 즐거웠다는 것을 늦게 알아차렸다. 풀스택을 하려니, 정말 프론트엔드 업무는 맞지 않다는 것을 다른 것을 해보고 알게 되었다. 그래서 최종적으로 백엔드 업무만 하는 회사로 이직했고, 그 후 백엔드 중에서도 개발 산업 내에서 부상하거나 중요한 분야를 찾았다. 신기하게도 그 이후로 코드 작성하는 것이 극도로 싫다고 느낀 적이 없다. (다만 현재는 번아웃이 자주 온다는 것…)

개발에는 수많은 분야가 있다. 코딩을 배워서 가질 수 있는 직업과 분야도 세분화되어있다. 만약 코드이 적성에 안 맞는다고 느껴지면 개발 내 다른 분야를 도전해 보는 건 어떨까? 코딩 스킬이 있으면 다양한 직업을 가질 수 있다. 데이터 과학, 사이버 보안, 테스트 엔지니어, 머신 러닝 엔지니어, 데이터 엔지니어, SRE, 솔루션 엔지니어 등등…

좀 더 나아가 주니어 시절 다양한 경험을 통해 여러 가지 분야의 개발을 해보며 빨리 내 길을 찾는 것도 중요하다고 생각한다. 예를 들어 얼마 전 프론트엔드 경력이 5년 있는 개발자가 백엔드 개발이 하고 싶어서 이직했는데, 3개월 만에 다시 프런트엔드 개발로 재이직했다. 전혀 새 분야를 이미 어느 정도 경력을 쌓고 배우는 건 힘들 수 있다.

함께 읽으면 좋은 글:

코딩 테스트 실력 향상시키기

자기 개발에 도움되는 개발 도서 효율적으로 읽는 법

💻 기술 소식: 커리어리 📄 무료 템플릿: 노션

🌱 새로운 유형이 기존 유형을 대체하지 않습니다.

📌 새로운 면접 유형

“요즘 새로운 유형”이라는 표현은 부적합하지만, 최근 2~3년간 기존 방식 외 다른 유형의 면접이 존재한다는 것을 알게 되었습니다.

1️⃣ 30분~60분짜리 프레젠테이션

프레젠테이션 면접은 본인의 사이드 프로젝트를 보여주거나 전문 지식을 가르쳐 주는 방식 또는 본인이 설계한 시스템을 설명하는 형식이다. 프레젠테이션 슬라이드를 준비해서 면접관에게 보여줘야 한다.

2️⃣ 본인이 실제 디자인한 시스템 설계 설명

기존 시스템 설계 면접은 "가상 시스템 설계"를 하는 방식이다. 예를 들어 "소셜 미디어 앱을 설계하세요"와 같은 문제를 풀어야 한다. 여기서 조금 진화한 유형은 과거에 설계해 본 시스템을 버추얼 화이트보드에 그리는 형식의 인터뷰다. 생각보다 상당히 많은 회사에서 사용하고 있는 면접 유형이다. 주의할 점은 시스템 설계 중 기밀 정보는 되도록 언급하지 않는 것이 좋다. 또는 보편적인 설계법이라 기밀 정보가 없는 시스템 디자인을 선택하는 것이 좋을 것 같다.

3️⃣ 특정 전문 분야 관련 토론 형식

지원한 포지션에 따라 다르지만 전문 분야 관련 토론하기 유형도 있다. 예를 들어 제 전문 분야인 분산 시스템에 관련된 주제에 관한 질문하고 대답하는 형식이다. 보편적인 분산 시스템 지식에 대해 질문을 하는 것이 아니라 경력 없이는 대답할 수 없는 아주 디테일한 부분까지 파고든다.

4️⃣ Computer Science 기초 지식

첫 전화 인터뷰 단계는 대부분 코딩 테스트다. 통상 리트코드 형식으로 알고리즘 문제를 출제하는데, 요즘은 컴공 기초 지식을 파고드는 유형도 있다.

5️⃣ 기존 코딩 테스트에서 살짝 변형한 유형

기존 코딩 테스트는 가상 문제를 푸는 형식입니다. 온라인에서 많이 볼 수 있는 문제가 제출될 때도 있고, 그렇지 않은 예도 있다. 살짝 변형한 유형은 흔한 문제를 제출하는 것 대신 실제 업무와 관련된 코딩 테스트 문제가 출제된다.

📌 생소한 유형 글로벌 기업에서 많이 보이는 유형이며, 생소할 수 있습니다. 서류 심시 통과 후 리쿠르터와 전화 미팅을 하는데, 이때 면접 포멧을 물어보는 것이 좋습니다.

📌 내 생각 개인적인 생각이나, 이직 생각이 없어도 코딩 테스트와 시스템 디자인 면접은 1년에 한 번씩 (모의 또는 실제) 인터뷰를 통해 꾸준히 연습하는 것이 좋아요.

📌 새로운 면접 유형에 대한 여러분의 생각은 어떠신가요?

함께 읽으면 좋은 글:

코딩 테스트 실력 향상시키기

자기 개발에 도움되는 개발 도서 효율적으로 읽는 법

💻 기술 소식: 커리어리 📄 무료 템플릿: 노션

📌 니트코드 150 아래 사이트에 들어가면 알고리즘 별 자주 출제되는 패턴과 친숙해질 수 있는 코딩 문제가 나옵니다. Easy, Medium, Hard 단계별로 정리되어 있고, 문제 풀이 영상도 같이 삽입되어 있어요. 니트코드라는 유튜버인데, 말을 느리게 해서 알아 듣기 쉽고, 문제 풀이법도 아주 쉽게 가르쳐 줍니다.

📌 니트코드 All 웹사이트에 있는 메뉴 탭에서 "Neetcode All"을 선택하면 니트코드의 코딩 문제 풀이법 305개가 전부 나옵니다. 처음부터 All버전으로 시작하면 조금 힘들 것 같아요.

처음에는 지난 포스팅에 언급한 Blind 75로 학습 시작하시고, 어느 정도 속도가 붙고 개념과 친숙해졌을 때 니트코드 150 해보신 다음, 시간이 나는 경우 니트코드 All 버전으로 350개 모두 풀어보는 것도 괜찮습니다.

이 플랫폼의 장점은 수천 가지가 넘는 문제를 풀 시간이 없는 분들에게 꼭 풀어야 하는 문제만 알려주는 것입니다. 기존 블라인드 75 리스트도 목적은 같지만 문제가 75개밖에 안돼서 면접 준비하기에는 조금 부족하다고 느끼는 사람도 있어요.

📌 알고리즘 패턴 내 것으로 만들기 패턴을 한 문제로 공부하고 연습하기에는 부족하지 않나요? 이때 리트코드에 있는 “비슷한 문제” 기능을 사용해 보세요.

리트코드의 비슷한 문제 기능은 거의 동일한 알고리즘 패턴을 사용하는 문제를 알려줍니다. 비슷한 문제의 코드를 보면 한, 두줄 차이 날 정도로 풀이법이 비슷합니다. 패턴과 익숙해지려면 비슷한 문제를 같이 풀어보는 것을 추천합니다.

📌 추가: 니트코드 유튜브에 있는 알고리즘 유형별, 문제 난이도별 플레이리스트 영어 듣기 연습할 겸 알고리즘 풀이법 공부할 겸 닛코드 플레이리스트 한 번 찾아보세요. 그래프, 트리 등등 알고리즘 별로 관련된 문제 풀이법을 모아 놓은 플레이리스트가 있습니다. 특정 유형이 어렵다면 풀이법을 보는 것도 나쁘지 않아요. 다만, 문제를 먼저 풀어보지 않고 풀이법부터 보는 건 그닥 도움되지 않아요.

📌 니트코드 문제 풀이법이 가르쳐 주는 것 단순하게 면접 패스를 위해 알고리즘 패턴을 외우는 것이 아니라, 문제의 접근 방식을 알려줍니다. 작은 단위로 보면 단순 문제 접근 방식이나, 크게 보면 실무에도 적용할 수 있는 방식입니다. 니트코드의 풀이법은 “접근 방식”과 “컴퓨터처럼 생각하는 힘”을 기르고 기본기를 다지는데 도움되는 것 같아요. 시간이 걸리더라도 단순 문제법과 알고리즘을 외우는 것이 아니라 위 두가지를 배워두는 것이 좋을 것같습니다.

🔗 https://youtube.com/c/NeetCode

함께 읽으면 좋은 글:

자기 개발에 도움되는 개발 도서 효율적으로 읽는 법

💻 기술 소식: 커리어리 📄 무료 템플릿: 노션

학생 시절에는 공부할 게 산더미 같던데 막상 개발자가 되니 도대체 뭘 공부해야 할지 모르겠더라고요. 주니어 시절 했던 아주 나쁜 이 공부법을 스스로 고치면서 나름 도움 되었던 "개발자의 공부법"에 대해 이야기해봅니다.

1️⃣ 시스템 디자인 공부 시스템 디자인 공부는 어느 개발 직종에 있더라도 필수이다. 알고리즘과 달리 대학 전공 수업에서 배울 수 없고, 배운다고 해도 학생 시절에는 제대로 써먹을 곳이 없다. 따라서 업무와 경력을 통해 얻어야만 하는 필수 스킬이다. 문제는 시스템 디자인 공부는 몇 개월 열심히 하면 느는 것이 아니다. 대부분 경험과 실무를 통해서 배워야지만 는다. 개발자 1년 차부터 차차 시스템 디자인 업무를 해본 사람과 아닌 사람의 실력 차이가 해가 지날수록 많이 나게 된다.

더욱더 큰 문제는 주니어 시절부터 미리 하지 않으면 나중에 이직이 어려워질 수 있다. 이직은 연봉을 두 배로 올리거나, 건강하지 못한 조직에서 벗어날 수 있는 아주 중요한 방법인데, 시스템 디자인을 못 하면 한 직장에 갇혀버릴 수 있다. 많은 시니어+ 직급의 면접은 시스템 디자인을 잘해야 통과할 수 있으며, 코딩 면접을 잘 통과해도 시스템 디자인을 잘하지 못할 때 본인의 현 직급 이하로 강등될 수 있다. 시스템 디자인 공부는 흥미와 상관없이 1년 차부터 관련 도서를 읽어 보며 업무를 통해 배우는 것이 아주 큰 도움 된다.

2️⃣ 업무와 관련된 키워드 10개 찾아내기 개발 관련 폭넓은 지식을 가지는 것은 상당히 중요하다. 하지만 처음부터 폭넓은 지식을 얻고 나면 막상 써먹을 곳이 없었던 것 같다. 책과 유튜브를 통해 공부해도 사용하지 않으면 쉽게 까먹게 되는 것이 개발 지식이다. 개발 직업군은 전문 분야에 따라 습득해야 하는 스킬이 상당히 다르다. 예를 들면 프런트 엔드와 Distributed Systems 백엔드 엔지니어가 가지고 있어야 할 스킬은 많이 다르다. 따라서 본인의 현재 업무에 관련된 키워드 10가지를 찾아내자 (예: kubernetes). 키워드 10개를 스스로 찾아본 후에는 매니저나 멘토 그리고 직장 동료와 간단하게 이야기해보고 1위부터 10위 순위를 정해보자. 탑 5 키워드 관련 도서를 검색해보고 읽거나 유튜브 동영상을 찾아보자.

3️⃣ 멘토의 중요성 멘토에게 개발자 성장기에 도움 되는 주제를 3가지 물어본다. 업무 관련된 지식이 성장 그리고 본인이 도달하고픈 큰 목표에 도움 되지 않을 수 있다. 예를 들면 백엔드 개발자가 프론트 엔드로 전향하기를 원하거나 다른 직업군으로 이직을 희망한다면, 업무 관련 공부는 길게보면 도움 되지 않는다. 내가 그랬다. 분산 시스템을 한 번도 공부해보지 않았던 내게 이 분야로 이직하려면 필요한 기초 지식을 습득해야 했다. 인터넷에 검색해도 정보량이 상당해서 멘토에게 물어봤다. 1,2명에게 물어보는 것보다 되도록 많은 이들에게 물어보고 추천해준 주제 관련 도서나 전자책을 읽어봤다.

4️⃣ 목표를 정하자 "일단 뭐라도 하자"라는 목표는 결국 3일을 못 가게 만든다. 실제로 내가 Coursera나 EdX 또는 Udemy에서 "일단 이 수업 들어보자"라는 목표를 정해 놓고 일주일도 못 가고 포기했던 기억이 있다. 공부하려면 목표가 필요한 것 같다. 목표는 최대한 구체적으로 데드라인까지 적는 것이 좋은 것 같다. 아니면 새해 목표처럼 세워도 된다. 예를 들면 한 달에 적어도 distributed system이나 system design 관련 테크 도서 한 권 읽기, 2022년 6월까지 distributed system Youtube Channel x,y,z playlists 모두 시청하기 등등.

5️⃣ 내가 자주 사용하는 공부 아이디어 찾는 요소

• https://www.reddit.com/r/cscareerquestions/
• https://www.teamblind.com
• 회사 내 북클럽, 리딩 리스트
• 직장 동료와 하는 커피챗

함께 읽으면 좋은 글:

자기 개발에 도움되는 개발 도서 효율적으로 읽는 법

💻 기술 소식: 커리어리 📄 무료 템플릿: 노션

1️⃣ 종이책보다는 전자책으로 연초에는 나름 세웠던 새해 계획을 시작한다고 열정이 넘쳐서 종이책을 구매한 후 한 줄 한 줄 꼼꼼히 읽으면서 덤으로 노트까지 받아 적었다. 이렇게 독서하니까 한 장을 읽는데 무려 하루 이상 걸리는 경우가 허다했다. 두 장까지는 할만한데 그 후부터는 책 만지기가 무서워졌다. 이 방법은 현재 내게 적합하지 않다고 판단하고, 가볍게 들고 다니면서 읽을 수 있는 전자책을 사용하고 있다. 30분씩 시간 날 때마다 들고 다니는 스마트폰 또는 태블릿으로 페이지 몇 장씩 읽었다.

2️⃣ 하이라이트의 중요성
읽으면서 중요하다고 생각하는 부분은 무조건 하이라이트 했다. 예전에는 받아 적으면서 했는데 시간이 너무 많이 걸려서 노트 받아 쓰기는 생략하고 하이라이트만 했다. 중요하지 않아도 모르거나 생소한 단어나 개념이 나오면 하이라이트하고 책을 다 읽은 후에 하이라이트 했던 문장을 다시 보면서 검색해봤다.

3️⃣ 하이라이트한 문장 복습하기 요즘 전자책 앱으로 킨들 사용하는데 좋은 점은 하이라이트 한 문장을 한꺼번에 볼 수 있는 기능이다. 다른 어플도 "북마크"한 문장은 모아서 따로 읽을 수 있기 때문에 책을 정독한 후 30분 정도 시간 날 때마다 하이라이트 한 문장만 다시 읽어본다. 하이라이트 해둔 문장만 읽어보면 "완전히 습득하지 못한 개념"을 이해하거나 오래 기억하는 데 큰 도움이 된다. 책 한 권을 다시 읽으려면 시간이 없고 빠른 시간 내에 효과적으로 개념을 다시 복습하려면 하이라트한 문장만 여러 번 시간 날 때마다 읽어보는 것이 아주 큰 도움이 되었다. 그뿐만 아니라, 하이라이트 한 문장을 읽으면서 앞, 뒤 문맥을 다시 읽어보려면 해당 문장을 클릭하면 관련 페이지로 갈 수 있다. 하이라이트 한 문장 중에서도 빠르게 읽을 수 있는 게 있고, 시간이 걸리거나 까먹은 부분이 있다. 그런 부분은 클릭해서 관련 페이지만 다시 빠르게 읽을 수 있으니까 효율적으로 복습하는데 도움 되는 것 같다. 마지막으로 좀 더 깊게 파고들고 싶은 부분은 하이라이트 해놓고, 그 부분은 따로 인터넷에 검색하면서 노트를 받아 적는다. 개발 도서 중에 한 주제만 깊게 파고드는 책만 있는 것이 아니라, 큰 그림을 가르쳐 주는 책이 상당히 많다 (예: system design interview나 지난번에 소개한 책의 경우). 이 경우 따로 검색해야 하는데, 읽으면서 하나씩 검색하고 정독하려면 시간이 엄청나게 걸려서 쉽게 포기하게 된다. 그래서 하이라이트만 해놓고 따로 시간 날 때 검색하는 방법을 사용하고 있다.

4️⃣ 하이라이트 부분만 노트로 정리하기 예전에는 책을 읽으면서 노트를 정리했다면, 요즘은 하이라이트 해뒀던 문장들을 몇 번 되새김질 해보고 인상 깊었던 부분이나 중요하다고 생각하는 점은 노트에 받아 적는다. 반복적으로 읽더라도 나중에 개발할 때 도움 될만한 부분은 노트에 한눈에 보기 쉽게 정리해 놓는다. 그리고 손으로 받아 적으면 그냥 읽는 것보다 개념을 습득하는 데 아주 큰 도움이 되는 것 같다.

5️⃣ 책에 나온 개념 관련 토론하기 이건 책 읽을 때마다 하는 건 아니지만 같은 책을 읽은 동료가 있거나 동료가 소개한 책이라면 책에서 배운 흥미로운 점은 간단하게 토론해봤다. 확실하게 그 부분은 시간이 지나도 잊히지 않았다. 토론하는 게 하이브리드/재택근무 때문에 많이 적어져서 아쉽지만, 북클럽을 한다면 북클럽에서 토론하는 형식으로 개념 이해를 굳히는 것이 아주 큰 도움이 될 것 같다.

💻 기술 소식: 커리어리 📄 무료 템플릿: 노션