대학 프로젝트 경험을 통해 연구 역량과 팀 내 기여도, 문제 해결 접근 방식을 평가한다.
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
4학년 캡스톤 디자인에서 소형 자동화 조립 장치 설계를 주제로 팀 프로젝트를 진행했습니다. 팀원 4명이 설계, 가공, 회로, 소프트웨어 파트를 나눠 맡았고, 저는 주로 기구 설계와 부품 선정을 담당했습니다. 설계 초반에는 3D 모델링만 하고 실제 가공 가능성을 따지지 않아, 첫 번째 목업에서 조립이 맞지 않는 문제가 발생했습니다. 이후 가공 담당 팀원과 매주 한 번 부품 리뷰를 함께 하는 방식으로 바꿨고, 두 번째 시제품부터는 수정 없이 조립이 됐습니다. 최종 발표에서 장치가 목표 사이클 타임 안에 작동하는 것을 시연했고, 교수님 평가에서 팀 협업 구조가 안정적이라는 피드백을 받았습니다. 그 경험에서 설계는 도면보다 실제 제작 조건과 대화하는 과정이 더 중요하다는 것을 배웠고, 지금도 설계할 때 가공 가능성부터 먼저 확인하는 습관이 남아 있습니다.
3학년 때 웹 서비스 개발 수업에서 5인 팀 리더를 맡아 8주 프로젝트를 완료했습니다. 기술 스택 선택부터 배포까지 팀이 직접 결정해야 하는 구조였는데, 프론트엔드와 백엔드 간 API 명세 합의가 늦어져 2주 차에 병목이 생겼습니다. 그 시점부터 매일 15분 스탠드업과 Notion 공유 명세서를 도입했고, 이후 한 파트가 기다리는 상황이 거의 사라졌습니다. 가장 기억에 남는 건 발표 이틀 전 API 응답 지연 버그가 터졌을 때였는데, 로그를 보고 DB 쿼리에서 N+1 문제를 확인한 뒤 조인 쿼리로 수정해 3시간 내에 해결했습니다. 발표에서 기능이 정상 작동하는 것을 시연했고, 교수님이 '실제 서비스처럼 완성도가 높다'는 평가를 남겼습니다. 명세 합의를 가장 먼저 고정하고 나머지를 붙이는 순서가 팀 프로젝트 병목의 절반 이상을 예방했습니다.
2학년 통계 수업에서 3인 팀으로 공공 데이터를 분석해 정책 제안 보고서를 제출하는 과제를 맡았습니다. 세 명이 모두 다른 주제를 원해, '데이터가 가장 풍부한 것'을 기준으로 투표해 교통 사고 데이터로 결정했습니다. 분석 초반에 제가 맡은 지역별 시각화가 팀원의 연령별 분석과 단위가 맞지 않아 그래프가 어색하게 나왔는데, 중간 발표 전에 팀 내에서 먼저 데이터 단위를 통일하는 기준을 만들었습니다. 가장 어려웠던 부분은 '데이터에서 보이는 것'과 '실제로 주장할 수 있는 것' 사이의 선을 그리는 과정이었습니다. 교수님 피드백으로 인과와 상관을 구분하라는 지적을 받았고, 이후 결론 문장마다 '~와 관련이 있는 것으로 나타났습니다'처럼 관계 수준에 맞게 표현을 조정했습니다. 최종 발표에서 '분석의 한계를 명확히 제시했다'는 점이 강점으로 평가됐고, 그 이후로 분석 결과를 과장하지 않는 습관이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 현대위아 일반 연구개발 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.