말 그대로, 사람대사람이 아니라 AI가 나의 말투, 말하는 속도, 자세 등을 판단한다고 생각하면 됨
주로 특정 상황을 제시한 후에 대해 거기에 대한 답변이 있기도 하지만 업무 관련하여 겪었던 경험이나 팀협업 관련해서도 주제들이 나온다고 함
아래는 딘모뉴님 질문 리스트
자기소개 관련
자신과 관련된 키워드 2개 정도와 해당 산업과 직무와 가장 연관있는 경험하나를 꼭지로 잡고 얘기 하면됨
자기소개의 내용과 형식으로는
- 강점 : 나는 어떤 사람이다.
- 경험 : 강점의 근거가 되는 경험.
- 포부 : 강점을 이렇게 활용하겠다.
엔지니어쪽인 나에게는 끊임없이 공부한다는 내용이 들어가면 좋을 것 같음
1.
"안녕하세요, 사용자 경험을 최우선으로 생각하는 프론트엔드 개발자 홍성혁입니다."
저는 Human Centered Computing Lab에서 학부연구생으로 활동하며, 다양한 기업과 협업 프로젝트를 수행하고 4번의 학회에 참가한 경험이 있습니다.
이를 통해 사용자 중심의 인터페이스 설계와 데이터 시각화 기술을 연구하며, 기술과 사용자 경험을 연결하는 개발자로 성장해왔습니다.
이후 티맥스 가이아에서 2년간 프론트엔드 개발자로 근무하며, 노코드 플랫폼을 개발하였습니다. 특히 외부 API 연동과 데이터 시각화를 통해 사용자가 쉽게 이해하고 활용할 수 있는 인터페이스를 설계하는 데 집중했습니다. 또한, 비개발자도 직접 API를 테스트하고 활용할 수 있도록 다이얼로그 기반 UI를 설계하여, 사용자의 편의성과 업무 효율성을 크게 향상시킨 경험이 있습니다.
앞으로도 사용자 중심의 서비스 개발과 기술적 확장성을 고려한 설계에 기여하며, 항상 배우는 것에 희열을 느끼는 개발자가 되고 싶습니다. 감사합니다.
2.
안녕하세요, 실패가 두렵지 않아 갈등을 해결하며 성장하고 배우는는 것에 희열을 느끼는 오뚝이 프론트엔드 개발자 홍성혁입니다.
저는 Human Centered Computing Lab에서 학부연구생으로 활동하며 다양한 기업과 협업 프로젝트를 수행하고 4번의 학회에 참가하며 넓고 다양한 기술 속에서 저만의 기술적 견문을 넓혔습니다. 이를 통해 사용자 중심의 인터페이스 설계와 오픈소스 활용 개발을 통해 기술과 사용자 경험을 연결하는 개발자로 성장해왔습니다.
이후 티맥스 가이아에서 2년간 프론트엔드 개발자로 근무하며 GAIA 노코드 플랫폼을 개발했습니다. 특히 외부 API 연동과 다이얼로그를 통한 직관적인 UI를 설계하며 사용자의 편의성과 업무 효율성을 크게 향상시킨 경험이 있습니다.
저는 꾸준한 개발 서적 스터디와 블로그 기록을 통해 학습을 지속하며, 어려운 상황에서도 지치지 않는 강한 멘탈과 문제 해결력을 갖춘 개발자입니다. 앞으로도 사용자 중심의 서비스 개발과 기술적 확장성을 고려한 설계에 기여하며 성장해 나가고 싶습니다. 감사합니다.
일반 질문
AI면접은 지원자의 경험에 대해 많이 물어봄
경험했던 대인관계 갈등 상황이나, 창의적으로 문제를 해결한 경험에 대해서 한 3-4단계로 이루어지며 물어봄
상황 - 역할 - 느낀점
- 처했던 상황
- 해결하기 위했던 나의 역할
- 갈등을 해결하며 느낀점
스스로 말할 때 막힘이 없는 기억에서 덜 풍화된 이야기를 꺼내면 좋음
주로 정리할 떈
1. 협력/팀플
2. 성공/실패
3. 사회이슈 (그 기업과 관련된)
이렇게 준비하면 좋음
아래처럼 스크립트를 써놓기보다 특정 상황에 대해서 이야기할 주제를 정리하는 것이 좋음
면접 준비
- 시선 카메라 고정
- 정자세
- 또박또박 일관된 속도
예상 질문
지원동기
"저는 디지털 혁신을 통해 기업의 비즈니스 가치를 극대화하는 것에 큰 관심을 가지고 있으며, SK㈜ C&C가 제공하는 디지털 기술 진단 서비스를 보며 이 회사가 IT 인프라 최적화, 클라우드 전환, AI 도입 등 디지털 전환(DT)의 핵심 기술을 선도적으로 제공하고 있다는 점이 인상 깊었습니다.
특히, SK㈜ C&C의 Assessment Tool은 기업이 현재 디지털 역량을 객관적으로 평가하고, 이를 바탕으로 최적의 전략을 수립할 수 있도록 지원하는 서비스가 기업의 성장뿐만 아니라, 더 많은 기업이 IT 기술을 쉽게 접근할 수 있도록 하는 것에도 기여한다고 생각합니다.
저는 프론트엔드 개발자로서 사용자 친화적인 UX/UI 설계 및 데이터 시각화 기술을 활용하여, 기업이 이러한 디지털 기술 진단 서비스를 보다 직관적으로 경험할 수 있도록 돕고 싶습니다.
SK C&C가 다양한 산업군의 디지털 전환을 지원하는 만큼, 폭넓은 도메인에서 비즈니스 로직과 사용자 경험을 최적화하는 개발 경험을 쌓고 싶어 지원하게 되었습니다.
장단점
"저는 팀원들과의 원활한 커뮤니케이션을 통해 부족한 점을 빠르게 캐치하고, 이를 해결하기 위해 새로운 기술을 적극적으로 습득하는 개발자입니다. 단순히 개인적인 학습에서 끝나는 것이 아니라, 습득한 내용을 팀원들과 공유하며, 독서 스터디에서 강의를 하거나 기술 블로그에 정리하는 방식으로 제 것으로 만들고 있습니다. 이러한 과정을 통해 더 깊이 이해할 수 있었고, 팀원들에게도 실질적인 도움을 줄 수 있었습니다.
또한, 저는 모르는 것이 있으면 쉽게 포기하지 않고 끝까지 파고들어 해결하려는 끈기와 열정을 가지고 있습니다. 새로운 기술을 도입하거나 해결책을 찾아야 하는 상황에서도, 단순히 기존의 방식에 머무르지 않고 적극적으로 탐구하며 성장해 왔습니다.
하지만 저는 완벽주의적인 성향이 있어 세부적인 부분에 지나치게 집착할 때가 있습니다. 작은 디테일에 신경을 쓰다 보면 개발 속도가 느려질 때도 있었습니다. 이를 보완하기 위해 핵심 우선순위를 설정하고, 팀원들과 지속적으로 피드백을 주고받으며 더 나은 방향을 찾으려 노력하고 있습니다. 저는 처음부터 모든 것을 잘하지는 않지만, 부족한 부분을 인정하고 꾸준히 노력하는 과정에서 성장한다고 믿으며, 팀과 함께 지속적으로 발전하는 개발자가 되고자 합니다."
성공/실패
배포를 앞둔 상황에서 예상치 못한 문제가 발생했음에도 팀원들과 협력하여 배포 일정을 맞췄을 때입니다. 일부 기능이 예상과 다르게 동작하는 문제가 발견되었고, 일정이 지연될 수도 있는 상황이었습니다.
이때 저는 팀원들과 함께 신속하게 원인을 분석하고, 서로 적극적인 코드리뷰를 통해 해결책을 도출했습니다. 주말에도 함께 출근해 더욱 꼼꼼하게 검토하며 문제를 해결했고, 담당자뿐만 아니라 관련 기능을 개발한 팀원들과도 적극적으로 소통하며 빠르게 대응했습니다. 또한, 서로가 서로에게 힘을 내며 동기부여가 되어 끝까지 집중력을 유지할 수 있었습니다.
결과적으로, 팀의 협업과 적극적인 문제 해결 덕분에 계획된 일정 안에 배포를 완료할 수 있었습니다. 이 경험을 통해, 단순히 기능을 개발하는 것 이상으로, 팀워크와 신속한 문제 해결 능력이 프로젝트 성공에 얼마나 중요한 요소인지 깨닫게 되었습니다.
주어진 개발 업무를 빠르게 진행하는 데 집중하다 보니, 설계를 충분히 검토하지 않은 채 개발을 진행한 적이 있었습니다. 기능 개발이 거의 끝나갈 무렵, 일부 데이터 구조가 예상했던 것과 달라 이후 기능 확장이 어려워질 수 있는 문제가 있었습니다. 이를 해결하기 위해 추가적인 수정 작업이 필요해졌고, 결국 예상보다 많은 시간이 소요되었습니다.
이 경험을 통해, 속도도 중요하지만 초기 설계를 여러 번 검토하고, 이후 발생할 수 있는 문제까지 고려하는 것이 중요하다는 것을 배웠습니다. 이후에는 개발을 시작하기 전, 기능의 목적과 기대하는 결과를 명확히 정리하고, 필요하면 팀원들과 함께 다양한 시나리오를 고려하며 설계를 점검하는 습관을 들였습니다. 초기에 더욱 구체적인 설계로 체계적으로 업무를 수행할 수 있었습니다.
자소서 기반 질문
[협업과정에서 문제 해결 경험]
1. '햄릿 증후군을 위한 술자리 결정 웹 애플리케이션' 프로젝트에서 가장 어려웠던 점은 무엇이었나요? 어떻게 해결했나요?
- 비전공자의 기획과 디자인으로 인하여 기술적으로 어려운 내용이 기획되었을 때 서로의 의견을 조율하는 점이 가장 힘들었습니다. 예를 들어, 사용자의 실시간 선호도를 분석하고 이를 바탕으로 음식을 추천해주는 기능에 관하여 이야기가 나올 때 구현 과정에서 기술적으로 복잡할 뿐만 아니라 프로젝트의 기한 내에 완서앟기 어려운 점이 있었습니다. 저는 이 기능을 쉽게 설명하기 위해 ERD와 API 호출 흐름도를 작성하여 현재 모델과 제안된 모델의 차이를 언급하고 이로 인해 유발되는 문제점에 대해 설명하였습니다. 결론적으로 핵심기능을 우선적으로 구현하고 추가적인 고급기능은 추후 업데이트에 포함시키는 방식으로 기획을 조정하였습니다.
2. RESTful API에 대한 설명과 RESTful API 설계 원칙을 팀원들에게 설명했다고 했는데, 이를 쉽게 풀어서 설명했던 구체적인 방법은 무엇인가요?
- RESTful API는 REST 아키텍쳐 스타일을 따르는 API로 클라이언트와 서버가 일관된 방식으로 데이터를 주고 받을 수 있도록 설계된 인터페이스 입니다. 이에 대표적인 특징으로는 무상태성, 캐치가능, 클라이언트-서버구조, 계층적시스템이라는 특징입니다. 저는 이것을 비전공자에게 설명하기 위해 비유를 사용하였습니다. "RESTful API는 식당 주문 시스템과 비슷하고, 손님이 웨이터에게 주문을 하며, 주방에서는 요리를 조리하여 손님에게 건네어주는 이러한 응답 과정을 거친다고 설명하였습니다.)
3. Socket.IO를 활용한 실시간 채팅 기능 개발 중 네트워크 병목 현상을 해결했다고 했는데, 병목 원인과 해결 과정을 자세히 설명해주세요.
- 메시지 전달이 지연되거나 누락되는 문제가 발생하였습니다. 테스트 중 사용자의 수가 증가할수록 채팅 메세지가 일정시간 후 한번에 몰려오는 현상이 발생하였고 과도한 이벤트의 중복 등록으로 클라이언트와-서버간의 불필요한 통신이 많아져 발한 문제였습니다. 중복 이벤트 리스너를 제거하여 클라이언트가 처음 연결될 때 한번만 등록되도록 수정하였습니다. 기존에는 사용자가 같은 방을 입장 할 떄마다 새로운 리스너가 생성되었지만, socket.off()를 사용해 불필요한 리스너를 제거하였습니다.
4. 이 프로젝트를 통해 배운 점은 무엇이며, 다음 프로젝트에 어떻게 적용할 수 있을까요?
- 초반 기획과 설계가 중요하다는 것과 설계가 엇나가게 적용되더라도 그에 대한 대비를 해둬야된다는 것입니다. 처음부터 꼼꼼한 설계를 하면 좋겠지만 예상치 못한 문제가 발생할수도 있기 때문에 그에 대한 대비로 해당 기능을 대체할 기능을 설계해놓는 것도 좋은 방법이라고 생각이 됩니다.
5. Git을 사용하여 작업을 작은 단위로 나누었다고 했는데, 구체적으로 어떤 전략을 사용했는지 설명해주세요.
- 자신이 잘할 수 있거나 하고 싶은 기능들을 자원받고 그 기능들만을 해결하는 것이 아니라 더 큰 범위에서 자신이 해결할 수 있는 스코프에 대한 작업만을 가져갈 수 있도록 나누었습니다. 억지로 하는 것이 아닌 자신이 배우고 싶던 기능들을 해보며 더욱 좋은 결과를 얻을 수 있었습니다.
6. '햄릿 증후군 웹 애플리케이션' 프로젝트에서 기술적 이해 차이를 해결하기 위해 시각적 자료를 활용했다고 했는데, 구체적으로 어떤 자료를 준비했으며 효과는 무엇이었나요?
- ERD와 API 호출 흐름도를 작성하였습니다. 비전공자에게는 단순한 버튼의 기능일지 몰라도 실제적으로 통신이 오가는 과정을 설명하여 단순한 버튼 하나에도 생각보다 많은 통신을 거쳐서 돌아온다는 것을 설명하였고 이를 통해 서로의 기술적 이해 차이를 줄일 수 있었습니다. 그 효과로 다른 기능에서는 이러한 통신 과정들을 염두하여 기획이 진행되어 더욱 애자일한 방식으로 프로젝트가 수행될 수 있었습니다.
[직무 유관 경험]
1. 티맥스 가이아에서 API 통신 서비스 기능을 담당했다고 했는데, 가장 기억에 남는 성과는 무엇인가요?
- 사용자 친화적인 다이얼로그 UI를 구현하여 비전공자도 쉽게 통신 테스트를 사용할 수 있도록 만들었던 것입니다. 이로인한 성과로 사내 사용자 피드백에서 기획, 검수자 분들이 이를 통해 통신 테스트에 걸리는 속도가 50%정도 빨라졌다는 응답과 테스트의 어려움이 80% 정도 감소했다는 효과를 얻을 수 있었습니다. 또한, JSON을 포맷팅하여 보여줌으로 응답 데이터에 효율적인 확인이 가능해졌습니다.
2. HTML 요소를 PNG로 변환하는 알고리즘을 구현했다고 했는데, 구현 과정에서 가장 어려웠던 점은 무엇인가요?
- 파일 관련 라이브러리를 사용하지 않고 보안을 위해 사내 전용 서버를 사용하는 것이었습니다. 여기에는 파일 관련처리에 대한 기능이 많지 않아 파일을 불러오고 저장하는데에 따로 설계된 서버를 사용하였기에 리소스가 부족하여 사수분들의 도움이 많이 필요했던 것 같습니다.
3. 애플리케이션의 리소스를 복사/저장/삽입하는 기능을 설계했다고 했는데, 데이터 이식과 비동기 처리에서의 주요 기술적 도전 과제는 무엇이었나요?
- 데이터를 저장할 때, 애플리케이션 내의 모든 데이터를 저장해야 하는지 식별 번호만을 저장하여 꺼내와야하는지에 대한 설계가 가장 어려웠던 것 같습니다. 사용자가 불편함없이 리소스를 저장하고 삽입하기 위해서는 빠른 저장과 불러오기가 가능했어야 하는데 이를 위해 데이터베이스에서 파싱하는 구조를 바꿔야 하였고 렌더링까지 걸리는 시간을 단축했어야했습니다. 결론적으로는 사용자에게 먼저 버튼을 렌더링 해준다음 실제로 해당 버튼을 사용시에 버튼에 대한 정보를 불러오도록 수정하였습니다.
4. RESTful API 아키텍처를 활용한 외부 API 통신 관리 기능을 개발했다고 했는데, 실제로 처리했던 API 호출에서 가장 까다로웠던 케이스는 무엇인가요?
- 토큰값을 얻기 위해 Custom헤더를 통해 호출하는 API들이 가장 까다로웠습니다. 사용자가 직접 Header값을 입력해야하는 상황에서 하나의 오타라도 발생하게 된다면 통신이 불가능하기에 사용자를 전적으로 믿어 통신을 할 수 밖에 없는 상황이었습니다. 여기에서 나오는 불편함이 곧 프로젝트 전체의 성능 저하로 이어질 수 있음을 알기에 더욱 고도화된 설계라 필요하던 상황이었습니다.
5.팀 내 개발 독서 스터디를 통해 프로젝트 개선 사항을 제안했다고 했는데, 제안한 Action Item 중 가장 효과적이었던 것은 무엇인가요?
- 커스텀 타입 가드를 적용하는 방안입니다. 초기에는 커스텀 타입 가드에 대한 부정적인 인식이 강했지만 우아한 타입스크립트 책을 읽고난 후에 API 응답 데이터에 커스텀 타입가드함수를 적용하여 안전한 타입 체크가 가능하고 런타임 에러가 감소하며 유지보수성이 향상 될 수 있음을 깨달을 수 있었습니다.
팀워크 관련 경험
1. 함께 일하고 싶은 동료와 함께 일하기 싫은 동료의 특징과 그 이유?
-
좋은사람 : 책임감이 강하고 열린마음으로 소통하는 사람입니다. 각자의 역할을 충실히 수행하면서 문제가 발생시 솔직하게 공유하고 함께 해결책을 찾아나갈 수 있고 맡은 일을 미루지 않아 팀 전체의 진행 속도를 지킬 수 있습니다. 또한, 자신의 의견만을 고집하지 않고 팀원들의 의견에 경청하며 조율하여 효율적인 의사결정을 진행하는 사람입니다.
(추가경험 : 자신의 작업이 예상보다 늦어져서 이를 솔직하게 공유하고 도움을 요청하여 함께 문제를 해결하여 프로젝트를 마감하였고 여기에서 책임감 있는 태도가 협업에서 얼마나 중요한지 깨달았다.) -
싫은사람 : 팀보다는 자신을 먼저 생각하는 사람입니다. 협업의 본질은 팀의 공동적인 목표를 달성하기 위해 노력하는 것이라고 생각합니다. 팀보다 개인의 성과나 이익을 우선시하는 사람은 협업의 균형을 깨트리고 팀 전체의 사기를 저하시킬 수 있습니다. 특히나 자신의 잘못으로 일이 생겼을 때 이를 인정하지 않고 책임을 회피하거나 다른 사람의 공로를 자신의 성과처럼 포장하는 태도는 팀 전체적으로 신뢰를 깨뜨릴 수 있기 때문입니다.
(추가 경험 : 개인의 성과만을 강조하며 팀의 피드백을 무시하고 자신의 스타일대로만 일을 진행하여 추후 일이 인수인계 될 때 팀원들의 히스토리를 몰라 애를 먹은 적이 있고 이로인해 결과적으로 프로젝트 전체의 품질이 떨어지게 되었다.)
2. 팀 내에서 매주 진행한 회고 과정에서, 가장 기억에 남는 제안 사항은 무엇이었나요?
- 관습처럼 정해진 사람에게 받던 코드리뷰를 한 명을 추가하여 이 업무와 관련이 없더라도 히스토리를 유지할 수 있게 간단하게 코드리뷰를 작성하자는 것입니다.
3. 팀원과의 협업에서 가장 중요하다고 생각하는 요소는 무엇인가요?
- 공동 목표에 대한 이해라고 생각합니다. 팀이 같은 목표를 향해 나아가야 개발 속도가 붙고 불필요한 논쟁을 줄일 수 있다고 생각합니다. 무엇보다 자신의 이익보다 팀을 생각하고 행동하기 때문에 서로에 대한 신뢰를 쌓을 수 있고 공동체적인 목표로 한 가족과 같이 업무를 진행하며 성과와 협업력 모두 키울 수 있기 때문입니다.
4. 성과보다 팀워크가 더 중요하다고 생각하나요? 그 이유는 무엇인가요?
- 좋은 팀워크가 전제 되어야 좋은 성과가 있다고 생각합니다. 단기적인 성과만을 초례하였을 땐 장기적으로 팀워크가 무너질 수 있지만. 지속 가능한 성과 창출을 위해 팀워크를 증진시키고 실수가 늘어나지 않는 것이 중요하다고 생각합니다. 예를 들어, 팀워크가 좋지 않아 서로가 솔직하지 못해 업무의 진척이 생기면 그것이 곧 성과로 이어지게 되지만 좋은 팀워크 속에서는 솔직한 자신의 업무 상황과 능력을 고려하여 서로가 서로를 배려하는 상황이 나올 수 있기 때문입니다.
5. 팀 프로젝트에서 갈등이 발생했을 때, 어떻게 해결했나요?
- 기능 구현 방식에 대한 의견 충돌이 있었을 때,공동 목표를 재확인하며 서로의 의견을 경청하고 논리를 이해하는 방식으로 접근하였습니다. 저는 팀원과 코드 구조를 분석하고, 성능 및 유지보수성을 비교하는 자료를 준비해 논의했습니다. 이를 바탕으로 핵심 기능을 먼저 개발하고, 점진적으로 리팩토링하는 절충안을 도출할 수 있었습니다.
6. 협업 과정에서 의견 충돌이 있었던 경우, 이를 해결하기 위해 어떤 커뮤니케이션 전략을 사용했나요?
- 상대방의 의견을 경청하고 그들의 논리를 이해하려고 앞섰던 것 같습니다. 서로간의 의견충돌은 자신의 니즈가 있다는 것으로 생각하여 어떤 니즈가 필요한 것인지 듣고 공동의 목표를 다시 확인하고 데이터나 사용자 피드백 같은 객관적인 근거를 활용하여 논의를 이끌어 나갔습니다. 최대한 감정적인 대립은 피하고 상대방의 관점에서 생각해보려 노력했던 것 같습니다.
7. 협업 과정에서 가장 힘들었던 점은 무엇이었으며, 이를 극복하기 위해 본인이 한 행동은 무엇인가요?
- 팀원간 우선순위에 대한 차이로 인해 개발 방향이 엇갈리는 문제였습니다. 이것을 위해 진행 중인 프로젝트의 핵심 목표를 다시 상기시키고 프로젝트의 기한 내에 맞출 수 있는지를 소통하고 서로의 의견을 정리하여 공유하는 시간을 가지게 하였습니다.
뷰인터 대화형 면접 연습
- 책임의식이 발견된 경험이 없음 -> 배포를 맞추기 위해 노력을 하고 설계가 정확하게 되었는지 꼼꼼하게 확인헀다는 것이 중요할 것 같음
보완할점
책임감을 드러내는 사례에 대해 구체적으로 언급이 되어있지 않음
책임감 관련 : 서로 배포를 도왔는데 내가 도운 부분이 나오지 않았음
외부 API 통신 기능을 담당했던 나의 경험으로 동료가 API 통신에 관해서 성능 저하 문제가 생겨 코드리뷰를 함께 진행하며 데이터 처리 방식을 최적화 하여 성능 개선을 진행할 수 있었음, 또한 이러한 문제를 해결하여 성공적인 배포를 마친 후 통신 관련 개발 서적을 구매하여 함께 팀내 독서 스터디를 진행하며 강의를 진행함
뷰인터 종합 면접 연습
- 어려웠던 경험을 극복하기 위해 했던 해결 방안
- 시선 처리가 보통 수준이기에 그냥 카메라만을 보고자연스럽게 대화하듯 하는 게 중요할 것 같음
- 머리 움직임을 하지 않고 안정된 자세로 편안하게 면접을 봐야함
- 무표정한 표정이 많아서 조금 웃으며 하는 게 좋을 것 같음
