Spring Boot Explained Fluently in Interviews — 4-Week Practical Challenge, Cohort 2
A 4-week hands-on challenge where you recreate Spring Boot request flows, beans and proxies, and transaction boundaries through direct tests and logs, documenting your progress each week in a GitHub PR.
🚀 Former Toss, POSTECH graduate | Current Backend Developer (+9 years) 🎥 YouTuber with 20,000 subscribers | Development content creator 📚 Inflearn Instructor | Over 18,000+ cumulative students 👥 Managing a developer career community (8,000+ members) 🧩 Contributor to multiple open-source projects (Gradle, Spring AI, etc.) 📝 Passed 38 resume screenings & experienced in 100+ Kmong resume reviews (5.0 rating)
I deliver vivid, real-world industry insights in a way that is easy to understand and logically deductive. 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.
Spring 4-Week Challenge · Free · First 100 Participants Only
DINGCO CHALLENGE · 4 WEEKS
Spring Boot that you used to code just to make it work, you’ll be able to explain it in four weeks.
Reproduce request flows, beans and proxies, and transaction boundaries yourself through tests and logs, and leave one PR each week. After four weeks, you’ll have 18 interview answers you can answer with your own code.
Free · First 100 applicants only
Created by Dingcodingco, with 18,000+ cumulative Inflearn students, an average satisfaction rating of 4.9, and successful hiring experience at 38 companies.
Program periodSeptember 16, 2026 - October 13, 2026
Weekly commitment5 hours per week
Submission: 4 GitHub PRs4 PR trên GitHub
This challenge does not provide lectures or textbooks. It is an execution track where you prove what you already know or have learned independently through practical problems and GitHub PRs. Preparation before starting · Basic Java syntax and the fundamentals of Git branches and commits are required.
A 4-week execution track where you prove the concepts you’ve already learned through code, experiments, and explanations.
WHAT YOU SHIP
What You’ll Have at the End
A production-ready User–Todo API and integration tests
Verification code and logs demonstrating bean, proxy, and transaction behavior
18 Spring Interview Answers Linked to Actual Code Evidence
BEFORE
Add the annotation, and once the response comes back, the implementation is complete.
AFTER
Reproduce the request flow, proxies, beans, and transaction boundaries through tests and logs, and explain the rationale behind your choices.
ACTUAL WORKFLOW
From application to review, in the order shown on the actual screen
Do not copy and submit the GitHub URL. The Dingo homepage guides you through preparing a personal repository, creating a mission branch and PR, and checking detailed reviews.
1GitHub first, Discord lastAfter completing Kakao login and the pre-assessment, we prepare your personal private repository and connect your Discord role and cohort channel at the end.2Complete missions in your private repositoryThe website guides you through creating the “Todo API with visible request flow and evidence-based answers” branch and a PR. You don’t need to copy and paste the PR URL.3Check the 92-point score and specific evidenceReview the strengths and areas for improvement identified by automated checks and AI review in the Dingco detailed review and GitHub PR comments, then update the same PR.4Spring Challenge 2nd Cohort Operations Channel Individual detailed reviews are not posted on Discord; only weekly summaries and operational announcements are shared.
The screen above is an example created based on the actual operational UI and repository/channel rules. The repository name, cohort number, and review score vary depending on the participant and cohort.
4-WEEK ROUTE
Weekly missions that turn what you already know into real deliverables
Each week, submit your implementation and experiments, tests and logs, rationale for your choices, and answers to the questions in a single PR. The questions are not homework requiring you to provide memorized answers separately; answer them using the code you just created and the evidence it provides.
W1
From Web Requests to Your First API
Observe HTTP and JSON and connect them to a directly executable Spring Boot API.
Weekly Integration PRA Todo API that shows the request flow and evidence-based answers
[Required] Define and implement the contract so that POST /todos returns 201 with the created id, title, and completed for valid input, and a common 400 error for invalid input.
[Required] Make GET /todos/{id} return 200 for an existing Todo and a common 404 error for a nonexistent id, and lock down the three boundaries with integration tests in the actual application context.
[Required] Explain, in connection with your own code and tests, the roles of DispatcherServlet, validation, and HttpMessageConverter from the point when a request becomes a controller argument to when it becomes a JSON response.
[Optional extension] Replace the in-memory repository with an H2·JdbcTemplate repository and verify that the same API contract tests still pass.
Submission evidence · Executable API code implementing the 201·400·404 contracts · Integration test results for success, validation failure, and 404 cases run in the actual application context · An explanation of the request flow citing your own files and tests · Answers to this week’s evidence-based questions 1–5 · The commit and verification results reflecting any review feedback, or a record stating that there was no feedback
함께 답할 근거형 질문 5개
What process does an HTTP request go through to become an argument of a controller method?
Who converts the Java object into a JSON response, and how did you verify that?
Why did you not handle input validation failures with explicit branching in the controller code?
Which boundary had to be verified through integration tests rather than unit tests?
What part of the current API contract is most likely to break first, and how would you verify it?
W2
Spring Container Through Proxies, Beans, and DI
We verify Spring’s automation through proxies, bean lifecycles, and dependency injection code.
Weekly Integration PRAnatomy of Spring Container Automation and Evidence-Based Answers
[Required] In the Todo use case, create two implementations of the same interface, specify the selection criterion with @Qualifier or @Primary, and compare the ambiguity failure before selection with the successful injection after selection in isolated context tests.
[Required] Use a test to demonstrate a case where, between a bean wired through constructor injection and an object instantiated directly with new, at least one of the dependency, lifecycle, or additional functionality actually differs.
[Required] Apply an AOP cross-cutting feature to the Todo service, verify whether it is a proxy and its target class using AopUtils, and confirm that only calls made through the proxy record the advice and target calls in the expected order and number of times.
[Optional extension] Add bean lifecycle callbacks or a scoped proxy to compare one more container-managed boundary.
Submission evidence · Isolated context tests showing both ambiguity failures and explicit bean selection · Test results asserting the proxy type, target class and advice, and the order and number of target invocations · Documentation linking the observable differences between a directly instantiated object and a container-managed bean · Answers to this week’s evidence-based questions 1–5 · A commit incorporating review feedback and verification results, or a record stating that there were no comments if none were received
함께 답할 근거형 질문 5개
What happens when Spring cannot determine which implementation to inject, and how did you resolve it?
Why is constructor injection more advantageous than field injection for testing and immutability?
What is the most important difference between an object managed by the container and an object created directly?
How can you determine in code whether it is a proxy object or the original object?
Without the call-order log from this experiment, which explanation could not have been verified?
W3
Layer Separation and Transactions
Validate the responsibilities of the service layer and the transaction boundary through failure scenarios.
Weekly Integration PRA service that preserves consistency even when failures occur, with evidence-based answers
[Required] Implement repositories that save User and Todo using H2 and JdbcTemplate, and a service use case that coordinates the two changes.
[Required] Call a non-transactional service that throws an exception immediately after saving the User, and, without adding @Transactional to the test method, verify that after the exception, a partial save remains with 1 User and 0 Todos.
[Required] Make the @Transactional service called externally through the Spring proxy fail at the same point, then perform a separate query after exception handling to verify User 0 and Todo 0, proving that both changes were rolled back.
[Optional extension] Compare the default behavior of checked exceptions and the behavior before and after applying rollbackFor, or compare proxy bypass through internal calls within the same class, in separate tests.
Submission evidence · User·Todo JDBC repository and service layer code · Results confirmed outside the test transaction: non-transactional User 1·Todo 0 versus transactional User 0·Todo 0 · Explanation of the transaction boundary linking the external proxy call and database state query · Answers to this week’s evidence-based questions 1–4 · If there were review comments, the corresponding commit and verification results; otherwise, a record stating that there were no comments
함께 답할 근거형 질문 4개
Why did you place the transaction boundary in the service rather than in the controller or repository?
How do the default rollback behaviors differ between checked and unchecked exceptions, and how did you verify them?
Why can calls made within the same class bypass the transaction proxy?
Why should rollback tests verify the database state as well?
W4
Complete an operational API
Complete the API to be presented as a portfolio piece by applying exception handling, validation, logging, and pagination.
Weekly Integration PROperational User–Todo API and Final Evidence Package
[Required] Complete POST /users, POST /users/{userId}/todos, GET /todos/{id}, and GET /users/{userId}/todos as a single User–Todo contract, and document the reason for maintaining or changing the Week 1 POST /todos contract.
[Required] Make all 400 and 404 responses use a common format with code, message, and requestId fields, and implement list retrieval with default values of page=0 and size=20, a maximum size, ascending ID order, and totalElements and hasNext metadata.
[Required] Lock down empty lists, multiple pages, stable sorting, invalid page·size values, validation failures, and 404 responses with integration tests.
[Required] Validate and reuse the external X-Request-Id or generate a new value, linking the same value in the response headers, error responses, and structured logs, while excluding the request body and authentication information from the logs.
[Optional Extension] Add a cursor-pagination comparison experiment or the first observed metric among request count, error rate, and latency.
Submission evidence · Compatibility decisions for the four specified User–Todo endpoints and the previous contract · A common error format with code, message, and requestId, plus a stable ascending id pagination specification · API and pagination integration tests, including boundary values, and their execution results · Observational evidence confirming the same requestId in the response, error, and logs · Answers to this week’s evidence-based questions 1–4 · Commits reflecting any review feedback and verification results; if there was no feedback, a record stating that there were no comments
함께 답할 근거형 질문 4개
What benefits do clients and operators gain when error response formats are standardized?
Why did you choose page-number-based pagination or cursor-based pagination as the approach best suited to the current API?
What information must be included in the logs, and what information must not be included?
What are the first observability metrics and failure validations you would add before putting this API into production?
WEEKLY LOOP
Complete a week’s practical work within a single PR.
Check the weekly hands-on problem
Complete the mission in your personal branch
Submit code, tests, and explanations in a PR.
Check automated tests and AI review results
Modify the same PR and merge automatically
Check passing PRs and the official explanation
Reflect accumulated peer reviews and crew learning records
Submissions must be made only through GitHub PRs. From branch creation through review and merging the exact head SHA, the challenge interface and GitHub are connected. It automatically checks whether the required evidence is included in the PR.
CREW ENGAGEMENT
We talk for just 20 minutes about the mission in a word.
Starting in week 2, leave a comment on the PR, and the crew will share only blockers and alternative approaches.
From week 2, leave a brief comment on the mission When submitting a PR, write 10–300 characters about what you got stuck on.
20 minutes at the time set by the team Tuesdays at 21:15 by default, share only what you got stuck on and alternative approaches.
The leader wraps up in 1–30 characters Starting in Week 2, completion earns the crew +5, separate from individual completion.
Team bonus activity Participants do not write separate posts beyond a brief comment on the mission. The crew +5 is separate from individual completion.
LIVE SESSION
Once live, we align on how it will proceed together
We will hold one live session during the challenge. We’ll align on the completion criteria and see on the spot how submissions appear on the screen.
KICKOFF LIVEMonday, 9/14 at 20:00
60 minutes · Online
Spring Challenge Kickoff Live
4-week program format and completion criteria guide
At Monday’s kickoff, we’ll prepare the branch for the first mission and demonstrate submitting a GitHub PR after Wednesday’s start.
Live Q&A
The participation link will be posted in the Discord announcement before the start. Even if you cannot attend the live session, you can still find the completion criteria and submission method on the Dingo website and in the Discord announcement.
CHALLENGE CONTRACT
Learn the concepts individually, practice and feedback together
This challenge does not provide lectures, textbooks, Notion pages, or bonus materials. You will apply what you already know or have learned independently to real problems and prove it through GitHub PRs.
What the challenge provides
Weekly hands-on problems · Personal private practice repository · Clear passing criteria · Automated checks and AI reviews · Peer comparison and completion records
Participants prepare
Basic concepts in the relevant field · Experience with Git and GitHub PRs · Time to practice every week · An attitude of independently filling in gaps in your understanding
This course and textbook are not included in the challenge, and taking the course is not required. Choose them only if you have areas you lack in the pre-assessment or need to reinforce certain concepts.
Regardless of whether you apply through Inflearn, check the current cohort’s recruitment status using the “Recruitment & Participation Confirmation” button above. Log in with Kakao on Dingco to secure your spot, and once you complete all the connections, you’ll be ready to participate.
On the Dinko recruitment and participation confirmation page, select the current cohort, and log in with Kakao to instantly create your challenge membership and secure your spot.
Once you pass the cohort-specific pre-assessment, the GitHub connection step will open.
When you connect GitHub first, verification of organization permissions and preparation of your personal private repository are automatically scheduled.
Connecting Discord sets up access to the Spring challenge category and the announcements, reading materials, questions, and open chat channels.
Create a submit/<mission> branch on the homepage, push your code, and submit a PR with a single click.
The latest commit that passes the automated checks and AI review is automatically merged by Dingco, and everyone celebrates together in the free channel. In the crew Discord, members share questions and progress, while official reviews first open PRs that passed within the same crew; if there are none, they proceed with PRs from other crews in the same cohort. The leaderboard is provisionally updated during the week and finalized after the final cumulative review deadline.
Read access for members of the same cohort Personal repositories remain private, and participants from the same cohort may refer to them in read-only mode after the weekly results are made public. Write access is granted only to each participant’s own repository. Crews usually consist of 5–6 members, and the member list remains hidden until it is made public. Detailed score sheets are not disclosed, and after the final scores are confirmed, only winning crews that have agreed to it will be featured in the Hall of Fame with GitHub badges and their public names. Registration closes at 19:00 on the Wednesday of the starting week. Tracks with a pre-assessment must be passed by the same time, and the crew roster and dedicated Discord channels will be revealed at 20:00. The official start and the release of the Week 1 mission take place at 21:00 on the same day. After that, a new mission opens every Wednesday at 21:00, and submissions close the following Tuesday at 21:00. Official reviews do not have to be completed immediately each week, but you must complete the required number of reviews based on different weeks by 21:00 on the Sunday after the final week. The Week 1 problem, personal repositories, and mission branches can be prepared in advance, and the PR submission button will be activated automatically once your crew channel is ready. Participants who have not fully completed their GitHub–Discord connection will remain assigned to their crew.
FIT CHECK
This is a good fit for those who, and not a good fit for those who.
Recommended for you
Those who have built Spring Boot APIs but find it difficult to explain how they work internally
Those who want to speak based on their own code and tests instead of memorizing interview answers
Those who need small PRs and automated reviews every week to follow through to completion
Not recommended.
Those who have never worked with Java syntax or HTTP requests and responses before.
Those who want to browse only the content without submitting code and tests
COMPLETION
We disclose the completion criteria before you start.
Over four weeks, submit all four weekly integrated mission PRs.
Submit official reviews on passing PRs from three different weeks.
Preparation Before Starting
Basic knowledge of Java syntax and Git branches and commits is required.
Each week, you are expected to spend approximately 4–6 hours implementing, revising explanations, and incorporating necessary review feedback.
FAQ
Most Frequently Asked Questions Before Participating
Is this the same program as the existing 10-week bootcamp?
No. This challenge is a separate track in which you complete one subject over four weeks. It only leads into the 10-week bootcamp if you need a longer project- and job-focused program.
Are lectures or textbooks also provided?
No. The challenge provides weekly problems, a private practice repository, submission criteria, and a review loop. The accompanying course is optional preparatory learning available for separate purchase, and taking it is not required.
Is it also possible to submit through the website or paste a link?
Submissions are accepted only via GitHub PRs. However, you can easily access repository and branch setup, PR preparation, and review checks through buttons on the Dingo website.
What will be made public on Discord?
Detailed individual reviews are not posted on Discord; only weekly summaries and operational announcements are shared. The shared channel for Spring Challenge Cohort 2 is a space for reading materials, questions, casual conversation, and operational guidance.
CREATOR NOTE
In the AI era, what should junior developers study?
You can first check in the video what criteria to use to execute and verify this problem.
![[Lv1] 면접에서 "설명할 수 있는" Spring Boot 선택형 사전학습 강의 표지](https://cdn.inflearn.com/public/files/courses/339618/cover/01kc8ghjzfkvc8pjh0fzcx0jdd.gif?w=960)
