취준생을 위한 개발자 면접 팁
자신을 감추지 말기
| 자신감이 넘쳐보인다. 너무 솔직해서 호불호가 있을 것 같다. |
회사의 정보를 알아보자
| 최근 지원자들이 지원 동기를 쓰는 것이 아니라 보이는대로 서류를 집어넣는 형태가 빈번하다. |
못해도 한 두시간 정도는 알아보는 것이 좋다.
이유는 단순하게 그냥 예의다.
만약 회사에 대한 관심이 없고, 면접 경험을 위해 가는 것이라면 뭐라고 못하겠지만. 전력으로 면접을 보고있는 상태라면 회사의 정보를 알아가는 것이 큰 도움이 된다.
- 회사의 주력 서비스
- 당연히 알아봐야된다고 생각한다.
- 내가 합격해서 개발을 하는 서비스이기 때문에 정말 관심 외의 서비스라면 면접을 취소하는 방향도 있다.
- 회사의 투자 현황에 대해 확인한다
- 스타트업 같은 경우 마땅한 캐시카우가 없을 가능성이 높다. 회사가 공중분해 될 수 있다는 것이기에 안정적인 자금 운용이 가능한지 알아보는 것이 좋다.
- 회사의 채용 페이지를 확인한다
- 대부분 회사의 홈페이지에서 채용을 누르면 노션 페이지로 이동하는 경우가 많다.
- 잘 읽어보면 회사에서 원하는 인재상이 있을 것이다. 이러한 부분을 면접에서 강조하면 좋은 이미지를 얻을 수 있다.
- 상시 채용이 오랜기간동안 진행됐을 경우 퇴사를 많이 한다는 의미도 있을 수 있으니 잘 알아보자.
- 면접 진행 이메일을 잘 읽어본다
- 이곳에는 면접관에 대한 정보가 존재한다.
- 채용페이지 + 메일을 바탕으로 면접관을 추측하고, 그 면접관이 중요시 여기는 부분이 무엇인지 알아볼 수 있다.
- 미리 도착하는 것, 주변 지리에 익숙해지는 것으로 마음의 안정을 가진다.
- 많은 사람들은 낯선 환경에 대해 자기 방어를 하기 떄문에 몸과 마음의 긴장도가 높아질 수 있다.
- 제출한 이력서 읽어보기
- 면접관이 나에게 질문할 수 있는 카테고리가 넓지 않다. 결국 내 이력서 안에서만 나온다.
- 그렇기에 이력서를 한번 더 읽어보면서 어떠한 질문이 나올 것인지 추측할 시간을 만든다.
많은 개발자분들이 이야기를 해주셨는데, 신입에게 바라는 것은 바로 코드를 작성할 수 있는 실력이 아니다.
그렇다면 신입에게 바라는 것이 무엇입니까? 라고 했을 때
대충 이런 것을 생각하고 고려해서 뽑는다고 알려주셨다.
하지만 이력서에서 저런 것을 알기 위해서는 기록을 봐야 알 수 있다.
- 레포지토리에 이런 코드가 있던데, 무슨 이유로 이렇게 적었는지 알 수 있을까요?
- 코드 컨벤션은 어떠한 기준을 잡고 정했는지 알 수 있을까요?
- 블로그에 이런 글이 적혀있던데, 설명해주실 수 있을까요?
- 이러한 작업사항이 있던데, 왜 이런 선택을 하셨나요?
즉, 결과를 보고 그렇게 선택한 이유를 물어보는 질문이 상당히 많이 나오게 된다.
이 사람이 어떻게 고민을 하는 사람이고, 근거를 가지고 의사결정을 하는 사람인지 확인하기 위해서 말이다.
면접
자기소개
굳이 자기소개를 시키는 이유에는 몇가지가 있다.
- 자기소개를 하는 동안 면접관들이 이력서를 훑어본다.
- 자기소개를 듣고 질문의 방향성을 잡는다.
방향성이 정말 중요한 키워드다.
자기소개에 들어가면 좋은 것들은 아래와 같다.
- 자기의 강점에 대한 설명 (보통 이력서에 있을텐데, 한번 더 언급하는 것으로 강조를 할 수 있다.)
- 개발자가 되려고 한 이유 (신입한테는 거의 100% 오는 질문이다. 어짜피 한번 더 들어올테니 간단하게만 언급하자.)
- 면접보는 회사의 지원 동기 (어짜피 물어볼텐데, 선수치는 편이 조금 더 나았다.)
강점같은 경우가 정말 큰 역할을 하는데
이것은 무조건 꼬리질문이 들어오기 때문에 어떻게 대답을 할 것인가?에 대한 고민을 하는 것이 좋다.
즉시 대답하는 것은 좋지 않다.
질문과 동시에 좋은 대답을 하는 경우, 면접관은 이 사람이 제대로된 지식을 알고 있구나. 라고 생각을 할 수 있다.
반대로 엉망진창 대답을 했을 경우, 생각이 짧다는 부정적인 평가를 내릴 수 있다.
이런 질문을 드렸는데, 어떻게 알고 계신가요?
자신이 듣고 싶었던 답변을 받지 못했기에 세부적으로 질문이 한번 더 들어오는 것이다.
그러니까, 즉시 대답하지 마라.
질문의 핀트를 제대로 잡지 못했다면 자기가 생각하고 있는 것에 대하여 이야기하고, 이런 질문을 하신 것이 맞냐고 한번 더 확인을 해라.
그리고 이야기해라, 잠시만 생각을 정리해서 답변 드려도 괜찮을까요?
많은 개발자들이 일을 하는 개발직군에서, 문제가 발생했을 경우의 행동 패턴을 보여줄 수 있는 좋은 기회다.
내가 생각하기엔 세 가지 정도를 내보일 수 있는 행동이라고 생각한다.
- 현재 발생한 문제에 대해서 다시 한번 확인한다.
- 발생한 문제에 대해서 가지고 있는 생각을 타인에게 공유한다.
- 자신이 가지고 있는 생각을 횡설수설하지 않고, 타인이 이해할 수 있도록 정리해서 설명할 수 있다.
그렇기에 자기가 정말 잘 알고 있다고 즉시 대답하지 말자.
자신이 알고 있는 지식이 언제나 맞는다고 생각하는 것은 위험하다
허세 부리지 마라.
나는 신입이고, 상대방은 어찌됐던 나보다 많은 것을 알고 있는 개발자일 가능성이 높다.
그런데 제대로 알지도 못하는 것에 대해서 언급을 하면 꼬리질문을 통해서 탈탈 털린다
첫번째 압박기술면접에서 이러한 질문을 받는다고 가정하자
- 팀프로젝트에서 Redis를 쓰셨는데, 그 이유를 들을 수 있을까요?
- In-memory DB는 왜 사용하나요?
- In-memory DB의 장점과 단점은 무엇이 있을까요?
- Redis의 특징이 무엇이 있을까요?
- Redis와 Memcached의 차이는 무엇일까요?
신입한테 이걸 왜 물어보는데!!!!!!!! 라고 할 수 있겠지만, 적당히 대답을 했기 때문에 저런 질문이 나온 것이다(....)
그러니 절대로 아는 척 하지말자. 어짜피 다 티난다.
모르는 것을 인정해라.
모르는 것에 대하여 인정을 하는 것으로 지식의 겸손함을 보여줄 수 있고, 앞으로 어떻게 할 것인지를 표현할 수 있다.
예를 들면
Q. NestJS의 Scope에 대해서 알고 계시는게 있을까요?
A. 이 질문에 대해서는 지식이 모자라 명확한 답을 드릴 수 없을 것 같습니다.
하지만, 공식문서에서 본 기억이 있어 아는 것에 대해서만 이야기를 해보자면 Scope는 3가지가 존재하는데 DEFAULT,REQUEST,TRANSIENT 이렇게 있다고 알고 있습니다.
이건 모른다고 대답한 것이 맞다. 하지만 알고 있는 것에 대해서는 언급을 한 것이다.
만약 네! 저 알아요! 라는 느낌으로 대답했다면 꼬리질문으로 내 밑천이 드러났을 것이다.
그러나 모른다고 이야기하고 아는 것에 대해 이야기를 하는 것으로
해당 질문에 대한 중요성을 알고 있고, 모르는 것에 대한 지식의 겸손함을 보여줄 수 있다.
참고자료