[우테코] 레벨1 인터뷰 회고: 학습 측면, 말하기 측면에서의 피드백과 나의 피드백

레벨1 마지막날에 인터뷰를 진행했다. 7명의 크루와 브리 코치가 한 팀이 되어 진행했고, 각각 돌아가면서 인터뷰어(질문하는 사람), 인터뷰이(질문을 받는 사람), 옵저버가 되었다. 나는 내가 작성한 레벨 로그를 바탕으로 질문을 받았다.

 

20분의 인터뷰를 마치고, 10분 간 인터뷰이를 제외한 다른 사람들이 피드백을 작성하고 발표하는 시간을 가졌다. 이번 회고를 통해 내가 받았던 피드백을 정리해보고, 레벨2 인터뷰를 위해서 9주 간의 레벨2 기간동안 어떤 방향으로 학습을 보완해야 하는지에 대해서 계획을 세워볼 수 있으면 좋을 것 같다. 

 

 

---

 

 

💋 학습 측면에서 받았던 질문과 나의 대답

 

모든 질문들이 기억에 남지는 않으므로, 기억에 남았던 질문만 모아봤다.

 

✔ TDD

 

Q. TDD를 사용하는 이유?

 

나의 대답)

• 처음 느낀 TDD는 단지 테스트 코드를 먼저 짜는 것으로, 기존에 하던 방식에서 순서만 바뀐 것 뿐이었다.
• 지금 생각하는 TDD는 한 객체가 다른 객체에게 어떤 요청을 보내서 어떤 응답을 받고 서로 어떻게 협력하는 지에 대한 설계를 먼저 하는 방식이다. 상위 객체에서 하위 객체로 흘러내려가는 요청, 거슬러 올라가는 응답을 먼저 생각해보고, 가장 하위에서 상위 객체가 시키는 일에 대해 어떤 요청을 받아 어떤 응답을 보내야 하는지에 대해 생각하고, 이것부터 테스트 코드를 작성해나가는 방식이다. TDD를 하게 되면 도메인 전체에 대한 파악은 하지 않더라도, 먼저 구현하고자 하는 내용에 대해 객체 간 협력 구조에 대해서 생각해보고 들어가야 한다. 따라서 객체 간 메세지 전달에 좀 더 초점을 맞춰서 설계하는 결과가 일어날 때가 많았던 것 같다.

 

나의 피드백)

• TDD를 사용하면서 프로그래밍 점점 복잡해지면서, 구현에 대한 상상의 범위가 굉장히 좁아질 때가 많다. 도메인에 대한 이해가 잘 되더라도 한 번에 구현하려고 하다보면 머리에 과부하가 걸리기 굉장히 쉽다는 부분을 언급했으면 더 좋을 것 같다.
• 나의 경험을 바탕으로 테스트 코드 작성, 테스트 코드 성공하게 만들기, 세부내용 리팩터링 하기 중 한 번에 한 가지만 하게 되기 때문에 이것저것 생각하면서 구현할 때보다 오히려 더 빠르게 구현하는 경험을 했음을 구체적으로 설명할 수 있었으면 더 좋았을 것 같다. 

 

Q. TDD가 이렇게나 좋은데 안하는 사람들의 이유?

 

나의 대답) 

• 새로운 방법에 대한 막연함으로 인한 시간 부족일 것 같다. 
• 설계에 대해서, 도메인에 대한 지식이 턱없이 부족할 경우, 테스트 코드에 작성할 메서드 시그니처조차 생각하기 힘들다면 TDD 방식이 조금 어려워질 수 있다고 생각했다.

Q. 본인이 속해있는 팀이 TDD를 사용하지 않는다면?

 

나의 대답) 

• 나는 팀에서의 적응과 협업을 굉장히 중요시하기 때문에, 곧바로 포기할 수 있다고 대답했다.
• 후에 브리가 추가적인 질문을 통해 나의 생각을 부연설명할 수 있는 기회를 주었고, TDD로 이룰 수 있는 장점인 객체 간 메세지를 보내는 것에 집중한 설계가 이루어질 수 있다면 팀 내 적응을 위해 장점을 조율할 수 있으며, 반드시 강경하게 테스트코드부터 작성하지는 않아도 된다고 생각한다고 답변을 일부 수정했다.

 

나의 피드백) 

• 앞서 내가 레벨1 동안 경험한 TDD의 장점을 자신감있게 말했는데, 후에 곧바로 나의 생각을 포기한 것이 조금 아쉽게 느껴졌다. 
• 처음부터 내가 느낀 장점을 곧바로 포기하지 않고, 고집하며 장점을 가지고 갈 수 있도록 조율한다는 답변하면 더 신뢰감을 줄 수 있었을 것 같다.

 

---

 

 

피드백은 두 가지 측면에서 받았다.

• 학습 측면: 이번 레벨 학습 측면에서 좋은 점과 부족한 점은?
• 말하기 측면: 인터뷰, 말하기 측면에서 좋은 점과 개선할 부분은?

 

 

 

 

💋 학습 측면에서 받았던 피드백

 

✔ 좋았던 부분

 

• 자신이 속한 집단에 맞춰 유연하게 대처할 수 있는 사람이라는 게 인터뷰에서도 드러난 것 같다.
• 또한 자신이 좋다고 느껴도 계속 경계하고 의심해보는 것 같다.
• 그래서 내가 좋다고 느꼈으니 무조건 TDD를 써야겠다가 아닌, 어떤 경우에 쓰면 좋고 또 다른 경우에 쓰면 안 좋은지를 알고 있어서, 시야가 넓어질 수 있는 개발자라는 생각이 들었다.
• 테스트 코드와 객체지향에 대해 많은 고민을 한 것 같아서 좋게 느껴졌고, 왜 하는지에 대한 이유를 많이 고민하신 것 같아서 좋았던 것 같다.
• TDD를 사용해야하는 이유가 여러가지가 있을텐데, 주관적인 의견을 말함으로써, 고민을 많이 해봤다는 것을 느낄 수 있었다.
• 학습할 때 직접 경험하고 실제 경험을 바탕으로 이걸 왜 해야하는지, 어떻게 하면 좋을지 생각하면서 학습한 것 같아 좋았다.
• 학습할때 경험해보지 못한 내용들에 대해서도 장단점을 생각해보면 좋을 것 같다. 

 

✔ 개선이 필요한 부분

 

• 한 가지 기술이 있을 때 단점에 대해서 생각해볼 필요가 있을 것 같다.
• TDD에 대한 장점을 느꼈다고 하자마자 팀에서 사용하지 않는다면, 포기하겠다는 답변보다 "장점을 가져가면서 하겠다"하는 대답을 먼저 하는 것이 좋을 것 같다.
• 좋은 프로그래머가 되기 위한 노력에서, 단순 이해하기 쉬운 코드가 컨벤션에 관련된 것 이상의 것이 들어갔으면 좋겠다. 내가 어떤 노력을 해서 개선점이 있었다는 것을 찾아야 한다.
• 한 가지 기술에 대해서 공부할 때, 그의 장점은 알기 쉬운 반면 단점은 알기가 어려운 경우가 많은데, 단점에 대해서도 구체적으로 알아보면 좋을 것 같다. 
• 모르는 질문이 나오면 추가적인 질문을 통해서 질문의 의도를 파악하거나, 부연설명을 요청하면 좋을 것 같다. 
• 람다식과 익명클래스의 차이에 대해 추가적인 학습을 하면 좋을 것 같다.
• 불변성과 성능문제에 대해 불변성을 보장하는 일급컬렉션의 예시를 생각해보면 좋을 것 같다.

 

나의 피드백) 

• 아직 자바를 오래 공부하지 못해서 경험한 바가 적은 편이었고, 따라서 내가 경험한 부분에 대한 질문에서 조금 어려웠던 것 같다.
• 앞으로 하나의 기술에 대해서 이야기할 때, 나의 구체적인 경험을 바탕으로 이야기할 수 있는 사례를 기억해 두면, 당황하지 않고 더 편하게 이야기할 수 있을 것 같다. 

 

 

---

 

 

💋 말하기 측면에서 받았던 피드백 

 

✔ 좋았던 부분

 

• 모르는 부분이 있으면, 바로 모른다고 대답하면서 다른 질문을 유도하는 모습이 좋다.
• 대답을 할 때, 생각하기 위해 멈추는 시간이 별로 없고 막힘없이 대답하는 모습이 좋다. 
• 목소리 성량이 좋다.
• 깃짱의 특유의 밝은 성격이 인터뷰에서 드러났던 것 같아요. 인터뷰라는 게 경직된 분위기에서 진행될 수 있는데, 깃짱의 이런 부분 덕분에 부드럽게 흘러갈 수 있었어요.
• 인터뷰 때 본인이 실수했을 때, 크게 당황하면서 경직되기 보다는 웃음으로 어떻게보면 재미의 요소로 잘 넘어가는 것 같아요.
• 목소리도 좋았고, 분위기도 좋았습니다.
• 답변을 할때 모르는 부분은 잘 모른다고 바로 답하여 질문을 잘 방어한 것 같다.
• 질문의 의도를 다시 물어보는 것도 좋은 점이다.
• 밝은 표정을 유지하며 답변을 하는 모습이 긍정적으로 보였습니다. 목소리 크기와 속도가 일정한 편입니다. 전반적으로 본인의 생각을 열심히 답하려고 노력하는 모습이라 좋았습니다.

 

✔ 개선이 필요한 부분

 

• 아는 부분을 말할 때는 살짝 빨라지는 경향이 있는데, 시간이 제한되어 있는 면접이라는 특성상 아는 부분일수록 차분하게 말하면서 아는 부분 위주로 말하는 것도 좋을 것 같다.
• 답변이 살짝 긴 편이니, 답변을 짧게 짧게 가져가서 인터뷰어와 대화하듯이 하는 방식도 좋다고 생각합니다.
• 조금 더 시간을 두고 천천히 답변하는 것이 좋을 것 같다.
• 답변이 조금 길어서, 집중이 잘 안되었던 것 같다.
• 모르는 부분에 대해 조금 재미있게 넘어갔다고 생각할수도 있지만, 장난스럽게 임한다는 생각도 들 것 같습니다.
•  '그런', '약간' 등의 추임새가 한 문장 안에서 여러번 등장하는 경우가 있어서 말이 길어지게 느껴지는 경우가 있다. 당황했을때, 답을 끊어서 하는 경우가 생기고 인터뷰어가 구체 질문을 하게 하는 경우가 생긴다.
• 미소를 지으면서 답변을 해주시는 모습이 좋았다. 하지만, 이는 관점에 따라 장난스럽게 느껴질 수도 있을 것 같습니다.
• 설명을 보충하기 위한 제스쳐는 좋습니다. 다만 의미없는 제스쳐가 많아질 경우 오히려 산만해보이거나 긴장함을 더 드러나게 하니 주의하면 좋을 것 같습니다.
• 처음에는 긴장해서 시선이 분산되는 느낌이 있었습니다. 점점 긴장이 풀리면서 시선을 잘 마주치는 모습을 볼 수 있었습니다.
• 문장이 긴 편이고 답변이 장황하게 들리는 편입니다. 좀 더 핵심을 위주로 요약된 문장으로 답변을 하면 보다 설득력있는 답변을 할 수 있을거에요. 본인만의 답변 방식을 만들기 위해 연습을 하면 좋을 것 같습니다.
• 모르는 부분을 빠르게 인정하는 건 좋으나 본인만의 철학이나 가치관을 드러낼 수 있는 질문은 잘 살릴 수 있으면 좋겠습니다.

 

나의 피드백) 

• 같은 말하기에 대해서도 누군가는 재치있다고, 누군가는 장난스러운 것 같다고 느끼는 바가 달랐다.
• 브리는 모두가 다 자신의 개성을 지우고 같은 방식으로 말해야 할까?라고 문제를 제기했고, 나도 일부분 동의한다. 다음 인터뷰 때에는 적절히 나의 성격과 가치관을 드러내는 긍정적인 태도를 유지하면서 조금 더 차분한 모습을 보여주면 좋을 것 같다. 

 

 

반응형

 

---

 

💋 대답하지 못한 질문

아직 기술적으로 지식이 모자라 답하지 못한 질문들이 있어서, 공부해봐야 할 것 같다.

• 람다식과 익명 클래스 사용 시의 실질적인 차이는 무엇이 있을까? 
• 불변객체에 관한 성능 문제는 무엇이 있을까?
• 테스트용 DB나 인메모리 DB에는 어떤 이슈가 있을까?
• 좋은 프로그래머란 어떤 것일까라는 질문에 다른 프로그래머와 협업할 수 있도록 다른 사람의 관점에서 내 코드를 볼 수 있는 공감능력이 몸에 익은 사람이라고 답변했고, 그런 프로그래머가 되기 위해서 어떤 노력을 하고 있나?라는 질문에, 코드리뷰 스터디를 통해서 다른 사람들이 내 코드를 보며 준 피드백을 반영한 이야기를 했는데, 구체적인 노력에 관한 사례를 들지 못했다. 내가 몸에 익은 능력은 무엇일까?에 대한 구체적인 예시를 하나 생각해 두면 좋을 것 같다.