안녕 어제 불난 곳에 피자들고 온 사람이야. 취준 하면서 공부한것들, 느꼈던 것들을 간단하게 공유해보려고함


일단 전공자고 긴 텀(3학년 초부터 본격적으로 준비했으니 거의 1~2년)을 갖고 준비해서, 급하게 취업하는 사람한텐 안맞을거임.


한창 우매봉의 정점에 있는 시기라 틀린 내용 있을 수도 있다. 걍 이런 사람도 있구나 하고 참고만 해줘


---------------------------


1. 코테


커트라인 넘기전까진 우선순위가 제일 높다. 나 같은 경우 초반(브실)엔 하루에 2~3문제씩, 골드 입성 이후엔 매일 한 문제씩 풀면서 늘렸음. 골랜디가 가능한 실력이면 웬만한 코테는 다 뚫을 수 있을거야. 랜덤 디펜스할 땐 구글에 '토탐정'이라고 쳐서 나오는 확장 깔아서 하는걸 추천함. 나는 평소엔 백준 풀고 코테 앞두고 프로그래머스로 기출푸는 느낌으로 준비했음.


취업은 충분한 실력을 갖고있어도 자신감이랑 제한 시간이라는 추가 변수가 존재함. 이는 코테도 마찬가지고. 자신감 부분은 골랜디 능숙하게 될정도면 꽤 붙어있을거라 생각하는데, 문제는 제한 시간임. 평소에도 시간 재서 푸는게 제일 좋긴한데, 적어도 코테 직전엔 제한시간 둬서 문제 풀기 연습해보자


가능하면 쉬운 대회나 콘테스트에 참석해보는 것도 좋다. 대학생기준 교내 알고리즘 대회가 있다면 꼭 참석해보자. 제한 시간이라는 압박이 생각보다 강해서 충분히 풀 문제도 못푸는 경험을 한번씩 미리 해보는게 좋음. 대회에 참가할 여력이 안되면 2~3학년 때부터 기업 코테 찍먹이라도 해보자. 운좋게 뚫으면 면접 경험치도 쌓는거고 (난 3학년 인턴도 실제로 봤음)


2. CS


난 뼈대 만들기(초벌) - 살 붙이기 형태로 했음.


난 일단 전공자라 강의로 초벌이 되어있었음. 비전공자라면 K-MOOC이나 영어가 된다면 유데미 같은데서 뼈대를 세워보자. 뼈대라는건 전반적인 흐름을 파악하는 정도라고 보면됨. 예를 들어 스레드라는 키워드를 주면, 스레드가 정말 대충 뭔지 알고 어떤 키워드로 찾아보면 될지 아는정도?


살 붙이는건 하나로 특정된 형식이 아님. 관련한 유투브, 강의, 컨퍼런스 영상도 찾아보고, 책도 읽어보고 하면서 살을 붙여야함. 책같은 경우 OSTEP이나 네트워크 하향식, Real Mysql 을 많이 읽었음. CS라는게 서로 얽혀있고 단숨에 공부할 수 있는 주제가 아님. 네트워크를 공부하다가도 OS쪽의 개념에 번뜩이는 인사이트가 생기기도 하고 그래. 느리더라도 꾸준히 공부하는게 제일 중요하다.


CS는 그리고 단순히 이론적인 지식으로 끝나는게 아니라 프로젝트에 어떻게 녹여낼 수 있을지도 고민해야함. 프로젝트에 이슈가 있다면 어떻게 해결할지 고민하는 과정에서 CS가 들어갈 수 있는거임. 당장 이슈가 없더라도, 프로젝트에 발생할 수 있는 문제점을 예측하려면 CS가 필요한거고


흔히 기업에서 요구하는 문제 해결 경험도 이런걸 의미한다고 생각함.


2-1. 자바, 스프링 공부


아마 백엔드 갤러리라 자바스프링하는 친구들이 제일 많을 거임. 적어도 자기가 사용한 언어와 프레임워크는 깊게 공부하자. 이때 가장 추천하는 방법은 디버깅해보고 코드를 직접 까보는 것. 나도 처음엔 이 큰 코드를 어떻게 까보지?했는데 지금은 그냥 뭐 안되면 바로바로 까보고 있다.


자바로 치면 List.of()가 unmodifiable 객체를 반환하는데 내부적으로 어떻게 구현되어있지? 스프링 DispatcherServlet은 진짜 설명대로 흘러갈까?를 디버깅 해보면서 탐구해보는게 그 예시임. 나같은 경운 처음에 디버깅 해본게 "스프링 mvc에서 ArgumentResolver는 누가 호출해주는지" 궁금해서 시작했었음. 처음엔 저거 찾는데만 3일내내 디버깅했다.


스프링은 장황하지만 현대 객체지향의 정수고 코드 까보면서 배울 점도 정말 많다고 생각함. 그리고 읽다보면 과거에 이걸 개발하면서 얼마나 많은 고민이 들어갔을지 느껴진다. 책으로만 공부하던 디자인 패턴이나 객체지향 철학들도 나와서 아 이래서 쓰는구나 하고 느낄 수도 있고.


(ps. 참고로 객체지향은 항상 옳은 패러다임이 아니다. 객체지향의 정수인 스프링을 파면서 객체지향의 단점이 느껴지기도 했음.)


3. 프로젝트


위에서 말한대로 CS를 어떻게 녹여내고 나의 고민이 어디까지 깊게 갔는지가 중요하다. 구현한 기능, 사용한 기술 스택은 큰 의미 없음.


기술 스택을 추가한다면 명확한 의도를 가져야한다. 프로젝트를 구현하다보니 무슨 이슈가 있었고, 이 이슈를 탐구하다보니 이 기술스택이 필요했다. 다른 대안으로는 뭐가 있었는데 장단점을 따져보고.. 쭉 이어져야함. 딱 드러나잖아 그냥 이슈 하나를 해결하는데도 이렇게 고민을 많이하는 친구구나 하고. 고민을 많이 한다는건 결국 성장할 가능성이 크다는 거고


Cs에서 언급했듯이 당장 발생한 이슈만 해결하는게 아니라, 발생할 수 있는 문제점을 예측해보는 것도 좋은 경험인 것 같음. 다만, 여기에 너무 몰두하진 말자 완벽한 소프트웨어는 없으니까 어디든 적당한 선이 중요함


프로젝트에선 여러 방안을 고민해보고, 각 방안의 장단점도 따져보고 추가로 발생할 문제도 예측해보자. 이때 트레이드 오프(타협)도 굉장히 중요하다. 발생할 확률이 적고, 영향이 없는 버그인데 고치기 까다롭다면 그냥 두기도함. (추후에 admin이나 수동으로 고치는 방식). 아무튼 이런 방안들에 대해 고민해보고 잘 따져보는게 좋다.


4. 커뮤니케이션, 마인드셋


개발자에게 코드는 수단일 뿐이고 결국은 사람과 소통하는 직업이다. 크게는 기획에서 내려온 요구사항을 주고 받아야하고, 그걸 어떻게 구현할지 팀원들과 상의도 할 수 있어야함. 면접관도 사람인지라 커뮤니케이션 좋은 사람을 뽑을 수 밖에 없다. 이게 뭐 인싸들 마냥 말하는게 재밌는 사람이 아니라, 진짜 기술적으로 토론을 하고싶은 사람을 의미함. (자기 말투가 톡식하거나 의미 전달이 부족하다면 꼭 고치자)


그리고 자기 프로젝트에 대해 남에게 많이 설명해보는게 좋음. (사실 그런 기회 얻기가 쉽진 않음) 발표 자리가 있다면 남에게 미루지 말고 꼭 발표 서보는걸 추천함


다이어그램과 같은 툴 활용도 좋다고 생각함. 다이어그램은 뭐 완벽하게 그릴 필욘 없고, 당장 생각하는 바를 간단하게 표현할 수 있을 정도? 대기업 면접가면 화이트보드 많이 쓰더라. 말로 주구장창 설명하는 것보단 그림으로 대충 표현하는게 더 깔끔함


마인드셋은 이 사람이 성장할 가능성이 큰 지 판단하는 거임. 회사에서 신입에게 요구하는 능력은 보통 그렇게 높지 않음. 특히 대기업에선 현재의 능력보단 성장 가능성을 더 크게보는 것 같음. 내가 가진 장점 중 어느 것이 가능성에 도움을 줄지 생각해보자. 예로 들면 '호기심'은 곧장 성장력에 연결되겠지?


자소서나 면접 볼 때는 본인의 메인 어필점을 1~2개 정도 정해놓는걸 추천함. 위에서 말한대로 '성장'이라는 키워드도 좋지만 '성장을 꿈꾸는', '성장해서 세상을 선하게 바꾸는' 같은 키워드는 너무 흔하지? 살짝씩 비트는걸 추천함. 나같은 경우 코드 레벨/기본기에 진짜 미친듯이 파고들었고, 다져진 토대위에 쌓기만 하면 된다 느낌으로 어필했음.


-------------------------


글 초에 언급하였듯이 단기간에 될게 아니라 장기간 계획 세우는 사람들을 위한 글이야.


사람마다 스타일이 다르긴 한데 나같은 경우 '매일' 공부하진 않았어. 1주에 하루 이틀쯤은 유독 공부하기 싫은 날 있잖아. 이런 날은 억지로 공부해봤자 잘 되지도 않고 부정적인 에너지만 쌓여서 다음날 까지 망치더라고. 롱런 해야하는 과정인 만큼 중간중간 적절히 쉬는 것도 중요하다 생각함.


그리고 취업은 운칠기삼이라는 말이 있지. 나도 운이 좋아서 취업된거라 생각함(기만아님..) 떨어져도 운이 안좋았다 하고 너무 상심하지 말자. 네가 면접관인데 앞에 있는 사람이 자기 실력에 자신이 없으면 뽑기 싫겠지? 자신감 잃지 말자는 소리임. 실력은 행운이 왔을 때 잡는게 실력이야.


이런 글은 처음써봐서 엉성한데 그 외 질문은 댓글로 주면 가능한 답변해줄게