모르는 질문을 받으면 먼저 무엇을 묻는지 확인하세요. 질문을 이해했지만 답을 모르는 경우에는 아는 범위와 모르는 범위를 나누고, 어떻게 확인할지 설명할 수 있습니다. 아는 척하며 수치를 만들면 이어지는 질문에서 사실관계가 더 흔들립니다.
질문의 범위가 넓을 때는 좁혀서 확인하기
면접 연습용 표현
말씀하신 성능 문제는 응답 시간이 길어진 경우를 의미하실까요, 아니면 같은 시간에 처리할 수 있는 요청 수가 부족한 상황을 의미하실까요? 우선 응답 지연을 기준으로 설명드려도 될까요?
이미 분명한 질문을 반복해서 되묻는 것은 피하세요. 필요한 가정 한 가지를 확인한 뒤 답변으로 돌아옵니다. 조건을 확인하지 못하면 “우선 이런 상황을 가정하고 말씀드리겠습니다”라고 범위를 밝힐 수 있습니다.
기술 용어를 정확히 모를 때
가상 지원자의 답변
그 알고리즘을 직접 구현한 경험은 없어서 세부 동작을 정확하게 설명드리기는 어렵습니다. 다만 질문하신 문제는 여러 노드가 같은 상태에 합의해야 하는 상황으로 이해했습니다. 제가 아는 방식과 차이를 확인하려면 먼저 장애를 가정하는 범위와 어떤 조건에서 합의가 보장되는지 공식 문서에서 확인하겠습니다.
관련 없는 지식을 길게 펼치지 마세요. 실제로 알고 있는 연결점이 있을 때만 설명하고, 전혀 모르면 “정확히 알지 못합니다”라고 짧게 인정한 뒤 학습할 지점을 정리합니다.
해본 적 없는 경험을 물을 때
가상 지원자의 답변
상용 서비스의 장애 대응을 직접 맡아본 적은 없습니다. 가장 가까운 경험은 프로젝트 테스트에서 주문 저장 실패를 재현하고 데이터가 원래 상태로 돌아오는지 확인한 일입니다. 실제 장애에서는 사용자 영향과 복구 우선순위를 판단하는 일이 추가된다고 생각하며, 그 부분은 아직 경험을 쌓아야 합니다.
경험이 없다는 사실을 밝힌 뒤 가장 가까운 경험을 연결하되, 둘의 규모와 책임이 같다고 말하지 않습니다.
생각할 시간이 필요할 때 쓸 문장
“잠시 생각을 정리하고 말씀드려도 될까요?”라고 말한 뒤 결론과 근거를 짧게 메모합니다. 침묵을 피하려고 같은 서론을 반복하기보다 첫 문장에 답을 놓는 데 시간을 쓰세요.
면접이 끝나면 질문을 기억나는 그대로 적고, 모른 이유를 ‘개념 부족·경험 부족·질문 오해’로 나눠 보세요. 다음 준비 행동이 달라집니다. 개념은 공식 자료로 확인하고, 경험 부족은 부풀리는 대신 관련 경험의 한계를 설명하는 연습을 합니다.