솔루션/SI회사 프론트엔드 면접 후기

 

 

이 후기는 나 스스로가 면접 질문에 어떻게 답했는지를 기록해두고 다시 한번 살펴 보면서 추후 면접 때 비슷한 질문이 나오면 좀더 개선된 답변을 준비할 수 있도록 하기 위해 쓴 글이다.

 

 

 

오늘 인생 첫 개발자 면접을 봤다.

아무리 취업이 급하다고 할지라도 SI업체는 되도록이면 입사하지 않겠다는 나름의 내 기준이 있어서

순전히 면접 경험 쌓으려고 갔다.

별로 큰 기대를 하지 않고 가서 그런가 그렇게 긴장하지도 않고 엄청 편하게 보고 왔다(...)

무난하게 보긴 했는데 지금 다시 생각해보니 답변할 때 너무 사족을 많이 달은거 같다ㅠ

 

 

면접 질문

1. 자기소개

2. 비전공자인데 개발이 적성에 맞는지?

3. 국비교육을 2회 받았는데 첫번째 교육 수료 후 바로 취업 안하고 프론트엔드 교육을 또 들은 이유

💬 첫번째 교육을 듣게 된 이유는 개발자로 어떻게 시작해야할지 몰라서 일단 개발교육을 들으려고 선택한 곳이었는데 백엔드 수업 위주여서 프론트엔드 개발자가 되기 위해서는 프론트엔드 공부가 더 필요하다고 생각되어 추가적으로 프론트엔드 과정을 듣게 되었다.

4. 개발 직군이 여러가지가 있는데 그 중 프론트엔드를 선택한 이유

국비수업 때 팀플젝할 때 자원해서 화면단을 도맡아서 만들었는데 UI개발도 미려하게 잘 만들었고 백과 데이터 주고 받는 로직 짜는 것도 재미있었다. 잘할 수 있다고 생각했다. 학원에서 프로젝트 제일 잘 만든 팀 뽑기도 했었는데 두번의 팀프로젝트에서 두번 다 내가 속한 팀이 1등했다.

5. 프론트엔드 분야는 트렌드가 빨리 바뀌고 그만큼 공부를 많이 해야하는데 개발공부는 어떻게 하고 있는지

온라인 강의 수강이나 서적을 통해서 공부를 하고 기술블로그에 공부한 것을 기록한다. 현재는 취업을 위한 프로젝트 만들기 위주의 공부를 하고 있다.

- (이력서에 블로그 주소 기재해놓은걸 까먹고 블로그 주소 기재안한 이유를 얘기함;;) 그런데 블로그에 글을 쓰긴 하는데 공부한 것을 혼자서 다시 보고 정리하는 차원에서 쓴거라 비공개 글이 많아서 기재 안했다.(근데 면접관들이 '블로그 주소 있는데요?' 이래가지고 식겁;;)

6. 이력서의 자기소개 문구(일상 속 삶의 질을 향상 시키는 IT서비스를 만들고 싶은)와 부합하는 프로젝트가 무엇인지

현재 아직 완성하진 못했지만 피그마로 디자인 시안까지는 만들어 둔 프로젝트로 '장소 즐겨찾기 서비스'가 있다. 카카오맵API를 활용하여 사용자가 가고싶은 장소를 검색하고 저장, 기록하는 서비스이다.

7. 프로젝트 깃헙에 들어가보니 깨져서 나오던데

URL 확인을 제대로 하지 않은 것 같다. 혼란을 드려서 죄송하다. 깃헙 리드미를 다시 확인하여 수정하도록 하겠다.

8. Sass를 사용해봤다고 했는데 Sass가 무엇인가

CSS를 컴파일해주는 CSS 전처리기 라이브러리라고 알고 있다.

(라이브러리 아니고 프레임워크인가.. 좀더 나은 답변 준비할 필요 있음..)

9. 리액트와 Next.js를 프로젝트에 사용해본 소감?

Next.js는 교육들으면서 찍먹해본 정도이고 리액트로 대부분 프로젝트를 만들었는데 리액트를 쓰면서 바닐라 자바스크립트를 쓰는것보다 왜 리액트를 쓰는 것이 효율적인지를 깨닫게 되었다.

10. 시안 만들 때 사용해본 디자인 툴은?

- 카카오 오븐, 피그마

- 피그마는 디자이너처럼 전문적인 레벨까지는 아니지만 그래도 어느정도 시안을 만들정도로는 사용할 줄 안다.

(오븐이 디자인 툴인가?; 프로토타이핑 툴이지만 어찌됐건.. 그냥 시안 만들때 사용했던 거라 그냥 얘기했다)

11. RDBMS 쓸줄 아는지? CRUD 정도의 쿼리는 쓸 줄 아는지?

이전에 써 본 경험이 있고, 업무에 필요하다면 구글링해서라도 SQL 쿼리 짤 수 있다.

12. 브라우저 웹앱 프로젝트에서 날씨, 위치 정보 가져오는 거 백엔드 어떻게 했는지? REST API 사용해봤는지

openAPI 사용. REST API는 사용해보지 않았다.

13. 단독으로 처음부터 끝까지 개발해본 경험이나 협업해본 경험

- (이거 약간 동문서답 한 부분도 있다..) 팀플젝 할 때는 PM 역할을 자원해서 맡아서 일정 조율 하면서 마감일까지 프로젝트가 완성될 수 있게끔 이끈 경험이 있다. 혼자서 처음부터 끝까지 만드는 프로젝트는 앞서 얘기한 장소 즐겨찾기 서비스 프로젝트를 만들 계획이다.

14. 혼자 개발하는 것과 여럿이 같이 개발하는 것 중 어떤게 더 좋은지

- (이 질문은 조금 당황스러웠음.. 당황하는 바람에 굳이 말 안해도 될걸 얘기했다.. 그리고 미묘하게 또 동문서답 한거 같기도 하다.. 면접관이 먼저 질문 하지도 않았는데 갈등상황을 겪었던 일이라든가를 내가 먼저 말함..) 각각 장단점이 있는데, 팀플젝을 하면 갈등상황이 생긴다. 팀플젝 하다가 한 팀원분과 의견이 안맞아서 타협점을 찾지 못하고 내가 팀이탈을 한적이 있다.(이걸 왜 말한거야 도대체..) 근데 돌이켜보니 그때 의견 불일치했던 사항은 프로젝트 완성이라는 전체 목표를 두고 봣을때는 굉장히 미미한 부분이었다. 그래서 내가 주장을 관철하기 보다는 큰 목표를 달성하는 데 초점을 맞췄어야 하는 것 같다. 

 개인으로 개발을 하게 되면 일정이라던지 자기가 원하는 기능 마음대로 넣을 수 있고 좋긴 한데 피드백을 받을 수가 없다. 내가 개발을 잘 하고 있는것이 맞는지를 알 수가 없기 때문에 좋은 제품을 만들기 위해서는 협업하여 개발하는 것이 더 좋다고 생각한다.

 -> 역시 예상한대로 위에 말한 갈등상황에서 타협점을 찾지 못하고 이탈했던 부분에 대해서 면접관이 언급을 했다. 근데 나는 '프로젝트 완성이라는 큰 목표를 위해서 갈등상황의 원인이 미미한 부분 때문이라면 내가 접는 것이 좋은것 같다'라고 답했는데 원하는 답은 아니었다는 피드백을 받았다. 원하는 답이 뭐였을까.. 갈등상황에서도 자기 의견을 관철해야되는건가.. 원하는 답이 뭐였는지 물어볼걸그랬다..

15. 기술면접 질문

그냥 전반적으로 기술면접 대비 안한거 티 많이 나는 대답만 했다(실제로도 별로 준비안함...)

 1) Map의 개념(내 벨로그 TIL 보고 질문)

- 어버버 하다가 잘 모른다고 함

2) 클로져 함수의 개념과 사용하는 이유

외부에서 특정 값을 마음대로 수정하기 못하게 하기 위해서 사용한다.

3) SSR과 SPA 구축한 경험 있는지

(구축한 경험 있는지를 물어봤는데 SSR, SPA가 무엇인지를 얘기해서 이것도 약간 동문서답..)

- 대표적으로 Next.js가 SSR 방식을 사용한다. 렌더링 방식이 SSR과 CSR이 있는데(CSR 물어보지도 않았는데 잘 설명하지도 못할거면서 왜 얘기했는지ㅠ ) SSR은 서버 측에서 렌더링을 다 해서 가져오는 것이고 CSR은 클라이언트 측에서 렌더링 하는 것이다.

- SPA는 html페이지 하나에 자바스크립트나 데이터 같은 것들이 렌더링 되는것이다.(? 이 뭐 이상한 설명은..)

16. 개발하다가 모르는 것들(문법, API 사용방법 등)이 생기면 어떻게 해결하나?

간단한 문법 같은거는 그냥 구글링해서 다른사람들 글 쓴거 참고하지만 익숙하지 않은 언어나 라이브러리, 프레임워크 혹은 API 같은 경우에는 무조건 공식문서를 참고한다. 구글링을 할 때에도 스택오버플로우나 주로 영어로 된 자료를 우선적으로 참고한다. 영어로 된 공식문서 참고에는 전혀 문제 없다.

 

 

 

느낀 점

1. 기술블로그

 기술블로그에 TIL 같은 공부한 내용을 기록하는 경우, 내가 공부한 것을 충분히 내 지식으로 소화해낸 내용만 글을 쓰는 게 좋다. 뭐 개념요약 이런거 써놓고 나중에 내가 이런거 썼던가? 이럴거면 차라리 안 쓰는게 낫다. 왜냐? 실제로 내가 이번 면접 때 크게 깨달았기 때문ㅋㅋ 내가 벨로그에 Map에 대해서 써놓고서는 추가적으로 더 공부가 필요한 것 같다고 써놓은 걸 보고 면접관이 이 부분을 질문했고 정작 나는 내가 그런 내용을 썼었는지도 잊고 있었다 심지어 추가 공부해야겠다고 써놓고선 하지도 않음ㅠㅋㅋ

신입 면접에는 면접관이 뭘 보고 판단할 만한 게(경력) 크게 때문에 기술블로그 주소 이력서에 기재되어있으면 대부분 본다고 생각하면 될것 같다. 블로그에 써진 글들을 기반으로도 질문을 하면서 이 사람이 진짜 공부한 게 맞는지, 꾸준하게 공부하고 있는지도 판단하는 것 같다.

2. 기술면접

 기술면접은 구글링하면 쉽게 볼 수 있는 기술면접 단골질문들 그 범위를 크게 벗어나지 않는다. 수많은 개발자 기술면접 후기를 봐오면서 자주 묻는 질문들 범위에서 크게 벗어나지않는다는 걸 알고는 있었지만 이번 면접을 통해서 그게 진짜라는걸 체감했다.

3. 개발자 면접 준비 방향성 확립

 면접을 보기 전에는 뭔가 뜬구름 잡는 식의 취준을 하고 있었는데 면접 후에는 어떤 식으로 개발자 면접을 준비하면 될지 명확하게 그려졌다. 나는 아는 게 하나도 없는 똥멍청이인데 기술 관련 질문 들어오면 답을 잘 할수나 있을까 걱정이 되었는데 너무 그렇게 자책할필요도 겁을 먹을 필요도 없었다.(생각보다 나는 그렇게 똥멍청이가 아니었다!)

 사실 면접 보기 전까지만해도 다른 부트캠프 교육 또 더 들어야하나 고민하고 있었는데 그 고민을 없애주는 계기도 되었다.(교육방랑자가 되지 말자..) 나에게 필요한건 지금 부트캠프가 아니고 정말 제대로 된 프로젝트 하나. 이거 하나만 있으면 어디든 지원할 수 있을 거 같다. 그래서 다른 데 한눈팔지않고 지금 디자인시안까지 진행되어있는 내 개인 프로젝트를 속도에 박차를 가해서 완성시키는 것을 최우선 목표로 삼고 있다.

 

4. 가능한한 면접 많이 보기

- 면접은 많이 볼 수록 좋다는 걸 다시금 느꼈다. 개인프로젝트 완성까지 직접 입사지원은 하지 않아도 채용플랫폼에 이력서 공개 해두고 면접 제안이 오면 되도록이면 응할 생각이다. 면접 경험을 되도록 많이 쌓아두고 정말 내가 입사하고 싶은 회사에 지원할 때는 좀 경험치가 있는 상태에서 면접을 볼 수 있도록 할 계획이다.

 

 

 

 

 원래 계획보다 이력서 넣는 시기가 좀더 미뤄지겠지만 앞으로의 개발자 커리어패스를 길게 보고 조급하게 생각하지 않고 차근차근 착실히 준비해서 꼭 좋은 회사에 입사할거다.