Spring Boot – Thử thách thực chiến 4 tuần, khóa 2, giúp bạn giải thích trôi chảy trong buổi phỏng vấn
Đây là thử thách thực hành kéo dài 4 tuần, trong đó bạn trực tiếp tái hiện luồng yêu cầu của Spring Boot, bean, proxy và ranh giới giao dịch thông qua các bài kiểm thử và log, rồi ghi lại kết quả bằng các PR trên GitHub mỗi tuầ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 đăng ký đầu tiên
DINGCO CHALLENGE · 4 TUẦN
Spring Boot trước đây chỉ viết sao cho chạy được, nay tôi sẽ giúp bạn giải thích được trong vòng 4 tuần.
Tái hiện trực tiếp bằng test và log luồng request, bean, proxy và ranh giới transaction, đồng thời để lại một PR mỗi tuần. Sau 4 tuần, bạn sẽ có trong tay 18 câu trả lời phỏng vấn có thể giải đáp bằng chính code của mình.
Miễn phí · 100 người đăng ký đầu tiên
Được tạo ra bởi Dingcodingco – hơn 18.000 học viên tích lũy trên Inflearn · mức độ hài lòng trung bình 4,9 · kinh nghiệm trúng tuyển vào 38 công ty
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 hành, nơi bạn chứng minh những gì đã biết hoặc tự học được thông qua các bài toán thực tế và PR trên GitHub. Chuẩn bị trước khi bắt đầu · Cần có kiến thức cơ bản về cú pháp Java và nhánh, commit trong Git.
Đây là lộ trình thực hành kéo dài 4 tuần, trong đó bạn chứng minh những khái niệm đã học bằng mã nguồn, thí nghiệm và phần giải thích.
NHỮNG GÌ BẠN SẼ BÀN GIAO
Những gì bạn đạt được sau khi hoàn thành
API User–Todo có thể vận hành và các bài kiểm thử tích hợp
Mã kiểm chứng và log cho thấy hoạt động của bean, proxy và transaction
18 câu trả lời phỏng vấn Spring gắn liền với bằng chứng từ mã nguồn thực tế
BEFORE
Gắn annotation và khi nhận được phản hồi thì hoàn tất triển khai.
AFTER
Tái hiện luồng yêu cầu, proxy, bean và ranh giới transaction bằng các bài kiểm thử và log, đồng thời giải thích cơ sở cho những lựa chọn đó.
QUY TRÌNH LÀM VIỆC THỰC TẾ
Từ lúc đăng ký đến khi review, theo đúng thứ tự trên màn hình thực tế
Không cần sao chép và nộp địa chỉ GitHub. Trang chủ Dingco sẽ hướng dẫn bạn từ việc chuẩn bị kho lưu trữ cá nhân, tạo nhánh nhiệm vụ và PR, cho đến kiểm tra bài đánh giá chi tiết.
1GitHub trước, Discord cuối cùngSau khi đăng nhập Kakao và hoàn tất chẩn đoán ban đầu, bạn sẽ chuẩn bị kho lưu trữ private cá nhân, rồi kết nối vai trò Discord và kênh của khóa học ở bước cuối.2Thực hiện nhiệm vụ trong kho lưu trữ private của tôiTrang chủ sẽ tiếp nối việc tạo branch và PR mang tên ‘Todo API hiển thị luồng yêu cầu và câu trả lời có căn cứ’. Không cần sao chép rồi dán địa chỉ PR.3Xác nhận 92 điểm cùng các căn cứ cụ thểBạn có thể xem những điểm làm tốt và điểm cần cải thiện từ quá trình kiểm tra tự động và đánh giá AI trong bản đánh giá chi tiết của Dingko cũng như phần bình luận PR trên GitHub, rồi chỉnh sửa chính PR đó.4Kênh vận hành Spring Challenge khóa 2Không đăng các bài đánh giá chi tiết cá nhân lên Discord, chỉ chia sẻ bản 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 UI vận hành thực tế cùng các quy tắc về kho lưu trữ và kênh. Tên kho lưu trữ, số khóa và điểm đánh giá sẽ khác nhau tùy theo người tham gia và khóa.
LỘ TRÌNH 4 TUẦN
Nhiệm vụ theo từng tuần để biến những điều đã biết thành sản phẩm thực tế
Mỗi tuần, hãy nộp trong một PR duy nhất phần triển khai và thử nghiệm, kiểm thử và nhật ký, căn cứ lựa chọn cùng câu trả lời cho các câu hỏi. Câu hỏi không phải là bài tập yêu cầu nộp riêng những câu trả lời học thuộc, mà được trả lời bằng chính đoạn mã vừa tạo và các bằng chứng.
W1
Từ yêu cầu web đầu tiên đến API đầu tiên
Quan sát HTTP và JSON, đồng thời kết nối chúng với API Spring Boot có thể chạy trực tiếp.
PR tích hợp hàng tuầnTodo API thể hiện luồng yêu cầu và câu trả lời dựa trên bằng chứng
[Bắt buộc] Định nghĩa và triển khai hợp đồng để POST /todos 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ệ.
[Bắt buộc] GET /todos/{id} phải trả về 200 đối với Todo tồn tại và lỗi chung 404 đối với id không tồn tại, đồng thời cố định ba ranh giới này bằng các bài kiểm thử tích hợp trong context ứng dụng thực tế.
[Bắt buộc] Giải thích, liên hệ với mã nguồn và các bài kiểm thử của bạn, vai trò của DispatcherServlet, cơ chế kiểm tra hợp lệ và HttpMessageConverter trong quá trình biến yêu cầu thành tham số của controller và tạo ra phản hồi JSON.
[Mở rộng tùy chọn] Thay thế kho lưu trữ trong bộ nhớ bằng kho lưu trữ H2·JdbcTemplate và xác nhận rằng các bài kiểm thử hợp đồng API tương tự vẫn được duy trì.
Bằng chứng nộp bài · Mã API có thể chạy được, triển khai các hợp đồng 201·400·404 · Kết quả kiểm thử tích hợp về thành công, thất bại xác thực và 404 được thực thi trong ngữ cảnh ứng dụng thực tế · Phần giải thích luồng yêu cầu, trích dẫn các tệp và bài 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 bằng chứng từ 1 đến 5 của tuần này · Commit và kết quả xác minh đã phản ánh các góp ý trong quá trình review; nếu không có thì ghi nhận là không có góp ý.
함께 답할 근거형 질문 5개
Yêu cầu HTTP trải qua quy trình nào để trở thành tham số của phương thức controller?
Java object được ai chuyển đổi thành phản hồi JSON, và bạn đã xác nhận điều đó như thế nào?
Tại sao không trực tiếp phân nhánh khi xác thực đầu vào thất bại trong mã controller?
Đâu là ranh giới nhất thiết phải được xác nhận bằng kiểm thử tích hợp thay vì kiểm thử đơn vị?
Trong hợp đồng API hiện tại, phần nào có khả năng bị phá vỡ đầu tiên và phương pháp xác minh phần đó là gì?
W2
Bộ chứa Spring qua lăng kính proxy, bean và DI
Xác minh cơ chế tự động hóa của Spring bằng proxy, vòng đời bean và mã tiêm phụ thuộc.
PR tích hợp hằng tuầnMổ xẻ cơ chế tự động hóa của Spring Container và câu trả lời dựa trên bằng chứng
[Bắt buộc] Trong use case Todo, tạo hai triển khai của cùng một interface, chỉ rõ tiêu chí lựa chọn bằng @Qualifier hoặc @Primary, đồng thời so sánh lỗi mơ hồ trước khi lựa chọn và việc tiêm thành công sau khi lựa chọn bằng các bài kiểm thử ngữ cảnh cô lập.
[Bắt buộc] Hãy dùng kiểm thử để cho thấy một cách thực tế rằng giữa bean được kết nối bằng việc tiêm qua constructor và đối tượng được tạo trực tiếp bằng new, có ít nhất một điểm khác biệt về dependency, vòng đời hoặc chức năng bổ sung.
[Bắt buộc] Áp dụng tính năng bổ sung AOP vào Todo service, sử dụng AopUtils để kiểm tra đối tượng có phải là proxy và xác định lớp đích, đồng thời xác minh rằng chỉ trong các lệnh gọi thông qua proxy, advice và lệnh gọi đến đối tượng đích mới được ghi nhận đúng thứ tự và số lần như kỳ vọng.
[Mở rộng tùy chọn] Thêm callback vòng đời bean hoặc scope proxy để so sánh thêm một ranh giới do container quản lý.
Bằng chứng cần nộp · Bài kiểm thử ngữ cảnh cô lập đồng thời cho thấy lỗi do mơ hồ và việc lựa chọn bean tường minh · Kết quả kiểm thử khẳng định loại proxy, lớp đích và advice, cũng như thứ tự và số lần gọi đối tượng đích · Tài liệu liên kết những khác biệt có thể quan sát được giữa đối tượng được tạo trực tiếp bằng new và bean do container quản lý · Câu trả lời cho các câu hỏi dựa trên bằng chứng từ 1~5 trong tuần này · Commit đã phản ánh các góp ý trong review và kết quả xác minh; nếu không có thì ghi nhận là không có góp ý
함께 답할 근거형 질문 5개
Khi Spring không thể xác định được implementation cần tiêm thì điều gì sẽ xảy ra và bạn đã giải quyết như thế nào?
Tại sao việc tiêm qua constructor lại có lợi hơn tiêm qua field đối với việc kiểm thử và tính bất biến?
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ự tạo là gì?
Làm thế nào để kiểm tra bằng mã xem đó là đối tượng proxy hay đối tượng gốc?
Nếu không có nhật ký thứ tự gọi của thí nghiệm này, bạn sẽ 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
Xác minh trách nhiệm của tầng dịch vụ và ranh giới giao dịch bằng các kịch bản thất bại.
PR tích hợp hàng tuầnDịch vụ vẫn duy trì 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
[Bắt buộc] Hãy triển khai repository lưu User và Todo bằng H2·JdbcTemplate, cùng với use case dịch vụ điều phối hai thay đổi này.
[Bắt buộc] Gọi dịch vụ không có giao dịch để ném ra ngoại lệ ngay sau khi lưu User, đồng thời xác nhận trạng thái lưu một phần còn lại 1 User và 0 Todo sau ngoại lệ, trong khi không gắn @Transactional vào phương thức kiểm thử.
[Bắt buộc] Làm cho dịch vụ @Transactional được gọi từ bên ngoài thông qua Spring proxy thất bại tại cùng một điểm, sau khi xử lý ngoại lệ, thực hiện một lần truy vấn riêng để xác nhận User có 0 bản ghi và Todo có 0 bản ghi, qua đó chứng minh cả hai thay đổi đều đã được rollback.
[Mở rộng tùy chọn] So sánh bằng các bài kiểm thử riêng về hành vi mặc định của checked exception và trước/sau khi áp dụng rollbackFor, hoặc việc bỏ qua proxy khi gọi nội bộ trong cùng một lớp.
Bằng chứng nộp · Mã nguồn repository JDBC và tầng service của User·Todo · Kết quả User 1·Todo 0 phi giao dịch và User 0·Todo 0 trong giao dịch được xác nhận bên ngoài giao dịch kiểm thử · Giải thích ranh giới giao dịch, liên kết lời gọi proxy bên ngoài với việc 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~4 trong tuần này · Nếu có nhận xét khi review thì commit đã phản ánh nhận xét và kết quả kiểm chứng; nếu không thì ghi nhận không có nhận xét
함께 답할 근거형 질문 4개
Vì sao đặt ranh giới giao dịch ở service thay vì controller hay repository?
Hành vi rollback mặc định khác nhau như thế nào giữa checked exception và unchecked exception, và bạn đã xác minh điều đó ra sao?
Tại sao việc gọi nội bộ trong cùng một lớp có thể bỏ qua proxy giao dịch?
Tại sao bài kiểm thử rollback cần kiểm tra cả trạng thái cơ sở dữ liệu?
Tuần 4
Hoàn thiện API có thể vận hành thực tế
Áp dụng xử lý ngoại lệ, xác thực, ghi log và phân trang để hoàn thiện API có thể trình bày trong portfolio.
PR tích hợp hàng tuầnAPI User–Todo có thể vận hành và bộ bằng chứng cuối cùng
[Bắt buộc] Hoàn thiện POST /users, POST /users/{userId}/todos, GET /todos/{id}, GET /users/{userId}/todos thành một hợp đồng User–Todo thống nhất và ghi lại lý do duy trì hoặc thay đổi hợp đồng POST /todos ở tuần 1.
[Bắt buộc] Chuẩn hóa tất cả phản hồi 400·404 theo định dạng chung có các trường code·message·requestId, đồng thời triển khai truy vấn danh sách với giá trị mặc định page=0·size=20, size tối đa, thứ tự tăng dần theo id và bao gồm siêu dữ liệu totalElements·hasNext.
[Bắt buộc] Cố định bằng kiểm thử tích hợp các trường hợp danh sách trống, nhiều trang, sắp xếp ổn định, page·size không hợp lệ, lỗi xác thực và 404.
[Bắt buộc] Xác thực X-Request-Id từ bên ngoài để tái sử dụng hoặc tạo giá trị mới, đồng thời liên kết cùng một giá trị trong tiêu đề phản hồi, phản hồi lỗi và nhật ký có cấu trúc; loại trừ nội dung yêu cầu và thông tin xác thực khỏi nhật ký.
[Mở rộng tùy chọn] Bổ sung thử nghiệm so sánh phân trang bằng con trỏ hoặc chỉ số quan sát đầu tiên trong số lượng yêu cầu, tỷ lệ lỗi và độ trễ.
Bằng chứng cần nộp · Quyết định về khả năng 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 gồm code·message·requestId và phân trang tăng dần ổn định theo id · Các bài kiểm thử tích hợp API·phân trang bao gồm các giá trị biên và kết quả thực thi · 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 bằng chứng 1~4 trong tuần này · Nếu có nhận xét khi review thì phản ánh trong commit·kết quả xác minh; nếu không có thì ghi nhận không có nhận xét
함께 답할 근거형 질문 4개
Việc chuẩn hóa định dạng phản hồi lỗi mang lại những lợi ích gì cho client và nhân viên vận hành?
Tại sao lại chọn phương thức phân trang dựa trên số trang thay vì dựa trên con trỏ cho API hiện tại?
Những thông tin nào nhất định phải được ghi vào nhật ký và những thông tin nào không được ghi lại?
Trước khi đưa API này vào vận hành thực tế, chỉ số quan sát và bước xác minh sự cố đầu tiên cần bổ sung là gì?
VÒNG LẶP HẰNG TUẦN
Hoàn thành phần thực hành của một tuần trong một PR duy nhất.
Xác nhận các bài toán thực tế theo từng tuần
Thực hiện nhiệm vụ trên nhánh cá nhân.
Nộp mã nguồn, kiểm thử và phần giải thích trong PR
Kiểm tra tự động và xem xét đánh giá bằng AI
Chỉnh sửa PR tương tự và tự động hợp nhất
Kiểm tra PR đã vượt qua và phần giải thích chính thức
Phản ánh đánh giá đồng nghiệp tích lũy và hồ sơ học tập của crew
Chỉ sử dụng GitHub PR để nộp bài. Từ lúc tạo branch đến review và hợp nhất chính xác theo head SHA, màn hình thử thách và GitHub được kết nối với nhau. Hệ thống sẽ tự động kiểm tra xem các bằng chứng cần thiết có nằm trong PR hay không.
SỰ THAM GIA CỦA CREW
Chỉ trò chuyện trong 20 phút về một câu ngắn cho 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 chỉ chia sẻ những điểm bị vướng mắc cùng các cách tiếp cận khác.
Từ tuần 2, một lời nhắn về nhiệm vụ Khi gửi PR, hãy viết lại điểm bị vướng mắc trong 10–300 ký tự.
Trong 20 phút vào thời gian do nhóm quy định mặc định là 21:15 thứ Ba, chỉ chia sẻ những điểm bị mắc và các cách tiếp cận khác.
Trưởng nhóm kết thúc trong 1–30 ký tự Từ tuần 2, hoàn thành sẽ được cộng +5 crew, tách biệt với việc hoàn thành cá nhân.
Hoạt động thưởng đội nhóm Người tham gia không viết bài riêng ngoài một câu về nhiệm vụ. Điểm crew +5 được tính riêng với việc hoàn thành cá nhân.
PHIÊN TRỰC TIẾP
Một lần trực tiếp, cùng thống nhất cách thức 진행 hành
Trong thời gian diễn ra thử thách, sẽ có một buổi live session. Chúng ta sẽ cùng thống nhất tiêu chí hoàn thành và trực tiếp kiểm tra cách bài nộp hiển thị trên màn hình ngay tại đó.
Hướng dẫn về cách thức 진행 4 tuần và tiêu chí hoàn thành
Trong buổi kickoff thứ Hai, hướng dẫn chuẩn bị branch cho nhiệm vụ đầu tiên và demo cách gửi PR lên GitHub sau khi bắt đầu vào thứ Tư
Hỏi & Đáp trực tiếp
Liên kết tham gia sẽ được đăng trong thông báo trên Discord trước khi bắt đầu. Ngay cả khi không thể tham gia buổi phát trực tiếp, bạn vẫn có thể xem tiêu chí hoàn thành và cách nộp bài trên trang web Dingo và thông báo trên Discord.
THỎA THUẬN THỬ THÁCH
Mỗi người tự học khái niệm, cùng nhau thực hành và nhận 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 gì đã biết hoặc tự học vào các bài toán thực tế và chứng minh bằng GitHub PR.
Thử thách cung cấp五月婷婷
Bài toán thực tế theo từng tuần · Kho lưu trữ thực hành private cá nhân · Tiêu chí đạt rõ ràng · Kiểm tra tự động và đánh giá bằng AI · So sánh với đồng nghiệp và ghi nhận hoàn thành
Người tham gia cần chuẩn bị
Kiến thức cơ bản về 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 độ chủ động tự bổ sung những khái niệm còn thiếu
Tự chọn học trước · Mua riêng · 9 giờ 58 phút
[Lv1] Spring Boot “có thể giải thích được” trong phỏng vấn
Khóa học và giáo trình này không nằm trong chương trình 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 trong bài đánh giá đầu vào hoặc cần bổ sung kiến thức.
Bất kể bạn có đăng ký trên Inflearn hay không, hãy kiểm tra trạng thái tuyển người của khóa hiện tại bằng nút “Kiểm tra tuyển người·tham gia” ở trên. Khi đăng nhập Kakao trên Dingco, chỗ của bạn sẽ được giữ lại; sau khi hoàn tất mọi kết nối, bạn đã sẵn sàng tham gia.
Trên trang kiểm tra tuyển sinh và tham gia Dingco, hãy chọn khóa hiện tại rồi đăng nhập bằng Kakao để tư cách thành viên thử thách được tạo ngay và giữ chỗ.
Sau khi vượt qua bài đánh giá đầu vào theo từng khóa, bước kết nối GitHub sẽ được mở.
Nếu 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ữ private cá nhân sẽ được tự động lên lịch.
Khi kết nối Discord, quyền truy cập vào danh mục riêng của thử thách Spring cùng các kênh thông báo, tài liệu đọc, câu hỏi và trò chuyện tự do sẽ được thiết lập.
Tạo nhánh submit/<nhiệm vụ> trên trang chủ, push code rồi gửi PR chỉ với một lần nhấn nút.
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, sau đó cùng nhau chúc mừng trong kênh tự do. Trên Discord của crew, mọi người cùng chia sẻ câu hỏi và tình hình tiến độ; các lượt review chính thức sẽ ưu tiên mở PR đã vượt qua của cùng crew, nếu không có thì sẽ tiếp tục với PR của crew khác trong cùng đợt. Bảng điểm sẽ được cập nhật tạm thời hằng tuần và được chốt chính thức sau khi kết thúc thời hạn review cộng dồn cuối cùng.
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ế độ private, và người tham gia cùng khóa chỉ có thể tham khảo ở chế độ chỉ đọc sau khi kết quả theo tuần được công khai. Quyền ghi chỉ được cấp cho kho lưu trữ của chính chủ. Mỗi crew thường có 5~6 người, và danh sách thành viên sẽ được ẩn cho đến trước khi công khai. Bảng điểm chi tiết sẽ không được công khai; sau khi điểm cuối cùng được xác nhận, chỉ những crew chiến thắng đã đồng ý mới được giới thiệu trong Hall of Fame, kèm huy hiệu GitHub và tên công khai. Đăng ký tham gia sẽ đóng vào 19:00 thứ Tư của tuần bắt đầu. Đối với các track có bài chẩn đoán đầu vào, người tham gia phải vượt qua trước cùng thời điểm, và danh sách crew cùng kênh Discord riêng sẽ được công khai vào 20:00. Buổi bắt đầu chính thức và thời điểm công bố nhiệm vụ tuần 1 đều diễn ra lúc 21:00 cùng ngày; sau đó, nhiệm vụ mới sẽ được mở vào 21:00 thứ Tư hằng tuần và hạn nộp là 21:00 thứ Ba tuần kế tiếp. Không cần phải thực hiện review chính thức ngay trong tuần, nhưng phải hoàn thành đủ số lượng review cần thiết dựa trên các tuần khác nhau trước 21:00 Chủ nhật sau tuần cuối cùng. Bài tập tuần 1, kho lưu trữ cá nhân và nhánh nhiệm vụ có thể được chuẩn bị trước, còn nút gửi PR sẽ tự động được kích hoạt sau khi kênh crew của bạn hoàn tất việc chuẩn bị. Những người tham gia chưa hoàn tất đầy đủ việc kết nối GitHub·Discord vẫn sẽ được giữ crew đã được phân công.
적합성 확인
Phù hợp với những người này, không phù hợp với những người này
Khuyến nghị dành cho bạn
Đã từng xây dựng API bằng Spring Boot nhưng gặp khó khăn khi giải thích cơ chế hoạt động bên trong.
Thay vì học thuộc câu trả lời phỏng vấn, dành cho những người muốn trả lời dựa trên mã nguồn và bài kiểm thử của chính mình
Dành cho những người cần có PR nhỏ hằng tuần và review tự động để có thể theo đuổi việc thực hiện đến cùng.
Không khuyến nghị
Những người chưa từng làm việc với cú pháp Java và yêu cầu·phản hồi HTTP
Những người chỉ muốn xem qua nội dung mà không nộp mã nguồn và bài kiểm thử
HOÀN THÀNH
Công bố tiêu chí hoàn thành trước khi bắt đầu
Trong 4 tuần, bạn sẽ gửi đủ 4 PR nhiệm vụ tích hợp theo từng tuần.
Gửi bài đánh giá chính thức cho các PR đạt yêu cầu của 3 tuần khác nhau.
Chuẩn bị trước khi bắt đầu
Cần có kiến thức cơ bản về cú pháp Java, cũng như nhánh và commit trong Git.
Mỗi tuần, bạn cần dành khoảng 4–6 giờ để tham gia triển khai, chỉnh sửa phần giải thích và phản hồi các đánh giá cần thiết.
FAQ
Những điều được hỏi nhiều nhất trước khi tham gia
Đây có phải là chương trình giống với bootcamp 10 tuần hiện tại không?
Không. Thử thách này là một lộ trình riêng, hoàn thành một môn học trong 4 tuần. Chỉ khi cần một dự án dài hơn hoặc một khóa học tập trung vào việc tìm việc, bạn mới tiếp tục với bootcamp 10 tuần.
Có cung cấp cả bài giảng hoặc giáo trình không?
Không. Challenge cung cấp các bài tập theo tuần, kho thực hành private, tiêu chí nộp bài và quy trình review. Các bài giảng liên quan là nội dung học trước tùy chọn có thể mua riêng, không bắt buộc phải tham gia.
Có thể nộp bài trên trang web hoặc dán liên kết không?
Kết quả nộp bài chỉ được tiếp nhận qua PR trên GitHub. Tuy nhiên, việc chuẩn bị kho lưu trữ, nhánh và PR cũng như kiểm tra đánh giá đều có thể dễ dàng thực hiện thông qua các nút trên trang chủ Dingco.
Discord sẽ công khai những gì?
Trên Discord, chúng tôi không đăng bài đánh giá chi tiết cho từng cá nhân mà chỉ chia sẻ bản tóm tắt hằng tuần và các thông báo vận hành. Kênh chung của Spring Challenge khóa 2 là không gian dành cho việc đọc tài liệu, đặt câu hỏi, trò chuyện tự do và nhận hướng dẫn vận hành.
GHI CHÚ CỦA NHÀ SÁNG TẠO
Trong thời đại AI, các nhà phát triển mới vào nghề nên học gì?
Bạn có thể xem trước trong video cách thực hiện và kiểm chứng vấn đề này dựa trên những tiêu chí nào.