신입 면접과 프로젝트 설명

면접 답변은 판단을 재검토하게 하는 설명입니다

신입 면접에서 도구 이름과 기능을 많이 말해도 본인이 어떤 문제를 판단했는지 드러나지 않을 수 있습니다. 행사 신청 프로젝트는 실제 운영 앱을 개발한 경험이 아니라 제공 근거로 업무 개선 제안을 만든 연습입니다. 그 범위를 먼저 밝히고 어떤 기록을 읽고 무엇을 선택했으며 어떤 조건을 보류했는지 설명합니다. 시니어가 신입에게 기대하는 설명은 모든 해답을 아는 말보다 근거를 찾고 한계를 인정하며 다음 확인을 정하는 말입니다. 모르는 내부 동작은 미확인으로 두고 조사할 위치를 제시합니다.

짧은 답에는 네 가지 역할이 있습니다

답변은 문제와 자신의 역할, 직접 한 판단, 근거와 확인 방법, 한계와 다음 행동 순서로 묶습니다. 문장 수보다 질문에 맞는 연결이 중요합니다. “저는 기획을 담당했습니다”는 역할 소개이고 “E003·E006을 읽고 경로 안내를 먼저 제안했습니다”는 판단입니다. “25.0퍼센트포인트 차이를 계산했습니다”는 계산 범위이고 “운영 전환율을 높였습니다”는 별도 실사용 성과 주장입니다. 같은 동사를 쓰더라도 근거 수준이 달라집니다. 질문에 답한 뒤 상대가 원문을 찾을 수 있는 근거 ID를 하나 이상 붙입니다.

제공 자료와 직접 수행한 범위를 나눕니다

interview의 ownRole은 자신이 맡은 작성·검토 역할이고 performedScope는 이번 패키지의 provided-material-review입니다. notPerformed에는 실제 인터뷰, 운영 구현, 실제 성과 측정을 하지 않았다고 적습니다. 제공 가상 참여자의 발화를 직접 만난 사용자 발화처럼 인용하지 않습니다. 학습 중 코드를 실행했다면 그 실행을 자신의 별도 기록에 남긴 뒤 실제 확인한 명령과 결과로 설명할 수 있습니다. 모범 답안에 실행 예시가 있다는 것만으로 자신의 수행을 증명하지는 않습니다. 도구나 도움을 사용했다면 초안 작성과 본인이 대조한 판단을 분리해 밝힙니다.

요청에서 문제를 찾는 질문에 답합니다

첫 질문에는 “승인 알림을 원한다”는 의견을 기능 요구로 바로 확정하지 않은 과정을 설명합니다. E003의 탐색 후 문의와 E006의 연결 안내 누락으로 Q01을 선택하고 E005의 기존 경로 성공을 반례로 남겼다고 말합니다. 후보 Q02의 검토 지연은 처리 시각 자료가 없어 보류했습니다. 답변이 “인터뷰하고 분석했습니다”로 끝나면 어떤 조건으로 문제를 선택했는지 보이지 않습니다. 선택한 이유와 선택하지 않은 후보를 짧게 비교하면 판단 기준을 설명할 수 있습니다.

사실과 의견을 구분하는 질문에 답합니다

관찰한 행동은 화면에서 어느 경로를 열고 문의했는지이고 의견은 알림이 있으면 좋겠다는 발화입니다. 가설은 경로를 모르는 것이 문의에 영향을 줬을 가능성입니다. 연구 기록의 kind와 basis를 가리키며 세 문장을 다른 칸으로 분류한 이유를 설명합니다. 의견이 중요하지 않다는 뜻이 아니라 어떤 검증을 더 해야 기능 후보가 되는지 구별하는 것입니다. 사용자 발화를 실제 행동으로 바꾸어 쓰지 않습니다. 제공 기록을 분류한 학습이라면 직접 중립 질문을 던진 인터뷰 경험이라고 말하지 않습니다.

저장 흐름은 경계와 실패 조건으로 설명합니다

저장 버튼 질문에는 화면 입력, API 검증과 권한 확인, DB 처리, 응답, 화면 표시의 경계를 설명합니다. 성공 응답을 확인한 SC-normal과 응답을 못 받은 AC-network-unknown을 비교하면 실패 위치를 단정하지 않는 습관이 드러납니다. DB를 설계하거나 운영 로그를 직접 분석하지 않았다면 제공 data-flow.json을 읽고 계약을 대조했다고 밝힙니다. 모든 요청이 같은 순서로 성공한다고 말하기보다 입력 오류와 권한 거부는 어디서 처리되고 저장 여부 미확인은 어떻게 안내할지 설명합니다.

명세 질문에는 같은 결과를 떠올릴 수 있는 예를 듭니다

“상태를 보여 준다” 대신 유효 회원의 EV01 제출과 저장 성공 확인이라는 전제, 본인 내역 조회라는 행동, 참가 미확정 문구와 다음 경로라는 결과를 말합니다. AC-normal 원본은 v1이므로 R01·R02의 수정 기준과 v2 제안 위치를 함께 안내합니다. 정상 상태만 소개하지 말고 응답 미수신 때 먼저 본인 내역을 조회한다는 예외도 짧게 언급합니다. 구현과 텍스트 대조를 구분하며 N02의 권한·키보드 회귀가 남아 있다고 말합니다. 검증 가능한 명세라는 주장에는 무엇을 관찰할지 보여 주는 예가 필요합니다.

로그인 문의 질문에는 질문 순서를 보여 줍니다

사용자가 로그인 안 된다고 말했을 때 화면, 행동, 기대와 실제, 환경과 시각, 오류 코드 순으로 조건을 좁힌다고 답합니다. 세션 만료와 권한 거부를 나누고 전체 인증 헤더나 비밀번호를 수집하지 않습니다. FAQ01은 본인 조회의 SESSION_EXPIRED 조건에서만 SE04로 가상 확인되었으며 SUP03의 저장 여부는 미확인입니다. 재로그인 하나로 모든 문제를 해결했다고 말하지 않습니다. 실제 고객을 응대한 경험이 없다면 접수·이관 문서를 작성하고 제공 모의 문의를 읽은 범위로 설명합니다.

지표 질문에는 계산 전에 계약을 말합니다

T01의 대상은 유효 시도이며 분모에 도움·실패·미확인을 포함하고 분자는 독립 성공입니다. 전후 기간 경계와 제외 조건을 metrics.json에서 확인했다고 설명합니다. 전 2/4, 후 3/4는 가상 이벤트의 50.0%와 75.0%이며 차이는 25.0퍼센트포인트입니다. 작은 표본과 반복 경험·기기 누락, 두 수정의 동시 적용 때문에 원인 효과를 입증하지 못했다고 덧붙입니다. 성공 시간은 성공한 시도만 대상으로 하므로 전체 시간 개선으로 소개하지 않습니다. 다음에는 실제 동의 관찰과 이전 노출 조건을 확인한다는 계획을 제안합니다.

후속 질문은 모르는 범위를 드러내는 기회입니다

면접관이 “이 개선으로 문의가 얼마나 줄었나요?”라고 물으면 제공 문의와 이벤트가 다른 자료라 효과를 계산하지 않았다고 답합니다. 모른다는 말 뒤에 같은 기간의 사용자 노출·문의 연결·집계 기준이 필요하다고 설명합니다. “정원이 동시 승인에 안전한가요?”에는 D01은 업무 정책 제안이고 구현 동시성 검증을 하지 않았다고 답합니다. 넓은 결과를 약속하기보다 확인할 담당과 검증 항목을 말합니다. 질문이 예상과 다를 때 외운 답을 반복하지 않고 질문의 단위와 자신의 근거를 다시 맞춥니다.

연습 답변의 피드백은 근거 위치로 받습니다

동료에게 질문 하나를 고르게 하고 답변 후 근거 파일과 ID를 직접 찾게 합니다. 무엇을 직접 했는지, 어디서 가상 자료가 나오는지, 어떤 결론을 보류했는지 물어보게 합니다. 피드백이 “자신감 있게 말하라”에 머물지 않도록 헷갈린 주장과 찾지 못한 근거를 기록합니다. 시간 제한을 정해 연습할 수 있지만 말을 빠르게 줄이는 것보다 질문에 맞는 예 하나를 남기는 편이 유용합니다. 답변을 수정한 뒤 이전 표현이 근거를 과장했는지 비교합니다. 실제 연습을 하지 않았다면 피드백 계획으로 제출합니다.

완성 제안서를 제출하는 기준

reference-contract.json의 신입 질문 여섯 개에 각각 answer·refs·ownRole·performedScope·notPerformed·limit를 작성합니다. FAIL interview가 나오면 질문 순서와 근거 배열, 필수 설명을 확인합니다. 자동 검사가 확인하는 것은 답 존재와 참조이며 답변이 설득력 있는지는 동료가 판단합니다. 마지막에는 전체 제안서 검사와 잘못된 제출 거절 회귀를 실행합니다. 결과가 맞아도 리뷰는 pending을 유지합니다. 수행하지 않은 일과 다음에 확인할 일을 정확히 밝히는 것이 신입에게 필요한 프로젝트 설명의 완료 기준입니다.