이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
동료들과 아이디어를 공유하고 문제를 해결한 경험은 팀 프로젝트에서 기술 스택 선정 과정에서였습니다. 각자 선호하는 기술이 달라 합의가 어려웠는데, 의견을 단순히 말로 주고받는 대신 비교 표를 만들어 기준을 공유하는 방식을 제안했습니다. 각 항목에 학습 곡선, 생태계 성숙도, 팀 경험 여부를 넣었고, 이 기준 자체에 먼저 합의하자 선택 결과에 대한 이의가 줄었습니다.
짧은 스파이크 개발로 후보 기술을 각자 이틀씩 써보고 느낀 점을 공유하는 방식도 효과적이었는데, 말로 설명하기 어려운 부분이 코드로 드러났습니다. 최종 결정 과정에서 소수 의견도 문서에 기록해두니, 나중에 비슷한 논의가 생겼을 때 다시 꺼내볼 수 있었습니다. 소통은 의견보다 기준을 먼저 맞추는 것이 합의를 빠르게 만드는 결임을 배웠습니다.
팀 프로젝트에서 기능 명세를 구두로만 공유하고 개발했는데, 나중에 합치자 제가 구현한 화면과 팀원이 기대한 화면이 전혀 달랐습니다. 각자 같은 말을 다르게 이해한 것이었습니다. 그 기능을 사흘 만에 다시 만들어야 했고, 팀 모두가 시간을 낭비했습니다. 이후에는 기능 구현을 시작하기 전에 와이어프레임이나 흐름도를 먼저 그리고, 팀원 전원이 댓글로 확인하는 과정을 넣었습니다. 처음에는 이 과정이 시간 낭비처럼 느껴졌는데, 수정 횟수가 눈에 띄게 줄었습니다. 같은 단어가 사람마다 다른 그림을 만들 수 있다는 걸 이 경험으로 배웠고, 말 대신 그림으로 합의하는 방식이 더 빠른 경우가 많다는 것도 알게 됐습니다.
팀 프로젝트에서 처음 같이 일하는 팀원과 코드 리뷰를 주고받았는데, 제가 짠 조건문 로직에 "이 경우 예외가 발생하지 않나요?"라는 댓글이 달렸습니다. 처음에는 문제없다고 생각해서 "그냥 보내도 됩니다"라고 답했는데, 다시 따라가 보니 엣지 케이스에서 실제로 NullPointerException이 터질 수 있는 코드였습니다. 같이 일한 적 없는 팀원이어서 더 꼼꼼히 봤던 것 같다고 나중에 말해줬습니다. 이 경험으로 오래 같이 일한 팀원과는 서로의 코드를 과신하기 쉽다는 걸 알게 됐고, 새로운 시각이 버그를 잡는 데 얼마나 효과적인지 직접 느꼈습니다. 이후 코드 리뷰 요청 시 질문 형식으로 의견을 남기는 방식을 배워 저도 적용하게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 111퍼센트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.