[기술 면접] Tech Interview - Backend [02-Communication]

개인적으로 인성 면접을 준비하면서 작성한 글입니다.

저의 개인적인 경험 및 지인들을 통해 이러한 질문들도 있었다를 참고해서 작성했습니다.

혹시, 추가될만한 질문 내용이 있으면 댓글에 작성해 주시면 감사하겠습니다.. :) 

 

728x90

애자일이란 무엇인가요?

애자일은 반복 작업을 통해 실제 작동이 가능한 소프트웨어를 개발하여 지속적으로 제공하기 위한 소프트웨어 개발 방식입니다. 그리고 애자일의 주요 원칙은 상호작용, 동작하는 소프트웨어, 고객과의 협력, 그리고 변화에 대한 대응을 중시합니다.

애자일 개발에서 어떤 방법들이 주로 사용되나요?

우선, 짧은 개발 주기를 가지고, 테스트 주도적인 개발, 지속적인 통합에 초점을 두는 익스트림 프로그래밍 방식과 작업 흐름을 시각화하여 시스템의 한계를 식별하여 작업량을 조절 및 지속적으로 개선하는 칸반 방식 그리고 프로젝트를 일정 주기로 나누어서 각 주기마다 공통된 목표를 달성하기 위해 일정 조율 및 작업을 진행하는 스크럼 방식이 있습니다.

애자일 회고 기법을 도입하신 이유와 그 결과에 대해 설명해 주실 수 있나요?

우선, 솔직히 말씀을 드리면 현업에서 자주 사용하는 전략이 어떤 게 있을까 찾아보던 중 애자일 회고 기법을 찾았습니다. 최대한 실무와 비슷한 환경을 조성하고 싶기도 하였고, 애자일이 짧은 개발 주기를 가지고 일정 주기로 나누어서 공통된 목표를 달성한다는 게 가장 와닿았고 사용자, 팀원들과의 소통과 피드백을 통해 요구사항을 명확하게 하여 변경이나 새로운 우선순위를 빠르게 설정해 대응하여 만족도를 높일 수 있었습니다.

그렇게 MVP 단계 및 스프린트 이후에 팀원들과의 과정과 결과에 대해 공유하고 얘기하며, 다음 스프린트를 점진적으로 개선했습니다. 그래서 전보다 나은 스프린트를 진행하여 프로젝트 퀄리티 및 개발 생산성을 향상 시켰습니다.

Jira Confluence를 사용하여 회의록 및 회고록 템플릿을 작성하였다고 하셨는데, 이를 통해 팀원 간의 커뮤니케이션을 어떻게 개선했나요?

각 회의의 핵심 사항과 액션 아이템을 기록함으로써, 모든 팀원이 동일한 정보를 공유하고 이해할 수 있게 하였습니다.

그리고 이슈가 발생하면 당일 공유를 하기 때문에 빠른 조치가 가능했으며, 지속적으로 좋은 방향성을 가질 수 있게 해 줬습니다.

코드 리뷰 과정에서 다른 사람의 의견을 어떻게 수용하나요?

모든 개발자분들에게 배울 점은 있다고 생각합니다.

개발자마다 구현하는 관점과 코딩 스타일이 다르기 때문에 배울 점은 있다고 생각합니다.

그렇기 때문에 코드 리뷰 과정에서 다른 사람의 의견을 포함해 회의 때 각 장단점을 얘기해서 방향성을 다시 잡습니다.

개발자로서 비기술적인 스킬 중에서 가장 중요하다고 생각하는 것은 무엇인가요? 그 이유는 뭔가요?

저는 커뮤니케이션이라고 생각합니다. 평범한 개발자분들을 생각하면 스킬적인 측면에서 다들 부족한 게 없을 거라고 생각합니다.

다들 비슷한 실력과 스킬을 겸비한 훌륭한 개발자들이지만, 각자의 생각이 다르기 때문에 정책 또는 이슈 발생 시 의견 차이가 발생할 것 같습니다. 그래서 이런 의견 차이를 잘 조율하기 위해 커뮤니케이션을 잘하는 것이 가장 중요하다고 생각합니다.

개발팀과 비개발팀 간에 커뮤니케이션에서 가장 어려운 점은 무엇이라고 생각하시나요?

가장 어려운 점은 각 팀별 전문 용어와 기술에 대한 이해도의 차이라고 생각합니다.

개발팀은 코드, 알고리즘, 아키텍처 등 기술적 지식을 갖고 있지만, 비개발팀은 이러한 주제애 대해 지식이 없을 수 있습니다. 물론, 개발팀도 비개발팀의 전문 지식이 부족할 수 있어서 어려울 수 있다고 생각합니다.

이를 극복하기 위한 방법은 모든 사람이 이해할 수 있게 기술적 명칭을 단순화하여 사용하는 것입니다.

개발팀과 비개발팀 간의 커뮤니케이션은 서로의 전문성을 이해하고 존중하는 게 핵심이라고 생각하고 이를 통해, 양 팀은 더 나은 결과를 달성할 수 있을 거라 생각합니다.

프로젝트 중 의견 차이가 발생했을 때 어떻게 해결했나요?

프로젝트 중에 의견 차이에 대한 내용은 보통 스크럼 또는 회의 때 발생한다고 생각합니다.

우선, 회의 때 나오는 의견들은 보통 서기나 팀원분들이 작성을 해주시다 보니 결정하기 전에 모든 의견을 종합해서 문서화하여 정리합니다. 저는 팀원들의 의견 모두 정답이라고 생각합니다. 의견이 다를 뿐이지 틀린 건 아니니깐요. 그래서 우선 이 부분을 먼저 강조했습니다. 그 후에 의견이 종합적으로 정리가 되면 이제 하나하나 어떤 게 더 사용자적인 측면에서 더 사용성이 올라갈 수 있을지? 그 문제가 아니라면 비용적인 문제에서 어떤 게 더 좋은지에 대한 판단을 했습니다. 마지막으로 사용자, 사용성을 위한 서비스에 초점을 맞춰서 최선의 선택을 하였습니다.

프로젝트에서 팀 리더로서의 역할에 대해 설명해 주실 수 있나요? 특히 팀원들과의 커뮤니케이션에서 어떠한 역할을 하셨는지 구체적으로 알려주세요.

팀원 간에 브릿지 역할을 했고, 모든 팀원들이 프로젝트의 목표를 이해하고, 효율적으로 수행할 수 있게 도움을 주었습니다.

각 팀원들의 의견을 듣고 종합하여 의사결정을 내리고, 일정 관리 및 진행 상황 파악도 하였습니다.

스크럼, 회의, 회고 템플릿도 개인적으로 작성하여 의견 종합할 때 더 원활하게 의사결정을 할 수 있게 노력하였습니다.

모든 팀원이 동의하지 않는 결정을 내려야 할 때, 어떻게 할 건가요?

우선, 모든 팀원이 동의하지 않는다라고 의견이 모인다면 우선 제 의견에 대해 한번 더 생각해 볼 것 같습니다.

그럼에도 불구하고, 제 의견이 좀 좋은 의견이라고 생각이 든다면 뭔가 전달이 잘못됐나?라고 의구심을 가질 것 같습니다. 그래서 한번 내용정리를 한 후에 동의를 구할 것 같습니다. 하지만 그래도 모두가 동의하지 않는다고 한다면 왜 동의하지 않는지에 대한 의견을 문서로 정리할 것 같아요.

협업 중 생기는 문제를 해결하기 위해 어떤 전략을 사용했나요?

제가 아직은 부족해서 어떤 전략이라고는 정확히 설명드리기는 어려울 것 같습니다. 그래도 제 경험 상 어떻게 해결했는지 설명해 보겠습니다. 우선 실질적인 문제의 원인을 파악하고, 가능한 해결책을 찾기 위해 팀원들과 논의하고, 각각의 의견을 존중했습니다. 마지막으로, 해결책을 실행하고 이를 스프린트 후 회의 시 잘 해결되었는지 확인합니다.

여러 프로젝트를 통해 얻은 커뮤니케이션과 협업에 대한 가장 중요한 교훈은 무엇인가요?

모든 팀원의 각자의 생각과 의견을 자유롭게 공유할 수 있는 환경을 조성하는 게 중요하다고 생각했습니다. 그래서 스크럼과 회의를 시작하기 전에 항상 아이스 브레이킹을 하기 위해 온도 체크를 진행했습니다. 이를 통해, 회의 전 분위기를 유연하게 만들어 원활하게 진행할 수 있는 환경을 조성하였습니다.

직접 운영한 스터디는 어떤 방식으로 진행했는지, 그리고 어떤 결과를 가져왔나요?

다양한 개발자들이 모여서 진행하다 보니 의견 충돌이 발생하는 건 자연스러웠습니다.  이를 해결하기 위해, 매 스터디 시 대표자를 사다리 타기를 통해 랜덤으로 정했습니다. 그렇게 해서 참여자들이 매번 대표자 스타일대로 스터디를 진행하며 다양한 스타일도 배울 수 있고, 존중할 수 있는 방법을 배웠습니다.

트러블 슈팅을 해본 경험이 있나요?

백앤드 개발을 하면서 막혔던 부분과 해결 과정, 그리고 그 과정을 통해 깊이 알게 된 개념을 한 가지 정도 풀어서 설명할 수 있으면 좋습니다.