취업특강 전략

yoneeki·2022년 12월 8일

interview

현대에서 근무하고 계시는 시니어 FE 개발자께서 맡아주신 강의를 코엑스 컨퍼런스 룸에서 듣고 왔다.

개요

취직은 빨리 할수록 좋다
(처음 직장의 레벨이 중요하다는 말과, 어디든 기준을 조금 낮춰서 일을 시작해야 한다라는 두 가지의 문장은 모두 참이다. 자신의 상황에 맞게 고려해보도록 하자.)
면접은 보면 볼수록 는다. 거의 비슷한 형태로 이루어지기 때문이다.
노션이나 링크드인 관리도 좋지만 자기소개서는 word 파일로도 하나 갖고 있자. 프로그래머스에서도 작성 가능하다. 그리고 계속 update하자!

자소서 및 이력서 작성

자소서를 지원한 형식 및 회사 별로 분류해서 관리하자(중요)
자소서 첫 장에는 이력, 역량, 자격증, 교육현황, 수상경력, 개발가능언어 등 자신이 어떤 사람인지 한 눈에 잘 보이도록 요약해서 정리하자 -> 첫 장의 임팩트가 면접의 분위기를 결정한다.
프로젝트를 했다면 내가 어떤 역할을 했는지 적고 그것은 기술 키워드 위주로 작성하자 -> 저는 중요한 역할을 했으며...(x) 마이바티스를 사용하고.. JPA를 사용하고...(o)
아직 큰 프로젝트가 없는 신입이라면 토이 프로젝트, 졸업작품, 부트캠프 포폴 등을 위주로 작성하자
내가 어떤 사람인지에 대해서는 포부 및 지원동기에 작성하자.
사실 지원서의 형태는 거의 동일하지만 "지원동기 및 목표, 경력사항 포인트"는 회사에 특성에 맞춰 적절하게 수정할 필요가 있다
회사 바이 회사겠지만, 중구난방의 Full-Stack 이력보다는 FE나 BE, 뭐 하나를 제대로 해 온 사람 혹은 잘 하는 사람을 선호하는 경향이 있을 수 있다 -> 그러므로 지원 포지션에 맞추어 자신의 해당 역량이 잘 드러날 수 있도록 자소서 작성할 것
이 필드에는 진짜 주도적인 사람들이 많다..! 그러므로 자신이 주도적으로 무언가를 해야만 얻을 수 있는 게 많을 것이다. -> 개발에 대해 잘 모르겠으면 개발자들한테 커피챗하자고 요청이라도 해본 적이 있는지?!
기술블로그에는 평소 공부하는 것들을 꾸준히 적자. 어차피 회사가서도 컴플라이언스 같은 것을 사용하게 되므로 남과 지식을 공유할 수 있는 문서 작성 능력은 중요하다.
결국 자소서는 내가 어떤 사람인지를 보여주는 것이다.

코딩테스트

코테는 이직할 때쯤 되어서 준비하는 것이 아니다. 그냥 일하면서도 매일매일 2-3문제씩 꾸준히 풀어야 하는 것이다.
Queue나 Stack 같은 경우에는 실무에서 자주 쓸 일이 없는데 코딩 및 알고리즘 테스트에서는 빈번히 출제된다.
BFS / DFS (깊이 및 넓이 탐색)는 출제가 너무나 자주 돼서 거의 외워야 하는 수준이다.
다이나믹 프로그래밍(DP)는 어렵다. ex) 라이브 코테에서 피보나치 수열 문제가 나와서 '재귀함수로 바로 끝내도 되나요' 라고 했더니 'dp로 안 하시면 다시 시킬 겁니다' 라는 면접관의 대답이.. ;-)
라이브 코딩 테스트에 대한 대비는 프로그래머스에서 할 수 있다
코테에 대한 경험이 하나도 없다면 프로그래머스에서 레벨 0,1 문제들을 풀어보자
해외 취업 준비를 하고 있다면 leetcode를 사용하면 된다. 그런데 국내 취업의 경우에도 대기업은 종종 영어로 출제되는 상황이 있다. leetcode도 참고하자.
2시간 동안 3문제를 푸는 형태가 많은데 그 중 한 문제는 무조건 어렵다. 그러니 하나에 꽂히지 말고 일단 나머지 두 문제를 잘 풀고 어려운 한 문제는 어떻게든 풀어보려는 노력을 남겨서 제출해보자.
라이브 코딩은 의사소통 능력까지 같이 보는 것이다.
긴장해서 생각이 안 나는데 힌트 좀 주실 수 있을까요..;)
이제 막 IT 관련 부서를 신설 중인 기업들이라면 "기술 PT"를 보는 경우가 많다. ex) 00자동차의 글로벌 전략에 대해 ex) 000쇼핑에서 구매자가 아닌 판매자를 위한 백오피스를 구축하고자 하는데 전략 서술 -> 인프라 관점에서 서술하면 좋을듯
과제 테스트는 받고 5분 만에 당락을 결정할 수 있다.
(1) README.md 없으면 탈락
: 어떤 환경세팅인지, 어떤 라이브러리를 사용했는지, 프로젝트를 실행하는 방법, 요구사항 등... 최대한 자세하게 서술한다. 일할 때도 이러한 자세는 필수다.
(2) TDD(테스트 주도 개발 : Test-Driven Test) 테스트 케이스 꼼꼼하게! : 기본 중의 기본이다. 그리고 이런 간단한 과제에서도 tdd를 안 하면 일하러 들어오면 어떻겠느냐 싶다.
(3) 코드를 한 번에 반영하지 않고 Git을 이용해서 개발 단위별로 반영했는지
다시 말해 과제 테스트는 그 사람이 평소에 어떤 사람인지가 보이는 테스트다. 서류 정리 능력이 어떤지, 정리가 잘 되는지, 깃으로 프로젝트를 관리하는지.

면접

1분 자기소개, 마지막으로 하고 싶은 질문
이직 생각이 없어도 가끔은 대기업에 서류 넣고 면접을 보며 경험을 쌓는 것도 좋을지도.
모르는 문제가 나와도 당황해서 분위기 안 좋게 만들지 말고 둥글둥글하게 그 상황에 대처하자. ex) 머리 긁거나, 허공 오래 응시하거나, 면접관 시선 피하거나 하는 행동들 다 금지
말투, 표정, 복장 등등은 당연히 다 기본적인 것이니 체크하자.
말 너무 빠르지 않게 또박또박하게.
이력서 관련 연관 질문에는 다 대처할 수 있도록 준비. 꼬리질문까지도! 이런 문제에 답을 못하면 면접관도 별 수 없이 CS 질문으로 넘어가 버린다. 케바케지만 내 이력서에 대해서가 아니라 CS 질문이 더 많이 들어오는 면접은 좋은 신호가 아닐 수 있다.
CS 질문만 들어온다는 것은 당신이 누구인지에 대해서는 궁금하지 않다는 것일 수 있다. 자소서를 잘 써서 나를 궁금하게 만들자. 그리고 자소서의 내용에 대해서는 다 대답할 수 있게 대비하자.
한 명 한 명 면접관과 눈 마주치며 미소지으며 대답하기(생각보다 1-4시간의 장시간 면접에서 이런 애티튜드를 끝까지 유지하기는 어려우니 신경쓰자)
바른 자세로, 요점에 대해서만 대답해라. 물어본 것에 대해서만 대답해라. 모르면 모른다고 (요령있게) 대답하라. 10%만 안다면 10%만 간략하게 이야기하고 나머지는 모른다고 해라. 중언부언하면 면접관 입장에서 그 말을 끊기도 애매하고 같이 일하고 싶지 않다는 생각이 든다.
같은 맥락에서 두괄식으로 이야기해라. ex) 전의 회사에서 트래픽이 많았는데... 이랬는데... -> 무슨 말이지 싶음
CS 질문이 안 나오지는 않는다. 개발상식 / 네트워크 / 디자인패턴 / 자료구조 등등 직무 CS 기본에 대해서는 구글링해서 찾아보고 공부하자. ex) 스레드와 프로세스의 차이
tech interview for beginner 를 검색해볼 것!
왜 그 언어를, 그 프레임워크를, 그 기술을 선택 및 사용했는지에 대해 항상 고민하고 대답할 수 있어야 한다. 왜 리액트를 사용하냐는 질문에 그래야 취직이 잘 된다고 들어서라고 대답할 수는 없다. ex) vue에 비해 react는 이런 이런 점에서 차이가 있고 해당 문제를 해결하는데 이런 이런 장점이 있을 것이라 생각해서....
일을 할 때도 그러므로 늘 생각해야 한다. 내가 왜 이 언어와 프레임워크를 쓰는지에 대해서 말이다. 그러므로 앞으로 사용할 생각이 없는 언어라도 리서치를 해야한다. 그를 통해서 내가 쓰는 언어에 대한 사용 이유를 찾을 수 있다.
1분 자기소개와 마지막으로 하고 싶은 말도 중요하다.
ex) 제가 입사하게 된다면 수행해야 할 프로젝트나 포지션은 어떻게 되나요 / 개발 관련된 귀사의 문화는 어떠한가요(사내 메신저는 슬랙을 사용하나요? 인텔리제이 라이센스를 제공하나요? 깃플로우를 사용하나요?) / 지금까지 제가 면접에 있어서 아쉬운 부분이 있었나요?

임원면접

태도 > 기술
"입사 하고 싶은 이유와 입사 포부"를 열정적으로 어필하는 자리(자식.. 하면서 귀엽게 봐주신다면 성공). 얼마나 여기에 들어가고 싶은지 표현.
면접자보다 면접관인 임원이 이야기의 점유도(?)가 더 높은 경우가 많다. 경청하는 자세를 보여주자.

입사 이후

본인의 위치에서 최선을 다 하자.
일을 할 때 사람 관계 및 태도가 중요하다(나중에 레퍼런스 체크 -> 쟤 어때?)
입사 이후에도 이직이 많은 직종이기에 꾸준히 경력관리 및 자기계발에 집중하자.
평생 직장을 찾는 것이 아니다. 그러므로 어디서든 필요로 하고 원하는 사람이 되자.
자신의 한계를 규정짓지 마라. 늘 배워라.

그 외

얕게 아는 언어는 시니어의 경우에는 이력서에 적지 않는다(실무에서 실제로 다룬 것만 적는다).
전 회사에서 마이바티스밖에 안 써봐서 마이바티스밖에 모른다는 식의 말은 그 사람이 개발자로서 무능함을 뜻한다. 혼자서 파일럿 프로젝트를 만들어서 사람들에게 배포해 방향성을 제안할 수도 있고 작은 회사일수록 자신의 의견이 더 크게 반영되기도 한다. 그리고 신기술이 나오면 사람들에게 회의를 요청해 간단하게 소개하는 시간을 가질 수도 있다. 자기하기 나름이다.