[우아한테크코스] 레벨2 인터뷰

레벨2가 끝나가는 만큼 마지막 마무리를 잘 하기 위해 레벨 인터뷰 회고를 해보려고 한다. 레벨 인터뷰는 각 레벨이 끝날 때 마다 진행하는 일종의 모의 면접 같은 느낌으로, 여러명의 크루들과 코치들이 모여 한 명에게 질문하고 대답하는 형식으로 이루어진다.

 

이번 면접에서는 무려 포비가 면접관이 되어주셨다. 나는 레벨인터뷰를 어제 했는데 하루 안에 회고를 작성하라는 포비의 말씀이 있어서 나도 까먹기 전에 내 인터뷰 영상을 보면서 회고를 작성하려고 한다.

 

질문이 너무 많았기 때문에 1/4 정도의 질문만 간단히 정리하고 내가 2레벨을 진행하면서 느낀점을 적어보려고 한다.

 

질문

---

페어하면서 실력차이가 나는 사람이랑 진행한 적이 있는가

---

아직 없다. 지금 나 정도의 레벨에서는 실력차이가 나봤자 내 페어가 모르는 키워드 정도 알려주는 정도이지, 내가 훨씬 잘해서 페어를 주도적으로 이끌어 갈 수준은 아니다.

 

말 수가 적고 자기 주장을 잘 펼치지 않는 사람들과 어떻게 하면 좋은 팀 문화를 만들 수 있을까

---

팀 문화를 바꿀 것 같다. 예를 들면 팀별 데일리를 할 때 우리팀에 대해 의견을 낸다거나 그런 약간의 강제성을 부여할 것 같다. 말 수도 없고 의견도 별로 내지 않는 사람들에게는 큰 도전이라고 생각하고 우리 팀의 분위기 자체를 바꿀 수 있다고 생각한다.

 

만약에 신입사원으로 입사했을 때 먼저 회사를 들어온 사람들에게 어떻게 자신의 의견을 표현할 것인가

---

일단 해당 조직에서 누가 봤을 때도 열심히하고 팀의 목표를 이루는데 도움이 되고 인정 받을 만한 엔지니어가 된다면 목소리를 못 낼 이유가 없다고 생각한다. 

---

그렇기 때문에 신입사원으로 들어왔을 때 부터 팀을 바꾸려고 하는건 말도 안된다고 생각하고, 내가 그 조직에 인정받을 만큼 기여한 다음에 목소리를 내는게 팀에게도 수지타산이 맞는 행동인 것 같다.

 

페어를 할 때 설계와 구현 중에 어느 것이 우선순위가 높은가

---

결론부터 말하면 딱히 우선순위를 두지 않는다. 물론 설계를 어느정도 하고 구현을 하긴 한다만, 처음부터 "엄청나고 부족함고 결함없는 설계를 만들꺼야!" 라고 생각하지 않는다는 뜻이다.

 

아무리 좋은 설계라고 한들 직접 구현하면 내가 생각하지 못한 부분들에 대해서 설계가 문제가 될 때도 있고 만족스럽지 않은 부분들이 계속 생겨날 것이다. 처음부터 모든 설계를 하는 것에는 한계가 명확히 존재한다.

 

그래서 나 같은 경우는 어느정도 틀이 잡혔다 하면 일단 구현부터 한다. 그리고 구현을 하다가 다시 설계로 돌아가서 부족한 부분을 채우고, 더 좋은 설계를 생각해본다.

 

레벨2 마지막 미션이 협업 미션이었는데, 어려움은 없었나

---

내가 조금 열정이 넘치는 편이다. 팀원들이 힘이 빠지거나 미션에 대해서 열정이 없는 분들이랑 팀을 하게 되면 나까지 힘이 빠지는 경향이 있다.

 

그래서 미션 막판에 어떤 분들은 새로운 기능까지 도입해보자 말이 나오는데, 어떤 분이 자기는 미션 시간 내에 하기 힘들 것 같다. 너무 빠듯하다. 이런 말씀을 하셔서 조금 힘이 빠지는 정도였다.

---

물론 개개인마다 기능을 구현하고 코드를 작성하는 속도는 모두 다르고, 기능을 추가하지 못하는 것 쯤은 얼마든지 이해할 수 있다. 하지만 팀 관점으로 보았을 때 그런 의견을 낼 때 자신의 어투가 팀원에게 어떻게 들릴지, 팀에는 어떤 영향을 끼칠지 정도는 생각해보는 것도 괜찮을 것 같다.

 

@JdbcTest는 어떤 의존성을 가지고 있는가

---

답변은 매우 간단했다. 잘 모르겠다.

---

이후에 내가 @JdbcTest를 뜯어보았을 때 의존성이라고 함은 상속받고 있는 JdbcAccessor과 구현하고 있는 JdbcOperations를 뜻한 것이었나?를 생각했다.

 

처음에 내가 생각한 의존성은 JdbcTest의 Composition이었다. 레벨 1에서 경험한 바로는 상속까지 생각했어야 했는데, 너무 단순하게 생각했다. 

 

질문받은 3가지의 어노테이션들 중 가장 많이 사용한다고 대답했음에도 불구하고 너무 어이없게 대답 못했다. 물론 몰라서 대답 못한 것도 있다. 그렇지만 내가 가장 많이 사용했다고 말한 어노테이션의 구현체를 한 번쯤은 뜯어보고 이해했어야 하지 않았을까?

 

단위 테스트를 많이 작성함으로써 얻는 장단점은 무엇인가

---

장점은 하나의 메서드에 대해 분기별로 테스트를 작성하기 때문에 커버리지가 그만큼 올라가고 내 코드를 신뢰할 수 있다.

 

단점은 당연히 테스트를 작성하는데 많은 시간과 리소스가 많이든다. 특히 서비스 계층에 단위테스트를 작성할 때 persist 계층에 대해서 Mock을 선언하고 Stubbing을 하여 테스트를 하는데, 의존하는 객체가 많아질수록 테스트 난이도가 급격하게 올라간다.

 

레벨2 레벨로그 총평

크루들의 피드백

[좋은 점]
- 조직문화와 협업 등에서 자신의 주장이 확고함이 보였다.
- 자기자신에 대한 인지가 잘 되어있음이 느껴졌다.
- 테스트에 대한 고민을 많이 했음이 느껴졌다.
- 말에서 솔직함이 보였다. 
- 차분함이 느껴지며 긴장하지 않고 당차보인다.
- 기술 선택에 있어서 자신만의 기준을 가지고 있다.

[특징]
- 자신의 주관이 아주 뚜렷하다.

[아쉬운 점]
- 손이 불안하게 계속 움직입니다. 차분해 보이지 않는다.
- 질문자를 보지 않고 허공이나 다른 사람을 보고 있어 집중하고 있지 않은 것처럼 보인다.
- '굳이'라는 어휘를 줄여도 좋을 것 같다. 대안책을 제시한 것은 굿!
- 선택한 기술 외에 다른 것을 고려안하는 것이 아쉬웠다.
- @JdbcTest 를 많이 사용했다고 말씀하셨는데, 어떤 의존성을 가져오는지에 대해 학습하지 않은 점이 아쉬웠다.
- RESTful한 API에 대한 본인의 기준을 물어봤을 때, 로이 필딩의 말을 인용하려는 자세는 좋았지만 거기에 이어지는 본인의 생각은 제대로 듣지 못한 것 같아서 아쉽다.
- 201 상태 코드로 응답할 때, 리소스의 위치를 어떻게 담아서 보내는지에 대해서 학습하면 좋을 것 같다.

포비의 피드백

베베가 인터뷰 하는걸 보면 자신감이 있어 좋아 보인다. 그리고 프로그래밍에 대한 자신의 소신과 철학이 확고해보인다. 하지만 이게 과하면 "이 친구가 협업하기 힘든 사람일 수도 있겠는데?"라는 인상을 줄 수 있다.

 

약간의 경계선에서 왔다갔다 하는 것 같다. 만약 잘못 인터뷰를 한다면 나의 진짜 실력과 커뮤니케이션 능력으로 평가 받는게 아니라 어느정도 곡해를 받을 수 있다. 이 부분만 잘 고민해보면 될 것 같다.

 

다르게 생각해보면 "나는 이런 사람인데 이런 사람을 소화할 수 있으면 뽑고 그렇지 않으면 떨어뜨려라." 이렇게 생각해도 좋다. 원래 베베는 그런 사람이고 그런 팀으로 가는게 제일 좋다. 아직까지 우리나라가 이런 사람들을 소화할 수 있는 면접관이나 그런 팀들이 점점 많아지고 있긴 하지만, 아직까진 부족한게 사실이다.

 

내 생각

원래 나는 내 생각과 철학이 워낙 확고한걸 알기 때문에 그것에 대해서 많이 놀라지는 않았다. 하지만 우리나라에 이런 문화를 가진 팀이 많이 없다는 사실에 약간 놀랐다.

 

그래도 나름 남이 해주는 말도 잘 듣고 피드백도 잘 반영하는 편이라고 생각하긴 했다. 그래서 포비가 피드백을 해줄줄은 몰랐는데.. 레벨3까지 가면 계속 팀프로젝트를 진행할텐데, 협업하기 좋은 사람이 되도록 노력해야겠다.

 

아차 레벨2가 시작되고 이론 공부를 약간 뜸하게 했는데, 면접보면서 너무 충격받았다. 방학때 진짜 열심히 공부해와야지... 모두 화이팅입니다~! :)