😥 면접관이 풀어주는 안타까운 면접 순간 시리즈 #1: 개념 A를 "충분히" 안다고 착각하는 경우

기술면접을 들어가다보면 개념 A를 설명해달라고 했을때 A의 정의 그리고 A에 대한 자신의 의견만 설명하고 끝나는 경우가 자주 있습니다. 제 개인적인 체감으로는 개념을 물어보는 질문 10번 중 4번 정도였습니다. 조사 통계는 아니에요. 이건 추측해보건데, 크게 두가지로 나뉘는 것 같아요. 첫번째는 A를 들어봤거나 적당히 아는데 추가적인 설명을 하기가 어려워서 여기까지만 답변하는 경우, 두번째는 첫번째와 아는 정도는 비슷한데 그 이상의 답변을 해야하는지 메타인지가 없는 경우예요.

두 케이스가 A에 대해 아는 정도는 비슷하지만 A의 정의 외에, A에 대한 입체적인 이해를 보여줄 수 있는 추가적인 답변을 하지 못한다는 점에서 비슷해요. 후자의 경우는 면접자 본인이 A를 "충분히" 안다고 착각하는 경우가 꽤 많은 것 같습니다.

🚩 면접에서 이런 질문을 받았을때 왜 정의만으론 부족할까?

당연히 A가 뭔지 물어봤으니 A의 정의에 대해 답변하는게 쉽고 그 자체로는 문제가 되지 않아요! 하지만 현업에서는 정의를 아는 것만으론 충분하지 않아요. 면접관 입장에서는 아래와 같이 A를 둘러싼 현실적인 것들을 고민해보고 문제를 직접 밟아보고 해결해본 흔적이 있는지를 볼 수 밖에 없죠.

• A가 실제 환경에서 어떻게 쓰이는지
• A가 현업 혹은 생태계에서 왜 선택받고 있는지, 개발자들에게 어떤 니즈를 충족해주길래 쓰이는지
• A의 장점을 어떻게 활용할 수 있고 단점은 무엇으로 보완할 수 있는지
• A의 알려진 문제가 무엇이고 어떤 경우에 엣지케이스가 생기는지, 그 해결 방법은 무엇인지
• 그래서 면접자 본인은 A를 어떻게 평가하고, 추가적으로 이어질만한 논제가 무엇이 있는지

이것들까지 함께 설명하는 사람을 보면 면접관은 "아 이 사람은 정말 A를 입체적으로 이해하고 체득했네. 우리 회사에 와서도 이런 경험을 하고 팀에 전파하며 경험을 자산화하겠구나. 뽑아야겠다" 이런 긍정적인 인상을 받을 수 있어요. 다만 실제 채용은 여러 평가 요소를 함께 보고 결정합니다.

결국 Software Engineering 업계에서는 네이티브, 백엔드, 프론트엔드, 인프라 영역에 관계없이 시장 상황과 비즈니스 요구사항은 오늘내일이 다르게 빠르게 변화하고, 그 변화에 적응하기 위해 기술도 변화하기 때문에 A의 개념을 물어봤을때 이런 "현실적인" 변화 가능성까지 염두에 둘 수 밖에 없는거죠.

🔍 깊이 있는 이해를 드러내는 5가지 체크리스트

이런 이유로 면접을 앞둔 면접자분들이 꼭 이 체크리스트를 검토하면 좋을 것 같아요.

• 사용 맥락: A를 어떤 환경에서, 무슨 이유로 왜 택했나요?
• 선택 근거: 대안 B/C와 비교했을 때 A가 충족한 핵심 니즈는?
• 장단점 활용: 장점을 극대화한 실전 팁, 단점을 커버하는 방법은?
• 알려진 리스크: 엣지케이스를 어떤 상황에서 겪었고 해결을 어떻게 했는지
• 개인적 평가 & 다음 논제: "A가 단점은 있지만 B라는 큰 문제를 대부분의 케이스에서 해결해주기 때문에 꼭 써야하는 패턴/기술 이라고 생각하고, 단점에 대해서는 앞으로 C 혹은 D로 확장해서 생각해보려고 해요."

최소한 이 다섯가지를 스토리 형태로 풀어서 설명하면 A에 대한 이해를 구체적으로 보여주는 데 도움이 됩니다. 질문의 범위에 맞춰 답하고, 실제 경험과 가정한 설계를 구분하세요. 앞으로는 A를 물어보는 질문을 받았을때 A 정의뿐 아니라 A를 둘러싼 위의 다섯가지 질문을 미리 준비해보는 것이 많은 도움이 되리라 생각합니다! 이 A는 여러분의 직군에 따라 천차만별이겠죠?

참고 링크

• techinterviewhandbook

자주 묻는 질문

정의를 물으면 무조건 길게 답해야 하나요?

아닙니다. 먼저 짧게 정의한 뒤 면접관이 원하는 깊이를 확인하세요. 맥락과 사례를 추가하되 질문과 무관한 설명은 줄이는 편이 좋습니다.

직접 겪지 않은 문제도 경험처럼 말해도 되나요?

직접 경험과 공부한 사례를 구분하세요. 실제로 하지 않은 일을 만들기보다 가정, 선택 이유와 확인 방법을 설명하는 편이 낫습니다.