Câu hỏi phỏng vấn IT bằng tiếng Hàn

Người phỏng vấn hỏi

안녕하세요. 먼저 간단하게 자기소개 부탁드립니다.

Gợi ý: Người phỏng vấn mời bạn tự giới thiệu ngắn. Nói tên, số năm kinh nghiệm, công nghệ chính, kết thúc gọn gàng. Phỏng vấn nên dùng đuôi -습니다.

Câu trả lời mẫu

안녕하세요. 저는 응우옌 반 안입니다. 자바 개발자로 5년 동안 일했고, 최근 3년은 넥사크로와 스프링을 사용해서 한국 고객사의 SI 프로젝트를 개발했습니다.

Xin chào. Tôi là Nguyễn Văn An. Tôi đã làm lập trình viên Java 5 năm, 3 năm gần đây phát triển các dự án SI cho khách hàng Hàn Quốc bằng Nexacro và Spring.

Người phỏng vấn hỏi

최근에 했던 프로젝트에 대해 조금 더 자세히 말씀해 주시겠어요?

Gợi ý: Hỏi chi tiết dự án gần nhất. Trả lời theo thứ tự: dự án gì, quy mô, vai trò của bạn, công nghệ. Dùng -았/었습니다 để kể kinh nghiệm.

Câu trả lời mẫu

물류 회사의 재고 관리 시스템을 구축하는 프로젝트였습니다. 저는 입고와 출고 관련 화면 20개 정도를 넥사크로로 개발했고, 백엔드는 스프링과 마이바티스로 구현했습니다.

Đó là dự án xây dựng hệ thống quản lý tồn kho cho một công ty logistics. Tôi phát triển khoảng 20 màn hình liên quan đến nhập kho và xuất kho bằng Nexacro, còn backend thì triển khai bằng Spring và MyBatis.

Người phỏng vấn hỏi

팀은 몇 명이었고, 그 안에서 맡은 역할은 무엇이었나요?

Gợi ý: Hỏi quy mô team và vai trò. Nói số người, vai trò chính, và một trách nhiệm thêm (review code, liên lạc với khách...).

Câu trả lời mẫu

개발자 8명 중에서 저는 화면 개발을 주로 맡았습니다. 그리고 한국어를 할 수 있어서 고객사와 요구사항을 확인하고 공유하는 역할도 했습니다.

Trong 8 lập trình viên, tôi chủ yếu phụ trách phát triển màn hình. Ngoài ra, vì nói được tiếng Hàn nên tôi cũng làm vai trò xác nhận và chia sẻ yêu cầu với phía khách hàng.

Người phỏng vấn hỏi

저희 회사에 지원하신 이유가 무엇인가요?

Gợi ý: Hỏi lý do ứng tuyển. Liên kết kinh nghiệm của bạn với công việc của công ty, tránh lý do chỉ vì lương.

Câu trả lời mẫu

넥사크로로 공공 및 금융 시스템을 개발하는 회사라고 들었습니다. 제 경험을 바로 활용할 수 있고, 한국 고객과 직접 일하면서 더 성장하고 싶어서 지원하게 되었습니다.

Tôi nghe nói công ty phát triển các hệ thống công và tài chính bằng Nexacro. Tôi có thể dùng ngay kinh nghiệm của mình, và muốn phát triển hơn nữa khi làm việc trực tiếp với khách hàng Hàn, nên đã ứng tuyển.

Người phỏng vấn hỏi

한국어는 어느 정도 하세요? 고객사와 직접 회의할 수 있을까요?

Gợi ý: Hỏi trình độ tiếng Hàn. Nói trung thực (TOPIK 3), cho ví dụ cụ thể bạn đã làm được gì, và cách bạn xử lý khi chưa hiểu.

Câu trả lời mẫu

토픽 3급입니다. 회의나 메신저로 업무 이야기를 하는 것은 가능합니다. 다만 잘 이해하지 못한 부분은 다시 확인하고, 회의 후에는 내용을 메일로 정리해서 공유하고 있습니다.

Tôi có TOPIK cấp 3. Tôi có thể trao đổi công việc qua họp hoặc tin nhắn. Tuy nhiên, phần nào chưa hiểu rõ thì tôi xác nhận lại, và sau cuộc họp tôi tóm tắt nội dung qua email để chia sẻ.

Người phỏng vấn hỏi

한국어 공부는 지금도 하고 계세요?

Gợi ý: Hỏi bạn có đang tiếp tục học tiếng Hàn không. Nói cách học cụ thể, liên quan đến công việc.

Câu trả lời mẫu

네, 매일 30분씩 업무에서 자주 쓰는 표현을 연습하고 있습니다. 올해 안에 토픽 4급을 따는 것이 목표입니다.

Vâng, mỗi ngày tôi luyện 30 phút các mẫu câu hay dùng trong công việc. Mục tiêu của tôi là đạt TOPIK cấp 4 trong năm nay.

Người phỏng vấn hỏi

개발하면서 가장 어려웠던 문제와 어떻게 해결했는지 말씀해 주세요.

Gợi ý: Kể tình huống: vấn đề gì, ảnh hưởng thế nào. Mở đầu rõ ràng, có bối cảnh.

Câu trả lời mẫu

운영 중인 시스템에서 월말 정산 화면이 가끔 다른 사용자의 데이터를 보여 주는 문제가 있었습니다. 재현이 잘 안 돼서 원인을 찾는 데 시간이 많이 걸렸습니다.

Trong hệ thống đang vận hành, màn hình quyết toán cuối tháng thỉnh thoảng hiển thị dữ liệu của người dùng khác. Vì khó tái hiện nên tôi mất nhiều thời gian để tìm nguyên nhân.

Người phỏng vấn hỏi

원인은 무엇이었고, 어떻게 찾으셨어요?

Gợi ý: Hỏi nguyên nhân và cách tìm. Kể quá trình: xem log, phân tích, phát hiện nguyên nhân kỹ thuật.

Câu trả lời mẫu

로그를 사용자별로 분석해 보니 동시에 요청이 들어올 때만 문제가 발생했습니다. 확인해 보니 싱글톤 서비스 클래스에 사용자 정보를 멤버 변수로 저장하고 있었습니다.

Phân tích log theo từng người dùng thì thấy lỗi chỉ xảy ra khi có request đồng thời. Kiểm tra thì phát hiện class service singleton đang lưu thông tin người dùng vào biến thành viên.

Người phỏng vấn hỏi

그 경험에서 배운 점이 있다면요?

Gợi ý: Hỏi bài học. Nói cách sửa và điều bạn thay đổi sau đó (quy tắc review, chia sẻ team).

Câu trả lời mẫu

사용자 정보를 지역 변수로 바꿔서 해결했습니다. 그 후로는 코드 리뷰를 할 때 싱글톤 빈에 상태를 저장하는지 꼭 확인하고, 팀에도 체크리스트로 공유했습니다.

Tôi giải quyết bằng cách đổi thông tin người dùng thành biến cục bộ. Từ đó, khi review code tôi luôn kiểm tra xem có lưu trạng thái trong singleton bean không, và chia sẻ với team thành checklist.

Người phỏng vấn hỏi

고객사가 개발 막바지에 요구사항을 바꾸면 어떻게 대응하시겠어요?

Gợi ý: Thay đổi yêu cầu sát deadline. Ý: không từ chối ngay, phân tích ảnh hưởng, báo PM, thống nhất lịch.

Câu trả lời mẫu

먼저 변경 내용이 일정과 다른 기능에 어떤 영향을 주는지 분석하겠습니다. 그 결과를 PM님께 공유하고, 고객사와 우선순위와 일정을 다시 협의하겠습니다.

Trước tiên tôi sẽ phân tích nội dung thay đổi ảnh hưởng thế nào đến lịch và các chức năng khác. Tôi sẽ chia sẻ kết quả với PM, rồi bàn lại thứ tự ưu tiên và lịch với khách hàng.

Người phỏng vấn hỏi

팀원과 의견이 다를 때는 어떻게 하세요?

Gợi ý: Bất đồng với đồng nghiệp. Ý: nghe lý do, so sánh bằng dữ liệu, tôn trọng quyết định cuối.

Câu trả lời mẫu

상대방의 이유를 먼저 듣고, 각 방법의 장단점을 정리해서 함께 비교합니다. 그래도 결정하기 어려우면 PL님의 의견을 듣고, 결정된 방향을 따릅니다.

Tôi lắng nghe lý do của đối phương trước, rồi tổng hợp ưu nhược điểm của từng cách để cùng so sánh. Nếu vẫn khó quyết định thì tôi hỏi ý kiến PL và làm theo hướng đã được quyết định.

Người phỏng vấn hỏi

오픈 전에는 야근이 많을 수도 있는데 괜찮으세요?

Gợi ý: Hỏi về làm thêm giờ trước go-live. Trả lời tích cực nhưng thực tế: hiểu tình huống, đồng thời quản lý việc để giảm phải làm thêm.

Câu trả lời mẫu

네, 오픈 전에는 필요할 수 있다고 생각합니다. 다만 평소에 일정을 잘 관리해서 야근이 꼭 필요한 상황을 줄이도록 노력하겠습니다.

Vâng, tôi nghĩ trước ngày go-live có thể cần làm thêm. Tuy nhiên, tôi sẽ cố gắng quản lý lịch tốt hằng ngày để giảm những tình huống bắt buộc phải làm thêm giờ.

Người phỏng vấn hỏi

합격하시면 언제부터 근무가 가능하세요?

Gợi ý: Hỏi ngày có thể bắt đầu. Trả lời cụ thể, có lý do (bàn giao công việc hiện tại) để thể hiện trách nhiệm.

Câu trả lời mẫu

현재 프로젝트 인수인계가 필요해서, 합격 통보를 받은 후 2주 뒤부터 근무가 가능합니다.

Vì cần bàn giao dự án hiện tại, tôi có thể bắt đầu làm việc 2 tuần sau khi nhận thông báo trúng tuyển.

Người phỏng vấn hỏi

마지막으로 궁금한 점이 있으면 질문해 주세요.

Gợi ý: Câu hỏi ngược. Hỏi về công việc/dự án/team, tránh hỏi ngay lương hay nghỉ phép ở vòng kỹ thuật.

Câu trả lời mẫu

입사하게 되면 처음에 투입될 프로젝트가 어떤 시스템인지, 그리고 넥사크로 외에 사용하는 기술이 있는지 궁금합니다.

Tôi muốn biết nếu vào công ty thì dự án đầu tiên tôi tham gia là hệ thống gì, và ngoài Nexacro thì có dùng công nghệ nào khác không.

Người phỏng vấn hỏi

네, 오늘 면접은 여기까지입니다. 결과는 다음 주 중에 연락드리겠습니다.

Gợi ý: Kết thúc phỏng vấn. Cảm ơn lịch sự, thể hiện mong muốn làm việc, chào bằng 하십시오체.

Câu trả lời mẫu

오늘 바쁘신 중에 시간 내 주셔서 감사합니다. 좋은 결과로 함께 일할 수 있으면 좋겠습니다. 감사합니다.

Cảm ơn anh/chị đã dành thời gian trong lúc bận rộn hôm nay. Tôi rất mong có kết quả tốt để được cùng làm việc. Xin cảm ơn.

Người phỏng vấn hỏi

유지보수 업무는 어떤 걸 해 보셨어요?

Gợi ý: Kể: hơn N năm bảo trì hệ thống Java/JSP cho khách Hàn; xử lý yêu cầu sửa, sự cố, và hiện đang chuyển màn hình Polymer sang JSP.

Câu trả lời mẫu

한국 고객사의 자바와 JSP 기반 시스템을 유지보수하고 있습니다. 고객 요청 처리와 장애 대응을 담당하고 있고, 최근에는 기존 Polymer 화면을 JSP로 전환하는 작업도 진행하고 있습니다.

Tôi đang bảo trì hệ thống nền tảng Java và JSP cho khách hàng Hàn Quốc. Tôi phụ trách xử lý yêu cầu của khách và ứng phó sự cố, gần đây còn làm việc chuyển các màn hình Polymer cũ sang JSP.

Người phỏng vấn hỏi

문서가 없는 오래된 코드는 어떻게 파악하세요?

Gợi ý: Cách làm: đọc log và tái hiện trên môi trường dev, lần theo luồng từ màn hình xuống DB, rồi ghi lại tài liệu để người sau dùng.

Câu trả lời mẫu

먼저 개발 환경에서 기능을 재현하고 로그를 보면서 화면부터 DB까지 흐름을 따라갑니다. 그리고 파악한 내용은 문서로 정리해서 팀에 공유합니다.

Trước tiên tôi tái hiện chức năng trên môi trường dev, vừa xem log vừa lần theo luồng từ màn hình xuống DB. Sau đó tôi viết lại những gì nắm được thành tài liệu và chia sẻ cho team.

Người phỏng vấn hỏi

앞으로는 어떤 역할을 하고 싶으세요?

Gợi ý: Mục tiêu: dùng kinh nghiệm kỹ thuật và tiếng Hàn để trở thành BrSE/PM, làm cầu nối giữa khách Hàn và team Việt Nam.

Câu trả lời mẫu

개발 경험과 한국어를 살려서 한국 고객사와 베트남 개발팀을 연결하는 브릿지 SE, 나아가 PM 역할을 하고 싶습니다.

Tôi muốn phát huy kinh nghiệm phát triển và tiếng Hàn để làm Bridge SE kết nối khách hàng Hàn với team dev Việt Nam, xa hơn nữa là vai trò PM.

Người phỏng vấn hỏi

유통 쪽 프로젝트 경험이 있으신가요?

Gợi ý: Trả lời có kinh nghiệm, nêu dự án cụ thể, vai trò và phạm vi.

Câu trả lời mẫu

네, 대형마트 POS와 본사 정산 시스템을 연동하는 프로젝트에서 2년 동안 백엔드 개발을 담당했습니다.

Vâng, tôi đã phụ trách phát triển backend trong 2 năm ở dự án liên kết POS của đại siêu thị với hệ thống quyết toán ở trụ sở.

Người phỏng vấn hỏi

유통 시스템에서 가장 어려웠던 점은 뭐였어요?

Gợi ý: Nêu khó khăn đặc thù ngành bán lẻ (dữ liệu lớn, batch đêm, cửa hàng mở cửa) và cách giải quyết.

Câu trả lời mẫu

영업시간에는 배포나 장애가 바로 매출에 영향을 줘서 부담이 컸습니다. 그래서 야간 배포 절차와 롤백 계획을 꼼꼼하게 준비했습니다.

Trong giờ mở cửa, deploy hay sự cố đều ảnh hưởng ngay đến doanh thu nên áp lực rất lớn. Vì vậy tôi đã chuẩn bị kỹ quy trình deploy ban đêm và kế hoạch rollback.

Người phỏng vấn hỏi

저희 프로젝트는 현업과 소통할 일이 많은데 괜찮으시겠어요?

Gợi ý: Thể hiện sẵn sàng giao tiếp với người nghiệp vụ, có ví dụ.

Câu trả lời mẫu

네, 이전 프로젝트에서도 현업 담당자와 요구사항 회의를 매주 진행했습니다. 용어가 헷갈릴 때는 회의 후에 메일로 다시 정리해서 확인했습니다.

Vâng, ở dự án trước tôi cũng họp yêu cầu với người phụ trách nghiệp vụ hằng tuần. Khi thuật ngữ dễ nhầm, sau buổi họp tôi tổng hợp lại qua mail để xác nhận.

Người phỏng vấn hỏi

지금 다니시는 회사를 그만두려고 하는 이유가 있나요?

Gợi ý: Hỏi lý do nghỉ việc. Đừng chê công ty cũ hay sếp cũ. Nói điều bạn muốn học/làm thêm ở nơi mới.

Câu trả lời mẫu

현재 회사에서는 주로 유지보수를 담당하고 있습니다. 앞으로는 고객과 직접 소통하면서 신규 개발에도 참여하고 싶어서 이직을 결심했습니다.

Ở công ty hiện tại tôi chủ yếu phụ trách bảo trì. Sắp tới tôi muốn giao tiếp trực tiếp với khách hàng và tham gia cả phát triển mới, nên tôi đã quyết định chuyển việc.

Người phỏng vấn hỏi

유지보수 경험도 중요한데, 그 경험에서 얻은 건 뭐라고 생각하세요?

Gợi ý: Hỏi bạn học được gì từ việc bảo trì. Nêu 1-2 điểm cụ thể: đọc hiểu code cũ, phân tích nguyên nhân lỗi, cẩn thận khi sửa.

Câu trả lời mẫu

남이 작성한 코드를 빨리 읽고 이해하는 능력을 키웠고, 수정 사항이 다른 기능에 주는 영향을 꼼꼼하게 확인하는 습관이 생겼습니다.

Tôi đã rèn được khả năng đọc hiểu nhanh code người khác viết, và có thói quen kiểm tra kỹ ảnh hưởng của một thay đổi tới các chức năng khác.

Người phỏng vấn hỏi

그럼 저희 회사에 오시면 어떤 일을 해 보고 싶으세요?

Gợi ý: Hỏi bạn muốn làm gì ở công ty mới. Kết nối với lý do chuyển việc: giao tiếp với khách bằng tiếng Hàn, tham gia từ giai đoạn yêu cầu.

Câu trả lời mẫu

요구사항 분석 단계부터 참여해서 한국 고객사와 직접 소통하는 역할을 해 보고 싶습니다. 개발 경험이 있기 때문에 기술적인 내용도 정확하게 전달할 수 있다고 생각합니다.

Tôi muốn tham gia từ giai đoạn phân tích yêu cầu và đảm nhận vai trò giao tiếp trực tiếp với khách hàng Hàn Quốc. Vì có kinh nghiệm phát triển nên tôi nghĩ mình có thể truyền đạt chính xác cả nội dung kỹ thuật.

Người phỏng vấn hỏi

본인의 장점이 뭐라고 생각하세요?

Gợi ý: Nói 1 điểm mạnh + ví dụ cụ thể. Đừng liệt kê 5-6 tính từ.

Câu trả lời mẫu

저는 책임감이 강한 편입니다. 지난 프로젝트에서 장애가 발생했을 때 끝까지 남아서 원인을 찾았고, 재발 방지 대책까지 정리해서 공유했습니다.

Tôi là người khá có trách nhiệm. Ở dự án trước, khi xảy ra sự cố, tôi ở lại đến cùng để tìm nguyên nhân và còn tổng hợp, chia sẻ cả biện pháp ngăn tái phát.

Người phỏng vấn hỏi

그럼 단점은요?

Gợi ý: Nêu một điểm yếu thật, không chí mạng với vị trí, và nói bạn đang khắc phục thế nào.

Câu trả lời mẫu

한 가지 일에 너무 집중하다 보면 진행 상황 공유가 늦어질 때가 있습니다. 그래서 요즘은 오전과 오후에 한 번씩, 정해진 시간에 팀에 상황을 공유하고 있습니다.

Khi quá tập trung vào một việc, đôi khi tôi chia sẻ tiến độ bị muộn. Vì vậy dạo này tôi chia sẻ tình hình với team vào giờ cố định, sáng một lần và chiều một lần.

Người phỏng vấn hỏi

동료들은 본인을 어떤 사람이라고 말하나요?

Gợi ý: Hỏi đồng nghiệp đánh giá bạn ra sao. Trích một nhận xét cụ thể, có thể dùng '-다고 하다' (gián tiếp).

Câu trả lời mẫu

모르는 걸 물어보면 친절하게 잘 알려 주는 사람이라고 합니다. 그래서 신입 개발자들이 저한테 질문을 많이 하는 편입니다.

Mọi người nói tôi là người hay chỉ dẫn tận tình khi được hỏi. Vì vậy các bạn lập trình viên mới thường hỏi tôi khá nhiều.

Người phỏng vấn hỏi

5년 후에 어떤 모습이 되고 싶으세요?

Gợi ý: Mục tiêu dài hạn. Nói rõ hướng đi và nó liên quan thế nào tới công ty này.

Câu trả lời mẫu

5년 후에는 한국 고객사와 베트남 개발팀 사이에서 프로젝트 전체를 관리하는 PM이 되고 싶습니다. 그래서 지금은 개발 업무를 하면서 한국어와 프로젝트 관리를 같이 공부하고 있습니다.

Năm năm nữa tôi muốn trở thành PM quản lý toàn bộ dự án giữa khách hàng Hàn Quốc và team phát triển Việt Nam. Vì vậy hiện tại, vừa làm phát triển, tôi vừa học thêm tiếng Hàn và quản lý dự án.

Người phỏng vấn hỏi

개발자로 계속 일하는 건 생각 안 해 보셨어요?

Gợi ý: Câu hỏi thử: sao không tiếp tục làm dev? Giải thích dev là nền tảng, không phải bỏ kỹ thuật.

Câu trả lời mẫu

개발 경험은 앞으로도 큰 도움이 된다고 생각합니다. 기술을 알아야 일정이나 리스크를 정확하게 판단할 수 있기 때문에, 역할이 바뀌어도 기술 공부는 계속할 생각입니다.

Tôi nghĩ kinh nghiệm phát triển sẽ tiếp tục rất hữu ích. Vì phải hiểu kỹ thuật thì mới đánh giá chính xác được lịch trình hay rủi ro, nên dù vai trò thay đổi tôi vẫn định tiếp tục học kỹ thuật.

Người phỏng vấn hỏi

그 목표를 위해서 최근에 따로 노력하고 있는 게 있나요?

Gợi ý: Hỏi hành động cụ thể. Nêu việc bạn đang làm: học tiếng Hàn, làm side project, đọc sách quản lý.

Câu trả lời mẫu

요즘은 한국어 업무 표현을 연습하는 앱을 직접 만들어서 매일 사용하고 있습니다. 회의나 메일에서 자주 쓰는 표현을 정리해 두고 말하기 연습을 하고 있습니다.

Dạo này tôi tự làm một app luyện các mẫu câu tiếng Hàn công sở và dùng hằng ngày. Tôi tổng hợp các câu hay dùng trong họp và email rồi luyện nói.

Người phỏng vấn hỏi

희망 연봉은 어느 정도 생각하고 계세요?

Gợi ý: Hỏi mức lương mong muốn. Nên nói một khoảng có căn cứ (lương hiện tại, kinh nghiệm) và thể hiện sẵn sàng trao đổi.

Câu trả lời mẫu

현재 연봉과 경력을 고려해서 지금보다 15% 정도 높은 수준을 희망합니다. 다만 회사 내규도 있으실 테니 협의는 가능합니다.

Cân nhắc lương hiện tại và kinh nghiệm, tôi mong muốn mức cao hơn hiện nay khoảng 15%. Tuy nhiên công ty chắc cũng có quy định nội bộ nên tôi có thể trao đổi thêm.

Người phỏng vấn hỏi

입사는 언제부터 가능하세요?

Gợi ý: Ngày có thể bắt đầu. Nhắc đến thời gian bàn giao ở công ty cũ: người Hàn đánh giá cao việc bàn giao có trách nhiệm.

Câu trả lời mẫu

현재 회사에서 인수인계할 기간이 필요해서, 합격 통보를 받은 후 한 달 뒤부터 출근 가능합니다.

Tôi cần thời gian bàn giao ở công ty hiện tại, nên có thể đi làm sau một tháng kể từ khi nhận thông báo trúng tuyển.

Người phỏng vấn hỏi

혹시 처우나 근무 조건에 대해 궁금한 점 있으세요?

Gợi ý: Cơ hội hỏi về điều kiện làm việc. Hỏi 1-2 điều chuyên nghiệp: chế độ làm việc, đào tạo, onsite.

Câu trả lời mẫu

한 가지 여쭤봐도 될까요? 입사 후에 한국 현지 파견이나 교육을 받을 수 있는 기회가 있는지 궁금합니다.

Tôi có thể hỏi một điều được không ạ? Tôi muốn biết sau khi vào công ty có cơ hội được cử sang Hàn Quốc hay được đào tạo không ạ.

Người phỏng vấn hỏi

이 포지션은 한국 고객사에 3개월 정도 파견 근무가 있을 수 있는데, 괜찮으세요?

Gợi ý: Hỏi bạn có đi onsite được không. Nếu có hoàn cảnh gia đình, nói thật nhưng tích cực.

Câu trả lời mẫu

네, 가능합니다. 가족과도 미리 이야기를 나눴습니다. 다만 일정이 정해지면 조금 일찍 알려 주시면 준비하는 데 도움이 될 것 같습니다.

Vâng, tôi đi được. Tôi cũng đã nói chuyện trước với gia đình. Chỉ là nếu lịch được chốt, anh/chị báo sớm một chút thì sẽ giúp tôi chuẩn bị tốt hơn.

Người phỏng vấn hỏi

한국 회사에서 일할 때 가장 신경 써야 할 점이 뭐라고 생각하세요?

Gợi ý: Hỏi hiểu biết về văn hóa làm việc Hàn. Nêu: báo cáo thường xuyên (보고), tôn trọng cấp bậc, đúng hạn.

Câu trả lời mẫu

보고를 자주 하는 것이 가장 중요하다고 생각합니다. 문제가 생기면 혼자 해결하려고 하지 않고, 작은 일이라도 먼저 공유해야 한다고 배웠습니다.

Tôi nghĩ quan trọng nhất là báo cáo thường xuyên. Tôi đã học được rằng khi có vấn đề thì không nên cố tự giải quyết một mình, mà dù việc nhỏ cũng phải chia sẻ trước.

Người phỏng vấn hỏi

현지에서 고객이 갑자기 회식에 같이 가자고 하면 어떻게 하실 거예요?

Gợi ý: Câu hỏi tình huống về 회식 (liên hoan công ty). Thể hiện thiện chí hòa nhập, biết giới hạn.

Câu trả lời mẫu

고객과 가까워질 수 있는 좋은 기회라고 생각해서 같이 가겠습니다. 다만 다음 날 업무에 지장이 없도록 적당히 조절하겠습니다.

Tôi nghĩ đó là cơ hội tốt để gần gũi với khách hàng nên tôi sẽ đi cùng. Nhưng tôi sẽ điều chỉnh vừa phải để không ảnh hưởng đến công việc ngày hôm sau.

Người phỏng vấn hỏi

Kafka 같은 메시지 큐를 사용해 본 경험이 있나요?

Gợi ý: Bạn chưa dùng. Nói thật, nêu điều bạn biết ở mức khái niệm và kinh nghiệm gần nhất.

Câu trả lời mẫu

실무에서 직접 사용해 본 적은 없습니다. 다만 메시지를 비동기로 주고받아서 시스템 간의 결합도를 낮춘다는 개념은 알고 있고, 비슷하게 배치 작업으로 시스템 간 데이터를 연동한 경험은 있습니다.

Trong công việc tôi chưa từng dùng trực tiếp. Tuy nhiên tôi biết khái niệm trao đổi message bất đồng bộ để giảm sự phụ thuộc giữa các hệ thống, và tôi từng có kinh nghiệm tương tự là liên kết dữ liệu giữa các hệ thống bằng batch job.

Người phỏng vấn hỏi

입사 후에 그 기술을 써야 한다면 어떻게 하실 거예요?

Gợi ý: Kế hoạch học nhanh: tài liệu chính thức, làm thử nhỏ, hỏi người có kinh nghiệm trong team.

Câu trả lời mẫu

공식 문서로 기본 구조를 먼저 익히고, 작은 예제를 직접 만들어 보겠습니다. 그리고 팀 안에 경험이 있는 분께 실제 프로젝트에서 주의할 점을 여쭤보겠습니다.

Tôi sẽ nắm cấu trúc cơ bản qua tài liệu chính thức trước, rồi tự làm thử một ví dụ nhỏ. Sau đó tôi sẽ hỏi người có kinh nghiệm trong team về những điểm cần chú ý ở dự án thực tế.

Người phỏng vấn hỏi

새로운 기술을 빨리 익힌 경험이 있으면 하나 말씀해 주세요.

Gợi ý: Kể một ví dụ có thời gian cụ thể: học gì, trong bao lâu, đạt kết quả gì.

Câu trả lời mẫu

이전 프로젝트에서 처음 써 보는 리포트 툴을 맡게 됐는데, 일주일 동안 샘플을 만들어 보면서 익혔고 2주 만에 보고서 화면 10개를 일정 안에 완료했습니다.

Ở dự án trước tôi được giao một công cụ làm báo cáo mà tôi chưa dùng bao giờ. Tôi làm thử các mẫu trong một tuần để làm quen, và sau 2 tuần đã hoàn thành 10 màn hình báo cáo đúng hạn.

Người phỏng vấn hỏi

(소리가 끊기면서) …그래서… 경험이… 말씀해…

Gợi ý: Tiếng bị đứt quãng. Báo lịch sự là nghe không rõ và nhờ nói lại.

Câu trả lời mẫu

죄송합니다. 소리가 조금 끊겨서 잘 못 들었습니다. 한 번만 다시 말씀해 주시겠습니까?

Xin lỗi ạ, âm thanh bị ngắt quãng một chút nên tôi nghe không rõ. Anh/chị có thể nói lại một lần nữa được không ạ?

Người phỏng vấn hỏi

제 목소리는 잘 들리세요? 화면이 좀 멈춘 것 같은데요.

Gợi ý: Người phỏng vấn báo hình bạn bị đơ. Đề nghị tắt camera tạm thời hoặc vào lại.

Câu trả lời mẫu

제 쪽 인터넷 연결이 불안정한 것 같습니다. 괜찮으시다면 잠깐 나갔다가 바로 다시 들어오겠습니다.

Hình như kết nối internet bên tôi không ổn định. Nếu anh/chị không phiền, tôi xin ra ngoài một chút rồi vào lại ngay ạ.

Người phỏng vấn hỏi

네, 이제 잘 들려요. 아까 질문 이어서 답변해 주세요.

Gợi ý: Kết nối lại xong. Cảm ơn, xin lỗi ngắn gọn rồi tiếp tục trả lời, có thể tóm tắt câu hỏi.

Câu trả lời mẫu

기다려 주셔서 감사합니다. 아까 질문하신 프로젝트 경험에 대해 이어서 말씀드리겠습니다.

Cảm ơn anh/chị đã chờ. Tôi xin tiếp tục trình bày về kinh nghiệm dự án mà anh/chị hỏi lúc nãy.

Người phỏng vấn hỏi

네, 인사팀 김민지입니다. 무슨 일로 연락 주셨어요?

Gợi ý: Giới thiệu mình là ai, phỏng vấn ngày nào, cho vị trí gì, rồi nêu mục đích gọi.

Câu trả lời mẫu

안녕하세요. 지난주 금요일에 Java 개발자 포지션으로 면접을 본 응우옌이라고 합니다. 결과 발표 일정이 궁금해서 연락드렸습니다.

Xin chào. Tôi là Nguyễn, người đã phỏng vấn vị trí lập trình viên Java vào thứ Sáu tuần trước. Tôi liên lạc vì muốn biết lịch thông báo kết quả ạ.

Người phỏng vấn hỏi

아, 네. 결과는 이번 주 안에 메일로 안내드릴 예정이에요.

Gợi ý: HR báo kết quả trong tuần qua email. Cảm ơn và chào kết thúc lịch sự.

Câu trả lời mẫu

네, 알겠습니다. 바쁘신데 확인해 주셔서 감사합니다. 좋은 하루 보내세요.

Vâng, tôi hiểu rồi. Cảm ơn chị đã kiểm tra giúp dù đang bận. Chúc chị một ngày tốt lành.

Người phỏng vấn hỏi

(며칠 후) 합격하셨습니다. 축하드려요. 처우 조건은 메일로 보내 드렸는데, 확인해 보시고 회신 부탁드립니다.

Gợi ý: Nhận tin trúng tuyển. Cảm ơn, nói sẽ xem điều kiện và trả lời trước một thời hạn cụ thể.

Câu trả lời mẫu

정말 감사합니다. 보내 주신 조건은 꼼꼼히 확인해 보고, 이번 주 수요일까지 회신드리겠습니다.

Thật sự cảm ơn chị. Tôi sẽ xem kỹ các điều kiện chị gửi và trả lời trước thứ Tư tuần này ạ.

Người phỏng vấn hỏi

객체지향 프로그래밍의 특징을 간단히 설명해 주세요.

Gợi ý: Câu hỏi kinh điển: 4 đặc trưng OOP. Nói tên và giải thích rất ngắn, không cần quá dài.

Câu trả lời mẫu

캡슐화, 상속, 다형성, 추상화가 있습니다. 예를 들어 캡슐화는 데이터를 private으로 숨기고, 메서드를 통해서만 접근하게 하는 것입니다.

Có tính đóng gói, kế thừa, đa hình và trừu tượng. Ví dụ, đóng gói là ẩn dữ liệu bằng private và chỉ cho truy cập qua phương thức.

Người phỏng vấn hỏi

인터페이스와 추상 클래스의 차이는 무엇인가요?

Gợi ý: Hỏi khác nhau interface và abstract class. Ý: đa kế thừa interface, abstract class có field/constructor, mục đích sử dụng.

Câu trả lời mẫu

인터페이스는 여러 개를 구현할 수 있지만, 추상 클래스는 하나만 상속할 수 있습니다. 공통 기능과 상태가 필요하면 추상 클래스를, 역할만 정의할 때는 인터페이스를 사용합니다.

Có thể implement nhiều interface nhưng chỉ kế thừa được một abstract class. Khi cần chức năng và trạng thái dùng chung thì dùng abstract class, khi chỉ định nghĩa vai trò thì dùng interface.

Người phỏng vấn hỏi

ArrayList와 HashMap은 각각 언제 사용하세요?

Gợi ý: Hỏi khi nào dùng ArrayList, HashMap. Ý: List giữ thứ tự, truy cập theo index; Map tìm nhanh theo key.

Câu trả lời mẫu

순서대로 데이터를 저장하고 반복할 때는 ArrayList를, 키로 값을 빠르게 찾아야 할 때는 HashMap을 사용합니다. 예를 들어 코드값으로 코드명을 찾을 때 HashMap을 씁니다.

Khi lưu dữ liệu theo thứ tự và duyệt lặp thì tôi dùng ArrayList, khi cần tìm nhanh giá trị theo key thì dùng HashMap. Ví dụ, khi tìm tên mã theo giá trị mã, tôi dùng HashMap.

Người phỏng vấn hỏi

스프링의 DI, 의존성 주입에 대해 설명해 주시겠어요?

Gợi ý: Giải thích DI. Ý: Spring tạo và tiêm object (bean), giảm phụ thuộc, dễ test. Nên nhắc constructor injection.

Câu trả lời mẫu

객체를 직접 new로 만들지 않고, 스프링 컨테이너가 필요한 객체를 주입해 주는 것입니다. 그래서 클래스 간의 결합도가 낮아지고 테스트하기도 쉬워집니다. 저는 주로 생성자 주입을 사용합니다.

Đó là việc không tự tạo object bằng new mà để Spring container tiêm object cần thiết vào. Nhờ vậy độ phụ thuộc giữa các class giảm và việc test cũng dễ hơn. Tôi chủ yếu dùng constructor injection.

Người phỏng vấn hỏi

@Transactional은 어디에 붙이고, 어떤 경우에 롤백되나요?

Gợi ý: Hỏi vị trí đặt @Transactional và điều kiện rollback. Ý: đặt ở Service, mặc định rollback với RuntimeException, checked exception cần rollbackFor.

Câu trả lời mẫu

보통 서비스 계층의 메서드에 붙입니다. 기본적으로 RuntimeException이 발생하면 롤백되고, 체크 예외도 롤백하려면 rollbackFor를 지정해야 합니다.

Thường tôi đặt ở method của tầng service. Mặc định khi xảy ra RuntimeException thì sẽ rollback, còn muốn rollback cả checked exception thì phải chỉ định rollbackFor.

Người phỏng vấn hỏi

실무에서 트랜잭션 때문에 문제가 생긴 적이 있나요?

Gợi ý: Hỏi kinh nghiệm thực tế. Kể ngắn: vấn đề, nguyên nhân, cách sửa (ví dụ gọi method nội bộ nên @Transactional không áp dụng).

Câu trả lời mẫu

같은 클래스 안에서 메서드를 호출해서 @Transactional이 적용되지 않은 적이 있었습니다. 원인을 찾은 후에 트랜잭션이 필요한 로직을 다른 서비스로 분리해서 해결했습니다.

Đã có lần @Transactional không được áp dụng vì tôi gọi method trong cùng một class. Sau khi tìm ra nguyên nhân, tôi tách logic cần transaction sang service khác để giải quyết.

Người phỏng vấn hỏi

마이바티스에서 #{}와 ${}의 차이를 알고 계세요?

Gợi ý: Câu hỏi bảo mật quen thuộc. Ý: #{} dùng PreparedStatement (an toàn), ${} nối chuỗi trực tiếp (nguy cơ SQL injection).

Câu trả lời mẫu

#{}는 PreparedStatement 파라미터로 바인딩되어서 안전하고, ${}는 문자열이 그대로 들어가서 SQL 인젝션 위험이 있습니다. 그래서 ${}는 꼭 필요한 경우에만 값을 검증한 후에 사용합니다.

#{} được bind làm tham số của PreparedStatement nên an toàn, còn ${} chèn nguyên chuỗi vào nên có nguy cơ SQL injection. Vì vậy tôi chỉ dùng ${} khi thật sự cần, sau khi đã kiểm tra giá trị.

Người phỏng vấn hỏi

검색 조건이 여러 개일 때 동적 SQL은 어떻게 작성하세요?

Gợi ý: Hỏi SQL động. Ý: dùng <if>, <where>, <choose> của MyBatis.

Câu trả lời mẫu

마이바티스의 <where>와 <if> 태그를 사용해서 값이 있는 조건만 쿼리에 추가되도록 작성합니다. 조건 중 하나만 선택해야 할 때는 <choose>를 사용합니다.

Tôi dùng thẻ <where> và <if> của MyBatis để chỉ những điều kiện có giá trị mới được thêm vào câu truy vấn. Khi chỉ được chọn một trong các điều kiện thì tôi dùng <choose>.

Người phỏng vấn hỏi

느린 쿼리를 개선해 본 경험이 있으면 말씀해 주세요.

Gợi ý: Hỏi kinh nghiệm tối ưu SQL. Kể: xem execution plan, thêm index, sửa điều kiện làm mất index, kết quả.

Câu trả lời mẫu

실행 계획을 확인해 보니 조회 조건 컬럼에 함수를 사용해서 인덱스를 타지 않았습니다. 조건을 수정하고 인덱스를 추가해서 30초 걸리던 쿼리를 1초 이내로 줄였습니다.

Kiểm tra execution plan thì thấy cột điều kiện tra cứu bị dùng hàm nên không sử dụng được index. Tôi sửa điều kiện và thêm index, giảm câu truy vấn mất 30 giây xuống dưới 1 giây.

Người phỏng vấn hỏi

전자정부 표준프레임워크를 사용해 보셨나요?

Gợi ý: Hỏi kinh nghiệm eGovFrame. Nói phiên bản/dự án và điểm bạn biết (dựa trên Spring, cấu trúc chuẩn).

Câu trả lời mẫu

네, 공공기관 프로젝트에서 전자정부 프레임워크 3.x 버전으로 개발했습니다. 스프링 기반이라서 구조를 이해하는 데 어렵지 않았습니다.

Vâng, tôi đã phát triển bằng eGovFrame phiên bản 3.x trong một dự án của cơ quan nhà nước. Vì nó dựa trên Spring nên việc hiểu cấu trúc không khó với tôi.

Người phỏng vấn hỏi

프로젝트의 계층 구조는 어떻게 되어 있었나요?

Gợi ý: Hỏi cấu trúc layer. Ý: Controller - Service (interface + Impl) - DAO/Mapper - DB, mỗi tầng làm gì.

Câu trả lời mẫu

컨트롤러, 서비스, DAO로 나뉘어 있었습니다. 컨트롤러는 요청을 받고, 서비스에서 비즈니스 로직과 트랜잭션을 처리하고, DAO에서 마이바티스로 DB에 접근했습니다.

Dự án được chia thành controller, service và DAO. Controller nhận request, service xử lý logic nghiệp vụ và transaction, DAO truy cập DB bằng MyBatis.

Người phỏng vấn hỏi

SI 프로젝트는 일정이 빡빡한데, 산출물 작성도 해 보셨어요?

Gợi ý: Hỏi về tài liệu (산출물) trong dự án SI: 화면 설계서, 단위 테스트 결과서... Nói loại tài liệu bạn đã viết.

Câu trả lời mẫu

네, 화면 설계서와 단위 테스트 결과서를 작성했습니다. 개발이 끝난 화면은 바로 테스트 결과를 정리해 두어서 마감 직전에 일이 몰리지 않도록 했습니다.

Vâng, tôi đã viết tài liệu thiết kế màn hình và báo cáo kết quả unit test. Màn hình nào phát triển xong là tôi tổng hợp kết quả test ngay để công việc không bị dồn vào sát hạn chót.

Người phỏng vấn hỏi

리액트는 어느 정도 다뤄 보셨어요?

Gợi ý: Hỏi mức độ kinh nghiệm React. Trả lời trung thực: dùng ở đâu, bao lâu, làm được gì.

Câu trả lời mẫu

실무에서는 1년 정도 사용했고, 주로 기존 화면에 컴포넌트를 추가하거나 수정하는 일을 했습니다. 개인 프로젝트에서는 처음부터 직접 설계해서 배포까지 해 봤습니다.

Trong công việc tôi dùng khoảng 1 năm, chủ yếu thêm hoặc sửa component cho các màn hình có sẵn. Trong dự án cá nhân thì tôi đã tự thiết kế từ đầu và deploy luôn.

Người phỏng vấn hỏi

useEffect는 언제 사용하나요?

Gợi ý: Giải thích khái niệm kỹ thuật bằng tiếng Hàn đơn giản: side effect, gọi API, dependency array.

Câu trả lời mẫu

렌더링이 끝난 후에 API 호출이나 이벤트 등록 같은 부수 효과를 처리할 때 사용합니다. 의존성 배열에 넣은 값이 바뀔 때만 다시 실행됩니다.

Dùng để xử lý side effect như gọi API hay đăng ký sự kiện sau khi render xong. Nó chỉ chạy lại khi giá trị trong dependency array thay đổi.

Người phỏng vấn hỏi

상태 관리는 어떻게 하셨어요? 라이브러리를 쓰셨나요?

Gợi ý: Hỏi cách quản lý state. Nêu lựa chọn và lý do: dự án nhỏ dùng useState/Context, lớn mới cần thư viện.

Câu trả lời mẫu

프로젝트 규모가 크지 않아서 useState와 Context만으로 관리했습니다. 상태가 복잡해지면 그때 라이브러리 도입을 검토하는 게 맞다고 생각합니다.

Vì quy mô dự án không lớn nên tôi chỉ dùng useState và Context để quản lý. Tôi nghĩ khi state trở nên phức tạp thì lúc đó mới nên cân nhắc đưa thư viện vào.

Người phỏng vấn hỏi

조회 화면이 너무 느리다는 요청이 들어오면 어떻게 원인을 찾으세요?

Gợi ý: Mô tả quy trình tìm nguyên nhân: đo thời gian, xác định phần chậm (SQL hay app), xem execution plan.

Câu trả lời mẫu

먼저 어느 구간이 느린지 로그로 처리 시간을 측정합니다. 쿼리가 원인이라면 실행 계획을 확인해서 풀 스캔이 발생하는지 살펴봅니다.

Đầu tiên tôi đo thời gian xử lý bằng log xem đoạn nào chậm. Nếu nguyên nhân là query thì tôi kiểm tra execution plan xem có full scan không.

Người phỏng vấn hỏi

실제로 튜닝해서 개선한 사례가 있으면 말씀해 주세요.

Gợi ý: Kể ví dụ có số liệu trước/sau. Con số làm câu trả lời thuyết phục.

Câu trả lời mẫu

주문 조회 쿼리에서 날짜 컬럼에 함수를 사용해서 인덱스를 타지 못하고 있었습니다. 조건을 범위 검색으로 바꿨더니 12초 걸리던 조회가 1초 이내로 줄었습니다.

Ở query tra cứu đơn hàng, vì dùng hàm trên cột ngày nên không dùng được index. Tôi đổi điều kiện sang tìm theo khoảng thì lần tra cứu mất 12 giây giảm xuống dưới 1 giây.

Người phỏng vấn hỏi

인덱스를 많이 만들면 항상 좋은 건가요?

Gợi ý: Câu hỏi bẫy. Trả lời: không, index làm chậm insert/update và tốn dung lượng.

Câu trả lời mẫu

아니요. 조회는 빨라질 수 있지만 데이터를 등록하거나 수정할 때마다 인덱스도 갱신해야 해서 오히려 느려질 수 있습니다. 그래서 자주 사용하는 조건 위주로 만드는 게 좋다고 생각합니다.

Không ạ. Tra cứu có thể nhanh hơn, nhưng mỗi lần thêm hay sửa dữ liệu thì index cũng phải cập nhật nên có khi lại chậm đi. Vì vậy tôi nghĩ nên tạo chủ yếu cho các điều kiện hay dùng.

Người phỏng vấn hỏi

회원 정보를 수정하는 API를 만든다면 URL과 메서드를 어떻게 설계하시겠어요?

Gợi ý: Mô tả bằng tiếng Hàn: dùng PUT/PATCH, URL theo tài nguyên. Đọc ký hiệu như người Hàn: 슬래시, 아이디.

Câu trả lời mẫu

PATCH 메서드를 사용해서 /members/{id} 형태로 만들겠습니다. 일부 항목만 수정하는 경우가 많아서 PUT보다 PATCH가 더 적합하다고 생각합니다.

Tôi sẽ dùng method PATCH với dạng /members/{id}. Vì thường chỉ sửa một số trường nên tôi nghĩ PATCH phù hợp hơn PUT.

Người phỏng vấn hỏi

요청한 회원이 없으면 어떤 응답을 주시겠어요?

Gợi ý: Mã lỗi HTTP: 404 khi không có tài nguyên, kèm body lỗi rõ ràng.

Câu trả lời mẫu

404 상태 코드를 반환하고, 응답 본문에 에러 코드와 메시지를 같이 내려 주겠습니다. 그래야 화면에서 상황에 맞는 안내를 보여 줄 수 있습니다.

Tôi sẽ trả mã trạng thái 404 và gửi kèm mã lỗi cùng thông báo trong body. Như vậy màn hình mới hiển thị được hướng dẫn phù hợp với tình huống.

Người phỏng vấn hỏi

API 스펙이 바뀌면 프론트 팀과는 어떻게 맞추세요?

Gợi ý: Hỏi về phối hợp. Nêu: cập nhật tài liệu API (Swagger), thông báo trước, giữ tương thích ngược.

Câu trả lời mẫu

변경된 부분은 Swagger 문서에 먼저 반영하고, 변경 내용과 적용 일정을 프론트 팀에 미리 공유합니다. 가능하면 기존 필드는 한동안 유지해서 호환성을 지키려고 합니다.

Phần thay đổi tôi cập nhật vào tài liệu Swagger trước, rồi chia sẻ trước nội dung thay đổi và lịch áp dụng cho team frontend. Nếu được, tôi giữ các trường cũ thêm một thời gian để đảm bảo tương thích.

Người phỏng vấn hỏi

팀에서 Git 브랜치는 어떻게 관리하셨어요?

Gợi ý: Mô tả chiến lược branch: feature branch, PR, merge vào develop/main sau khi review.

Câu trả lời mẫu

기능별로 브랜치를 따로 만들고, 작업이 끝나면 PR을 올려서 리뷰를 받은 후에 develop 브랜치에 머지했습니다. 배포할 때는 main 브랜치에 반영했습니다.

Chúng tôi tạo branch riêng cho từng chức năng, làm xong thì tạo PR, được review rồi mới merge vào branch develop. Khi deploy thì đưa vào branch main.

Người phỏng vấn hỏi

충돌이 나면 어떻게 해결하세요?

Gợi ý: Cách xử lý conflict: xem cả hai thay đổi, hỏi người viết nếu không chắc, test lại.

Câu trả lời mẫu

충돌이 난 부분에서 양쪽 변경 내용을 모두 확인하고, 의도를 잘 모르겠으면 해당 코드를 작성한 분께 직접 물어봅니다. 해결한 후에는 반드시 다시 테스트합니다.

Ở chỗ bị conflict, tôi xem cả hai bên thay đổi, nếu không rõ ý đồ thì hỏi trực tiếp người viết đoạn code đó. Giải quyết xong thì nhất định test lại.

Người phỏng vấn hỏi

코드 리뷰에서 본인 코드에 지적을 많이 받으면 어떠세요?

Gợi ý: Hỏi thái độ khi bị góp ý. Thể hiện cởi mở, coi đó là cơ hội học.

Câu trả lời mẫu

리뷰는 코드 품질을 높이는 과정이라고 생각해서 감사하게 받아들입니다. 이해가 안 되는 부분은 이유를 여쭤보고, 같은 지적을 다시 받지 않도록 따로 정리해 둡니다.

Tôi coi review là quá trình nâng cao chất lượng code nên tiếp nhận một cách biết ơn. Chỗ nào chưa hiểu thì tôi hỏi lý do, và ghi chú lại riêng để không bị nhắc lại lỗi đó.

Người phỏng vấn hỏi

스프링하고 스프링 부트는 뭐가 다른가요?

Gợi ý: Ý chính: Spring Boot giảm cấu hình nhờ auto-configuration và starter, có sẵn server nhúng (Tomcat), chạy bằng file jar.

Câu trả lời mẫu

스프링 부트는 자동 설정과 스타터 의존성 덕분에 설정을 많이 줄일 수 있습니다. 그리고 내장 톰캣이 있어서 jar 파일 하나로 바로 실행할 수 있습니다.

Nhờ auto-configuration và các dependency starter, Spring Boot giúp giảm nhiều cấu hình. Ngoài ra có Tomcat nhúng nên có thể chạy ngay chỉ với một file jar.

Người phỏng vấn hỏi

개발, 스테이징, 운영 환경마다 DB 주소가 다르면 어떻게 관리하세요?

Gợi ý: Dùng profile: application-dev.yml, application-prod.yml; mật khẩu lấy từ biến môi trường, không commit vào Git.

Câu trả lời mẫu

환경별로 application-dev.yml, application-prod.yml처럼 프로파일을 나누고, 실행할 때 프로파일을 지정합니다. 비밀번호 같은 값은 환경 변수로 넣어서 Git에는 올리지 않습니다.

Tôi tách profile theo môi trường như application-dev.yml, application-prod.yml và chỉ định profile khi chạy. Các giá trị như mật khẩu thì truyền qua biến môi trường, không đưa lên Git.

Người phỏng vấn hỏi

레거시 스프링 프로젝트를 스프링 부트로 옮긴다면 뭘 먼저 확인하시겠어요?

Gợi ý: Kiểm tra: phiên bản Java, thư viện không tương thích (javax → jakarta khi lên Boot 3), cấu hình XML, cách deploy (war/jar).

Câu trả lời mẫu

자바 버전과 라이브러리 호환성을 먼저 확인하겠습니다. 특히 스프링 부트 3는 자바 17 이상이 필요하고 javax 패키지가 jakarta로 바뀌어서 영향 범위가 큽니다. 그다음에 XML 설정을 자바 설정으로 옮기는 순서로 진행하겠습니다.

Tôi sẽ kiểm tra phiên bản Java và tính tương thích của thư viện trước. Đặc biệt Spring Boot 3 cần Java 17 trở lên và package javax đổi thành jakarta nên phạm vi ảnh hưởng lớn. Sau đó tôi chuyển cấu hình XML sang cấu hình Java.

Người phỏng vấn hỏi

API에서 예외 처리는 어떻게 하셨어요?

Gợi ý: Dùng @RestControllerAdvice + @ExceptionHandler để xử lý lỗi tập trung, trả về format lỗi chung.

Câu trả lời mẫu

@RestControllerAdvice로 전역 예외 처리 클래스를 만들고, 업무 예외와 시스템 예외를 나눠서 처리했습니다. 응답은 에러 코드와 메시지가 있는 공통 형식으로 맞췄습니다.

Tôi tạo class xử lý exception toàn cục bằng @RestControllerAdvice, tách riêng exception nghiệp vụ và exception hệ thống. Response thì thống nhất theo một format chung có mã lỗi và thông báo.

Người phỏng vấn hỏi

사용자한테는 에러 메시지를 어디까지 보여 줘야 할까요?

Gợi ý: Bảo mật: không lộ stack trace, SQL, thông tin hệ thống. Người dùng thấy thông báo dễ hiểu + mã tra cứu; chi tiết để trong log.

Câu trả lời mẫu

사용자에게는 이해하기 쉬운 메시지와 문의할 때 쓸 수 있는 오류 번호만 보여 주고, 자세한 내용은 서버 로그에만 남깁니다. 스택 트레이스나 SQL이 노출되면 보안 문제가 될 수 있기 때문입니다.

Với người dùng tôi chỉ hiển thị thông báo dễ hiểu và mã lỗi để họ dùng khi hỏi hỗ trợ, chi tiết thì chỉ ghi trong log server. Vì nếu lộ stack trace hay SQL thì có thể thành vấn đề bảo mật.

Người phỏng vấn hỏi

로그는 어떻게 남기세요? 운영에서 원인 찾기 쉽게요.

Gợi ý: Log có cấp độ (INFO/WARN/ERROR), có request ID để nối các dòng log, không ghi thông tin cá nhân.

Câu trả lời mẫu

요청마다 고유 ID를 만들어서 모든 로그에 함께 남기고, 레벨을 INFO, WARN, ERROR로 구분합니다. 개인정보는 마스킹해서 남깁니다.

Tôi tạo một ID riêng cho mỗi request và ghi kèm vào mọi dòng log, phân cấp INFO, WARN, ERROR. Thông tin cá nhân thì được che (masking) trước khi ghi.

Người phỏng vấn hỏi

같은 클래스 안에서 @Transactional 메서드를 호출하면 트랜잭션이 적용되나요?

Gợi ý: Bẫy self-invocation: gọi nội bộ không đi qua proxy nên @Transactional không có tác dụng.

Câu trả lời mẫu

적용되지 않습니다. 스프링 트랜잭션은 프록시를 통해서 동작하는데, 같은 클래스 안에서 호출하면 프록시를 거치지 않기 때문입니다. 그래서 그런 경우에는 메서드를 다른 빈으로 분리합니다.

Không được áp dụng. Transaction của Spring hoạt động thông qua proxy, mà gọi trong cùng class thì không đi qua proxy. Vì vậy trong trường hợp đó tôi tách method sang một bean khác.

Người phỏng vấn hỏi

저장 중에 실패해도 오류 이력은 남기고 싶으면 어떻게 하세요?

Gợi ý: Dùng propagation REQUIRES_NEW cho method ghi log lỗi để nó commit riêng, không bị rollback cùng.

Câu trả lời mẫu

이력 저장 메서드에 propagation을 REQUIRES_NEW로 지정해서 별도의 트랜잭션으로 처리합니다. 그러면 본 작업이 롤백되더라도 이력은 커밋됩니다.

Tôi đặt propagation REQUIRES_NEW cho method lưu lịch sử để xử lý bằng transaction riêng. Như vậy dù công việc chính bị rollback thì lịch sử vẫn được commit.

Người phỏng vấn hỏi

조회만 하는 서비스에도 트랜잭션을 거세요?

Gợi ý: @Transactional(readOnly = true): rõ ý đồ, một số DB/ORM tối ưu, tránh ghi nhầm.

Câu trả lời mẫu

조회 메서드에는 readOnly = true를 붙입니다. 의도가 명확해지고, JPA를 사용할 때는 변경 감지를 하지 않아서 성능에도 도움이 됩니다.

Với method tra cứu tôi gắn readOnly = true. Ý đồ rõ ràng hơn, và khi dùng JPA thì không chạy dirty checking nên cũng có lợi cho hiệu năng.

Người phỏng vấn hỏi

JPA하고 마이바티스는 각각 언제 쓰는 게 좋다고 생각하세요?

Gợi ý: So sánh: MyBatis hợp với SQL phức tạp, báo cáo, DB có sẵn; JPA hợp với domain rõ ràng, CRUD nhiều.

Câu trả lời mẫu

복잡한 통계 쿼리가 많거나 기존 DB 구조에 맞춰야 하는 SI 프로젝트에는 마이바티스가 편하고, 도메인 중심으로 새로 만드는 서비스에는 JPA가 생산성이 좋다고 생각합니다.

Tôi nghĩ với dự án SI có nhiều query thống kê phức tạp hoặc phải theo cấu trúc DB sẵn có thì MyBatis thuận tiện hơn, còn dịch vụ làm mới theo hướng domain thì JPA cho năng suất tốt hơn.

Người phỏng vấn hỏi

JPA에서 N+1 문제가 뭔지 아세요?

Gợi ý: Giải thích: lấy N bản ghi cha rồi mỗi bản ghi lại query thêm con → 1 + N query. Cách xử lý: fetch join, EntityGraph, batch size.

Câu trả lời mẫu

목록을 한 번 조회한 다음에 연관된 엔티티를 가져오기 위해 건마다 쿼리가 추가로 실행되는 문제입니다. 페치 조인이나 배치 사이즈 설정으로 해결할 수 있습니다.

Đó là vấn đề sau khi tra cứu danh sách một lần, để lấy entity liên quan thì mỗi bản ghi lại chạy thêm một query. Có thể giải quyết bằng fetch join hoặc cấu hình batch size.

Người phỏng vấn hỏi

마이바티스 프로젝트에서 같은 쿼리가 여기저기 복사돼 있으면 어떻게 하시겠어요?

Gợi ý: Dùng <sql> + <include> để tái sử dụng đoạn SQL; refactor dần, có test.

Câu trả lời mẫu

<sql> 태그로 공통 부분을 분리하고 <include>로 재사용하겠습니다. 한 번에 다 바꾸지 않고, 수정이 필요한 화면부터 조금씩 정리하면서 테스트하겠습니다.

Tôi sẽ tách phần chung bằng thẻ <sql> và tái sử dụng bằng <include>. Không đổi hết một lần, mà dọn dần từ những màn hình cần sửa, vừa làm vừa test.

Người phỏng vấn hỏi

로그인 처리는 세션 방식과 JWT 방식 중에 어떤 걸 써 보셨어요?

Gợi ý: Nêu đã dùng gì, và khác biệt chính: session lưu ở server, JWT không trạng thái hợp với mobile/nhiều server.

Câu trả lời mẫu

사내 시스템에서는 세션 방식을 사용했고, 모바일 앱과 함께 쓰는 API 서버에서는 JWT를 사용했습니다. 서버가 여러 대일 때는 JWT가 상태를 저장하지 않아서 확장하기 편했습니다.

Với hệ thống nội bộ tôi dùng session, còn với API server dùng chung với app mobile thì dùng JWT. Khi có nhiều server, JWT không lưu trạng thái nên dễ mở rộng hơn.

Người phỏng vấn hỏi

비밀번호는 DB에 어떻게 저장하세요?

Gợi ý: Hash một chiều có salt (BCrypt), không mã hóa hai chiều, không lưu plain text.

Câu trả lời mẫu

BCrypt 같은 단방향 해시로 저장합니다. 복호화할 수 없기 때문에 유출되더라도 원래 비밀번호를 알아내기 어렵습니다.

Tôi lưu bằng hash một chiều như BCrypt. Vì không giải mã được nên dù bị lộ cũng khó biết mật khẩu gốc.

Người phỏng vấn hỏi

메뉴나 버튼별로 권한을 다르게 줘야 하면 어떻게 구현하세요?

Gợi ý: Kiểm tra quyền ở cả hai phía: frontend ẩn nút, backend bắt buộc kiểm tra lại (không tin client).

Câu trả lời mẫu

권한 정보를 DB 테이블로 관리하고, 화면에서는 권한이 없는 버튼을 숨깁니다. 하지만 화면만 막으면 안 되기 때문에 서버 API에서도 반드시 권한을 다시 확인합니다.

Tôi quản lý thông tin quyền bằng bảng trong DB, trên màn hình thì ẩn các nút không có quyền. Nhưng chỉ chặn ở màn hình là chưa đủ, nên ở API phía server nhất định cũng kiểm tra quyền lại.

Người phỏng vấn hỏi

배치 개발 경험이 있으세요? 어떤 걸 만드셨어요?

Gợi ý: Kể batch cụ thể: làm gì, chạy khi nào, lượng dữ liệu, công nghệ (Spring Batch, @Scheduled, Quartz).

Câu trả lời mẫu

네, 매일 새벽 2시에 매장별 매출 데이터를 집계하는 배치를 Spring Batch로 만들었습니다. 하루에 약 50만 건 정도를 처리했습니다.

Có, tôi đã làm batch bằng Spring Batch để tổng hợp dữ liệu doanh thu theo cửa hàng, chạy lúc 2 giờ sáng mỗi ngày. Mỗi ngày xử lý khoảng 500 nghìn bản ghi.

Người phỏng vấn hỏi

배치가 중간에 실패하면 어떻게 하세요?

Gợi ý: Thiết kế chạy lại được: xử lý theo chunk, ghi vị trí đã xử lý, chạy lại từ chỗ lỗi; báo động cho người phụ trách.

Câu trả lời mẫu

청크 단위로 커밋하고 처리 위치를 기록해 두었기 때문에 실패한 지점부터 다시 실행할 수 있게 했습니다. 그리고 실패하면 담당자에게 메일 알림이 가도록 했습니다.

Vì commit theo từng chunk và ghi lại vị trí đã xử lý, tôi làm cho batch có thể chạy lại từ điểm bị lỗi. Ngoài ra nếu thất bại thì sẽ gửi email cảnh báo cho người phụ trách.

Người phỏng vấn hỏi

배치 때문에 새벽에 DB가 느려진다는 얘기가 나오면요?

Gợi ý: Giảm tải: chạy ngoài giờ cao điểm, chia nhỏ commit, index phù hợp, tránh khóa bảng lâu; trao đổi với DBA.

Câu trả lời mẫu

처리 단위를 작게 나눠서 락이 오래 잡히지 않게 하고, 실행 계획을 보고 필요한 인덱스가 있는지 확인하겠습니다. 다른 작업과 시간이 겹치면 DBA와 상의해서 실행 시간을 조정하겠습니다.

Tôi sẽ chia nhỏ đơn vị xử lý để không giữ lock quá lâu, xem execution plan để kiểm tra có cần index không. Nếu trùng giờ với tác vụ khác thì bàn với DBA để điều chỉnh giờ chạy.

Người phỏng vấn hỏi

단위 테스트는 작성해 보셨어요?

Gợi ý: Trả lời thật: dùng gì (JUnit 5, Mockito), test phần nào, mức độ.

Câu trả lời mẫu

네, JUnit 5와 Mockito로 서비스 계층 테스트를 작성했습니다. 특히 금액 계산이나 상태 변경처럼 업무 규칙이 복잡한 부분은 반드시 테스트를 작성했습니다.

Có, tôi viết test cho tầng service bằng JUnit 5 và Mockito. Đặc biệt những phần có quy tắc nghiệp vụ phức tạp như tính tiền hay đổi trạng thái thì tôi luôn viết test.

Người phỏng vấn hỏi

Mockito는 왜 쓰나요?

Gợi ý: Mock để cô lập: thay DB, API ngoài bằng đối tượng giả, test chạy nhanh và ổn định.

Câu trả lời mẫu

DB나 외부 API 같은 의존 대상을 가짜 객체로 바꿔서 테스트하려는 로직만 따로 검증할 수 있기 때문입니다. 그래서 테스트도 빠르고 결과도 안정적입니다.

Vì có thể thay các đối tượng phụ thuộc như DB hay API bên ngoài bằng đối tượng giả để kiểm tra riêng phần logic cần test. Nhờ vậy test chạy nhanh và kết quả ổn định.

Người phỏng vấn hỏi

일정이 바빠서 테스트 쓸 시간이 없다고 하면 어떻게 하세요?

Gợi ý: Ưu tiên: ít nhất test phần rủi ro cao; giải thích lợi ích (giảm bug khi sửa sau); thêm test khi sửa bug.

Câu trả lời mẫu

전부는 못 하더라도 금액 계산처럼 틀리면 영향이 큰 부분은 꼭 테스트를 작성하겠습니다. 그리고 버그를 수정할 때마다 그 케이스의 테스트를 추가해서 점점 늘려 가겠습니다.

Dù không làm được hết, những phần mà sai thì ảnh hưởng lớn như tính tiền thì tôi nhất định viết test. Và mỗi khi sửa bug tôi thêm test cho trường hợp đó để tăng dần lên.

Người phỏng vấn hỏi

스레드 세이프하다는 게 무슨 뜻인가요?

Gợi ý: Định nghĩa: nhiều thread dùng cùng lúc mà kết quả vẫn đúng.

Câu trả lời mẫu

여러 스레드가 동시에 같은 객체를 사용해도 결과가 항상 올바르게 나오는 것을 말합니다.

Nghĩa là dù nhiều thread cùng sử dụng một đối tượng thì kết quả vẫn luôn đúng.

Người phỏng vấn hỏi

스프링 빈은 기본이 싱글톤인데, 서비스 클래스에 필드로 상태를 저장하면 어떻게 되나요?

Gợi ý: Bean singleton dùng chung cho mọi request → field lưu trạng thái bị ghi đè lẫn nhau. Dùng biến cục bộ.

Câu trả lời mẫu

모든 요청이 같은 인스턴스를 공유하기 때문에 동시에 들어온 요청끼리 값이 섞일 수 있습니다. 그래서 상태는 필드가 아니라 메서드 안의 지역 변수로 처리해야 합니다.

Vì mọi request dùng chung một instance nên giá trị giữa các request đến cùng lúc có thể bị lẫn vào nhau. Do đó trạng thái phải xử lý bằng biến cục bộ trong method, không phải bằng field.

Người phỏng vấn hỏi

실무에서 동시성 문제를 겪어 본 적이 있나요?

Gợi ý: Kể ví dụ: SimpleDateFormat dùng chung dạng static gây sai ngày; sửa bằng DateTimeFormatter (thread-safe).

Câu trả lời mẫu

네, static으로 공유하던 SimpleDateFormat 때문에 가끔 날짜가 이상하게 변환되는 문제가 있었습니다. 스레드 세이프한 DateTimeFormatter로 바꿔서 해결했습니다.

Có, từng có lỗi thỉnh thoảng ngày bị chuyển đổi sai do dùng chung SimpleDateFormat dạng static. Tôi đổi sang DateTimeFormatter (thread-safe) để giải quyết.

Người phỏng vấn hỏi

운영 서버가 며칠에 한 번씩 OutOfMemoryError로 죽는다면 어떻게 원인을 찾으세요?

Gợi ý: Lấy heap dump (thêm option HeapDumpOnOutOfMemoryError), phân tích bằng công cụ (Eclipse MAT) xem object nào chiếm nhiều.

Câu trả lời mẫu

먼저 OOM이 발생할 때 힙 덤프가 남도록 JVM 옵션을 설정합니다. 그리고 덤프 파일을 분석 툴로 열어서 어떤 객체가 메모리를 많이 차지하고 있는지 확인합니다.

Đầu tiên tôi cấu hình option JVM để khi xảy ra OOM thì để lại heap dump. Sau đó mở file dump bằng công cụ phân tích để xem đối tượng nào đang chiếm nhiều bộ nhớ.

Người phỏng vấn hỏi

분석해 보니 static Map에 캐시 데이터가 계속 쌓이고 있었어요. 어떻게 고치시겠어요?

Gợi ý: Rò rỉ do cache không giới hạn. Sửa: giới hạn kích thước + thời gian hết hạn (Caffeine, Spring Cache), hoặc bỏ cache tự viết.

Câu trả lời mẫu

크기 제한과 만료 시간이 없는 게 원인이라서, 최대 개수와 만료 시간을 설정할 수 있는 캐시 라이브러리로 바꾸겠습니다. 그리고 메모리 사용량을 모니터링해서 다시 늘어나지 않는지 확인하겠습니다.

Nguyên nhân là không có giới hạn kích thước và thời gian hết hạn, nên tôi sẽ đổi sang thư viện cache có thể cấu hình số lượng tối đa và thời gian hết hạn. Sau đó theo dõi lượng bộ nhớ sử dụng để chắc chắn nó không tăng lại.

Người phỏng vấn hỏi

장애 당시에 고객한테는 어떻게 보고하셨을 것 같아요?

Gợi ý: Báo cáo sự cố: hiện tượng, ảnh hưởng, biện pháp tạm thời, nguyên nhân, biện pháp phòng tái phát (재발 방지 대책).

Câu trả lời mẫu

현상과 영향 범위, 임시 조치를 먼저 보고드리고, 원인 분석이 끝나면 원인과 재발 방지 대책을 장애 보고서로 정리해서 공유하겠습니다.

Tôi sẽ báo cáo trước hiện tượng, phạm vi ảnh hưởng và biện pháp tạm thời, rồi khi phân tích nguyên nhân xong thì tổng hợp nguyên nhân và biện pháp ngăn tái phát thành báo cáo sự cố để chia sẻ.

Người phỏng vấn hỏi

스트림 API는 어떤 경우에 쓰세요?

Gợi ý: Dùng để lọc/biến đổi/tổng hợp collection gọn gàng; nhưng logic phức tạp thì vòng for dễ đọc hơn.

Câu trả lời mẫu

리스트에서 조건에 맞는 데이터를 걸러 내거나 그룹별로 합계를 낼 때 주로 사용합니다. 다만 로직이 너무 복잡해지면 오히려 for문이 읽기 쉬울 때도 있어서 상황에 따라 선택합니다.

Tôi chủ yếu dùng khi lọc dữ liệu theo điều kiện từ list hoặc tính tổng theo nhóm. Tuy nhiên khi logic quá phức tạp thì đôi khi vòng for lại dễ đọc hơn, nên tôi chọn tùy tình huống.

Người phỏng vấn hỏi

Optional은 어디에 쓰는 게 좋다고 생각하세요?

Gợi ý: Dùng làm kiểu trả về khi có thể không có giá trị; không dùng cho field hay tham số; tránh get() không kiểm tra.

Câu trả lời mẫu

값이 없을 수도 있는 메서드의 반환 타입으로 쓰는 게 좋다고 생각합니다. 필드나 파라미터에는 잘 쓰지 않고, get()을 바로 호출하기보다 orElse나 orElseThrow를 사용합니다.

Tôi nghĩ nên dùng làm kiểu trả về của method có thể không có giá trị. Ít dùng cho field hay tham số, và thay vì gọi thẳng get() thì dùng orElse hoặc orElseThrow.

Người phỏng vấn hỏi

자바 17에서 실무에 도움이 된 기능이 있나요?

Gợi ý: Ví dụ: record cho DTO, text block cho SQL/JSON dài, switch expression.

Câu trả lời mẫu

record로 DTO를 간단하게 만들 수 있어서 코드가 많이 줄었습니다. 그리고 텍스트 블록 덕분에 긴 SQL이나 JSON을 문자열로 작성할 때 읽기가 쉬워졌습니다.

Nhờ record có thể tạo DTO đơn giản nên code giảm đi nhiều. Ngoài ra nhờ text block, khi viết SQL hay JSON dài dưới dạng chuỗi thì dễ đọc hơn.

Người phỏng vấn hỏi

운영 배포는 어떤 방식으로 하셨어요?

Gợi ý: Mô tả quy trình: Jenkins build → deploy lên Tomcat; deploy theo giờ được duyệt, có checklist.

Câu trả lời mẫu

Jenkins로 빌드하고 톰캣 서버에 war 파일을 배포했습니다. 운영 배포는 고객 승인을 받은 후 정해진 시간에만 진행하고, 체크리스트로 확인했습니다.

Tôi build bằng Jenkins rồi deploy file war lên server Tomcat. Deploy production chỉ tiến hành vào giờ đã định sau khi được khách duyệt, và kiểm tra bằng checklist.

Người phỏng vấn hỏi

서버에서 에러 로그는 어떻게 확인하세요?

Gợi ý: Lệnh Linux: tail -f để xem trực tiếp, grep tìm ERROR hoặc request ID, less để đọc file lớn.

Câu trả lời mẫu

tail -f로 실시간 로그를 확인하고, 특정 오류는 grep으로 에러 메시지나 요청 ID를 검색합니다. 큰 파일은 less로 열어서 시간대별로 찾아봅니다.

Tôi xem log thời gian thực bằng tail -f, lỗi cụ thể thì tìm bằng grep theo thông báo lỗi hoặc ID request. File lớn thì mở bằng less và tìm theo khung giờ.

Người phỏng vấn hỏi

배포 직후에 주요 화면에서 오류가 나면 어떻게 하시겠어요?

Gợi ý: Ưu tiên khôi phục dịch vụ: rollback về bản trước theo kế hoạch đã chuẩn bị, báo ngay, rồi mới phân tích.

Câu trả lời mẫu

먼저 미리 준비한 롤백 절차대로 이전 버전으로 되돌려서 서비스를 복구하겠습니다. 동시에 고객에게 상황을 공유하고, 원인은 개발 환경에서 분석하겠습니다.

Trước tiên tôi rollback về phiên bản trước theo quy trình đã chuẩn bị sẵn để khôi phục dịch vụ. Đồng thời chia sẻ tình hình với khách hàng, còn nguyên nhân thì phân tích trên môi trường phát triển.

Người phỏng vấn hỏi

넥사크로는 어떤 버전을 사용해 보셨어요?

Gợi ý: Hỏi phiên bản Nexacro đã dùng. Nói rõ phiên bản (넥사크로 N, 넥사크로 17...) và thời gian sử dụng.

Câu trả lời mẫu

넥사크로 17로 2년, 넥사크로 N으로 1년 정도 개발했습니다. 두 버전 모두 넥사크로 스튜디오에서 화면과 공통 함수를 만들어 봤습니다.

Tôi đã phát triển khoảng 2 năm với Nexacro 17 và 1 năm với Nexacro N. Ở cả hai phiên bản tôi đều đã làm màn hình và hàm dùng chung trong Nexacro Studio.

Người phỏng vấn hỏi

데이터셋(Dataset)이 무엇인지 설명해 주시겠어요?

Gợi ý: Câu hỏi khái niệm: Dataset là gì. Giải thích ngắn: dữ liệu dạng bảng phía client, bind với component, có trạng thái từng row.

Câu trả lời mẫu

데이터셋은 화면에서 사용하는 표 형태의 데이터입니다. 그리드 같은 컴포넌트와 바인딩해서 사용하고, 각 행의 상태를 가지고 있어서 변경된 데이터만 서버로 보낼 수 있습니다.

Dataset là dữ liệu dạng bảng dùng trên màn hình. Nó được bind với các component như Grid, và vì mỗi dòng có trạng thái riêng nên có thể chỉ gửi dữ liệu đã thay đổi lên server.

Người phỏng vấn hỏi

그리드에서 많이 사용해 본 기능은 무엇인가요?

Gợi ý: Hỏi tính năng Grid hay dùng. Kể 2-3 tính năng cụ thể (정렬, 필터, 엑셀 다운로드, 체크박스, 합계...).

Câu trả lời mẫu

헤더를 클릭해서 정렬하는 기능, 체크박스로 여러 행을 선택하는 기능, 엑셀 다운로드를 많이 구현했습니다. 합계가 필요한 화면에서는 서머리 밴드도 사용했습니다.

Tôi đã làm nhiều chức năng sắp xếp khi bấm vào header, chọn nhiều dòng bằng checkbox, và tải Excel. Ở màn hình cần tổng cộng, tôi cũng dùng summary band.

Người phỏng vấn hỏi

넥사크로에서 서버를 호출할 때 어떻게 하세요?

Gợi ý: Hỏi cách gọi server. Nói về hàm transaction(): ID, URL, dataset gửi/nhận, tham số, callback.

Câu trả lời mẫu

transaction 함수를 사용합니다. 서비스 ID와 URL, 보낼 데이터셋과 받을 데이터셋, 파라미터, 콜백 함수를 지정해서 호출합니다.

Tôi dùng hàm transaction. Tôi gọi bằng cách chỉ định service ID và URL, dataset gửi đi và dataset nhận về, tham số, và hàm callback.

Người phỏng vấn hỏi

콜백 함수에서는 주로 어떤 처리를 하세요?

Gợi ý: Hỏi xử lý trong callback. Nói: kiểm tra lỗi (errorcode), hiện thông báo, xử lý tiếp theo ID của transaction.

Câu trả lời mẫu

먼저 에러 코드를 확인해서 오류가 있으면 메시지를 보여 줍니다. 정상일 때는 서비스 ID에 따라 조회 결과를 표시하거나, 저장 완료 메시지를 보여 주고 다시 조회합니다.

Đầu tiên tôi kiểm tra mã lỗi, nếu có lỗi thì hiển thị thông báo. Khi bình thường thì tùy theo service ID, tôi hiển thị kết quả tra cứu hoặc hiện thông báo lưu xong rồi tra cứu lại.

Người phỏng vấn hỏi

그리드에서 수정한 데이터만 저장하려면 어떻게 하나요?

Gợi ý: Hỏi cách chỉ lưu dữ liệu đã sửa. Ý chính: dùng trạng thái row của Dataset (:U), server xử lý theo rowtype.

Câu trả lời mẫu

보낼 데이터셋에 ':U' 옵션을 사용하면 변경된 행만 서버로 전송됩니다. 서버에서는 행 상태를 확인해서 insert, update, delete를 나눠서 처리합니다.

Nếu dùng tùy chọn ':U' cho dataset gửi đi thì chỉ những dòng đã thay đổi được gửi lên server. Ở server, tôi kiểm tra trạng thái dòng để xử lý riêng insert, update, delete.

Người phỏng vấn hỏi

조회 결과가 5만 건 정도인데 화면이 너무 느리다고 하면, 어떻게 개선하시겠어요?

Gợi ý: Tình huống hiệu năng. Gợi ý: phân trang phía server, giới hạn điều kiện tìm kiếm, tải thêm khi cuộn.

Câu trả lời mẫu

먼저 서버에서 페이징 처리를 해서 한 번에 필요한 만큼만 가져오도록 하겠습니다. 그리고 조회 조건을 필수로 입력하게 해서 데이터 양을 줄이는 방법도 고객사와 협의하겠습니다.

Trước tiên tôi sẽ phân trang ở server để mỗi lần chỉ lấy lượng dữ liệu cần thiết. Ngoài ra, tôi cũng sẽ bàn với khách hàng phương án bắt buộc nhập điều kiện tìm kiếm để giảm lượng dữ liệu.

Người phỏng vấn hỏi

화면 쪽에서 할 수 있는 개선 방법도 있을까요?

Gợi ý: Hỏi tối ưu phía client. Ý: tắt vẽ lại (enableredraw) khi thao tác nhiều dòng, giảm cột/format phức tạp.

Câu trả lời mẫu

데이터셋에서 여러 행을 한꺼번에 수정할 때는 enableevent를 잠시 false로 해서 이벤트를 줄이고, 처리가 끝나면 다시 true로 바꿉니다. 꼭 필요하지 않은 컬럼은 그리드에서 빼는 것도 도움이 됩니다.

Khi sửa nhiều dòng Dataset cùng lúc, tôi tạm đặt enableevent = false để giảm sự kiện, xử lý xong thì bật lại true. Bỏ những cột không thật sự cần khỏi Grid cũng giúp ích.

Người phỏng vấn hỏi

그런 개선 결과는 어떻게 확인하시나요?

Gợi ý: Hỏi cách đo kết quả. Nói: đo thời gian trước/sau, so sánh bằng số liệu, chia sẻ với khách.

Câu trả lời mẫu

개선 전후로 조회 시간을 측정해서 비교합니다. 예를 들어 10초 걸리던 조회가 2초로 줄었다면, 그 결과를 정리해서 고객사에 보고합니다.

Tôi đo thời gian tra cứu trước và sau khi cải thiện để so sánh. Ví dụ, nếu lần tra cứu trước mất 10 giây nay giảm còn 2 giây, tôi tổng hợp kết quả và báo cáo cho khách hàng.

Người phỏng vấn hỏi

이력서에 넥사크로 전환 프로젝트를 하셨다고 되어 있는데, 어떤 작업이었나요?

Gợi ý: Giới thiệu dự án chuyển đổi: từ gì sang gì, lý do, phạm vi bạn phụ trách. '전환하다' = chuyển đổi.

Câu trả lời mẫu

기존 XPLATFORM 화면을 넥사크로 N으로 전환하는 프로젝트였습니다. 기술 지원이 종료되고 모바일에서도 사용해야 해서 진행하게 됐고, 저는 영업 관리 화면 40개 정도를 담당했습니다.

Đó là dự án chuyển các màn hình XPLATFORM cũ sang Nexacro N. Vì hết hỗ trợ kỹ thuật và cần dùng được cả trên mobile nên dự án được tiến hành, tôi phụ trách khoảng 40 màn hình quản lý kinh doanh.

Người phỏng vấn hỏi

전환하면서 가장 어려웠던 점은 뭐였어요?

Gợi ý: Kể một khó khăn kỹ thuật cụ thể và cách giải quyết. Ví dụ: hàm/thuộc tính không còn được hỗ trợ, script khác cú pháp, layout lệch.

Câu trả lời mẫu

자동 변환 툴을 사용해도 지원이 종료된 함수나 스크립트 문법 차이 때문에 오류가 많이 발생했습니다. 그래서 자주 나오는 변환 패턴을 목록으로 정리해서 팀 전체가 같은 방식으로 수정하도록 했습니다.

Dù dùng công cụ chuyển đổi tự động vẫn phát sinh nhiều lỗi do các hàm hết hỗ trợ và khác biệt cú pháp script. Vì vậy tôi tổng hợp các mẫu chuyển đổi hay gặp thành danh sách để cả team sửa theo cùng một cách.

Người phỏng vấn hỏi

전환 후에 기존이랑 동작이 똑같은지는 어떻게 검증하셨어요?

Gợi ý: Cách kiểm chứng: checklist hành vi màn hình cũ, so sánh kết quả tra cứu/lưu, test với người dùng (현업).

Câu trả lời mẫu

화면마다 기존 동작을 체크리스트로 정리하고, 같은 조건으로 조회하고 저장한 결과를 기존 시스템과 비교했습니다. 마지막에는 현업 담당자와 함께 확인했습니다.

Với mỗi màn hình tôi lập checklist hành vi cũ, rồi so sánh kết quả tra cứu và lưu với hệ thống cũ trong cùng điều kiện. Cuối cùng tôi kiểm tra cùng người phụ trách nghiệp vụ.

Người phỏng vấn hỏi

넥사크로 프로젝트에서 공통 함수는 어떻게 관리하셨어요?

Gợi ý: Mô tả: file thư viện chung (lib), quy tắc tiền tố (gfn_), ai được sửa.

Câu trả lời mẫu

공통 라이브러리 파일을 따로 두고 모든 화면에서 include해서 사용했습니다. 함수 이름은 gfn_으로 시작하도록 규칙을 정했고, 수정은 공통 담당자만 할 수 있게 했습니다.

Chúng tôi để riêng một file thư viện chung và include ở mọi màn hình. Quy định tên hàm bắt đầu bằng gfn_, và chỉ người phụ trách phần chung mới được sửa.

Người phỏng vấn hỏi

공통 함수에는 주로 어떤 걸 만들었어요?

Gợi ý: Nêu ví dụ cụ thể: gọi transaction chung, kiểm tra bắt buộc nhập, format ngày/tiền, mở popup, thông báo lỗi.

Câu trả lời mẫu

트랜잭션 호출, 필수 입력값 체크, 날짜와 금액 포맷, 공통 팝업 호출, 에러 메시지 표시 같은 걸 만들었습니다. 특히 트랜잭션 공통 함수에서 에러 처리를 한 곳에 모아서 화면 코드가 많이 줄었습니다.

Tôi làm các hàm như gọi transaction, kiểm tra trường bắt buộc, format ngày và tiền, mở popup chung, hiển thị thông báo lỗi. Đặc biệt việc gom xử lý lỗi về một chỗ trong hàm transaction chung giúp code màn hình giảm đi rất nhiều.

Người phỏng vấn hỏi

팝업에서 선택한 값은 부모 화면으로 어떻게 넘기세요?

Gợi ý: Kỹ thuật popup: mở bằng showModal, truyền tham số vào, trả kết quả qua close() và callback.

Câu trả lời mẫu

showModal로 팝업을 열 때 파라미터를 넘기고, 팝업에서 값을 선택하면 close 함수로 결과를 돌려줍니다. 부모 화면에서는 콜백 함수에서 그 값을 받아서 처리합니다.

Khi mở popup bằng showModal tôi truyền tham số vào, khi chọn giá trị ở popup thì trả kết quả về bằng hàm close. Màn hình cha nhận giá trị đó trong hàm callback để xử lý.

Người phỏng vấn hỏi

그리드 데이터를 엑셀로 내려받는 기능은 어떻게 구현하셨어요?

Gợi ý: Nêu: dùng ExcelExportObject của Nexacro (export phía client) hoặc tạo file ở server khi dữ liệu nhiều.

Câu trả lời mẫu

데이터가 적을 때는 넥사크로의 ExcelExportObject로 화면에서 바로 내려받게 했고, 몇만 건 이상이면 서버에서 파일을 생성해서 내려받게 했습니다.

Khi dữ liệu ít tôi cho tải trực tiếp từ màn hình bằng ExcelExportObject của Nexacro, còn từ vài chục nghìn dòng trở lên thì tạo file ở server rồi cho tải về.

Người phỏng vấn hỏi

엑셀 업로드로 데이터를 일괄 등록할 때는 뭘 주의해야 하나요?

Gợi ý: Kiểm tra dữ liệu (định dạng, bắt buộc, trùng), báo lỗi theo dòng, xử lý trong transaction.

Câu trả lời mẫu

업로드 전에 필수값, 형식, 중복 여부를 먼저 검증하고, 오류가 있는 행은 행 번호와 이유를 화면에 보여 줍니다. 저장은 하나의 트랜잭션으로 처리해서 중간에 실패하면 전체를 롤백합니다.

Trước khi tải lên tôi kiểm tra giá trị bắt buộc, định dạng và trùng lặp, dòng nào lỗi thì hiển thị số dòng và lý do trên màn hình. Việc lưu xử lý trong một transaction để nếu giữa chừng thất bại thì rollback toàn bộ.

Người phỏng vấn hỏi

10만 건짜리 엑셀을 올렸더니 서버가 멈췄다면 원인이 뭘까요?

Gợi ý: Nguyên nhân thường gặp: đọc cả file vào bộ nhớ (OOM). Giải pháp: đọc dạng streaming, insert theo batch.

Câu trả lời mẫu

파일 전체를 한 번에 메모리에 올려서 OutOfMemory가 발생했을 가능성이 큽니다. 스트리밍 방식으로 읽고 1,000건 단위로 나눠서 배치 insert하면 해결할 수 있습니다.

Nhiều khả năng do đọc toàn bộ file vào bộ nhớ một lúc nên bị OutOfMemory. Có thể giải quyết bằng cách đọc theo kiểu streaming và chia thành từng khối 1.000 dòng để insert theo batch.

Người phỏng vấn hỏi

사용자가 저장 버튼을 눌러도 아무 반응이 없다고 하면, 어디부터 확인하세요?

Gợi ý: Quy trình: tái hiện lỗi → xem log/trace phía client → xem request có lên server không → log server.

Câu trả lời mẫu

먼저 같은 조건으로 재현해 보고, 넥사크로 트레이스 로그에서 스크립트 오류가 있는지 확인합니다. 오류가 없으면 트랜잭션 요청이 서버까지 갔는지 서버 로그를 확인합니다.

Đầu tiên tôi thử tái hiện với cùng điều kiện, rồi xem trace log của Nexacro có lỗi script không. Nếu không có lỗi thì tôi xem log server để biết request transaction có lên tới server không.

Người phỏng vấn hỏi

확인해 보니 저장 전에 필수값 체크에서 조용히 return되고 있었어요. 이런 건 어떻게 막을 수 있을까요?

Gợi ý: Nguyên nhân: return mà không báo. Cách phòng: luôn hiển thị thông báo khi dừng, focus vào ô lỗi, đưa vào hàm chung.

Câu trả lời mẫu

체크에서 걸리면 반드시 어떤 항목이 문제인지 메시지를 보여 주고 해당 칸에 포커스를 주도록 공통 함수로 만들겠습니다. 그러면 모든 화면에서 같은 방식으로 처리할 수 있습니다.

Tôi sẽ làm thành hàm chung để khi kiểm tra không đạt thì nhất định hiển thị thông báo mục nào có vấn đề và focus vào ô đó. Như vậy mọi màn hình đều được xử lý theo cùng một cách.

Người phỏng vấn hỏi

운영에서만 나고 개발 서버에서는 재현이 안 되는 오류는 어떻게 하세요?

Gợi ý: Khác biệt môi trường: dữ liệu, cấu hình, phiên bản. Bổ sung log, so sánh cấu hình, xin dữ liệu điều kiện.

Câu trả lời mẫu

운영과 개발 환경의 데이터, 설정, 배포 버전 차이를 먼저 비교합니다. 그래도 원인을 모르면 관련 부분에 로그를 추가해서 배포하고, 다음에 발생했을 때 원인을 찾습니다.

Đầu tiên tôi so sánh khác biệt về dữ liệu, cấu hình và phiên bản deploy giữa môi trường vận hành và phát triển. Nếu vẫn chưa ra nguyên nhân, tôi thêm log vào phần liên quan rồi deploy, để lần sau khi lỗi xảy ra thì tìm được nguyên nhân.

Người phỏng vấn hỏi

BrSE는 어떤 역할을 한다고 생각하세요?

Gợi ý: Không chỉ là phiên dịch: hiểu yêu cầu, truyền đạt cho team, quản lý rủi ro giao tiếp.

Câu trả lời mẫu

단순한 통역이 아니라, 고객의 요구사항을 정확히 이해해서 개발팀이 구현할 수 있는 형태로 전달하는 역할이라고 생각합니다. 그리고 문화나 업무 방식의 차이 때문에 생기는 오해를 미리 막는 것도 중요합니다.

Tôi nghĩ đó không chỉ là phiên dịch, mà là hiểu chính xác yêu cầu của khách và truyền đạt cho team dev dưới dạng họ có thể triển khai. Ngoài ra, việc ngăn trước những hiểu lầm do khác biệt văn hóa và cách làm việc cũng rất quan trọng.

Người phỏng vấn hỏi

요구사항이 애매할 때는 어떻게 하세요?

Gợi ý: Không đoán: liệt kê câu hỏi, hỏi dạng A/B, ghi lại bằng văn bản.

Câu trả lời mẫu

추측해서 진행하지 않고, 애매한 부분을 질문 목록으로 정리해서 고객에게 확인합니다. 가능하면 'A 방식과 B 방식 중 어느 쪽인가요?'처럼 선택지를 드리고, 답변은 Q&A 시트에 기록해 둡니다.

Tôi không làm theo phỏng đoán, mà tổng hợp phần chưa rõ thành danh sách câu hỏi để xác nhận với khách. Nếu được, tôi đưa lựa chọn kiểu 'cách A hay cách B?', và ghi câu trả lời vào Q&A sheet.

Người phỏng vấn hỏi

한국어 실력은 어느 정도라고 보세요?

Gợi ý: Trung thực: nêu TOPIK, việc làm được, và cách bù chỗ yếu.

Câu trả lời mẫu

TOPIK 4급이 있고, 업무 회의나 메일은 문제없이 할 수 있습니다. 다만 빠른 회의에서 놓치는 부분이 있을 수 있어서, 회의 후에는 항상 회의록으로 내용을 다시 확인하고 있습니다.

Tôi có TOPIK cấp 4 và làm được họp công việc, email mà không gặp vấn đề. Tuy nhiên trong cuộc họp nhanh có thể sót vài chỗ, nên sau họp tôi luôn xác nhận lại nội dung bằng biên bản họp.

Người phỏng vấn hỏi

고객과 개발팀 사이에 오해가 생긴 경험이 있으세요?

Gợi ý: Kể ngắn theo tình huống: bối cảnh, hiểu lầm gì, hậu quả.

Câu trả lời mẫu

네, 고객이 '검토해 보겠습니다'라고 했는데 개발팀은 승인으로 이해하고 개발을 시작한 적이 있습니다. 실제로는 거절에 가까운 의미여서 이틀 정도 작업이 낭비됐습니다.

Có ạ, khách nói 'chúng tôi sẽ xem xét', nhưng team dev hiểu là đã duyệt và bắt đầu code. Thực ra ý đó gần với từ chối nên khoảng 2 ngày công bị lãng phí.

Người phỏng vấn hỏi

그때 어떻게 해결하셨어요?

Gợi ý: Hành động: xác nhận lại với khách, giải thích cho team, giảm thiệt hại.

Câu trả lời mẫu

바로 고객에게 진행 여부를 명확히 확인했고, 개발팀에는 한국 고객의 완곡한 표현을 설명했습니다. 이미 만든 코드 중 재사용할 수 있는 부분을 정리해서 손실을 줄였습니다.

Tôi lập tức xác nhận rõ với khách là có làm hay không, và giải thích cho team dev về cách nói giảm nói tránh của khách Hàn. Tôi tổng hợp phần code đã viết có thể tái sử dụng để giảm thiệt hại.

Người phỏng vấn hỏi

그 후로 바뀐 점이 있나요?

Gợi ý: Bài học → quy trình: chỉ bắt đầu khi có xác nhận bằng văn bản.

Câu trả lời mẫu

그 후로는 고객의 승인을 메일이나 티켓으로 받은 다음에 개발을 시작하는 규칙을 만들었습니다. 그리고 회의 후에는 결정 사항과 보류 사항을 나눠서 회의록을 공유하고 있습니다.

Sau đó tôi đặt quy tắc chỉ bắt đầu dev sau khi nhận được xác nhận của khách qua email hoặc ticket. Và sau họp, tôi chia sẻ biên bản tách riêng mục đã quyết định và mục còn treo.

Người phỏng vấn hỏi

개발이 일정보다 늦어질 것 같으면 언제 고객에게 알리시겠어요?

Gợi ý: Báo sớm ngay khi thấy rủi ro, không đợi tới hạn.

Câu trả lời mẫu

지연 가능성이 보이는 시점에 바로 알리겠습니다. 한국 고객은 나쁜 소식이라도 빨리 공유하는 것을 더 신뢰한다고 생각합니다.

Tôi sẽ báo ngay khi thấy có khả năng trễ. Tôi nghĩ khách Hàn tin tưởng hơn khi được chia sẻ sớm, dù là tin xấu.

Người phỏng vấn hỏi

그럼 실제로 어떻게 말씀하시겠어요? 예를 들어 보세요.

Gợi ý: Mẫu: xin lỗi ngắn → hiện trạng + lý do → lịch mới → biện pháp.

Câu trả lời mẫu

죄송합니다. 외부 API 연동에서 예상하지 못한 이슈가 있어 결제 기능 완료가 사흘 정도 늦어질 것 같습니다. 다른 기능은 예정대로 진행 중이고, 인원을 한 명 추가해서 지연을 최소화하겠습니다.

Xin lỗi anh. Do có vấn đề không lường trước khi tích hợp API bên ngoài, việc hoàn thành chức năng thanh toán sẽ trễ khoảng 3 ngày. Các chức năng khác vẫn theo đúng lịch, và chúng tôi sẽ thêm một người để giảm thiểu việc trễ.

Người phỏng vấn hỏi

고객이 화를 내면 어떻게 하시겠어요?

Gợi ý: Bình tĩnh lắng nghe, không cãi, tập trung vào giải pháp và báo cáo thường xuyên hơn.

Câu trả lời mẫu

먼저 고객의 말씀을 끝까지 듣고 불편을 드린 점을 사과하겠습니다. 그다음 만회 계획을 구체적으로 설명하고, 일정이 회복될 때까지 매일 진행 상황을 보고하겠습니다.

Trước hết tôi lắng nghe khách nói hết và xin lỗi vì đã gây bất tiện. Sau đó tôi giải thích cụ thể kế hoạch bù, và báo cáo tiến độ hằng ngày cho đến khi lịch được khôi phục.

Người phỏng vấn hỏi

릴리스 3일 전에 고객이 기능을 바꿔 달라고 하면 어떻게 하시겠어요?

Gợi ý: Quy trình: nắm rõ thay đổi → đánh giá ảnh hưởng (công số, lịch) → báo cáo và đưa phương án cho khách chọn.

Câu trả lời mẫu

먼저 변경 내용을 정확하게 확인하고, 영향 범위와 필요한 공수를 산정하겠습니다. 그다음에 이번 릴리스에 포함하는 안과 다음 릴리스로 미루는 안을 함께 말씀드리고, 고객이 선택하실 수 있게 하겠습니다.

Trước tiên tôi sẽ xác nhận chính xác nội dung thay đổi, rồi ước tính phạm vi ảnh hưởng và công số cần thiết. Sau đó tôi trình bày cả phương án đưa vào bản release lần này lẫn phương án dời sang lần sau, để khách hàng lựa chọn.

Người phỏng vấn hỏi

고객이 일정은 그대로 두고 무조건 넣어 달라고 하면요?

Gợi ý: Khách ép. Đề xuất giảm phạm vi hoặc ưu tiên, nói rõ rủi ro và xin xác nhận bằng văn bản.

Câu trả lời mẫu

그 경우에는 꼭 필요한 부분만 먼저 반영하고 나머지는 다음 릴리스에 넣는 방법을 제안하겠습니다. 그리고 테스트 기간이 줄어드는 리스크도 말씀드리고, 결정된 내용은 메일로 남겨 두겠습니다.

Trong trường hợp đó tôi sẽ đề xuất đưa vào trước những phần thật sự cần, phần còn lại để bản release sau. Tôi cũng nói rõ rủi ro do thời gian test bị rút ngắn, và lưu lại nội dung đã quyết định bằng email.

Người phỏng vấn hỏi

팀원들이 야근 때문에 불만이 많으면 어떻게 하실 거예요?

Gợi ý: Quản lý team: lắng nghe, chia lại việc, nói chuyện với PM về bù trừ.

Câu trả lời mẫu

팀원들 이야기를 먼저 들어 보고, 업무를 다시 분배할 수 있는지 확인하겠습니다. 그리고 그런 상황이 계속되면 PM과 일정이나 인원 조정에 대해 상의하겠습니다.

Tôi sẽ lắng nghe các thành viên trước, rồi xem có thể phân chia lại công việc được không. Nếu tình trạng đó kéo dài thì tôi sẽ bàn với PM về việc điều chỉnh lịch hoặc nhân sự.

Người phỏng vấn hỏi

공수 산정은 어떤 방식으로 하세요?

Gợi ý: Mô tả phương pháp: chia nhỏ công việc (WBS), tham khảo dự án cũ, cộng buffer.

Câu trả lời mẫu

작업을 화면이나 API 단위로 잘게 나누고, 비슷한 과거 프로젝트의 실적을 참고해서 산정합니다. 불확실한 부분에는 버퍼를 따로 잡아 둡니다.

Tôi chia nhỏ công việc theo đơn vị màn hình hoặc API, rồi tham khảo số liệu thực tế của các dự án tương tự trước đây để ước tính. Phần nào chưa chắc chắn thì tôi để riêng buffer.

Người phỏng vấn hỏi

진행 중에 일정이 밀릴 것 같으면 언제 고객에게 알리세요?

Gợi ý: Nguyên tắc: báo sớm ngay khi thấy rủi ro, kèm nguyên nhân và kế hoạch đối phó.

Câu trả lời mẫu

지연 가능성이 보이는 시점에 바로 알립니다. 원인과 영향, 그리고 만회 계획을 같이 정리해서 보고드립니다.

Tôi báo ngay khi thấy có khả năng trễ. Tôi tổng hợp nguyên nhân, mức ảnh hưởng và kế hoạch bù lại rồi báo cáo cùng lúc.

Người phỏng vấn hỏi

리스크는 평소에 어떻게 관리하세요?

Gợi ý: Theo dõi rủi ro: danh sách rủi ro, cập nhật hằng tuần, chia sẻ trong họp tuần.

Câu trả lời mẫu

리스크 목록을 따로 만들어서 발생 가능성과 영향도를 적어 두고, 주간 회의 때마다 업데이트해서 고객과 공유합니다.

Tôi lập riêng danh sách rủi ro, ghi khả năng xảy ra và mức độ ảnh hưởng, rồi cập nhật mỗi buổi họp tuần và chia sẻ với khách hàng.

Người phỏng vấn hỏi

한국어는 어떻게 공부하셨어요? TOPIK 급수가 있나요?

Gợi ý: Nêu cấp TOPIK và cách bạn dùng tiếng Hàn trong công việc. Khiêm tốn nhưng tự tin.

Câu trả lời mẫu

TOPIK 3급을 가지고 있습니다. 업무에서 메일이나 메신저는 한국어로 처리하고 있고, 회의에서 말하는 건 아직 부족해서 매일 따로 연습하고 있습니다.

Tôi có TOPIK cấp 3. Trong công việc tôi xử lý email và tin nhắn bằng tiếng Hàn, còn nói trong họp thì vẫn chưa tốt nên hằng ngày tôi luyện riêng.

Người phỏng vấn hỏi

(빠르게) 그러면 지난번 프로젝트에서 고객사 요구사항이 바뀌었을 때 어떤 프로세스로 처리했는지 설명해 주실 수 있을까요?

Gợi ý: Người phỏng vấn nói nhanh. Nếu chưa nghe rõ, hãy lịch sự nhờ nói lại hoặc xác nhận lại ý câu hỏi; đừng đoán mò.

Câu trả lời mẫu

죄송하지만 조금만 천천히 다시 말씀해 주시겠습니까? 요구사항이 변경됐을 때의 처리 과정을 여쭤보신 게 맞으시죠?

Xin lỗi, anh/chị có thể nói lại chậm hơn một chút được không ạ? Anh/chị đang hỏi về quy trình xử lý khi yêu cầu thay đổi, đúng không ạ?

Người phỏng vấn hỏi

네, 맞아요. 천천히 설명해 보세요.

Gợi ý: Giờ trả lời. Dùng các từ nối thứ tự: 먼저, 그다음에, 마지막으로. Câu ngắn, rõ.

Câu trả lời mẫu

먼저 변경 내용을 메일로 받아서 정리했습니다. 그다음에 개발팀과 영향 범위를 확인하고 일정을 다시 산정했습니다. 마지막으로 고객의 승인을 받은 후에 작업을 시작했습니다.

Đầu tiên tôi nhận nội dung thay đổi qua email và tổng hợp lại. Tiếp theo tôi cùng team phát triển kiểm tra phạm vi ảnh hưởng và ước tính lại lịch. Cuối cùng, sau khi khách hàng phê duyệt thì mới bắt đầu làm.

Người phỏng vấn hỏi

지금까지 어떤 테스트 업무를 해 보셨어요?

Gợi ý: Nêu số năm, loại dự án, loại test đã làm, công cụ.

Câu trả lời mẫu

3년 동안 쇼핑몰과 그룹웨어 프로젝트에서 기능 테스트와 회귀 테스트를 담당했습니다. 테스트 케이스 작성부터 결함 관리까지 했고, Jira와 Postman을 주로 사용했습니다.

Trong 3 năm, tôi phụ trách test chức năng và test hồi quy ở các dự án trang mua sắm và groupware. Tôi làm từ viết test case đến quản lý lỗi, chủ yếu dùng Jira và Postman.

Người phỏng vấn hỏi

테스트 케이스는 어떻게 설계하세요?

Gợi ý: Kỹ thuật: dựa trên spec, giá trị biên, phân vùng tương đương, case bất thường.

Câu trả lời mẫu

사양서의 요구사항별로 정상 케이스를 먼저 만들고, 경계값 분석과 동등 분할로 입력값을 나눕니다. 그리고 네트워크 끊김이나 중복 클릭 같은 예외 케이스도 꼭 추가합니다.

Tôi tạo các case bình thường trước theo từng yêu cầu trong spec, rồi chia giá trị đầu vào bằng phân tích giá trị biên và phân vùng tương đương. Tôi cũng luôn thêm các case ngoại lệ như mất mạng hay bấm trùng nhiều lần.

Người phỏng vấn hỏi

자동화 테스트 경험도 있나요?

Gợi ý: Trung thực về mức độ, nêu điều đang học.

Câu trả lời mẫu

네, 기본적인 수준입니다. Selenium으로 로그인과 주문 같은 주요 시나리오를 자동화해 본 적이 있고, 요즘은 Playwright를 공부하고 있습니다.

Vâng, ở mức cơ bản. Tôi từng tự động hóa các kịch bản chính như đăng nhập và đặt hàng bằng Selenium, và gần đây đang học Playwright.

Người phỏng vấn hỏi

좋은 버그 리포트에는 무엇이 들어가야 한다고 생각하세요?

Gợi ý: Liệt kê: tiêu đề rõ, môi trường, bước tái hiện, kết quả mong đợi/thực tế, bằng chứng, mức độ.

Câu trả lời mẫu

한눈에 알 수 있는 제목, 테스트 환경, 재현 절차, 기대 결과와 실제 결과, 그리고 스크린샷이나 로그가 들어가야 합니다. 심각도도 함께 적어서 우선순위를 판단할 수 있게 합니다.

Cần có tiêu đề nhìn là hiểu, môi trường test, các bước tái hiện, kết quả mong đợi và thực tế, cùng ảnh chụp màn hình hoặc log. Ghi kèm mức độ nghiêm trọng để có thể quyết định thứ tự ưu tiên.

Người phỏng vấn hỏi

개발자가 '이건 버그가 아니라 사양'이라고 하면 어떻게 하세요?

Gợi ý: Không cãi tay đôi; dựa vào spec, nếu spec không rõ thì hỏi khách/PO.

Câu trả lời mẫu

먼저 사양서에서 근거를 같이 확인합니다. 사양서에 없거나 해석이 다르면, 개인 판단으로 정하지 않고 PM이나 고객에게 확인해서 결과를 티켓에 남깁니다.

Trước tiên tôi cùng dev tìm căn cứ trong spec. Nếu spec không có hoặc hiểu khác nhau, tôi không tự quyết mà xác nhận với PM hoặc khách, rồi ghi kết quả vào ticket.

Người phỏng vấn hỏi

릴리스 직전에 치명적인 버그를 발견하면요?

Gợi ý: Báo ngay cho người quyết định, kèm bằng chứng và ảnh hưởng; không tự quyết dừng release.

Câu trả lời mẫu

바로 PM에게 재현 절차와 영향 범위를 공유하고, 릴리스 여부를 판단할 수 있도록 우회 방법이 있는지도 함께 알려 드립니다.

Tôi lập tức chia sẻ với PM các bước tái hiện và phạm vi ảnh hưởng, đồng thời cho biết có cách workaround hay không để PM quyết định có release hay không.

Người phỏng vấn hỏi

왜 QA 업무를 선택하셨어요?

Gợi ý: Lý do tích cực, gắn với chất lượng và người dùng.

Câu trả lời mẫu

사용자 입장에서 서비스를 보고, 문제를 출시 전에 막는 일에 보람을 느껴서 선택했습니다. 제가 찾은 결함 하나가 실제 사용자의 불편을 줄인다는 점이 좋습니다.

Tôi chọn vì thấy ý nghĩa khi nhìn dịch vụ từ góc độ người dùng và chặn được vấn đề trước khi ra mắt. Tôi thích việc một lỗi mình tìm ra giúp giảm bất tiện cho người dùng thật.

Người phỏng vấn hỏi

본인의 강점은 뭐라고 생각하세요?

Gợi ý: Một điểm mạnh + ví dụ có con số.

Câu trả lời mẫu

꼼꼼함입니다. 지난 프로젝트에서 회귀 테스트 체크리스트를 만들어서, 운영에서 발견되는 결함을 이전보다 절반 정도로 줄였습니다.

Đó là sự tỉ mỉ. Ở dự án trước tôi lập checklist test hồi quy, nhờ đó số lỗi phát hiện trên production giảm khoảng một nửa so với trước.

Người phỏng vấn hỏi

한국 고객과 일하고 싶은 이유가 있나요?

Gợi ý: Gắn với văn hóa chất lượng của Hàn và mục tiêu tiếng Hàn của bạn.

Câu trả lời mẫu

한국 고객은 품질 기준이 높고 피드백이 빨라서 QA로서 많이 성장할 수 있다고 생각합니다. 또 한국어를 계속 공부하고 있어서, 고객과 직접 소통하면서 오해를 줄이는 데 기여하고 싶습니다.

Tôi nghĩ khách Hàn có tiêu chuẩn chất lượng cao và phản hồi nhanh nên tôi có thể phát triển nhiều với vai trò QA. Hơn nữa tôi vẫn đang học tiếng Hàn, nên muốn góp phần giảm hiểu lầm bằng cách giao tiếp trực tiếp với khách.