Giải thích Spring Boot trôi chảy trong buổi phỏng vấn — Thử thách thực chiến 4 tuần
Đây là thử thách thực chiến trong 4 tuần giúp bạn trực tiếp tái hiện các API đã tạo thông qua kiểm thử và nhật ký (log), từ luồng yêu cầu, Bean và Proxy cho đến ranh giới giao dịch (transaction boundary), để có thể giải thích trôi chảy trong các buổi phỏng vấn.
🚀 Từng làm việc tại Toss, tốt nghiệp POSTECH | Nhà phát triển Backend hiện tại (+9 năm) 🎥 YouTuber 20.000 sub | Sáng tạo nội dung lập trình 📚 Giảng viên Inflearn | Tổng số học viên 18.000+ 👥 Đang vận hành cộng đồng tuyển dụng lập trình viên (8.000+) 🧩 Contributor cho nhiều dự án mã nguồn mở (Gradle, Spring AI, v.v.) 📝 Kinh nghiệm vượt qua 38 vòng hồ sơ và hơn 100 lần chỉnh sửa CV trên Kmong (Đánh giá 5.0 sao)
Truyền tải những thông tin thực tế sống động từ ngành công nghiệp một cách dễ hiểu và có tính diễn dịch.
Thử thách Spring 4 tuần · Miễn phí · 100 người đầu tiên
THỬ THÁCH DINGCO · 4 TUẦN
Từ Spring Boot chỉ viết cho chạy được, nay sẽ sẵn sàng để giải thích tường tận trong vòng 4 tuần.
Tái hiện luồng yêu cầu (request flow), bean và proxy, ranh giới transaction thông qua các bài kiểm tra và log trực tiếp, sau đó lưu lại dưới dạng một PR mỗi tuần. Sau 4 tuần, bạn sẽ nắm trong tay 18 câu trả lời phỏng vấn mà bạn có thể tự tin trả lời bằng chính mã nguồn của mình.
Miễn phí · 100 người đầu tiên
Được tạo bởi Dingcodingco, người có tổng cộng 18.000+ học viên trên Inflearn · mức độ hài lòng trung bình 4.9 · và kinh nghiệm trúng tuyển vào 38 doanh nghiệp
Thử thách này không cung cấp bài giảng hay giáo trình. Đây là một lộ trình thực thi nhằm chứng minh những nội dung bạn đã biết hoặc tự học thông qua các bài toán thực tế và GitHub PR. Chuẩn bị trước khi bắt đầu · Cần có kiến thức về cú pháp Java cơ bản và kiến thức nền tảng về Git branch, commit.
Đây là lộ trình thực thi trong 4 tuần nhằm chứng minh các khái niệm đã học thông qua mã nguồn, thực nghiệm và giải thích.
NHỮNG GÌ BẠN SẼ HOÀN THÀNH
Những gì còn lại sau khi hoàn thành
API User–Todo có thể vận hành và kiểm thử tích hợp
Mã kiểm chứng và nhật ký (log) hiển thị hoạt động của Bean, Proxy và Transaction.
18 câu trả lời phỏng vấn Spring đi kèm với bằng chứng mã nguồn thực tế
BEFORE
Gắn annotation vào và khi có phản hồi thì kết thúc việc triển khai.
AFTER
Tái hiện luồng yêu cầu, proxy, bean và ranh giới transaction thông qua kiểm thử và log, đồng thời giải thích cơ sở lựa chọn.
QUY TRÌNH LÀM VIỆC THỰC TẾ
Từ đăng ký đến đánh giá, theo đúng trình tự màn hình thực tế
Đừng sao chép và nộp địa chỉ GitHub. Trang chủ Dingco sẽ hỗ trợ từ việc chuẩn bị kho lưu trữ cá nhân, tạo nhánh nhiệm vụ và PR, cho đến việc kiểm tra đánh giá chi tiết.
1GitHub trước, Discord sau cùngSau khi hoàn tất đăng nhập Kakao và chẩn đoán sơ bộ, hãy chuẩn bị kho lưu trữ riêng tư (private repository) cá nhân, còn vai trò Discord và kênh theo khóa học sẽ được kết nối sau cùng.2Thực hiện nhiệm vụ trong kho lưu trữ riêng tư (private) của tôiTrang chủ sẽ kết nối việc tạo nhánh và PR cho 'Todo API với luồng yêu cầu rõ ràng và câu trả lời có căn cứ'. Không sao chép và dán địa chỉ PR.3Xác nhận 92 điểm và căn cứ cụ thểKiểm tra các điểm tốt và điểm cần cải thiện từ kiểm tra tự động và đánh giá AI trong phần đánh giá chi tiết của Dingco và bình luận trên GitHub PR, sau đó tiến hành chỉnh sửa trên cùng một PR đó.4Kênh vận hành Spring Challenge khóa 1Các bài đánh giá chi tiết cho từng cá nhân sẽ không được đăng lên Discord, chỉ chia sẻ tóm tắt hàng tuần và thông báo vận hành.
Màn hình trên là ví dụ được tạo dựa trên giao diện vận hành thực tế và quy tắc của kho lưu trữ/kênh. Tên kho lưu trữ, số thứ tự khóa học và điểm đánh giá sẽ thay đổi tùy theo người tham gia và khóa học.
4-WEEK ROUTE
Nhiệm vụ hàng tuần giúp chuyển đổi những nội dung đã biết thành thành quả thực tế
Mỗi tuần, bạn sẽ nộp các nội dung bao gồm: triển khai/thử nghiệm, kiểm thử/log, căn cứ lựa chọn và câu trả lời cho các câu hỏi trong cùng một PR. Các câu hỏi không phải là bài tập về nhà để trả lời theo kiểu học thuộc lòng, mà phải được trả lời dựa trên mã nguồn và minh chứng mà bạn vừa tạo ra.
W1
Từ yêu cầu web đến API đầu tiên
Quan sát HTTP và JSON, sau đó kết nối trực tiếp với Spring Boot API đang thực thi.
PR tổng hợp hàng tuầnTodo API hiển thị luồng yêu cầu và câu trả lời dựa trên bằng chứng
[필수] POST /todos là hợp đồng xác định và triển khai để trả về 201 cùng với id·title·completed đã được tạo khi đầu vào hợp lệ, và trả về lỗi chung 400 khi đầu vào không hợp lệ.
[필수] GET /todos/{id}는 존재하는 Todo에 200을, 존재하지 않는 id에 404 공통 오류를 반환하게 하고 세 경계를 실제 애플리케이션 컨텍스트의 통합 테스트로 고정합니다.
[Tất yếu] Giải thích vai trò của DispatcherServlet, Validation và HttpMessageConverter từ khi yêu cầu trở thành đối số của Controller cho đến khi trở thành phản hồi JSON, có liên hệ trực tiếp với mã nguồn và bài kiểm tra (test) của bản thân.
[선택 확장] bộ nhớ lưu trữ (memory storage) được thay thế bằng H2·JdbcTemplate storage và xác nhận xem các kiểm thử hợp đồng API tương tự có được duy trì hay không.
Bằng chứng nộp bài · Mã nguồn API có thể thực thi đã triển khai các hợp đồng 201·400·404 · Kết quả kiểm thử tích hợp thành công·thất bại xác thực·404 được chạy trong ngữ cảnh ứng dụng thực tế · Giải thích luồng yêu cầu có trích dẫn tệp và kiểm thử của bản thân · Câu trả lời cho các câu hỏi dựa trên căn cứ từ 1 đến 5 của tuần này · Commit·kết quả xác minh đã phản hồi các góp ý đánh giá (nếu có), nếu không có góp ý thì ghi lại là không có.
함께 답할 근거형 질문 5개
Yêu cầu HTTP trải qua quá trình nào để trở thành đối số của phương thức controller?
Ai là người chuyển đổi đối tượng Java thành phản hồi JSON, và bạn đã xác nhận điều đó bằng cách nào?
Tại sao bạn không phân tách nhánh trực tiếp trong mã nguồn của controller khi xác thực đầu vào thất bại?
Ranh giới nào nhất thiết phải được xác nhận bằng kiểm thử tích hợp (integration test) thay vì kiểm thử đơn vị (unit test)?
Trong hợp đồng API hiện tại, phần nào có khả năng dễ bị phá vỡ nhất và phương pháp kiểm chứng phần đó là gì?
W2
Container Spring dưới góc nhìn của Proxy, Bean và DI
Kiểm chứng sự tự động hóa của Spring thông qua mã nguồn của proxy, vòng đời của bean và tiêm chủng phụ thuộc (dependency injection).
PR tổng hợp hàng tuầnPhân tích tự động hóa Spring Container và câu trả lời dựa trên bằng chứng
[필수] Trong use case Todo, hãy tạo hai bản triển khai của cùng một interface và chỉ định tiêu chí lựa chọn bằng @Qualifier hoặc @Primary, sau đó so sánh lỗi mơ hồ trước khi chọn và việc tiêm (injection) thành công sau khi chọn thông qua các bài kiểm tra ngữ cảnh (context test) riêng biệt.
[필수] Cho thấy thông qua bài kiểm tra (test) cảnh tượng thực tế có sự khác biệt về phụ thuộc (dependency), vòng đời (lifecycle) hoặc tính năng bổ sung giữa một bean được kết nối bằng tiêm hàm tạo (constructor injection) và một đối tượng được tạo trực tiếp bằng từ khóa new.
[필수] Áp dụng tính năng bổ sung AOP vào Todo service và sử dụng AopUtils để kiểm tra xem đó có phải là proxy hay không cũng như xác nhận class đối tượng, đồng thời kiểm chứng xem advice và lệnh gọi đối tượng có được ghi lại đúng thứ tự và số lần mong đợi chỉ khi gọi thông qua proxy hay không.
[Lựa chọn mở rộng] Thêm callback vòng đời của bean hoặc proxy phạm vi (scope proxy) để so sánh thêm một ranh giới nữa do container quản lý.
Bằng chứng nộp bài · Bài kiểm tra ngữ cảnh cô lập thể hiện đồng thời lỗi mơ hồ và việc lựa chọn bean rõ ràng · Kết quả kiểm tra khẳng định loại proxy, lớp đối tượng mục tiêu và advice, thứ tự cũng như số lần gọi mục tiêu · Tài liệu liên kết sự khác biệt có thể quan sát được giữa đối tượng được tạo trực tiếp bằng từ khóa new và bean trong container · Câu trả lời cho các câu hỏi dựa trên căn cứ từ 1 đến 5 của tuần này · Kết quả kiểm tra và commit đã phản ánh các góp ý đánh giá (nếu có), nếu không có góp ý thì ghi lại là không có.
함께 답할 근거형 질문 5개
Chuyện gì sẽ xảy ra khi Spring không thể quyết định được implementation nào để inject và bạn đã giải quyết vấn đề đó như thế nào?
Tại sao tiêm phụ thuộc qua hàm tạo (constructor injection) lại có lợi cho việc kiểm thử và tính bất biến hơn so với tiêm phụ thuộc qua trường (field injection)?
Sự khác biệt quan trọng nhất giữa đối tượng do container quản lý và đối tượng được tạo trực tiếp là gì?
Làm thế nào để có thể kiểm tra bằng mã nguồn xem đó là đối tượng Proxy hay đối tượng gốc?
Nếu không có nhật ký (log) về thứ tự gọi hàm trong lần thử nghiệm này, bạn đã không thể kiểm chứng được lời giải thích nào?
W3
Phân tách các tầng và Giao dịch (Transaction)
Kiểm chứng trách nhiệm của tầng dịch vụ và ranh giới giao dịch (transaction boundary) thông qua các kịch bản thất bại.
PR Tích hợp Hàng tuầnDịch vụ bảo đảm tính nhất quán ngay cả khi thất bại và câu trả lời dựa trên bằng chứng
[필수] Triển khai repository lưu trữ User và Todo bằng H2·JdbcTemplate và service use case điều phối cả hai thay đổi đó.
[필수] 트랜잭션이 없는 서비스가 User 저장 직후 예외를 던지게 호출하고, 테스트 메서드에 @Transactional을 붙이지 않은 상태에서 예외 뒤 User 1건·Todo 0건이 남는 부분 저장을 확인합니다.
[Bắt buộc] Gọi dịch vụ có gắn @Transactional thông qua Spring Proxy từ bên ngoài để gây ra lỗi tại cùng một thời điểm, sau đó xử lý ngoại lệ và kiểm tra thông qua truy vấn riêng biệt để xác nhận User 0 bản ghi · Todo 0 bản ghi, nhằm chứng minh việc rollback của cả hai thay đổi.
[tùy chọn mở rộng] So sánh hành vi mặc định của check exception với trước và sau khi áp dụng rollbackFor, hoặc so sánh việc bỏ qua proxy khi gọi nội bộ trong cùng một class thông qua các bài kiểm tra riêng biệt.
Bằng chứng nộp bài · Mã nguồn lớp Repository và Service của User·Todo JDBC · Kết quả so sánh giữa User 1·Todo 0 (không giao dịch) và User 0·Todo 0 (có giao dịch) được xác nhận bên ngoài giao dịch thử nghiệm · Giải thích ranh giới giao dịch kết nối giữa việc gọi proxy bên ngoài và truy vấn trạng thái cơ sở dữ liệu · Câu trả lời cho các câu hỏi dựa trên căn cứ từ 1 đến 4 của tuần này · Kết quả commit/xác nhận đã phản hồi các góp ý đánh giá (nếu có), nếu không có góp ý thì ghi nhận là không có.
함께 답할 근거형 질문 4개
Tại sao ranh giới giao dịch (transaction boundary) lại được đặt ở tầng Service mà không phải ở Controller hay Repository?
Sự khác biệt trong hành vi rollback mặc định giữa checked exception và unchecked exception là gì và bạn đã kiểm chứng điều đó như thế nào?
Tại sao việc gọi nội bộ trong cùng một lớp lại có thể bỏ qua proxy giao dịch (transaction proxy)?
Tại sao bài kiểm tra rollback (hoàn tác) cần phải xác nhận đến cả trạng thái của cơ sở dữ liệu?
W4
Hoàn thiện API có thể vận hành được
Hoàn thiện API để đưa vào hồ sơ năng lực (portfolio) bằng cách áp dụng xử lý ngoại lệ, kiểm chứng, ghi nhật ký (logging) và phân trang.
PR tổng hợp hàng tuầnAPI User–Todo có thể vận hành và gói căn cứ cuối cùng
[필수] POST /users, POST /users/{userId}/todos, GET /todos/{id}, GET /users/{userId}/todos를 하나의 User–Todo 계약으로 완성하고 1주차 POST /todos 계약을 유지하거나 변경한 이유를 기록합니다.
[필수] 모든 400·404 응답을 code·message·requestId 필드가 있는 공통 형식으로 만들고, 목록 조회는 page=0·size=20 기본값, 최대 size, id 오름차순, totalElements·hasNext 메타데이터를 포함하도록 구현합니다.
[필수] Cố định danh sách trống, nhiều trang, sắp xếp ổn định, page·size sai, lỗi xác thực và 404 bằng kiểm thử tích hợp (integration test).
[필수] Kiểm tra X-Request-Id bên ngoài để tái sử dụng hoặc tạo giá trị mới và liên kết cùng một giá trị đó vào header phản hồi, phản hồi lỗi và log có cấu trúc, đồng thời loại trừ nội dung yêu cầu và thông tin xác thực khỏi log.
[tùy chọn mở rộng] Thêm thử nghiệm so sánh phân trang bằng con trỏ (cursor paging) hoặc các chỉ số quan sát đầu tiên trong số lượng yêu cầu, tỷ lệ lỗi và thời gian trễ.
Bằng chứng nộp bài · Quyết định tính tương thích của bốn endpoint User–Todo đã nêu với hợp đồng trước đó · Đặc tả lỗi chung code·message·requestId và phân trang theo thứ tự tăng dần của id ổn định · Kiểm thử tích hợp API·phân trang bao gồm cả các giá trị biên và kết quả thực hiện · Bằng chứng quan sát xác nhận cùng một requestId trong phản hồi·lỗi·log · Câu trả lời cho các câu hỏi dựa trên căn cứ từ 1~4 của tuần này · Kết quả commit·xác minh đã phản hồi các góp ý review, nếu không có góp ý thì ghi nhận không có góp ý
함께 답할 근거형 질문 4개
Việc thống nhất định dạng phản hồi lỗi mang lại những lợi ích gì cho khách hàng và người vận hành?
Tại sao bạn lại chọn phương pháp phân trang dựa trên số trang (page-based) hay dựa trên con trỏ (cursor-based) cho phù hợp với API hiện tại?
Những thông tin nào nhất định phải lưu lại trong log và những thông tin nào tuyệt đối không được lưu lại?
Chỉ số quan sát đầu tiên và việc kiểm chứng lỗi cần thêm vào trước khi vận hành thực tế API này là gì?
WEEKLY LOOP
Kết thúc thực hành của một tuần chỉ trong một PR duy nhất
Kiểm tra vấn đề thực chiến theo từng tuần
Thực hiện nhiệm vụ trên nhánh (branch) cá nhân
Nộp PR bao gồm mã nguồn, bài kiểm tra và giải thích
Kiểm tra tự động và xác nhận đánh giá của AI
Sửa cùng một PR và tự động hợp nhất
Kiểm tra PR đã vượt qua và giải thích chính thức
Phản ánh đánh giá đồng nghiệp tích cực và hồ sơ học tập của phi hành đoàn
Việc nộp bài chỉ sử dụng GitHub PR. Từ việc tạo nhánh, đánh giá cho đến việc hợp nhất chính xác head SHA, màn hình thử thách và GitHub sẽ được kết nối với nhau. Hệ thống sẽ tự động kiểm tra xem các minh chứng cần thiết có nằm trong PR hay không.
SỰ THAM GIA CỦA CREW
Chỉ thảo luận trong 20 phút về phần "Lời nhắn nhiệm vụ"
Từ tuần thứ 2, hãy để lại một lời nhắn trong PR, và các thành viên (crew) chỉ chia sẻ về những điểm bị tắc nghẽn và các cách tiếp cận khác.
Lời nhắn nhiệm vụ từ tuần thứ 2 Để lại những điểm còn vướng mắc khi nộp PR từ 10 đến 300 ký tự.
20 phút vào thời gian nhóm đã định Chia sẻ về những điểm bị tắc nghẽn và các cách tiếp cận khác nhau, mặc định vào lúc 21:15 thứ Ba.
Trưởng nhóm kết thúc trong khoảng 1~30 ký tự Từ tuần thứ 2, thành viên hoàn thành được +5 điểm, tách biệt với việc hoàn thành cá nhân.
Hoạt động thưởng cho nhóm Người tham gia không viết thêm bài viết nào khác ngoài lời nhắn thực hiện nhiệm vụ. Điểm +5 cho thành viên (crew) được tính riêng biệt với việc hoàn thành cá nhân.
BUỔI LIVE (LIVE SESSION)
Một lần trực tiếp, cùng nhau thống nhất cách thức tiến hành
Trong thời gian diễn ra thử thách, một buổi Live Session sẽ được tổ chức. Chúng ta sẽ cùng nhau thống nhất các tiêu chuẩn hoàn thành và kiểm tra trực tiếp tại chỗ quá trình nộp bài diễn ra như thế nào trên màn hình.
Hướng dẫn về cách thức tiến hành trong 4 tuần và tiêu chuẩn hoàn thành
Demo chuẩn bị nhánh (branch) nhiệm vụ đầu tiên tại buổi Kick-off thứ Hai và hướng dẫn nộp GitHub PR sau khi bắt đầu vào thứ Tư
Giải đáp Q&A trực tiếp
Link tham gia sẽ được đăng trên thông báo Discord trước khi bắt đầu. Ngay cả khi không thể tham gia trực tiếp, bạn vẫn có thể kiểm tra tiêu chuẩn hoàn thành và cách thức nộp bài trên trang chủ Dingco và thông báo Discord.
BẢN CAM KẾT THỬ THÁCH
Tự học khái niệm, cùng nhau thực hành và phản hồi
Thử thách này không cung cấp bài giảng, giáo trình, Notion hay tài liệu bổ sung. Bạn sẽ áp dụng những nội dung đã biết hoặc tự học vào các vấn đề thực tế và chứng minh thông qua GitHub PR.
Thử thách cung cấp
Các vấn đề thực tế theo từng tuần · Kho lưu trữ thực hành cá nhân (private) · Tiêu chuẩn vượt qua rõ ràng · Kiểm tra tự động và đánh giá bằng AI · So sánh với đồng nghiệp và hồ sơ hoàn thành
Người tham gia chuẩn bị
Khái niệm cơ bản của lĩnh vực tương ứng · Kinh nghiệm sử dụng Git và GitHub PR · Thời gian thực hiện mỗi tuần · Thái độ tự bổ sung các khái niệm còn thiếu
Học tập trước tùy chọn · Mua riêng · 9 giờ 58 phút
[Lv1] Spring Boot có thể "giải thích được" trong buổi phỏng vấn
Bài giảng và giáo trình này không bao gồm trong thử thách và việc học cũng không bắt buộc. Chỉ chọn khi bạn có lĩnh vực còn thiếu sót trong bài kiểm tra chẩn đoán trước hoặc khi cần bổ sung khái niệm.
Bất kể bạn đã đăng ký trên Inflearn hay chưa, hãy kiểm tra trạng thái tuyển sinh của khóa hiện tại thông qua nút ‘Xác nhận tuyển sinh·tham gia’ ở trên. Khi bạn đăng nhập bằng Kakao trên Dingco, vị trí của bạn sẽ được đảm bảo, và sau khi hoàn tất tất cả các kết nối, việc chuẩn bị tham gia sẽ sẵn sàng.
Tại trang xác nhận tuyển sinh và tham gia của Dingco, hãy chọn khóa hiện tại và đăng nhập bằng Kakao, tư cách thành viên thử thách sẽ được tạo ngay lập tức và vị trí của bạn sẽ được đảm bảo.
Sau khi vượt qua bài kiểm tra chẩn đoán trước theo từng khóa, bước kết nối GitHub sẽ được mở.
Nếu bạn kết nối GitHub trước, việc kiểm tra quyền tổ chức và chuẩn bị kho lưu trữ riêng tư (private repository) cá nhân sẽ tự động được lên lịch.
Khi kết nối Discord, quyền truy cập vào danh mục Spring Challenge khóa 1 và các kênh thông báo, tài liệu đọc, câu hỏi, tự do sẽ được thiết lập.
Tạo nhánh submit/<nhiệm vụ> trên trang chủ, push mã nguồn và gửi PR chỉ với một nút bấm.
Các commit mới nhất vượt qua kiểm tra tự động và đánh giá AI sẽ được Dingco tự động hợp nhất và cùng chúc mừng trên kênh tự do. Trên Discord của Crew, mọi người cùng chia sẻ câu hỏi và tiến độ công việc; các bài đánh giá chính thức sẽ ưu tiên mở cho các PR đã vượt qua của cùng một Crew, nếu không có sẽ tiếp tục với các PR của Crew khác trong cùng khóa. Bảng điểm sẽ được phản ánh tạm thời trong tuần và sẽ được chốt chính thức sau khi thời hạn đánh giá tích lũy cuối cùng kết thúc.
Quyền đọc của các thành viên cùng khóa Kho lưu trữ cá nhân được giữ ở chế độ riêng tư và những người tham gia cùng khóa chỉ có thể tham khảo ở chế độ chỉ đọc sau khi kết quả hàng tuần được công bố. Quyền ghi chỉ được cấp cho kho lưu trữ của chính bạn. Nhóm (crew) thường hoạt động với 5-6 người và danh sách được ẩn cho đến khi công bố. Bảng điểm chi tiết không được công khai, và sau khi xác nhận điểm cuối cùng, chỉ những nhóm chiến thắng đã đồng ý mới được giới thiệu trong Hall of Fame, nhận huy hiệu GitHub và hiển thị tên công khai. Đăng ký tham gia kết thúc vào lúc 19:00 thứ Tư của tuần bắt đầu. Các lộ trình có bài kiểm tra chẩn đoán trước phải vượt qua trước cùng thời điểm đó, danh sách nhóm và kênh Discord riêng sẽ được công bố vào lúc 20:00. Thời gian bắt đầu chính thức và công bố nhiệm vụ tuần 1 là 21:00 cùng ngày, sau đó nhiệm vụ mới sẽ mở vào 21:00 thứ Tư hàng tuần và hạn chót nộp bài là 21:00 thứ Ba tuần sau. Việc đánh giá (review) chính thức không nhất thiết phải thực hiện ngay mỗi tuần, nhưng phải hoàn thành số lượng review cần thiết theo tiêu chuẩn của các tuần khác nhau trước 21:00 Chủ Nhật sau tuần cuối cùng. Câu hỏi tuần 1, kho lưu trữ cá nhân và nhánh nhiệm vụ có thể được chuẩn bị trước, và nút nộp PR sẽ tự động được kích hoạt sau khi việc chuẩn bị kênh nhóm hoàn tất. Những người tham gia chưa hoàn tất kết nối GitHub/Discord vẫn sẽ được giữ nguyên nhóm đã phân bổ.
KIỂM TRA ĐỘ PHÙ HỢP
Phù hợp với những người này, và không phù hợp với những người này
Đề xuất cho những người sau
Những người đã từng tạo Spring Boot API nhưng cảm thấy khó khăn khi giải thích cơ chế hoạt động bên trong.
Những người muốn trả lời phỏng vấn dựa trên mã nguồn và bài kiểm tra của chính mình thay vì học thuộc lòng câu trả lời.
Những người cần có PR nhỏ và review tự động mỗi tuần mới có thể thúc đẩy việc thực hiện đến cùng
Không đề xuất
Những người chưa từng tiếp cận với cú pháp Java và yêu cầu/phản hồi HTTP lần nào.
Những người chỉ muốn xem nội dung mà không nộp mã nguồn và bài kiểm tra
HOÀN THÀNH
Công bố tiêu chuẩn hoàn thành trước khi bắt đầu
Trong vòng 4 tuần, nộp tất cả 4 PR nhiệm vụ tích hợp theo từng tuần.
Gửi đánh giá chính thức (official review) cho các PR đã vượt qua của 3 tuần khác nhau.
Chuẩn bị trước khi bắt đầu
Tôi cần kiến thức cơ bản về cú pháp Java và các khái niệm cơ bản về nhánh (branch) cũng như commit trong Git.
Mỗi tuần bạn cần dành khoảng 4~6 tiếng để tham gia vào việc triển khai, chỉnh sửa giải thích và phản hồi các đánh giá cần thiết.
Câu hỏi thường gặp
Những điều được hỏi nhiều nhất trước khi tham gia
Đây có phải là khóa học giống với Bootcamp 10 tuần trước đây không?
Không phải ạ. Thử thách này là một lộ trình riêng biệt để hoàn thành một môn học trong vòng 4 tuần. Chỉ trong trường hợp bạn cần một khóa học tập trung sâu hơn vào dự án và việc làm dài hạn thì mới tiếp nối sang chương trình bootcamp 10 tuần.
Có bao gồm bài giảng hay giáo trình không?
Không phải vậy. Thử thách cung cấp các bài toán theo từng tuần, kho lưu trữ thực hành riêng tư (private repository), tiêu chuẩn nộp bài và quy trình đánh giá (review loop). Các bài giảng liên quan là phần học trước tùy chọn có thể mua riêng và việc tham gia khóa học là không bắt buộc.
Có thể nộp bài trên trang chủ hoặc dán link vào được không?
Kết quả nộp bài chỉ được chấp nhận thông qua GitHub PR. Tuy nhiên, việc chuẩn bị kho lưu trữ (repository), nhánh (branch), PR và kiểm tra review có thể được thực hiện dễ dàng thông qua các nút bấm trên trang chủ Dingco.
Nội dung nào được công khai trên Discord?
Trên Discord sẽ không đăng các bài đánh giá chi tiết cho từng cá nhân, mà chỉ chia sẻ các bản tóm tắt hàng tuần và thông báo vận hành. Kênh chung của Spring Challenge khóa 1 là không gian dành cho các bài đọc, đặt câu hỏi, trò chuyện tự do và hướng dẫn vận hành.
GHI CHÚ CỦA NGƯỜI SÁNG TẠO
Thời đại AI, lập trình viên mới vào nghề nên học gì?
Bạn có thể xem trước trong video về các tiêu chí để thực hiện và kiểm chứng vấn đề này.
Xin chào! Vì lý do cá nhân nên bây giờ tôi mới xem bản ghi hình buổi học trực tiếp và nhấn vào link mời tham gia thử thách, nhưng link báo đã hết hạn. Không biết bây giờ tôi bắt đầu có còn kịp không ạ?
![[Lv1] 면접에서 "설명할 수 있는" Spring Boot 선택형 사전학습 강의 표지](https://cdn.inflearn.com/public/files/courses/339618/cover/01kc8ghjzfkvc8pjh0fzcx0jdd.gif?w=960)
