개발자 취업 준비 전술과 전략

💡 포트폴리오 첨삭 필요하신 분들은 참고 👉🏻 링크

📌 서론

여러 시행착오를 통해 알아낸 것들과 현직 개발자분들을 통해서 수집했던 정보들입니다.

제가 사용하지 않은 방법들도 있긴 하다만, 써먹어 볼만한 아이디어가 있다면 찍먹해보는 용도로 읽어보셔도 무방합니다.

추가로 공유할 정보가 떠오를 때마다 별도 공지없이 추가될 수 있으며, 궁금한 점은 댓글로 남겨주세요.

(쓰다가 글이 한 번 날아가는 바람에 다시 쓰고 있는데, 시간이 너무 오래 걸려서 미완성인채로 일단 게시했습니다.)

부질없는 포스팅일 수도 있지만, 지독한 취업난에서 단 한 명이라도 더 도울 수 있길 바랍니다.

한 가지 당부드리고 싶은 것은 개발을 잘 하는 사람과 취업을 잘 하는 사람은 다릅니다.

취준을 위해 프로젝트에 매진하신 분들이 많으신데, 응원하고 싶은 마음은 굴뚝같으나 정말 그게 문제인지 고민해볼 필요가 있습니다.

요즘 취업은 운입니다.

제가 취업을 할 수 있었던 것이 온전히 저의 노력 덕분이 아닌 것처럼, 여러분들께서 취업을 못한 것이 오로지 여러분들의 문제라고 볼 수도 없습니다.

다만, 적어도 그 실낱같은 운이 찾아왔을 때 전력을 다해 붙잡으려면 노력을 해야하고, 그러기 위한 취업 전략을 구상해야 합니다.

너무 희망 고문같은 말을 늘어놓는 것같아 저도 마음이 굉장히 좋지 않네요.

노력하고 계신 모든 분들께 좋은 결과가 있길 바라는 마음에서 글을 적습니다.

🙅🏻 제 포트폴리오를 달라는 요청은 정중히 사양합니다.

전 감히 값싼 동정을 던지고자 이 글을 작성한 것이 아닙니다.
그저 조금 운이 좋았던 대등한 위치의 한 사람으로서, 제가 가진 정보를 공유할 뿐입니다.
따라서 무례함에는 단호하게 대처하겠습니다.

📌 기본 전략

원하는 도메인 정할 것
- 빅테크, 스타트업, 전통적인 대기업, 금융권 등등 도메인에 따라 준비 방법이 심할 땐 천차만별로 갈리기도 합니다.
가고 싶은 회사 최소 10곳 정도 스캔해둘 것
- 각 회사에서 요구하는 인재상, 요구 스택, 최근 6개월 이내의 기술적 & 사업적 관심사, 연복, 복지 등.
  - 구글, 마소, 엔비디아 같은 곳을 갈 게 아니라면 최고가 될 필요는 없습니다. 아뇨, 오히려 그들이 줄 수 있는 연봉으로 당신을 잡을 수 없다고 판단하면 오버스펙으로 채용을 안 합니다. (이건 현직자들하고 조금만 대화해봐도 쉽게 얻을 수 있는 정보입니다.)
  - 나의 월등한 능력을 어필하는 것보다, 내가 왜 이 회사에 적합한 인재인지, 내가 이 도메인 혹은 회사에 얼마나 관심이 많은 지 보여주는 게 나은 곳도 있습니다.
- 해당 회사에 직무하는 현직자가 진행하는 커피챗을 돈 주고 하든, 링크드인에서 커피챗 해달라고 부탁을 드려보든, 어떻게든 실무자와 접촉해서 정보를 수집하는 것이 가장 좋음.
  - 지원서를 넘겨보다가 커피챗을 해줬던 사람을 보면 한 번이라도 더 봅니다.
- 희망하는 회사는 떨어지면 3~6개월 내 재지원해도 서류 자동 탈락될 확률이 높고, 붙는다고 하더라도 성장한 모습을 증명해야 해서 난이도가 급상승합니다. 함부로 지원하시면 안 돼요.
  - 사실 저는 딱히 가고 싶은 회사를 못 찾아서 방황하고 있었습니다. 연봉, 복지 이런 것보다 나와 회사가 함께 성장할 수 있느냐가 가장 중요했는데, 이건 뭐 정보 수집이 너무 어려워서 면접 보면서 분위기 읽는 방법 뿐이라...
최대한 많이 지원해보고, 모든 지원 정보 상태를 갱신할 것
- "제가 아직 준비가 되지 않아서요"라는 핑계로 서류 제출을 꺼려하시는 분들이 많이 계신데, 완벽하게 준비된 상태같은 건 존재하지 않습니다. 겸손함과 미련함은 엄연히 것입니다. (제가 완벽한 사람같나요?? 전혀요.)
  - '이런 사람이 왜 아직도 취직을 못했지?'하고 보면 완벽을 추구한다고 상반기 지원을 거의 안 한 사람들이 태반이던데, 그건 실력이나 노력의 문제가 아니라 그냥 전략적 사고가 뭔지 모르는 겁니다.
  - 노력이 당신을 배신하나요? 그렇겠죠. 눈 가리고 앞으로 전력질주하는 것도 노력이라고 불러주는 미련한 사회에 순응하면 그렇게 됩니다. 제가 그렇게 재수 생활 대차게 말아먹고 정신 차렸었습니다.
- 위에서 뽑은 10가지 회사를 제외한 나머지 회사는 떨어져도 별 타격 없으므로, 공고가 올라오면 관심없는 도메인도 모두 지원해봐야 합니다. (한창 채용 많이 열릴 시기엔 주에 10개씩 지원하라고 들었음.)
  - 지방에 사는 분들은 교통비 절감을 위해 수도권에 고시텔 하나 구해놓고 베이스 기지로 활용하시는 게 오히려 싸게 먹힙니다. (한 회사에서 2차 면접까지 가면 최소 20만 원부터 시작하니 잘 계산해보세요.)
  - 전 3~5년차 경력직 공고까지 지원해보기도 했습니다. 놀랍게도 붙을 때가 있는데, 종종 운이 좋으면 채용 전환 인턴 기회를 주는 곳도 있으니 도전해보면 좋습니다.
- 노션같은 도구를 이용해서, 각 지원 현황(e.g. 지원 회사, 요구 스택, 지원 날짜, 마지막으로 진행한 프로세스 등) 정보를 갱신해두어야 합니다.
  - 그래야 내가 채용 프로세스 어디서 계속 떨어지는지를 파악하고, 취약점을 개선할 포인트를 찾아낼 수 있습니다.
취준은 장기전입니다. 최소 1년은 잡고 하세요.
- 요샌 1년 취준한다고 늦는 것도 아닌 게 슬픈 현실입니다. 졸업하고 4개월만에 겨우 취업했는데, 영어 스터디 같이하는 모 회사 이사님께서 엄청 빨리 갔다고 놀라시는 걸 보면... 이미 다들 알고 있습니다.
- 우리가 취준을 시작한다고, 회사들이 거기에 맞춰서 채용 공고를 내주지 않습니다. 채용을 위한 예산 절차를 밟아야 하고, 이는 보통 1년 단위로 계획됩니다. 조바심낸다고 공고가 열리진 않습니다.
- 붙어도 1년 내로 이직을 염두할 회사는 안 가는 게 맞지만, 요샌 워낙 경제가 안 좋아서 이건 본인이 잘 판단하시길 바랍니다. 저도 몇 군데 붙었을 때 갈까 말까 엄청 고민했었는데, 회사와 저 모두 손해만 입는 관계라 접었었습니다. 그 뒤에 부모님 눈치를 한참 봤었습니다. (ㅜㅜ)
CS는 제발 학교 다닐 때 제대로 공부해두시고, 안 했다면 평소에 계속 다시 보시길 바랍니다.
- 면접 준비할 때 얕게 공부하면 다 티 납니다.
- 취준할 때는 잊어먹은 CS 복습 정도만 하는 것이지, 학창 시절에 게으르게 살았던 걸 보상하는 시기가 아닙니다.
블로그 잘 써두시면 유용합니다.
- 어디서나 볼 수 있는 글 복붙하거나, 번역해놓은 거 말고, 짧아도 좋으니 개인 고찰이 담겨 있어야 유의미합니다.
- 취업을 위해 운영한다고 하면 어려우실 거고, 공부를 위해 운영하세요. 이 내용은 기술 블로그 포스팅을 작성하는 노하우라는 포스트를 작성했던 관계로 생략합니다.
협업 시 발생하는 갈등은 스트레스 원인이 아니라 기회로 삼으세요.
- 물론 좋은 팀원, 팀장, 사람이 되고 싶다는 마음가짐과 올바른 길을 끝없이 고민하기 위해 갈등을 대응하려는 게 가장 중요합니다.
- 하지만, 그런 내적 고민들을 무색하게 만들 정도의 갈등이 생겼을 때는 '이걸 어떻게 해결해야 포트폴리오에 쓸 수 있을까?'라고 발상의 전환을 해보시는 것도 하나의 방법입니다. (예전에 제가 팀플 때문에 너무 힘들어하니 현직자 분이 해주셨던 조언입니다.)
고립하지 마세요.
- 주위에서 "OO님은 이런 걸로 무너질 분이 아니시잖아요~"라고 하는데, 저도 제가 이렇게 많이 흔들릴 줄 몰랐습니다.
- 같이 공부하는 모임 만들어서라도 정보 수집하고 멘탈 관리하세요.
본인만의 킥을 만드세요
- 요새 스타트업 채용 공고 하나에도 서류 몇백, 몇천 장씩 들어갑니다. 면접관 분들께서 그거 하나하나 다 꼼꼼하게 못 읽습니다.
- 시험이라도 쳐서 "상위 O명 뽑는다!"라고 하지 않는 이상, 개개인의 실력을 가늠하기도 쉽지 않습니다.
- 그래도 가능성을 조금이라도 만드는 방법이 있다면, 그 수두룩한 서류 더미에서 나를 긍정적이든, 부정적이든 한 번은 되돌아보게 만들 요소가 필요합니다. 가장 무서운 건 무관심입니다.
가능하다면 대학 다니면서 영어 면접이 가능한 수준의 공부를 해보시는 것도 고려해보세요.
- 선택의 폭이 생각 이상으로 정말 많이 넓어집니다. (전 3번 도전하고 시원하게 말아먹은 후부터 각 잡고 공부 중이긴 합니다. ㅎㅎ;)
- 영어 공부하면서 만났던 개발자 분들 중에 외국계 기업 국내 지사 다니시는 분들 보면 대부분 그런 케이스였습니다. (생각보다 영어 잘 하는 개발자가 흔치 않은 건가 싶긴 한데, 잘 모르겠어요.)

📌 자소서 & 포트폴리오

세상에 완벽한 포폴은 존재하지 않습니다. 더 나은 포폴만이 존재할 뿐.
전 포폴만 쓰고 자소서는 쓰지 않았습니다. 그냥 자소서 & 포폴 모두 내라고 하면 자소서에다가 포폴내버렸습니다.
'나'의 입장에서 서술하지 말고, '면접관'의 입장에서 서술하세요.
- 동아리 대표할 때 면접관 입장으로 서류를 읽어본 적이 있는데, 하나하나 꼼꼼하게 읽는 게 매우매우매우 어렵습니다.
- 본인의 경험을 모두 적고 싶은 욕구는 이해하지만, 읽는 입장에서 필요한 정보만 빠르게 확인할 수 있도록 간결하게 적는 게 나을 수도 있습니다.
양날의 검을 도입하는 것을 고려해보세요.
- 자기 소개 첫 줄에 워딩이 센 단어를 삽입했었는데 호불호가 극명하게 갈렸었습니다. 그런데 불호였던 분들조차 어쨌든 눈에 띄긴 해서 넣는 게 좋을 것 같다는 의견들을 많이 내주긴 하셨습니다. (자칫하면 호불호를 떠나 그냥 불호니까 첨삭을 많이 받아보세요.)
- 보수적인 문화를 가진 회사에 지원할 때는 순화한 버전의 포폴을 내시는 게 좋습니다.
포트폴리오 버저닝을 하고, 서류 합격률을 계속 확인하세요.
- 저는 프론트엔드 개발하듯이 포트폴리오를 작성했었는데, 하나의 주제를 여러가지 버전으로 작성해 컴포넌트를 만들고, 지원하는 회사 성향에 따라 컴포넌트를 조립해서 포폴을 제출했었습니다.
- 똑같은 포폴로 5~10군데 지원해보고, 합격률이 저조하면 멘트를 바꿔보거나 다른 컴포넌트를 끼워보는 등. 서류 합격률이 70% 이상 나올 때까지 반복했습니다.
쉬운 용어를 사용하는 것을 고려해보세요.
- 예를 들어, 여러분들이 이커먼스 회사에 지원을 했다고 칩시다. 해당 팀은 Spring + Java에 굉장히 익숙한데, 내가 포트폴리오에 적은 도메인과 기술은 완전히 별개의 것인 상황이라고 가정해봅시다. 여기서 나의 전문성을 어필하기 위해 온갖 비즈니스 용어와 전문 기술 용어를 나열했을 때, 면접관 분들은 '정말 뛰어난 지원자구나'라고 생각을 할까요, 아니면 '뭐라는 거지'라고 생각을 할까요? (저도 진짜 몰라서 던지는 질문입니다.)
- 경우에 따라서는 누구나 이해할 수 있는 쉽고 직관적인 용어로 나의 강점을 어필하는 것이 효과적일 수도 있습니다.
전달력을 높이기 위해 거짓을 섞지는 마세요.
- 첨삭을 해드리다보면, 해보지도 않은 거짓 경험을 나열하시는 분들이 생각 이상으로 정말 많습니다. 도덕성을 논할 생각은 없지만, 뒷감당할 자신 없으면 하지 마세요. 대화를 해보면 상대가 사용하는 언어, 행동, 말투 등으로 거짓이 드러나는 경우가 많습니다. 특히나 고작 제 수준에서 걸릴 거짓이면 하는 의미가 없습니다.
- '전달력을 높인다'라는 의미는 말 그대로 문장 구조에 신경을 쓰라는 의미입니다. 서술 구조와 각 문단 별로 어떤 내용을 몇 줄 정도로 적었을 때, 가장 효과적으로 나의 경험을 상대에게 전달할 수 있을 지 고민해보세요. 생각보다 이것만으로도 같은 경험을 전혀 다르게 인식하게 만들 수 있습니다.
많은 분들에게 첨삭을 받아보세요.
- 전 주니어, 시니어 개발자 분들 뿐 아니라, 비개발자 분들께도 많이 첨삭 받았었습니다.
  - 주니어 & 신입 개발자: 얼마 전까지 취업 전선에서 뛰던 분들이기에 최근 채용 트렌드를 가장 잘 알고 있습니다.
  - 시니어 개발자: 되도록 최근 1년 이내 면접 경험이 있는 시니어 개발자 분이 좋습니다.
  - 비개발자: 최근에는 거의 드물지만, 예전에는 인사팀이 서류를 먼저 확인하는 곳도 많아서 비개발자 시선에서 포폴 첨삭 받았었습니다.
- 지인이나, 지인의 지인을 통해 첨삭을 받으면 관계 상 어쩔 수 없이 사실을 있는 그대로 전달해주지 않는 경우가 많습니다. 첨삭은 칭찬과 응원을 받는 것이 아니라, 내가 부족한 것이 무엇인지 확인하고 보완하는 자리라는 것을 적어도 본인은 잊으면 안 됩니다.
포트폴리오에 취약점을 섞어서 공격 루트 파악해보는 방법
- 예전에 해커가 공격을 할 때, 보안팀이 일부로 바로 잡지 않고 침투 루트를 관찰하다가 잡는 경우도 있다는 말을 듣고 착안한 방법입니다.
- 고의적으로 포트폴리오에 면접관이 치고 들어오기 좋아보이게 만든 취약점을 드러내고, 거기서 파생될 수 있는 질문과 꼬리 질문들을 모두 준비해놓은 적이 있습니다. 만약, 면접 때 예상치 못한 경로로 치고 들어오면, 면접이 끝나고 그 경로도 보완하는 식으로 개선하는 전략입니다.
- 다만 이게 성사가 되려면, 다른 부분은 최대한 완벽하게 만듦과 동시에 면접관이 취약점을 치고 들어가고 싶게끔 맛있게 만들어야 하는데 상당히 어렵습니다.
포트폴리오 주도 개발을 해보시는 것을 고려해보세요.
- 📎 개발 공부하다가 방황하는 사람들을 위해 써보는 글에서 나의 이상적인 모습을 포트폴리오로 먼저 쓰고, 실제로 거기에 맞춰 나를 만들어나가는 공부 방법에 대해 쓴 적이 있습니다. 전 사용하지 않은 전략입니다.
추진력을 이용해서 1년 내로 이직을 해보는 것도 방법입니다.
- 취준을 하다가 적당히 타협을 볼 수 있는 회사를 들어갔을 때, 그 회사의 문화에 안착하는데 시간이 걸립니다. 그 때는 실무적인 경험치보다도 지금까지의 취업을 위해 달린 노하우가 압도적으로 높습니다.
- 나름 한동안 다닐만한 회사에 일단 붙었지만, 만약 더 욕심이 생긴다면 1년 정도는 지금까지 달렸던 추진력을 이용해서 이직을 시도해보기 가장 좋은 시기입니다.
포폴의 첫 번째 핵심은 가독성, 둘째는 실증적인 정보입니다.
- 나의 핵심 역량을 보여주는 것 외에 나머지는 다 부차적인 요소입니다. 자기소개, 작업했던 프로젝트를 소개, 구구절절한 사연 등을 적는 것에 너무 매몰되지 마세요.
- 실증적인 정보가 없으면 모두 신뢰할 수 없는 말일 뿐입니다. 증거를 열심히 수집해서 보여주세요.
- 내용이 길면 핵심 역량이 드러나게 보여주기가 매우 어렵습니다. 위에서 말했듯 여러분들의 포폴만 시간을 들여 찬찬히 읽어줄 거란 기대를 하시면 안 됩니다.

📌 코딩 테스트

우선 기초적인 것부터 짚고 넘어가자면,

백준은 최소 실버2 이상, 프로그래머스는 레벨 3 이상(너무 어려우면 2)을 추천합니다.
- 기초 문법이 익숙치 않아서 낮은 레벨을 꾸준히 풀고 계신 분들을 많이 봤는데, 내 주력 언어로 문제를 푸는데 문법이 약한 거면 평소 공부 습관이 잘못된 것이고, 코테용 언어를 사용 중이신 거면 문법을 한 곳에 모두 정리해두고 코테 풀기 전에 한 번씩 읽어보세요.
- 코테 공부는 문제 해결 사고를 기르기 위함이지, 기초 문법을 공부하는 시간이 아닙니다.
너무 심오한 알고리즘 문제보다는 구현 문제부터 우선 다 풀어보세요.
자신만의 코테 전용 프로그래밍 스타일을 만들어두는 것이 좋습니다.
- 예를 들어, Java에서 bfs queue를 만들 때 좌표를 기록해야 한다면, 누구는 객체를 만들 것이고 저는 Queue<int[]> 같은 문법을 많이 사용했었습니다.
문제를 풀기 위한 자신만의 프로세스를 계속 만들어보시길 바랍니다.
- 예를 들어, 문제에서 가장 핵심적인 내용들을 추려내서 정리하는 노하우라던가, 문제 해결을 위한 설계를 하는 방법이라던가..
- 저는 그냥 코드에 제 생각을 주석으로 전부 써버리는 편이었는데, 이걸로 지적을 받아본 적이 한 번도 없었고, 오히려 제가 어떤 관점에서 문제를 풀었는지 전달이 되어서 흥미롭게 보신 분들은 계셨었습니다. (가끔 A4 허용 안 하는 테스트들이 있어서 연습할 때도 필기를 아예 안 했습니다.)
- 무려 3년 전에 작성했던 📎 알고리즘 문제를 풀면서 생각해보아야 할 것들 포스팅 링크 첨부해둡니다.
저는 하루에 몰아서 많이 푸는 것보다 매일 꾸준히 푸는 게 나았습니다.

만약 저와 같은 웹 서비스 직군이라면, 최근의 트렌드는 알고리즘보다 구현 문제에 중점을 두는 경향이 있습니다.

즉, 어려운 알고리즘 문제 보다는 "충분한 메모리와 제한 시간을 줄 테니, 이 문제를 해결할 수 있는가?"를 많이 묻습니다.

알고리즘 문제와 다를 게 뭐냐는 의문이 생기실 수도 있지만, 이런 유형의 문제는 사용하는 프로그래밍 언어에 대한 이해도와 평소 개발 습관이 묻어나오기 마련이기 때문입니다.

코드 리딩을 많이 해보신 분들은 아시겠지만, 사용한 자료구조와 코딩 스타일 등을 통해 평소 개발에 대한 태도와 습관을 어느정도 들여다보는 것이 가능합니다.

다만, 저처럼 평소에는 잘 푸는 문제들을 시험이라는 환경만 되면 못 푸시는 분들이라면, 이건 공부가 부족하기 보다 스트레스 관리를 못하고 계신 겁니다.

저는 다음과 같이 스트레스를 다뤘습니다.

채용 프로세스 뿐만 아니라, 백준에서 상시로 열리는 대회같은 것도 계속 참여하면서 테스트 환경 자체에 익숙해지도록 만들었습니다.
- 코테를 너무 많이 치다보니, 어느 순간부터 확실히 긴장감이 많이 낮아지는 게 느껴졌습니다.
일단 빠르게 통과하는 코드를 만들었습니다.
- 항상 아이디어를 기반으로 설계를 해놓고, 코드를 깔끔하게 작성하기 위해 시간을 쏟다가 시간을 넘긴 적이 많았습니다.
- 중요한 건 일단 최저점은 넘겨야 면접에서 그렇게 코드를 작성한 이유를 설명하든 뭘 해보기라도 할 기회라도 주어집니다. 그래서 코드 깔끔하게 작성하는 거 고민할 시간에 일단 작성하는 거에 집중한 이후로 코테 통과율이 높아졌었습니다.
- 생각보다 코테에서 코드 어떻게 작성했는지 관심없는 회사가 많습니다. (그래서 제가 지금 다니고 있는 회사 면접에서 코테에서 작성한 코드 리뷰해주실 때 상당히 놀랐었습니다.) 보통 코테 언급도 안 하는 경우가 많았습니다.
문제 풀다가 막히면 깔끔하게 포기하고 넘어가거나, 코드 다 지우고 다시 작성하는 게 빠릅니다.
- 코드를 고치는 것보다 새로 작성하는 게 훨씬 쉽습니다.
- 정말 무모해보이겠지만, 제 경우엔 막혔을 때 코드 다 지워버리고 다시 작성했을 때가 성공률이 더 높았습니다.

다만 AI나 게임 개발 쪽 준비하시는 분들 이야기를 들어보면, 확실히 수학을 잘 해야 하는 경우가 많아서 그런지 알고리즘 난이도가 상당하다는 것을 느낀 적이 있습니다.

파이팅..!

📌 사전 과제 & 라이브 코딩 테스트 or ...

저 또한 경험이 많지 않은 영역이라서, 어떠한 노하우나 트릭을 전혀 알지 못합니다.

사전 과제의 경우, 문제 출제 당일에 바로 AI 사용해서 제출해버리는 것을 흥미롭게 봤다는 글을 링크드인과 스레드에서 자주 본 적이 있긴 합니다.

예전에는 가볍게 넘겼었는데, 근래 들어서 AI 활용 능력의 중요도가 높아짐에 따라 마냥 뜬소문은 아닌 것 같다는 생각이 들기는 합니다.

단, AI로 제출한 코드를 모두 이해하고 설명 가능하실 수 있긴 해야하지 않을까 싶습니다.

라이브 코딩 테스트는 평소 습관이 가장 중요한 영역이기는 하나, 3월 쯤에 Youtube에서 📎내일 모레 라이브 코딩 테스트인데 어떻게 해야 하나요? 라는 영상을 참고 했던 적이 있었습니다.

이 때 기억해놓았던 게 이번 회사 면접에서 제법 도움이 되었다고 생각합니다.

📌 면접

전 면접까지 간 회사에서 떨어진 경험이 적습니다. (결코 자랑하려는 목적으로 하는 말이 아닙니다.)

때문에 실패를 통해 전략을 다듬어 볼 기회가 딱히 없었다 보니, 너무 신뢰하진 않으셨으면 합니다.

면접이 아니라 커피챗이라고 생각해보세요.
- 트라우마 때문인지 테스트라는 상황을 인지하고 나면 스트레스를 워낙 많이 받는 성격이라, 면접을 볼 때마다 너무 많이 떨어서 매번 '아직도 긴장하시네요'라는 말을 정말 많이 들었었습니다.
- 다만, 저는 항상 제 의견에 맞받아쳐줄 사람들을 찾아다녔던 터라, 제 아이디어나 코드에 부정적이거나 반대되는 입장의 멘트를 들었을 때 오히려 좋아했던 성격이라 어느정도 상쇄가 되었던 것 같습니다.
- (말은 쉽다는 것을 알지만) 면접에서 긴장을 많이 하는 편이라면, '면접에서 떨어지더라도 하나라도 배워가겠다'라고 임하는 게 어쩌면 도움이 되실 수도 있을 것 같습니다.
모르겠으면 역질문을 하세요.
- 정답이 있는 문제를 답하지 못한 건 조금 곤란할 수 있지만, 정답이 없는 문제들은 면접관 분들이 특정한 답을 원하고 던지는 경우가 아닐 때가 많습니다. 말 그대로 지원자의 생각이 궁금했을 수도 있구요. (e.g. 언제 테스트를 하시나요? 언제 로그를 남기시나요? 언제 scale-up을 고려하시나요? 등등)
- 저는 일단 제 생각을 던져보고, 역으로 회사(혹은 팀)에서는 어떤 식으로 하는 지 질문을 하곤 했습니다. 좋은 인상을 남기기 위한 목적은 아니었고 '날 떨어트리더라도 난 하나라도 주워 먹어야겠다'라는 마인드긴 했는데, 이게 오히려 분위기 완화하고 긴장 푸는데 도움이 된 적이 많았습니다. 🙄
면접은 회사가 나를 평가하는 자리기도 하지만, 내가 회사를 들여다 볼 수 있는 자리기도 합니다.
면접장을 나오자마자, 어떤 질문을 받았고, 어떤 답변을 했고, 그 답변에 면접관 분들의 반응과 꼬리 질문을 즉시 기록하세요. 복기하기 전까지 면접은 끝난 게 아닙니다.
돈 내고 면접 준비하는 것도 고려해볼만 한 것 같긴 합니다.
- 전 한 번도 면접 준비를 따로 해본 적은 없었으나, 제 가까운 지인에게 듣기로는 토스 같은 경우엔 토스 면접 최적화로 면접 대비 해주는 곳이 있다고 들었습니다. (비용이 제법 됐었던 것 같긴 한데 절박하면 뭐든 못할까요.)
전 면접 대비로 보통 CS 가물가물한 것들 되짚어보고, 제 포트폴리오와 지원서 다시 읽어보는 시간을 가졌습니다.
- 가치관이나 개인적인 성향 같은 질문에 대한 답변도 준비해본 적이 있으나, 항상 까먹어서 매번 프리스타일로 하게 되길래 어느샌가부터 그냥 준비 안 했습니다. 이런 건 그냥 평소에 명상 같은 거 하면서 많이 생각해보면 따로 준비 안 해도 될 거 같기는 합니다.
머릿속으로 '어차피 싸우면 내가 이긴다'라고 생각해보는 방법도 나쁘지 않습니다.
- 반쯤 웃자고 하는 이야기지만, 운동을 꾸준히 하신 분이라면 심리적으로 제법 안정을 줍니다.
- 그렇다고 진짜 싸우면 사회에서 매장 당하니까 그러진 마시구요.

📌 부가적인 요소들

부트 캠프는 필수인가?
- 소마에 대한 환상이 깨지고 난 이후부터 부캠의 필요성을 딱히 느끼지는 못하지만 (물론 안 한 게 아니라 못한 겁니다.), 학창 시절에 이것저것 해보는 것 상당히 도움이 많이 된다고 생각합니다. 사실 부캠 자체보다는 거기서 쌓는 인맥과 정보가 어마어마한 거죠.
- 졸업 이후의 부캠은 의견을 내기 조심스럽습니다. 잘 알려진 부캠 이외에는 자칫 "학창 시절 공부 게을리 해서 간 거 아니냐"라는 인상을 주는 경우가 있다고 들어서..... :(
- 제 경우엔 졸업 유예도, 부트 캠프도 신청하지 않고 배수진을 쳤습니다. 제 성격을 고려했을 때, 프로젝트 시작하면 또 취준이 아니라 플젝에 최선을 다하고 있을 것 같아서 저를 사지로 내몰았습니다. 덕분에 멘탈은 엄청나게 갈려나가긴 하지만, 이미 준비를 많이 했었고, 4학년 때 졸작에 시간 빼앗겨서 취준 소홀히 했던 것을 번복하지 않으려고 그랬습니다.
Kafka, K8S, DDD, MSA 같은 개념들을 알아야 할까요?
- 말씀드리기 매우 조심스러운 부분이긴 하지만, 개인적인 의견으로는 신입 자격 요건에 저런 요구 사항을 적어놓는 것이 아직도 이해가 안 갑니다. 그래서 저는 그냥 중고 신입 뽑겠다는 의미로 받아들였습니다.
- 제가 생각하는 '공학도'란 문제를 최소 비용으로 최대 효과를 내도록 해결하는 사람이지, 상황에 맞지도 않는 과한 도구를 끌어와서 기술의 극한을 연마하는 사람이 아니라는 생각이 확고했기 때문입니다. 애초에 저런 도구와 개념들이 나온 이유는 그만한 규모의 서비스를 운영하는 회사들이 필요에 의해 만든 것들인데, 트래픽이 매우 저조한 제 서비스에 도입해본 경험이 있길 바란다는 게 너무 무책임하다는 생각도 들었구요.
- 심지어 '이걸 정말 안다고?'라는 생각으로 공격적인 질문들을 하는 사례를 너무 많이 봐서, 저는 공부를 해봤음에도 기술 스택에서 모두 제외했습니다.
도메인을 모르는 것이 문제가 될까요?
- 경력이면 모를까, 신입에겐 도메인을 모르는 것이 엄청 큰 장애가 되진 않습니다. (개발자 한정)
- 다만, 그만큼 도메인을 이해하기 위한 기초, 기반이 되는 지식들이 탄탄해야 할 것이고, 새로운 것들을 많이 배워야 할 텐데 이를 어떻게 체계적이고 전략적으로 학습해나갈지 보여주는 것이 중요합니다. 실증적인 자료가 있으면 가장 좋겠죠. 가령 블로그같은?
- 회사 분위기와 개발팀 문화 정도는 알아두면 좋습니다. 같은 개발팀이라도 도메인이나 수행중인 프로젝트에 따라 주요하게 보는 것들이 다르니까요. 예를 들어, 인프라나 운영 쪽 팀들은 가용성과 안정성에 가장 높은 우선 순위를 두고 있을 것이고, 클라이언트 쪽 개발팀들은 빠른 장애 대응과 변화무쌍한 요구 사항에 대응하기 쉬운 유연한 코드를 선호하는 것처럼 말입니다.
- 적어도 자신이 만들었던 서비스의 도메인에 대한 이해를 하고 있고, 그 중요성을 알고 있다는 걸 보여줄 수만 있다면, 지원하는 회사의 도메인을 모르는 것이 큰 걸림돌이 되진 않습니다. (그것이 걸림돌이 되어서도 안 되구요. 만약 그걸로 불이익을 받으면 그 회사가 이상한 겁니다.)
관심없는 회사에 면접을 보는 게 맞을까요?
- 많은 취준생분들이 이직을 평가받는 자리라고 느끼지만, 면접은 서로가 서로에 대해 알아가는 자리입니다. 지원자 또한 면접 프로세스를 통해서 회사의 분위기를 엿볼 수 있는 기회라는 뜻입니다.
- 그런데 그 회사가 괜찮은지 아닌지 어떻게 알 수 있을까요? 미리 조사라도 한 게 아니라면, 이는 여러 번의 면접을 통해 안목을 길러야 가능합니다. 즉, 최악의 면접 프로세스도 경험을 해봐야, 지금 보는 회사가 어느 정도인지 가늠할 수가 있는 겁니다.
- 붙었다고 해서 갈 필요도 없고, 연봉 협상까지 해보거나, 다니다가 한 두달 정도 해보고 퇴사하는 것도 방법입니다.
자꾸 취업이 안 되니 우울해져요
- 스스로 아무리 "실패는 성공의 어머니다.", "난 할 수 있다"라는 말을 되뇌어도, 실패의 기간이 길어지면 길어질 수록 우울해지는 것은 당연한 겁니다. 이는 본인이 나약해서가 아니라는 사실을 먼저 받아들이세요.
- 하루만 우울하세요. 넘어지지 않는 것보다, 몇 번을 넘어져도 다시 일어나는 연습을 하셨으면 합니다. 우울함의 깊이가 깊고 길어질 수록 이후의 본인이 감당해야 하는 짐만 더 커지지만, 하루 정도는 실컷 우울함에 빠져있다가 다음 날엔 다시 달립시다.
AI를 사용하지 않는 것이 좋을까요?
- 최근 AI의 활용 능력은 매우 중요한 요소 중 하나입니다. 다만 무엇이든 극단적인 사고에 치우치면 망할 뿐입니다.
- 개인적으로 AI에 과하게 의존적인 개발자나, AI를 완전히 배척하는 개발자 모두 빠른 시일 내에 도태될 것이라 여깁니다.
- AI를 어떻게 더 잘 다룰 수 있을지 이것저것 실험하는 것은 필요합니다. 다만 그것과 별개로 개인을 위한 학습은 꾸준히 해야 합니다. 예나 지금이나, 도구에 휘둘리는 개발자는 쓸모가 없다는 점은 동일합니다.
- 중요한 점은 그 역량을 지원하는 회사에서 달갑게 여길지는 조사가 필요합니다. AI 사용을 적극적으로 푸시하는 회사가 있는 반면, 여전히 다양한 이유로 과거 방식에 갇혀있는 회사도 많습니다. 후자의 경우 AI 활용 역량을 높게 평가해주지 않을 겁니다.

📌 주절주절

저는 타인에게 조언을 하는 것을 굉장히 꺼리는 편이라, 이번 포스팅을 할지말지 엄청나게 많은 고민을 했었습니다.

설령 제가 제 스스로를 보잘 것 없이 여기더라도, 누군가는 저를 동경의 대상이자, 길이자, 목표로 삼는 것을 봐왔습니다.

그런 사람들은 말에 책임을 져야 합니다.

말이 아니라, 행동과 결과로 보여주는 것이 가장 이상적이겠지만요.

저는 아직 여러분들의 인생에 책임을 질 수 있는 사람은 아닙니다.

코딩을 시작한 이후로 한 번이라도 가르쳐본 사람이 세 자리 수에 달하지만, 주기적으로 계속 컨설팅을 해드리는 분은 2명 뿐입니다.

지금으로써는 고작 2명에게 조언을 하는 책임을 감당하는 것조차도 제게는 너무 큰 부담입니다.

그러나, 단 한 명이라도 도울 수 있는 위치에 있음에도 불구하고 부담스럽다는 이유로 방관하기를 선택하는 것이 옳은가에 대한 회의감이 들었습니다.

그래서 제가 겪었던 시행착오의 경험을 공유하는 것만으로도, 누군가가 자신만의 전략을 세우는 데 통찰을 줄 수 있을 것이라는 기대감에 글을 작성했습니다.

지금은 고작 이 정도가 제가 감당할 수 있는 책임의 무게고, 그렇기에 위 내용들은 한 개인의 의견일 뿐이라는 책임 회피성 언급을 할 수밖에 없음에 양해 부탁드립니다.

여러분들께 빛나는 하루가 찾아오길 언제나 진심으로 기원합니다.

저작자표시 비영리 (새창열림)

티스토리툴바