📸 기록 사진
📜 진행 기록
- 자기소개
- 멘토님의 썰
- 블루시그넘 입사 + 그리고 요기요 실시간 합격👍
- 최종적으로 블루시그넘 입사 확정
- 면접 후기
- 블루시그넘: 커피챗 → 1차: 과제 전형 → 2차: 과제 리뷰(직무 인터뷰) + 컬쳐핏 인터뷰
- 과제 리뷰 때 에러 상속에 대한 질문을 들었음
- 요기요: 1차 코딩 테스트 → 2차 직무 인터뷰 → 3차 컬쳐핏 인터뷰
- HTTP에 대한 질문이 프론트, 백엔드 가릴 것 없이 꼭 나온다!
❓QnA
팀 프로젝트 초기 설정은 무엇을 중심으로 하는 게 좋을까요? 작업을 팀원과 수행할 때 다른 구성원이 작업을 진행하는 동안 그 작업을 이어서 진행하지 못하는 경우가 생겨서 이를 해결하고 싶습니다.
A) 어떤 프로젝트를 할 것인지 정하는 게 가장 중요하다고 생각합니다. 롤을 셋팅하고 템플릿을 만드는 건 어떤 프로젝트를 할지 명확하게 정의가 되고 구성원끼리 서로의 목표와 가치가 공유된 이후에 하는 과정입니다.
프로젝트를 셋팅할 때 개인의 목표와 공동의 목표를 잘 조율하는 것이 중요합니다. 구성원 모두가 만족할 수 있는 공동의 목표 하에 가치가 정립되고 프로젝트 방향이 정해졌다면, 그때부터 개발자로서 프로젝트를 진행하기 위한 셋팅을 진행하는 겁니다. 셋팅 과정에서 자동화 도구를 활용하는 것도 좋은 선택입니다.
또한 협업 규칙, 코드 스타일, 협업 도구, PR 규칙, 작업 분배 방식 등 프로젝트 초기 셋팅 과정은 구성원 간 협의를 통해 이루어지기 때문에 정답이 없습니다. 예를 들어, 구성원에게 작업을 분배할 때, 구성원마다 잘할 수 있는 작업이 모두 다를 수 있기 때문에 이런 부분을 고려하여 작업을 분배하는 것이 좋겠죠.
사실 작업을 나누는 건 조금 어려운 과정이기도 한데요. 일단 작업을 분해하는 게 먼저가 되어야 합니다. 무엇을 만들지 정하고, 이 서비스를 위해 어떤 기능을 구현해야 하는지 작업을 잘게 쪼개야 합니다. 문제를 정의하고 처리하는 문제해결능력이 이 과정에서 활용될 수 있습니다. 문제가 정의되었으면, 문제를 분해할 줄 알아야 하는데 Top-down이나 bottom-up 등 접근 방법에 따라 문제를 분해할 수 있을 것입니다.
문제를 분해할 때 유의해야 할 점은 문제를 직렬적, 의존적으로 분해하면 안된다는 점입니다. 어떤 사람의 작업이 완료되어야 다른 구성원이 작업을 이어서 할 수 있는 구조보다 어떤 사람이 작업을 진행하는 동안 다른 구성원이 또 다른 작업을 수행할 수 있는 구조로 병렬적으로 문제를 처리하고 작업을 수행할 수 있는 구조여야 합니다. 보통 충분히 구체적이지 않거나, 추상화 수준이 일치하지 않는 경우에 작업 진행이 의존적으로 이루어지는 경우가 많습니다.
프로젝트 일정 관리는 어떻게 해야 하는지 궁금합니다.
A) 제가 프리랜서로 활동했을 때는 예상 기간의 2배를 프로젝트 기간으로 정했습니다.(대부분 맞아 떨어지더라구요.)
보통 제 경험 상 처음 예상했던 기간은 프로젝트 진행이 굉장히 낙관적이라고 가정해서 정해진 기간이기 때문에, 다른 요인에 따른 영향을 고려해서 기간을 2배 정도 넉넉하게 잡는 것이 딱 좋았습니다.
개인적으로 저는 MVP(최소 기능 제품)로 프로젝트의 핵심 기능을 압축한 결과물을 먼저 만든 다음에, 점차 확장시켜나가는 것을 선호하는 편입니다. 처음부터 너무 크게 잡고 진행하면 기간이 지체가 되더라구요.
사실 소프트웨어 공학적으로 일정, 비용을 산출하는 방법론이 있긴 하지만, 실제 매 순간 프로젝트에서 적용하기에는 과한 면이 있죠. 쉽게 예상 기간의 2배로 정하면 보통의 프로세스는 기간 안에 진행이 됩니다.(경험 상 4배까지 딜레이 되는 경우도 있긴 했어요)
함수형 프로그래밍에서 함수를 연속적으로 호출하는 방법이 어떤 개념인가요..?
A) 아래 링크를 참고해보시면 좋을 것 같아요!
추가적으로 이것도 확인해보세요!
스타트업 회사를 고르는 기준, 들어가기 전에 고려해야 하는 사항은 무엇이 있을까요?
A) 본인이 정말 관심 있는 도메인인지가 가장 중요합니다. 다음으로는 현실적으로 처우나 복지가 어떠한지 중요하겠죠. 그리고 마지막으로 회사의 도메인이 시장에서 어떠한 위치인지, 전망이 어떠한지 알고 있으면 좋습니다. 또한 내부적으로 회사가 얼마나 투자 받았는지, 비즈니스가 어떻게 운영되고 있는지도 중요하죠. (The VC, 크래딧잡, 사람인 등 최대한 기업에 대해 조사해보세요!)
무엇보다 본인의 선택에 책임을 지기만 하면 됩니다. 이런 점을 잘 고려하셔서 좋은 방향으로 선택하시면 좋겠습니다.
회사와 딜(?)할 수 있는 꿀팁
A) 회사에 보여줄 것이 많고 나를 부각할 수 있는 셀링 포인트가 많을수록 회사와 딜하기 좋습니다.(ㅎㅎㅎ)
나보다 잘하는 사람의 코드 리뷰 혹은 신입으로 들어갔을 때 코드 리뷰를 어떻게 하는 게 좋을지 궁금합니다.
A) 일단 코드 리뷰는 일방향 소통이 아니라 양방향 소통입니다. 일방적으로 남기기만 하는 건 정말 제한적이에요. 코드를 보고 궁금한 점이나 배운 점을 리뷰로 남기거나 상대가 남긴 질문에 답변을 달아주는 것이 바람직한 코드 리뷰의 예시입니다! 더 좋은 코드를 위한 방법에 대해서도 코드 리뷰를 통해 같이 토론을 하는 것도 좋겠죠. 이렇게 양방향 커뮤니케이션을 통해 서로 더 좋은 코드, 더 나은 서비스를 만들어가는 과정이 코드 리뷰라고 생각하시면 좋습니다.