면접 질문지를 만들어 두었는데도 면접관마다 묻는 질문과 남기는 기록이 다르면, 지원자 답변을 나란히 놓고 비교하기 어렵습니다. 면접이 끝나고 면접관 세 명의 기록을 모아 보면 한 사람은 프로젝트 이력을, 한 사람은 성격에 대한 인상을, 한 사람은 연봉 이야기를 적어 둔 경우가 있습니다.
이 글에서는 경력직 백엔드 개발자 채용을 예시로, 면접에서 확인할 역량 3개를 고르고 이를 공통 질문과 후속 질문으로 바꾼 뒤, 60분 면접에서 바로 쓸 수 있는 질문지 한 장으로 정리해 보겠습니다.
구현 능력 자체를 확인하는 코딩 테스트나 기술 과제는 이 글의 범위가 아닙니다. 여기서 만드는 것은 지원자가 과거에 어떻게 판단하고 협업했는지를 확인하는 60분 면접의 질문지입니다. 구조화 면접의 뜻과 우리 회사 면접 진단이 먼저 필요하다면 1편 「우리 회사 면접 진단 12문항: 어디부터 구조화할까요?」에서 확인하실 수 있습니다.
📌
한눈에 보는 핵심
면접 질문 준비는 좋은 예시를 베끼는 일이 아니라 무엇을 확인할지 정하는 일에서 시작합니다. 확인할 것을 정하지 않고 고른 질문은 답변이 돌아와도 무엇을 봐야 할지 알 수 없습니다.
순서는 역량을 먼저 고르고 그다음에 질문으로 바꾸는 것입니다. 이 순서가 뒤집히면 질문지는 길어지는데 판단은 그대로입니다.
역량은 이름으로 정해지지 않습니다. 「잘하는 사람이 실제로 한 행동」을 한 문장으로 쓸 수 있을 때부터 질문으로 바꿀 수 있습니다.
좋은 질문의 조건은 세 가지입니다. 과거에 실제로 한 일을 묻고, 답이 정해져 있지 않고, 답변에서 확인할 사실이 나옵니다.
역량 3개로 질문 6개를 만들고 그중 3개를 공통 질문으로 골라 한 장에 정리하면, 그대로 면접장에 들고 들어갈 수 있습니다.
좋은 면접 질문과 나쁜 면접 질문은 무엇이 다른가요?
질문의 좋고 나쁨은 문장이 세련됐는지가 아니라, 그 질문에 돌아온 답에서 확인할 사실이 있는지로 갈립니다.
예시 포지션: 경력직 백엔드 개발자
아래는 경력직 백엔드 개발자 면접에서 질문의 모양을 비교한 예시입니다. 다음 섹션에서는 이 포지션의 역량을 고르고, 실제 질문지까지 완성합니다.
기준 | 나쁜 문안 | 좋은 문안 |
|---|
1. 과거에 실제로 한 일을 묻는가 | 좋은 코드란 무엇이라고 생각하시나요? | 가장 최근 직장에서 원인을 찾기 어려웠던 장애 하나를 말씀해 주세요. 그 장애를 확인하고 가장 먼저 하신 일은 무엇이었나요? |
2. 답이 정해져 있지 않은가 | 기술 문제를 주도적으로 해결하시는 편인가요? | 아무도 요청하지 않았는데 코드나 배포 절차를 스스로 손봤던 최근 사례를 말씀해 주세요. 무엇을 보고 그 일이 필요하다고 판단하셨나요? |
3. 답변에서 확인할 사실이 나오는가 | 다른 팀과 협업해 본 경험이 있으세요? | 구현 방식을 두고 다른 개발자나 기획자와 의견이 갈렸던 최근 사례에서, 본인은 의견을 맞추기 위해 무엇을 하셨나요? |
왜 구분이 필요한가. 나쁜 문안 세 개의 공통점은 지원자의 의견이나 자기 평가를 묻는다는 것입니다. 의견은 누구나 정답에 가깝게 말할 수 있습니다. 「주도적으로 해결하는 편인가요」라고 물으면 대부분 그렇다고 답하고, 그 답만으로는 지원자 사이에 차이가 생기지 않습니다.
구분하면 실무에서 무엇이 달라지는가. 기준 세 개를 통과한 질문은 답변이 길어져도 면접관이 어디를 더 확인해야 할지 적을 수 있습니다. 장애를 확인하고 가장 먼저 한 일을 물으면 판단의 순서가 그 자리에서 드러납니다.
기준끼리의 관계. 3번이 마지막 관문입니다. 과거 행동을 물었고 원하는 답을 유도하지도 않았는데 「예, 있습니다」로 끝나는 질문이 있습니다. 그때는 질문이 닫혀 있는 것이라 열어야 합니다. 「경험이 있으세요」를 「그 경험에서 본인은 무엇을 하셨나요」로 바꾸는 것이 여는 일입니다.
기준을 세웠으니 남은 질문은 ‘무엇에 대해 물을 것인가’입니다.
이 포지션에서 확인할 역량은 어떻게 고르나요?
질문을 고르기 전에 이 포지션에서 무엇을 확인할지부터 정해야 합니다. 역량 후보는 다음 세 곳에서 나옵니다.
채용 공고에 적힌 업무 대신, 그 자리에 앉은 사람이 실제로 시간을 가장 많이 쓰는 일 세 가지.
같은 직무에서 잘하는 사람과 보통인 사람이 실제로 다르게 하는 행동. 「어떤 사람이 좋은가」가 아니라 「최근에 누가 무엇을 다르게 해서 결과가 달라졌는가」로 묻습니다.
지난 채용에서 잘 맞지 않았던 경우, 무엇을 미리 확인하지 못했는지.
후보를 뽑았다면 각 후보마다 「잘하는 사람이 실제로 한 행동」을 한 문장으로 적습니다. 이 문장이 나오지 않으면 아직 질문으로 만들 수 있는 역량이 아닙니다.
예시 포지션: 경력직 백엔드 개발자
역량 | 잘하는 사람이 실제로 한 행동 |
|---|
이상 징후를 먼저 알아채기 | 지표나 로그의 변화를 먼저 알아채고, 사용자 신고가 들어오기 전에 원인 범위를 좁힌다 |
권한 없이 조율하기 | 일정이나 요구사항이 충돌할 때 기술 부채와 사용자 영향을 정리해 우선순위를 다시 합의한다 |
반복 문제를 구조로 바꾸기 | 같은 운영 요청이 반복되면 매번 처리하는 대신 자동화하거나 문서와 도구로 만들어 다른 사람도 쓰게 한다 |
세 문장의 공통점은 주어가 사람이고 서술어가 관찰 가능한 동작이라는 것입니다. 「꼼꼼하다」나 「분석적이다」처럼 상태를 적으면 그다음 질문이 만들어지지 않습니다. 문장이 잘 안 나올 때의 요령은 하나입니다. 그 역량을 잘하는 동료가 지난달에 한 일 하나를 떠올리고 그것을 그대로 적으면 됩니다.
후보가 여럿 나왔다면 다음 세 가지 규칙으로 3개까지 좁힙니다.
역량 후보 | 판정 | 이유 |
|---|
이상 징후를 먼저 알아채기 | 채택 | 성과가 갈리는 지점이고 과거 행동으로 확인할 수 있습니다 |
권한 없이 조율하기 | 채택 | 지난 채용에서 어긋났던 지점입니다 |
반복 문제를 구조로 바꾸기 | 채택 | 잘하는 사람과 보통인 사람의 실제 차이입니다 |
사내 시스템·도메인 지식 | 제외 | 입사 후 한두 달 학습으로 메워집니다 |
코드 품질과 설계 능력 | 제외 | 과제나 기존 결과물로 확인하는 편이 정확합니다 |
동종 업계 서비스 경험 | 제외 | 서류에서 이미 확인됩니다 |
꼼꼼함 | 제외 | 행동 문장이 나오지 않아 질문으로 바꿀 수 없습니다 |
제외한 네 개가 중요하지 않은 역량이라서 빠진 것이 아닙니다. 면접에서 확인할 수 없어서 빠졌습니다. 도메인 지식과 업계 경험은 확인하는 위치가 다르고, 코드 품질은 결과물을 봐야 알며, 꼼꼼함은 행동 문장이 나오지 않습니다.
3개로 줄이는 데에는 시간 문제도 있습니다. 역량 하나를 답변과 후속 질문까지 들으며 제대로 확인하려면 면접 시간의 상당 부분이 듭니다. 역량을 다섯 개, 여섯 개로 늘리면 질문은 모두 던지지만 어느 것도 끝까지 확인하지 못합니다.
조직의 가치관이나 일하는 방식이 맞는지는 직무 역량과 다른 방법으로 확인합니다. 그 기준을 세우는 방법은 컬처핏 평가 글에서 따로 다룹니다.
역량을 행동 기반 질문으로 어떻게 바꾸나요?
역량을 질문으로 바꾸는 일은 문장 세 조각을 조립하는 작업입니다.
참고 · 행동 기반 질문(BEI)
과거에 실제로 한 일을 묻는 질문 방식입니다. 앞으로 어떻게 하겠느냐고 물으면 지원자가 아는 정답이 돌아오지만, 지난달에 무엇을 했느냐고 물으면 실제로 한 일이 돌아옵니다. 「문제가 생기면 어떻게 대응하시겠어요」와 「가장 최근에 맡았던 장애에서 가장 먼저 무엇을 하셨나요」의 차이입니다.
조립할 세 조각은 다음과 같습니다.
시점 한정. 「최근 1년 안에」, 「가장 최근 직장에서」처럼 시점을 좁힙니다. 열어 두면 지원자가 자신에게 가장 유리한 오래된 사례를 고릅니다.
상황 지정. 「협업했던 경험」이 아니라 「상대 팀의 우선순위가 아니었던 상황」처럼 확인하려는 조건을 문장에 넣습니다.
행동 요구. 한 일을 묻습니다. 「어떻게 하셨나요」로 닫습니다.
예시 포지션: 경력직 백엔드 개발자 / 역량 3개는 앞 섹션에서 고른 것
여기서 만드는 문안 6개가 마지막 질문지 한 장의 재료입니다.
역량 | 공통 질문 | 예비 질문 |
|---|
이상 징후 감지 | 최근 1년 안에 크게 번질 뻔했던 장애나 성능 문제를 맡았던 경험을 말씀해 주세요. 문제가 커지겠다고 느낀 뒤 가장 먼저 무엇을 하셨나요? | 처음에는 대수롭지 않게 보셨는데 나중에 크게 번진 문제가 있었나요? 그때 본인이 놓친 것은 무엇이었나요? |
권한 없이 조율 | 다른 팀의 결정이나 작업이 꼭 필요한데 그 팀의 우선순위가 아니었던 상황을 말씀해 주세요. 그때 어떤 순서로 움직이셨나요? | 요청이 거절되거나 계속 밀렸던 경험이 있나요? 그다음에 무엇을 하셨나요? |
반복 문제 구조화 | 반복되는 운영 요청이나 수작업을 줄이려고 처리 방식을 바꿔 본 경험을 말씀해 주세요. 무엇을 어떻게 바꾸셨나요? | 본인이 만든 도구나 문서를 다른 사람도 쓰게 된 경험이 있나요? 만들기 전에 무엇을 확인하셨나요? |
질문마다 준비해 둘 후속 질문
이상 징후 감지, 공통 질문: 무엇을 보고 그렇게 판단하셨나요? / 그 뒤에 그 문제는 다시 발생했나요?
이상 징후 감지, 예비 질문: 확인했던 신호와 확인하지 않았던 신호는 각각 무엇이었나요? / 그 뒤로 무엇을 바꾸셨나요?
권한 없이 조율, 공통 질문: 상대 팀에는 무엇을 근거로 말씀하셨나요? / 결과는 어떻게 됐나요?
권한 없이 조율, 예비 질문: 포기한 시점이 있었다면 언제였나요? / 다시 시도했다면 무엇을 바꿔서 하셨나요?
반복 문제 구조화, 공통 질문: 반복된다고 판단한 근거는 무엇이었나요? / 바꾼 뒤에 무엇이 달라졌나요?
반복 문제 구조화, 예비 질문: 실제로 쓰이는지는 어떻게 확인하셨나요? / 쓰이지 않은 것이 있다면 왜였나요?
역량마다 질문을 두 개씩 만든 이유가 있습니다. 각 역량에서 잘된 경험과 놓쳤거나 막힌 경험을 함께 받도록 구성했습니다. 잘된 이야기만 들으면 그 사람의 수준이 보이지 않고, 막힌 이야기만 들으면 무엇을 할 수 있는 사람인지 알 수 없습니다. 실제 면접에는 공통 질문만 쓰고, 예비 질문은 답변이 얕을 때나 같은 포지션을 반복해서 채용할 때 씁니다.
이 질문들을 후속 질문과 함께 한 장으로 정리한 완성본은 마지막 섹션에 있습니다.
「만약 배포 직후 오류율이 올라가면 어떻게 하시겠습니까」 같은 상황 가정 질문도 구조화 면접에서 씁니다. 다만 가정형은 그 사람이 아는 정답을 확인하는 데 가깝고, 과거 행동 질문은 실제로 한 일을 확인합니다. 신입처럼 관련 경험 자체가 없을 때는 가정형이 필요합니다. 경력직 면접에서는 과거 행동 질문을 기본으로 두고 가정형을 보조로 씁니다.
답변 내용이 부족하면 어떻게 더 물어볼까요?
후속 질문은 비어 있는 조각을 채우려고 하는 것입니다.
그래서 「좀 더 구체적으로 말씀해 주시겠어요」는 쓰지 않습니다. 무엇이 비었는지 지목하지 않으면 지원자는 같은 이야기를 더 길게 반복합니다.
참고 · STAR와 후속 질문(프로빙)
STAR는 답변을 상황, 본인 역할, 행동, 결과 네 조각으로 나눠 보는 방법입니다. 네 조각으로 나눠 두면 답변이 길어도 어디가 비었는지 지목할 수 있어서, 「좀 더 구체적으로 말씀해 주세요」 대신 「그래서 가장 먼저 하신 일이 무엇이었나요」라고 물을 수 있습니다. 이렇게 비어 있는 조각을 겨냥해 더 캐묻는 질문을 프로빙이라고 부르기도 합니다.
답변에서 비어 있는 것 | 후속 질문 문안 |
|---|
어떤 상황이었는지 | 서비스 이름이나 사내 정보는 말씀하지 않으셔도 됩니다. 어떤 문제였고 어느 범위까지 영향이 있었는지만 알려주실 수 있나요? |
본인이 맡은 몫 | 그 상황에서 본인이 맡은 몫은 어디까지였나요? |
첫 행동 | 그래서 가장 먼저 하신 일이 무엇이었나요? |
결과 | 그 뒤에 그 문제는 다시 발생했나요? |
네 가지를 순서대로 다 물어야 하는 것이 아닙니다. 비어 있는 것만 골라 묻습니다. 지원자는 대개 상황과 결과를 먼저 말합니다. 그때 필요한 것은 가운데 두 개, 본인이 맡은 몫과 첫 행동입니다.
답변 유형별 대응 문안
준비된 답이 그대로 나올 때 → 「그 방법을 쓰기로 정한 것이 언제였나요?」 준비된 답에는 실패한 시도가 빠져 있습니다.
추상적으로 답할 때(「소통이 중요하다고 생각해서 소통을 많이 했습니다」) → 「구체적으로 누구에게 무엇을 언제 말씀하셨나요?」
팀 성과와 본인 몫이 섞일 때(「저희 팀이 응답 속도를 개선했습니다」) → 「그중에 본인이 직접 하신 부분은 무엇인가요?」
네 조각 중 무엇이 비었는지 알아채는 것이 면접관 훈련의 핵심입니다. 그 훈련을 조직에 정착시키는 방법은 4편에서 다룹니다. 후속 질문을 몇 개까지 하고 시간이 부족할 때 무엇을 버릴지는 마지막 섹션의 질문지에서 정리합니다.
같은 역량을 경력 수준별로 어떻게 확인하나요?
같은 역량이라도 경력 수준에 따라 확인할 수 있는 경험의 크기가 다릅니다. 직무는 백엔드 개발자로 그대로 두고, 앞에서 고른 역량 가운데 「권한 없이 조율하기」를 세 가지 지원자 유형으로 변주해 보겠습니다.
예시 포지션: 백엔드 개발자
확인할 역량: 권한 없이 다른 팀과 조율하는 능력
지원자 유형 | 질문 문안 | 후속 질문 |
|---|
경력직 백엔드 개발자 | 다른 팀의 결정이나 작업이 꼭 필요했지만 그 팀의 우선순위가 아니었던 상황을 말씀해 주세요. | 그때 어떤 순서로 움직이셨나요? |
신입 지원자 | 팀 프로젝트나 인턴 업무에서 다른 사람의 작업이 필요했지만 일정이 맞지 않았던 경험을 말씀해 주세요. | 기다리는 것 말고 직접 해 보신 일이 있다면 순서대로 말씀해 주세요. |
개발팀 리더 | 팀 사이에서 반복해서 밀리던 요청의 처리 방식을 바꿔 본 경험을 말씀해 주세요. | 무엇을 바꾸셨고, 왜 그 방식을 선택하셨나요? |
경력 수준이 올라갈 때 질문에서 바뀌는 것은 세 가지입니다.
경험의 범위. 개인에서 팀으로, 팀에서 조직으로 넓어집니다.
책임의 크기. 참여에서 주도로, 주도에서 설계로 올라갑니다.
판단의 성격. 방법 선택에서 우선순위 결정으로, 다시 기준 수립으로 바뀝니다.
신입 채용에서는 특히 주의할 것이 있습니다. 경력자용 질문을 신입에게 그대로 쓰면 답변이 나오지 않는데, 이때 그 침묵이 경험할 기회가 없어서인지 역량이 없어서인지 구분되지 않습니다. 상황의 범위를 학교 프로젝트, 인턴, 개인 프로젝트까지 열어 주는 것이 문안 설계의 일입니다.
질문을 만들 때 피해야 할 것은 무엇인가요?
잘 만든 질문 옆에 잘못된 질문 하나가 섞이면 그 면접의 답변 전체를 신뢰하기 어려워집니다.
1. 문항 자체를 걸러내기: 유도·이중·닫힌 질문
만들어 둔 문안을 다시 볼 때 다음 세 가지를 걸러냅니다.
유도 질문. 원하는 답이 문장 안에 들어 있습니다. 「압박이 있어도 견디실 수 있죠?」라고 물으면 견딜 수 있다는 답만 돌아옵니다.
이중 질문. 서로 다른 두 가지를 한 번에 묻는 경우입니다. 「그때 어떻게 대응하셨고, 결과는 어땠나요?」라고 물으면 지원자는 하나만 답하고 면접관은 나머지를 놓칩니다. 나눠서 묻습니다. 다만 상황을 지정한 뒤 행동을 묻는 두 문장은 한 가지를 확인하는 한 세트라 여기에 해당하지 않습니다.
닫힌 질문. 예와 아니오로 끝납니다. 앞에서 본 기준 3번과 같은 문제입니다.
2. 법으로 물을 수 없는 것 걸러내기: 직무와 무관한 개인정보
면접 질문지에는 직무와 무관한 개인정보를 넣지 않습니다. 실무 원칙이자 법으로 정해진 사항입니다.
채용절차법 제4조의3은 구인자가 직무 수행에 필요하지 않은 정보를 기초심사자료에 기재하도록 요구하거나 입증자료로 수집하는 것을 금지합니다. 대상은 구직자 본인의 용모·키·체중 등 신체적 조건, 본인의 출신지역·혼인여부·재산, 직계 존비속과 형제자매의 학력·직업·재산입니다. 이 법은 상시 30명 이상의 근로자를 사용하는 사업 또는 사업장에 적용되고, 위반하면 500만 원 이하의 과태료가 부과됩니다. 서류에서 제외한 정보를 면접에서 다시 확인하는 운영도 피해야 합니다.
물으면 안 되는 질문 | 대체 문안 |
|---|
결혼하셨나요? 자녀 계획은 있으신가요? | 이 직무에는 분기별 2~3일의 지방 출장이 포함됩니다. 이 근무 조건으로 업무 수행이 가능하신가요? |
부모님은 어떤 일을 하시나요? | 대체 문안이 없습니다. 묻지 않습니다 |
집이 어디신가요? | 근무지는 OO이며 정해진 근무 시간에 해당 장소에서 근무합니다. 이 근무 조건으로 업무 수행이 가능하신가요? |
대체 문안의 원칙은 사람의 배경이 아니라 근무 조건의 수행 가능성을 묻는 것입니다. 그래서 가능한지 여부만 확인하고, 가능하지 않다는 답이 와도 가족 상황 같은 이유를 더 묻지 않습니다. 이유를 묻는 순간 우회 확인이 됩니다. 서류부터 최종 단계까지 전형별로 지켜야 할 채용절차법 요건은 별도 글에서 정리했습니다.
만든 질문을 질문지 한 장으로 정리해 봅시다
질문을 다 만들었어도 면접장에 들고 들어갈 형태가 아니면 면접관은 결국 자기 방식대로 묻습니다. 앞에서 만든 6개 중 역량마다 하나씩, 공통 질문 3개를 골라 한 장에 담습니다.
백엔드 개발자 60분 면접 질문지
역량 | 공통 질문 | 답변에서 기록할 것 | 준비된 후속 질문 | 시간 | 질문 리드 |
|---|
이상 징후 감지 | 최근 1년 안에 크게 번질 뻔했던 장애나 성능 문제를 맡았던 경험을 말씀해 주세요. 문제가 커지겠다고 느낀 뒤 가장 먼저 무엇을 하셨나요? | 위험 신호로 삼은 지표 / 첫 조치와 그 순서 / 재발 여부 | 무엇을 보고 그렇게 판단하셨나요 | 12분 | A |
권한 없이 조율 | 다른 팀의 결정이나 작업이 꼭 필요한데 그 팀의 우선순위가 아니었던 상황을 말씀해 주세요. 그때 어떤 순서로 움직이셨나요? | 움직인 순서 / 설득에 쓴 근거 / 본인이 직접 한 부분 | 상대 팀에 무엇을 근거로 말씀하셨나요 | 12분 | B |
반복 문제 구조화 | 반복되는 운영 요청이나 수작업을 줄이려고 처리 방식을 바꿔 본 경험을 말씀해 주세요. 무엇을 어떻게 바꾸셨나요? | 반복이라고 판단한 근거 / 바꾼 내용 / 바뀐 뒤의 변화 | 반복된다고 판단한 근거는 무엇이었나요 | 12분 | A |
질문 세 개에 36분, 여기에 도입 5분과 지원자 질문 10분을 더하면 51분입니다. 60분 면접에 9분의 여유가 남습니다. 시간이 부족하다고 질문을 빼지 않습니다. 지원자마다 받은 질문이 다르면 비교가 성립하지 않아 구조화의 전제가 깨집니다. 예비 질문 3개는 답변이 얕을 때 쓰고, 6개를 모두 공통 질문으로 쓰려면 75분 이상이 필요합니다.
맨 오른쪽의 질문 리드는 그 질문을 던지는 사람입니다. 리드가 묻는 동안 다른 면접관은 답변을 기록합니다. 한 사람이 질문과 기록을 동시에 하면 어느 쪽이든 놓칩니다.
이 표는 답변에서 기록할 것까지만 적습니다. 같은 기록을 점수로 바꾸는 일은 3편에서 다룹니다.
만든 질문지를 계속 쓰는 방법
같은 역량을 다른 직무에 쓸 때는 상황 문장만 바꿉니다. 질문의 경로(시점 한정 → 상황 지정 → 행동 요구)와 「답변에서 기록할 것」은 그대로 두고, 「반복되는 운영 요청」 자리에 그 직무에서 반복되는 문제를 넣으면 됩니다. 마케팅이라면 매달 되풀이되는 리포트 작업이, 고객지원이라면 같은 유형으로 반복 접수되는 문의가 그 자리에 들어갑니다.
같은 포지션을 반복해서 채용한다면 역량별 질문 하나를 예비 질문으로 교체합니다. 같은 문안을 오래 쓰면 지원자 사이에 답변이 공유됩니다.
입사 후 3~6개월이 지난 뒤, 면접에서 확인한 내용과 실제 업무 성과가 맞았는지 점검합니다. 어긋난 항목이 있으면 역량 정의나 질문 문안을 고칩니다.
질문지를 문서 파일로 만들어 메일이나 메신저로 보내면, 면접이 반복될수록 어느 것이 최신 판본인지 확인하기 어렵습니다. 질문을 바꿔 물었는지, 지원자의 답변을 어떻게 기록했는지도 면접관마다 다른 곳에 남습니다.
나인하이어에서는 면접 질문을 템플릿으로 저장해 두고, 같은 템플릿을 불러와 지원자에게 추가하면 면접관이 지원자 상세 화면의 면접 질문 탭에서 같은 질문을 봅니다. 질문 아래 코멘트에 지원자의 답변과 실제로 바꿔 물은 질문을 함께 기록할 수 있고, 여러 면접관이 동시에 적어도 실시간으로 반영됩니다. 구조화 면접 평가표 기능은 모든 요금제에서 쓸 수 있습니다.
질문 초안을 도구로 빠르게 만들고 싶다면 AI로 구조화 면접 설계하기 글을 참고하세요.
자주 묻는 질문 (FAQ)
Q. 질문 수를 늘리면 더 정확해지지 않나요?
A. 질문을 늘리는 것보다 한 질문을 끝까지 파는 편이 정확합니다. 공통 질문 3~4개에 후속 질문을 붙여 답변의 빈 조각을 채우면, 질문 여섯 개를 표면만 훑는 것보다 확인되는 사실이 많습니다. 면접 시간을 늘릴 수 없다면 질문 수를 먼저 줄이세요.
Q. 면접관이 질문지를 안 따르면 어떻게 하나요?
A. 강제하기 전에 공통 질문만 고정하고 후속 질문은 열어 두는 편이 정착이 빠릅니다. 면접관이 자기 판단으로 더 물을 여지가 있어야 질문지를 자기 것으로 받아들입니다. 면접관 운영과 교육은 4편에서 다룹니다.
Q. 지원자가 질문을 미리 알면 소용없지 않나요?
A. 과거에 실제로 한 일은 미리 안다고 만들어지지 않습니다. 준비된 답에는 실패한 시도와 판단 근거가 빠져 있어서 후속 질문에서 갈립니다.
Q. 기술 면접이나 코딩 테스트와는 어떻게 나누나요?
A. 구현하거나 문제를 푸는 능력은 과제와 기술 면접에서 확인하는 편이 정확합니다. 이 질문지는 그 앞뒤에 두는 역량 면접용으로, 과거 프로젝트에서의 판단·협업·개선 이력을 확인합니다. 두 라운드는 서로를 대체하지 않습니다.
질문지를 만들었다면,
다음은 채점 기준을 정할 차례입니다
좋은 질문은 잘 쓴 문장이 아니라 답변에서 확인할 사실을 끌어내는 문장입니다. 역량 3개를 고르고 질문 6개를 만들어 그중 3개를 한 장에 정리했다면, 이제 모든 지원자가 같은 질문을 받습니다.
여기까지 오면 다음 질문은 대개 하나로 모입니다. 질문지는 생겼는데, 돌아온 답변에 몇 점을 줄지는 여전히 사람마다 다릅니다.
3편 「구조화 면접 평가표 예시와 평가 기준, 평가 의견 작성법까지」에서는 오늘 적은 「답변에서 기록할 것」을 점수 기준으로 나누고, 면접관마다 같은 뜻으로 점수를 매기는 평가표를 만듭니다. 오늘 질문지에 역량 3개를 채워 두셨다면 그 세 줄을 그대로 가지고 이어서 보세요.
🎤 다음 편 이어서 보기