취업하고 공부할까, 하다가 이력서에 대한 글을 적었으니 면접까지는 적는게 좋다고 생각했습니다.

---

저는 학교 연계 취업을 했기에 사실상 면접이란 것을 봤던 적이 없었습니다.

그래서 제가 기술면접, 인성(컬쳐핏)면접을 보면서 실수 했던 부분들
미리 알았더라면 좋았던 것들, 절대로 하면 안됐던 것들에 대해서 적어보면
누군가에게는 도움이 될 것이라 생각하여 작성합니다.

이력서와 마찬가지로 면접에는 정답이라는 것이 존재하지 않습니다.
이 부분은 유념하시고 읽으시길 바랍니다.

해당 포스트를 읽으시기 전에, 과거에 작성된 주니어 개발자 이력서 쓰는 법을 읽어보고 오시는 것을 추천드립니다.

---

서론

면접에서 제일 스트레스 받을 때가 언제냐? 라고 물어보면 나는 단호하게 이야기할 수 있다.

• 긴장을 많이 해서, 준비한 만큼 대답을 하지 못했을 때
• 공부를 하려고 했던 것인데 질문이 나와서 대답을 하지 못했을 때
• 할 수 있는 대답이 모르겠습니다. 라는 말만 반복할 때
• 나 자신에게 실망했을 때.

---

취업준비는 장애물 장거리 달리기와 같은 것이라, 먼저 넘어져서 쓰러지는 사람은 패배한다.
하지만 넘어졌어도 다시 일어나서 달릴 수 있는 사람에게는 기회가 찾아오게 된다.

많이 넘어져봐라, 그리고 왜 넘어졌는지에 대해서 고민하자.
그렇다면 어느 순간부터 높아보였던 그 장애물이 낮아보일테니까.

그러니 면접은 최대한 많이 보는 것이 좋다.

---

자신을 감추지마라.

자신감이 넘쳐보인다, 너무 솔직해서 호불호가 있을 것 같다.

내가 봤던 첫 면접에서 받았던 피드백이다.

사람은 개개인의 성격이 가치관이 존재하고 다양한 사람들이 모이면 문화 라는 것이 자연스럽게 만들어진다.
그리고 면접에서는 그런 문화(핏)을 확인하는데 자신을 속여서 회사에 입사한다면 문화의 차이때문에 적응을 하지 못하는 경우가 발생한다.

그래서 나는 면접에 임할때 나를 속이지 않기로 했다.
내가 가지고 있는 날 것 그대로를 보여주기로 결정했다.

왜냐하면 회사가 나를 선택할 수 있는 것처럼, 나도 회사를 선택할 수 있어야 한다고 생각했다.
나를 감춘 채로 하루의 절반 가까운 시간을 살아가는 것은 정신적으로 피곤해질테니까.

면접으로 회사가 나를 평가할 수도 있겠지만, 나도 면접관을 통해서 회사를 평가한다고 생각해야한다.

그렇기에 어느정도 기준을 잡아놓는 것을 추천한다.

---

회사의 정보를 알아보자.

최근에는 지원자들이 지원동기를 쓰는 것이 아니라 보이는대로 서류를 집어넣는 형태가 빈번하다.

그렇기에 서류가 붙었을 경우 회사의 정보가 미흡할 수 밖에 없는데, 못해도 한 두시간 정도는 알아보는 것이 좋다.

이유는 정말 단순한데, 그냥 예의다 예의.
내가 따발총 갈겨서 서류가 붙었는데, 그럼 적어도 면접을 보러 가기 전에 회사에 대한 것은 알아봐야 하지 않겠는가?

만약 회사에 대한 관심이 없고 그냥 면접 경험을 위해서 가는 것이라면 뭐라고 못하겠지만

취업을 하고 싶어서 매번 전력으로 면접을 보고 있는 상태라면, 정보를 알아가는 것이 정말 큰 도움이 된다.

나같은 경우에는 조금 과한 편이긴 했지만, 준비를 이렇게 했다.

• 회사의 주력 서비스가 무엇인지 확인한다.
  • 당연히 알아봐야한다고 생각한다.
  • 내가 합격해서 개발을 해야할 수도 있는 서비스이기에, 정말 관심 외의 서비스라면 나는 면접을 취소했다.
• 회사의 투자 현황에 대해서 확인한다.
  • 회사이름 + 투자로 치면 현재 투자 상태라던가 뉴스 기사를 확인할 수 있다.
  • 이 부분이 왜 중요하냐면, 스타트업 같은 경우에 마땅한 캐시카우가 없을 가능성이 높다.
    지금 같이 경기가 안좋을 때는 회사가 공중분해 될 수 있다는 것이기에, 회사에 대해서 안정적인 자금 운용이 가능한지 알아보는 것이 좋다.
• 회사의 채용 페이지를 확인한다.
  • 요즘은 대부분 회사의 홈페이지에서 채용을 누르면 노션 페이지로 이동을 하는 경우가 많다.
  • 잘 읽어보면 회사에서 원하는 인재상이 있을텐데, 이러한 부분을 면접에서 강조하면 좋은 이미지를 얻을 수 있다.
• 면접 진행 이메일을 잘 읽어본다.
  • 여기에는 어떤 정보가 있냐면, 면접관에 대한 정보가 존재한다.
    채용 페이지 + 메일을 바탕으로 면접관을 추측하고, 맞는 것 같다면 링크드인을 찾아서 그 면접관이 중요시 여기는 부분이 무엇인지 알아볼 수 있다.
  • 링크드인 계정을 찾아서 커피챗을 요청한다는 취준생도 있던데, 저 부분에 대해서는 조금 문제가 생길 것 같아서 나는 하진 않았다.
• 회사에서 서비스하는 것을 사용해본다.
  • 여러가지가 있을텐데 웹서비스를 하면 웹, 앱서비스를 하면 앱을 다운받아서 사용해봤다.
    B2B같이 개인이 사용할 수 없는 서비스는 방법이 없다(...)
  • 서비스를 직접 사용해보면서 문제점이라던가 개선점을 이야기하는 취준생도 있다고 들었는데, 정말 가고 싶은 회사라면 해볼만 한 것 같다.
    정말 가고 싶었던 회사들이 대부분 B2B라서 해보지 못한 것도 있었지만, 리소스가 좀 많이 든다고 생각이 들어서 이 부분은 해보지 않았다.

그리고 맨 아래에서 이야기를 하겠지만, 질문을 하고 싶었던 것에 대해서는 노트에 적어서 가져갔다.

---

면접 당일 준비

면접을 시작하기 전에 준비해야할 것들이 많다.

음성채팅을 해본 사람은 알겠지만 전반적으로 나는 긴장도 별로 안하고 말을 하는 것에 대한 두려움이 적은 편인데
그럼에도 불구하고 나는 면접 장소에 못해도 1시간 이상 일찍 도착해서 기다리는 편이였다.

이렇게 시간 여유를 많이 두고 이동하는 이유는 단순했다.(단순한가?)

• 미리 도착하는 것으로 주변의 지리에 익숙해지는 것으로 마음의 안정을 가진다.
  • 많은 사람들은 낯선 환경에 대하여 자기방어를 하기 때문에 몸과 마음의 긴장도가 높아진다.
    그렇기에 일찍 이동해서 그 주변을 돌아다니는 것으로 무의식 속 나의 긴장도를 끌어내렸다.
• 제출한 이력서 읽어보기.
  • 면접관이 나에게 질문할 수 있는 카테고리가 넓지 않다, 결국은 이력서 내에서만 나온다.
    그렇기에 이력서를 한번 더 읽어보면서 어떠한 질문이 나올 것인지 추측할 시간을 만든다.

그렇다면 이제, 조금 더 깊게 준비를 해보자.

---

기록으로 증명하라.

위에 적은 것처럼 대부분의 질문은 이력서에 있는 정보를 통해서 나온다.
CS같이 공통 질문을 제외하고는 말이다.

그렇다면 이력서에는 무슨 정보들이 있을까?

일반적으로는 아래 적히는 것들이 있다.

• 개발자가 되려고 한 이유
• 블로그
• 깃허브
• About Me
• 사용한 스택
• 프로젝트
• 자격증, 전직장, 대학교

여기서 주목을 해야하는 것은 기록 이 남아있는 것들이다.

왜냐하면, 바로 면접을 보는 내가 신입이니까.

많은 개발자분들이 이야기를 해주셨는데
신입에게 바라는 것은 바로 코드를 작성할 수 있는 실력이 아니라고.

그렇다면 신입에게 바라는 것이 무엇입니까? 라고 했을 때

(사진 출처 코드브릭 유투브)

대충 이런 것을 생각하고 고려해서 뽑는다고 알려주셨다.

하지만 이력서에서 저런 것을 알기 위해서는, 기록을 봐야 알 수 있다.

그렇다면 기록으로 하여금 나오는 질문이 무엇이 있을까?

• 레포지토리에 이런 코드가 있던데, 무슨 이유로 이렇게 적었는지 알 수 있을까요?
• 코드 컨벤션은 어떠한 기준을 잡고 정했는지 알 수 있을까요?
• 블로그에 이런 글이 적혀있던데, 설명해주실 수 있을까요?
• 이러한 작업사항이 있던데, 왜 이런 선택을 하셨나요?

즉, 결과를 보고 그렇게 선택한 이유를 물어보는 질문이 상당히 많이 나오게 된다.

이 사람이 어떻게 고민을 하는 사람이고, 근거를 가지고 의사결정을 하는 사람인지 확인하기 위해서 말이다.

그렇기 때문에 모든 행동에 대한 의미를 생각하고 있어야한다, 의미가 생각나지 않는다면 가려놓는 것이 좋다.

레포지토리는 프라이빗으로 바꿔놓고, 블로그 포스팅은 비공개로 바꿔라.
이력서같은 경우에도, 내가 대답을 제대로 못할 것 같은 항목이 있다면 지워라.

개발자라는 직업 특성상 판단의 근거 가 중요하기 때문에 대답할 수 없다면 상당히 마이너스 요인이 된다.
반대로 중요하기 때문에 명확하게 대답할 수 있는 사람이라면 플러스 요인이 될 것이다.

---

면접

드디어 본론(!)이다.

자기소개 -> 기술면접 -> 인성면접 -> 마지막으로 궁금한 것 이라는 순서로 목차를 잡아놨지만
모든 면접의 순서가 아니라, 그냥 말 그대로 카테고리별로 나눠놓은 것이라 큰 의미는 없다.

인사 담당자한테 연락하기

나같은 경우에는 비대면 면접보다 대면 면접을 선호하는 편이다.
같이 일을 할지도 모르는 사람인데 얼굴은 직접 봐야지(....)

보통 사무실 위치를 알려주고 약속 시간까지 오라는 연락을 준다.

나같은 경우에는 약속 시간 10분 전에 도착해서 인사 담당자한테 연락하는 편이다.

이 시간에 대해서도 많은 고민을 했는데, 10분정도가 제일 적당하다고 생각했다.

저 시간보다 일찍 갈 경우에는 회사의 입장으로 면접 스케줄이 연달아 있거나 대응할 수 없는 사람이 있을 가능성이 높기에 추천하지 않는다.
일찍 도착하면 계단에서 운동이라도 하던 구석에 짱박혀서 기다렸다가 메세지를 보내면 된다.
(나같은 경우에는 시간이 카페에 가기도 애매해서 건물 계단에 짱박혀있던 적도 있었다 ㅠㅠ)

그럼 보통 면접장소(미팅룸)으로 안내를 해주고 마시고 싶은게 있냐고 질문을 하시면서 기다리라고 하는데
이 시간에는 다른 생각 안하고 마음만 다스리는 것을 추천한다.
수능을 볼 때 시험장을 미리 가서 환경에 적응하는 것과 동일하다.

면접 시간이 돼서, 면접관들이 들어온다면 일어서서 인사해라.

굳이 면접관이라서 인사를 하는게 아니라, 우리는 유교의 K국가니까 그냥 일어서서 하자.
예의를 지켜서 나쁠 것은 전혀 없다.

---

자기소개

대부분의 면접은 자기소개로 시작한다.

그리고 이 자기소개는 면접의 방향성에 있어서 거대한 역할을 하기에 미리 준비하는 것이 좋다.

굳이 자기소개를 시키는 이유에는 몇가지가 있다.

• 자기소개를 하는 동안 면접관들이 이력서를 훑어본다.
• 자기소개를 듣고 질문의 방향성을 잡는다.

방향성이 정말 중요한 키워드다.

그렇기에 자신이 이끌어가고 싶은 방향성에 맞춰서 자기소개를 하면 된다.

자기소개에 들어가면 좋은 것들은 아래와 같다.

• 자기의 강점에 대한 설명 (보통 이력서에 있을텐데, 한번 더 언급하는 것으로 강조를 할 수 있다.)
• 개발자가 되려고 한 이유 (신입한테는 거의 100% 오는 질문이다. 어짜피 한번 더 들어올테니 간단하게만 언급하자.)
• 면접보는 회사의 지원 동기 (어짜피 물어볼텐데, 선수치는 편이 조금 더 나았다.)

강점같은 경우가 정말 큰 역할을 하는데
이것은 무조건 꼬리질문이 들어오기 때문에 어떻게 대답을 할 것인가?에 대한 고민을 하는 것이 좋다.

나같은 경우에는 거의 동일한 레퍼토리로 자기소개를 했다.

왜냐하면 너희들, 나한테 이게 무조건 궁금할텐데? 물어봐야 하지 않겠어? 라는 뉘앙스를 주는 것으로
다른 회사의 면접을 가더라도 비슷한 질문을 받을 수 있고, 시간이 점차 지나면서 정교한 대답을 할 수 있기 때문이다.

질문의 방향성은 면접관이 정하는 것이 아니라, 내가 하는 발언에 의해서 정해진다는 것을 잊지말자.

---

기술면접

개발자 면접의 하이라이트, 기술면접이다.

기술면접은 세가지의 갈래로 나눠져서 질문이 들어온다.

• 기초 CS에 대한 질문
• 내가 이력서에 적거나, 프로젝트에 사용했던 기술에 대한 질문
• 회사에서 사용하는 기술에 대한 질문

일반적으로 신입 질문은 기초 CS에 대한 질문이라고 생각하는데
CS에 대한 질문은 상대적으로 적고, 이력서나 프로젝트에 사용한 기술에 대한 질문이 요즘 들어서는 많이 나오는 것 같다.

왜냐하면 문제은행처럼 자료가 너무 많다보니 외워서 대답할 수 있기 때문에 변별력이 사라진다는 이유로.
그래서 신입한테 MSA 물어보는건가?

그렇기에 이력서 글에서도 적혀있지만, 한번 써봤다고 해당 스택을 이력서에 적지마라.
어느정도 알고 있고 타인에게 설명할 수 있다면 적는 것이 좋다.
싫다면 직접 경험해보시던가(...)

---

즉시 대답하는 것은 좋지 않다.

이것은 기술면접이 아니라 면접 진행 과정에 있어서 정말 중요한 것이다.

질문과 동시에 좋은 대답을 하는 경우, 면접관은 이 사람이 제대로된 지식을 알고 있구나. 라고 생각을 할 수 있다.
반대로 엉망진창 대답을 했을 경우, 생각이 짧다는 부정적인 평가를 내릴 수 있다.

엉망진창 대답을 할 경우에 돌아오는 말은 보통 아래와 같다.

이런 질문을 드렸는데, 어떻게 알고 계신가요?

자신이 듣고 싶었던 답변을 받지 못했기에 세부적으로 질문이 한번 더 들어오는 것이다.

그러니까, 즉시 대답하지 마라.

질문의 핀트를 제대로 잡지 못했다면 자기가 생각하고 있는 것에 대하여 이야기하고, 이런 질문을 하신 것이 맞냐고 한번 더 확인을 해라.
그리고 이야기해라, 잠시만 생각을 정리해서 답변 드려도 괜찮을까요?

별거 아닌 것처럼 보이지만, 생각보다 많은 것을 보여줄 수 있는 대목이다.

많은 개발자들이 일을 하는 개발직군에서, 문제가 발생했을 경우의 행동 패턴을 보여줄 수 있는 좋은 기회다.

내가 생각하기엔 세 가지 정도를 내보일 수 있는 행동이라고 생각한다.

• 현재 발생한 문제에 대해서 다시 한번 확인한다.
• 발생한 문제에 대해서 가지고 있는 생각을 타인에게 공유한다.
• 자신이 가지고 있는 생각을 횡설수설하지 않고, 타인이 이해할 수 있도록 정리해서 설명할 수 있다.

그렇기에 자기가 정말 잘 알고 있다고 즉시 대답하지 말자.
자신이 알고 있는 지식이 언제나 맞는다고 생각하는 것은 위험하다.

---

허세 부리지 마라.

기술면접에서 제일 중요하다고 생각하는 키워드, 바로 아는 척에 관한 이야기다.

나는 신입이고, 상대방은 어찌됐던 나보다 많은 것을 알고 있는 개발자일 가능성이 높다.

그런데 제대로 알지도 못하는 것에 대해서 언급을 하면 꼬리질문을 통해서 탈탈 털린다..

꼬리질문은 보통 면접자가 대답으로 나오는 것을 통해서 이어지는 경우가 많은데, 경험으로 예시를 들어보겠다.

첫번째 압박기술면접에서 이러한 질문을 받았다.

1. 팀프로젝트에서 Redis를 쓰셨는데, 그 이유를 들을 수 있을까요?
2. In-memory DB는 왜 사용하나요?
3. In-memory DB의 장점과 단점은 무엇이 있을까요?
4. Redis의 특징이 무엇이 있을까요?
5. Redis와 Memcached의 차이는 무엇일까요?

신입한테 이걸 왜 물어보는데!!!!!!!! 라고 할 수 있겠지만, 적당히 대답을 했기 때문에 저런 질문이 나온 것이다(....)

그러니 절대로 아는 척 하지말자. 어짜피 다 티난다.

---

모르는 것을 인정해라.

그럼 멍청하게 모른다고 인정해야하냐! 라고 물어볼 수 있다.

맞다, 모른다고 인정을 해야한다.

모르는 것에 대하여 인정을 하는 것으로 지식의 겸손함을 보여줄 수 있고, 앞으로 어떻게 할 것인지를 표현할 수 있다.

나 같은 경우에는 이렇게 대답을 하는 편이다. 아래 Q&A 또한 경험 중 하나였다.

Q. NestJS의 Scope에 대해서 알고 계시는게 있을까요?

A. 이 질문에 대해서는 지식이 모자라 명확한 답을 드릴 수 없을 것 같습니다.
하지만, 공식문서에서 본 기억이 있어 아는 것에 대해서만 이야기를 해보자면 Scope는 3가지가 존재하는데 DEFAULT,REQUEST,TRANSIENT 이렇게 있다고 알고 있습니다.

저게 모른다고 대답한거에요?

모른다고 대답한 것이 맞다. 하지만 알고 있는 것에 대해서는 언급을 한 것이다.

만약 네! 저 알아요! 라는 느낌으로 대답했다면 꼬리질문으로 내 밑천이 드러났을 것이다.

그러나 모른다고 이야기하고 아는 것에 대해 이야기를 하는 것으로
해당 질문에 대한 중요성을 알고 있고, 모르는 것에 대한 지식의 겸손함을 보여줄 수 있다.

정말 모르면 어떻게 해요?

정말 무슨 소리하는지 모르겠다면, 완곡하게 모른다고 표현을 하면 된다.
그리고 이건 면접관마다 케바케가 있는 부분인데

답변을 하지 못한 질문에 대한 정답을 물어보는 것도 나쁘지 않다.

면접관의 성향이나, 남은 시간에 따라서 달라지긴 하는데 긍정적인 면만 봐보자.

• 자신이 모르는 것을 인정하고, 지식을 얻으려고 하는 모습을 보여줄 수 있다.
• 질문하는 것에 대한 두려움이 없다는 것을 보여줄 수 있다.

신입에게 바라는 것은 배우고자 하는 의지라고 위에서 이야기했는데 그것을 보여줄 수 있는 좋은 방법이다.

---

인성면접(컬쳐핏)

두루뭉술하게 인성 면접과 컬쳐핏 면접이 다르다고 이야기하는 경우도 있지만
두 개를 나눠서 적기엔 또 공통되는 것이 너무 많아서 한 개로 적어본다.

개인적으로는 제일 어려운 질문이 많이 나온다고 생각하는 인성(컬쳐핏)면접이다.

왜냐하면 몇가지 이유가 존재하는데

• 질문에 대한 정답이 존재하지 않는다.
• 자신의 가치관을 녹여내서 대답을 해야한다.
• 가지고 있는 생각에 대해서 논리정연하게 대답을 할 수 있어야한다.

자신이 가지고 있는 생각을 정리해서, 논리가 틀리지 않도록 설명을 해야하기에 일단 어려운데
회사에서 요구하는 것과 어긋난다면 떨어진다.

여기서 보통, 문제해결 능력과 커뮤니케이션 능력에 대한 검증이 이루어진다고 나는 생각하고 있다.

어떤 질문들이 대표적으로 나오냐면, 나의 경우는 팀프로젝트 리더와 PM을 했다고 적어놔서 그런지 아래와 같은 질문을 받았다.

• 리더와 PM을 하셨는데 어떤 점이 어려우셨나요?
• 팀프로젝트를 하면서 팀원끼리 다툼이 벌어졌을 때 어떻게 하셨나요?
• 기능 구현에 대한 일정 산정을 할 때, 어떤 기준으로 잡으셨나요?
• 만약 회사에서 요구하는 일정내로 할 수 없을 경우에는 어떻게 하실 예정이신가요?
• 일정내로 기능 구현을 하기 위해서 어떤 방법을 할 수 있을까요?

더럽게 어렵다 진짜

그럼 이러한 질문에 대답을 할 때, 주의해야하는 것이 무엇일까.

---

정확한 조건을 파악한다.

이것은 컬쳐핏 질문에 있어서 정말 중요한 포인트라고 생각한다.

예를 들어서 아래에 있는 질문을 받았을 때, 무엇을 확인해야할까?

• 만약 회사에서 요구하는 일정내로 할 수 없을 경우에는 어떻게 하실 예정이신가요?

현재의 상태, 사용할 수 있는 리소스에 대해서 먼저 파악을 해야한다.

1. 해당 기능이 그 일정내로 구현하지 못할 경우 발생하는 문제를 물어봐야한다.
2. 바로 투입할 수 있는 경력을 포함한 개발자의 인원을 물어봐야한다.
3. 급하게 만드는 것으로 발생할 수 있는 위험도에 대하여 설명을 해야한다.

즉, 질문을 받았을 때 바로 대답을 하는 것이 아니라 질문에 대한 조건을 자세하게 물어본 후 대답을 해야한다.

조건에 대해서 물어보지 않았다면 좋은 대답을 할 수 없을 것이다.

---

입장 변화는 좋지 않다.

조건에 대한 질문을 하지 않았거나, 자신이 대답한 것에 대한 근거가 모자를 경우 발생하는 문제다.

예시를 들자면 이런거다.

나 : A처럼 하는게 더 좋은 것 같습니다.
면접관 : B처럼 하는게 더 좋지 않을까요?
나 : 이야기를 들어보니 A가 아니라 B처럼 하는 것이 더 좋을 것 같습니다.

내용이 중복될 수 밖에 없는데 그만큼 중요하다는 소리다.
생각을 제대로 하지 않은 상태로 대답을 했기 때문에 발생하는 것이다.

자신이 틀렸다고 인정하고, 다른 사람 의견을 받아들일 수 있는 사람이 아닌가요?

그렇게 생각할 수도 있겠지만, 그만큼 자신의 논리에 대해서 깊은 고민을 하지 않은 사람이라고 볼 수 있다.

이것은 기술면접에서도 제법 나오는 패턴인데, 대답을 했을 때 일부로 틀린 것을 알려주면서 이게 맞지 않냐? 라는 식으로 되묻는 경우가 있다.

그렇기에 함정에 빠지지말고, 대답한 것에 대해서 명확한 근거를 이야기하자.

A. 제가 생각하기에는, 이런 이유를 가지고 말씀을 드렸기 때문에 제가 말씀드린 방안이 더 좋은 것 같습니다.
혹은
B. 생각을 조금 해보았는데, 제가 말씀드린 방안에서는 이러한 문제점이 있을 것 같아서, 말씀해주신 방안의 일부를 차용하는 것도 좋을 것 같습니다.

질문에 대한 정답은 없지만, 대답의 근거는 꼭 이야기하도록 하자.

---

마지막으로 궁금하신 점이 있을까요?

드디어 면접의 마지막, 면접자가 질문을 할 수 있는 시간이다.

면접의 결과를 뒤집을 수 있다고 이야기하는 사람도 있는데, 어지간하면 어렵다고 생각하고 있다.

그럼 뭐가 의미가 있냐? 라고 할 수 있겠지만 앞으로 면접을 계속 볼 것이다.
다음 면접에는 조금 더 나은 결과를 낼 수 있도록 개선점을 찾는 시간이라고 보면 좋을 것이다.

---

나를 위해 면접을 이용해라.

내가 이 시간이 왔을 때 제일 먼저 했던 질문은 바로 나에 대한 피드백을 받는 것이다.

많은 면접관들은 취준생들이 하는 노력을 알고 있다.

그래서 면접관에게 이번에 본 면접에 대한 피드백을 요청하면 거의 90% 확률로 이야기를 해준다.
장점과 개선해야하는 점에 대해서 모조리 물어봐라.

이것은 선택이 아니라 필수다.

---

관심도를 끌어올려라.

나같은 경우에는 회사에 대해 궁금한 점을 노트에 적고, 이 타이밍에 허락을 받고 꺼내서 물어봤다.

내가 좀 일반적인 경우와 다른 점도 있었을텐데, 나는 내가 관심이 없는 도메인을 서비스하는 곳은 면접을 취소했다.

그러다보니 내가 관심이 있던 회사들만 면접을 가다보니 취업이 아니라
그냥 회사가 서비스하는 것에 대해서 궁금한 점이 있다면 그런 것을 모두 적어서 물어봤다.

당연히 좋게 봐주는 것도 있었지만, 그냥 내 지적 호기심을 채워서 좋았다(...)

신입에게 요구하는 요구치가 그렇게 높지 않은 만큼
회사에 대한 관심도를 보여준다면 면접을 진행하면서 아쉬웠던 점을 메꿀 수 있다고 보고 있다.

그렇기에 정말 가고싶은 회사에 면접기회를 얻었다면, 꼭 많은 정보를 알아가자.

---

다음 스탭을 위하여

마지막으로 면접을 보고와서는 다음을 위한 준비를 해야한다.

그것은 바로 받았던 면접에 대한 질문을 리스트로 만들어서 정리를 하는 것이다.

신입 백엔드 면접 질문 Ver. 2.0.7 <- 필자가 만든 기술 면접 리스트.

왜냐하면, 면접이라는 것이 뻔하다.
신입에게 물어볼 수 있는 질문이 한정되어있고, 어지간해서는 한개의 이력서로 지원을 하기 때문이다.

솔직히 말해서 웹상에 뿌려져있는 프론트,백엔드 기술면접 리스트같은 경우에서 큰 도움을 받기는 어렵다.

컴공 학부생이라면 알고 있어야할 CS 지식이 대부분이라서 말이다.

그렇기에 면접에서 받았던 질문에 대해서는, 면접이 끝나고 기억이 남아있을 때 핸드폰에 다 적어놓는 것이 좋다.

집에 도착한 후에는 만약 답변하지 못했던 질문에 대해 찾아보고 공부를 하면 된다.

나같은 경우에도 해당 질문 리스트에 있는 것을 당연히 대부분 대답 못했지만
리스트를 만들면서 계속 공부를 하고 포스팅을 했더니, 마지막으로 봤던 기술면접에서는 대부분을 대답할 수 있었다.

그 날 본 면접에서 대답을 너무 못해서 멘탈이 깨졌더라도, 술 마시면서 한탄을 하고 있을 시간이 없다.

면접을 보았기에 한발자국 더 나아갈 수 있다는 생각으로 준비를 한다면
자신도 모르게 상당히 높은 지식의 탑을 쌓을 수 있을 것이다.

---

---

---

취업을 위하여 열심히 달려가고 있는 많은 취준생 분들을 응원합니다.

제 개인적인 의견이 매우 많이 포함된 글이기에, 도움이 되실지는 모르겠지만 필요한 부분만 소화를 하신다면 분명 가치가 있을 것이라 생각합니다.

틀린 부분, 오탈자가 존재한다면 댓글로 달아주세요.

끝