Question 1

최근 프로젝트에서 그 기술 스택을 선택한 이유가 뭔가요? 다른 선택지는 없었나요?

Accepted Answer

유행이라서가 아니라 요구사항에 맞춰 골랐는지, 트레이드오프를 아는지 봐. 답변 순서: 결론: 선택한 기술과 핵심 이유 → 비교했던 대안과 버린 이유 → 실제로 써보니 좋았던 점과 아쉬운 점 → 다시 고른다면. 피할 것: "요즘 많이 써서", "익숙해서"만 말하는 것.

Question 2

서비스나 프로젝트에서 장애나 심각한 버그를 해결해 본 경험을 말씀해 주세요.

Accepted Answer

문제를 좁혀가는 과정, 재발 방지까지 생각하는지 봐. 답변 순서: 상황: 증상과 영향 범위 → 원인을 좁혀간 순서 (로그, 재현, 가설) → 해결 방법과 걸린 시간 → 재발 방지 조치. 피할 것: "구글링해서 해결했습니다"로 끝나는 것.

Question 3

코드 리뷰에서 본인 코드가 강하게 지적받은 적이 있나요? 어떻게 대응하셨어요?

Accepted Answer

기술적 비판을 감정 없이 받아들이고 토론할 수 있는지 봐. 답변 순서: 받은 지적 내용 → 내 첫 반응과 확인한 근거 → 수정한 것 또는 합의한 결론 → 이후 내 코딩 습관에 생긴 변화. 피할 것: "리뷰를 받은 적이 별로 없습니다". 리뷰 경험이 없으면 스스로 점검한 방식이라도 말해.

Question 4

느린 화면이나 느린 API를 개선해 본 적 있나요? 어떻게 원인을 찾았는지 궁금합니다.

Accepted Answer

감으로 고치지 않고 측정부터 하는지 봐. 답변 순서: 결론: 무엇을 얼마나 빠르게 했는지 → 측정 방법과 찾은 병목 → 적용한 개선 → 전후 수치와 남은 과제. 피할 것: "캐시를 적용했습니다"처럼 측정 없이 해결책만 말하는 것.

Question 5

처음 보는 기술을 짧은 시간 안에 익혀야 했던 경험이 있나요?

Accepted Answer

신입은 학습 속도가 곧 역량이야. 배우는 방식이 체계적인지 봐. 답변 순서: 상황: 무엇을, 얼마 안에 익혀야 했는지 → 학습 순서 (문서, 예제, 작은 실습) → 실제로 만들어낸 결과물 → 지금 쓰는 학습 루틴. 피할 것: "강의를 다 들었습니다". 결과물이 없으면 학습으로 안 쳐.

Question 6

사용자가 지금보다 열 배 늘어난다면, 지금 맡고 있는 시스템에서 가장 먼저 문제가 될 곳은 어디라고 보세요?

Accepted Answer

자기 시스템의 병목을 알고 있는지, 확장을 현실적으로 생각하는지 봐. 답변 순서: 결론: 가장 먼저 무너질 지점 → 그렇게 판단한 근거 (현재 지표, 구조) → 단계별 대응 (단기 완화, 구조 개선) → 비용과 우선순위 판단. 피할 것: "서버를 늘리면 됩니다". 병목을 짚지 않은 답이야.

Question 7

기획 쪽에서 기술적으로 무리한 일정을 요구하면 어떻게 하시겠어요?

Accepted Answer

안 된다고만 하지 않고, 범위와 일정을 협상할 줄 아는지 봐. 답변 순서: 결론: 가능한 범위부터 제안하겠다 → 무리한 이유를 근거로 설명 → 대안: 기능 축소, 단계 출시, 인력 조정 → 합의한 내용 기록하고 공유. 피할 것: "무조건 맞추겠습니다" 또는 "불가능하다고 하겠습니다".

Question 8

좋은 코드는 어떤 코드라고 생각하세요? 본인이 실제로 지키는 습관이 있다면요?

Accepted Answer

원칙을 외운 건지, 몸에 밴 습관이 있는지 봐. 답변 순서: 결론: 좋은 코드의 기준 한 문장 → 그 기준으로 지키는 구체적인 습관 2개 → 그 습관 덕분에 문제를 피한 장면 → 타협하는 선. 피할 것: "가독성이 좋은 코드"에서 멈추는 것.