이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
가장 많이 쓴 언어는 `TypeScript`입니다. 프론트엔드 프로젝트부터 시작했는데, 타입 시스템이 처음에는 번거롭게 느껴졌습니다. 그러나 팀 프로젝트에서 타입이 없으면 다른 사람의 코드를 이해하는 데 시간이 더 걸린다는 것을 경험했습니다. 런타임 오류가 컴파일 시점에 잡히는 것도 유지보수에서 체감되었습니다. 이 경험이 '코드는 혼자 읽는 것이 아니다'라는 태도를 만들어주었습니다. 업무에서는 협업 코드에서 타입 명세가 문서 역할을 하여 온보딩 속도가 빨라지는 효과가 있을 것이라고 생각합니다. 새 언어를 배울 때도 이 태도로 접근합니다. 도구보다 문제를 보는 방식이 중요합니다. 언어가 달라도 그 방식이 있으면 빠르게 적응할 수 있습니다.
주력 언어는 `Java` 예요. 학교 수업과 프로젝트를 대부분 자바로 했어요. 객체지향 설계를 몸으로 익힌 언어예요. 인터페이스 분리, 의존성 주입 같은 개념을 자바로 처음 경험하면서 코드 구조가 왜 중요한지를 알게 됐어요. 업무에서는 이 경험이 다른 언어에서도 좋은 구조를 고민하는 태도로 이어진다고 생각해요. 언어가 달라도 설계 원칙은 비슷하거든요.
Go는 공부 중인데, 동시성 모델이 자바와 다르게 설계되어 있어서 흥미로웠어요. 한 언어를 깊게 배우면 다른 언어를 배우는 속도가 빨라요. 한 언어를 깊이 파고들면 다른 언어의 구조가 왜 그런지 더 잘 보여요. 비교가 이해를 만들어요.
가장 많이 쓴 건 `TypeScript` 이고, 이후에 Go를 공부했어요. 두 언어를 비교하면서 언어 설계 철학이 코드 스타일에 얼마나 영향을 주는지 느꼈어요. TypeScript는 유연함과 안전성 사이를 개발자가 선택하는 구조고, Go는 단순함과 명확성을 강제하는 구조예요. 이 차이를 이해하고 나서 코드를 볼 때 '왜 이렇게 짰는지'를 먼저 생각하는 습관이 생겼어요. 업무에서는 팀 언어에 빠르게 적응하는 데 이 경험이 도움이 될 것 같아요.
도구보다 문제를 이해하는 방식이 더 중요하다고 생각해요. 팀 언어에 빠르게 적응하는 게 목표예요. 익숙함보다 유연함이 중요한 시기라고 생각해요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.