Explaining Spring Boot Flawlessly in Interviews — 4-Week Hands-on Challenge
This is a 4-week hands-on challenge where you'll use tests and logs to reproduce the request flow, bean and proxy mechanics, and transaction boundaries of the APIs you've built, empowering you to explain them seamlessly in interviews.
🚀 Toss, POSTECH alumnus | Current Backend Developer (+9 years) 🎥20k YouTuber | Development Content Creator 📚 Inflearn Instructor | Over 18,000+ cumulative students 👥 Operating a developer career community (8,000+) 🧩 Contributor to various open-source projects (Gradle, Spring AI, etc.) 📝 Passed 38 document screenings and experienced 100+ resume reviews on Kmong (5.0 rating)
I deliver vivid, real-world industry information in an easy and deductively understandable way. Tôi truyền đạt 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 registrants · Registration closes on 8/9 (Sun) at 23:59
DINGCO CHALLENGE · 4 WEEKS
Spring Boot, where you've only been writing code just to make it work, I'll teach you how to explain it in just 4 weeks.
Reproduce request flows, beans and proxies, and transaction boundaries firsthand through tests and logs, submitting one PR each week. By the end of the 4 weeks, you'll walk away with 18 interview answers you can confidently back up with your own code.
Free · First 100 applicants · Applications open until 8/9 (Sun) 23:59
Total Inflearn students: 18,000+ · Average satisfaction: 4.9 · Created by Dingcoding, who has passed interviews at 38 companies.
This challenge does not provide lectures or textbooks. It is a hands-on 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 a fundamental understanding of Git branches and commits are required.
This is a 4-week hands-on track where you demonstrate the concepts you've already learned through code, experiments, and explanations.
WHAT YOU SHIP
What you take away upon completion
Production-Ready User–Todo API and Integration Testing
Verification code and logs demonstrating the behavior of beans, proxies, and transactions.
18 Spring Interview Answers Backed by Actual Code Evidence
BEFORE
You just add an annotation, and once the response comes back, the implementation is complete.
AFTER
It reproduces the request flow, proxies, beans, and transaction boundaries through tests and logs, and explains the rationale for the choices.
ACTUAL WORKFLOW
From application to review, in the order of the actual screens
You don't need to copy and submit the GitHub URL. The Dingco website handles the entire workflow, from setting up your personal repository and creating the mission branch and PR to checking detailed reviews.
1GitHub first, Discord last Once you complete the Kakao login and pre-assessment, you will set up your personal private repository, and connect your Discord role and cohort channel at the very end.2Complete the mission in your private repositoryThe website guides you through creating the branch and PR for 'Creating an API that shows the request flow'. Do not copy and paste the PR URL.3Check your score of 92 and the specific rationale Review the strengths and areas for improvement from the automated checks and AI reviews in the Dingco detailed review and GitHub PR comments, and update the same PR.4Spring Challenge Cohort 1 Public Channel Scores and key feedback are shared in the cohort's public channel, and detailed reviews can be found on Dingo and GitHub.
The screen above is an example created based on the actual operational UI and repository and channel rules. The repository name, cohort number, and review scores vary depending on the participant and cohort.
4-WEEK ROUTE
Weekly missions that turn what you already know into actual deliverables.
Each week, submit your implementations and experiments, tests and logs, rationale for your choices, and Q&A in a single PR. The Q&A isn't a separate homework assignment for regurgitating memorized answers; instead, you answer questions using the code you just built and supporting evidence.
W1
From Web Requests to the First API
Observe HTTP and JSON, and connect them to a directly executable Spring Boot API.
Weekly Integrated PRTodo API showing the request flow and evidence-based responses
Define and implement the request/response contract for POST /todos and GET /todos/{id}.
We lock in the expected behaviors for successful creation, invalid input, and querying a non-existent Todo via integration tests.
Explain the flow from the moment the request reaches the controller until it becomes a JSON response, linking it to your own code.
Submission Evidence · Executable API Code · Success, Validation Failure, and 404 Integration Tests · Request Flow Explanation · Answers to Evidence-Based Questions 1-5
5 Evidence-Based Questions to Answer Together
Through what process does an HTTP request become an argument of a controller method?
Who converts the Java object into a JSON response, and how did you verify this?
Why didn't you handle input validation failures directly via conditional branching in the controller code?
What was the boundary that had to be verified with integration tests rather than unit tests?
Which part of the current API contract is most likely to break first, and how should it be verified?
W2
Understanding the Spring Container Through Proxies, Beans, and DI
We verify Spring's automation through proxies, the bean lifecycle, and dependency injection code.
Weekly Integrated PRDissecting Spring Container Automation and Evidence-Based Responses
Create two implementations of the same interface and apply explicit bean selection criteria.
It demonstrates the difference between an object wired via constructor injection and one instantiated directly with 'new' through a verification test.
Log the order of bean creation and dependency invocation, and verify the actual class information if a proxy is applied at any point.
Submission Evidence · Bean/DI Verification Code · Creation and Invocation Order Logs · Documentation Comparing with Direct Instantiation · Answers to Evidence-Based Questions 6-10
5 Evidence-Based Questions to Answer Together
What happens when Spring cannot determine which implementation to inject, and how did you resolve it?
Why is constructor injection more advantageous for testing and immutability than field injection?
What is the most important difference between a container-managed object and an object created directly?
How can you tell in code whether it is a proxy object or the original object?
Without the call sequence log from this experiment, which explanation could we not have verified?
W3
Layer Separation and Transactions
We verify the service layer's responsibilities and transaction boundaries using failure scenarios.
Weekly Integrated PRServices that preserve consistency even upon failure and evidence-based responses
Implement a use case in the service layer that updates both User and Todo.
Reproduce the risk of a partial save by throwing an exception after the first save.
Write an integration test comparing the behavior before and after applying transactions, where both changes are rolled back together.
Submission Evidence · Layer Separation Code · Integration Test for Failure Reproduction and Rollback · Explanation of Transaction Boundaries · Answers to Reasoning Questions 11~14
4 Evidence-Based Questions to Answer Together
Why is the transaction boundary placed at the service layer rather than the controller or repository?
How does the default rollback behavior differ between checked and unchecked exceptions, and how did you verify it?
Why can internal calls within the same class bypass the transaction proxy?
Why does a rollback test need to verify the database state as well?
W4
Completing a Production-Ready API
Complete a portfolio-ready API by implementing exception handling, validation, logging, and pagination.
Weekly Integrated PRProduction-Ready User-Todo API and Final Root Package
Complete the User-Todo creation and retrieval API as a single, consistent contract.
Implement input validation, common error responses, and pagination as part of the mandatory scope, and write integration tests.
Add a request identifier or structured logs as an optional scope, and explain what operational issues this helps mitigate.
Submission evidence · Completed API code · Integration test results · Error response and pagination specifications · Answers to evidence-based questions 15-18
4 Evidence-Based Questions to Answer Together
What are the benefits of standardizing the error response format for both clients and operators?
Why did you choose the pagination method best suited for the current API between page-number-based and cursor-based pagination?
What information must be logged, and what information should not be logged?
Before deploying this API to production, what is the first observability metric you would add, and what failure verification would you perform?
WEEKLY LOOP
Complete the week's hands-on practice in a single PR.
Check Weekly Practical Exercises
Complete the mission on your personal branch.
Submit code, tests, and explanations in a PR.
Check automated tests and AI reviews
Modify the same PR and pass
Only GitHub PRs are accepted for submissions. The challenge screen is fully integrated with GitHub, from branch creation and reviews to merging the exact head SHA. It automatically verifies whether the required evidence is included in the PR.
LIVE SESSION
We'll meet live once to align on the process.
We'll be hosting a live session during the challenge period. We'll align on the completion criteria together and see firsthand how submissions flow on the screen.
KICKOFF LIVE8/10 (Mon) 20:00
60 minutes · Online
Spring Challenge Kickoff Live
Guide to the 4-Week Schedule and Completion Criteria
First Mission GitHub PR Submission Demo
Live Q&A
The participation link will be posted in the Discord announcement before the session starts. Even if you are unable to attend the live session, you can still check the completion criteria and submission guidelines on the Dingco website and in the Discord announcements.
CHALLENGE CONTRACT
Learn concepts on your own, tackle practice and feedback together
This challenge does not provide lectures, textbooks, Notion resources, or bonus materials. Apply what you already know or have learned independently to real-world problems and prove your work via a GitHub PR.
What the Challenge Provides
Weekly practical problems · Personal private practice repository · Clear passing criteria · Automated checks and AI reviews · Peer comparison and completion records
What Participants Need to Prepare
Fundamental concepts in the relevant field · Experience with Git and GitHub PRs · Weekly time commitment · A proactive attitude to independently fill in knowledge gaps
Optional Pre-learning · Sold Separately · 9 Hours 58 Minutes
[Lv1] Spring Boot You Can "Explain" in an Interview
This lecture and textbook are not part of the challenge, and taking them is not mandatory. Only choose them if you have weak areas in the pre-assessment or need to brush up on specific concepts.
After applying on Inflearn, access the shared participation link in the updates section. You don't need to re-enter your email or cross-reference the application list. Simply log in with Kakao to instantly create your membership.
Logging in with Kakao through the Inflearn participation link instantly creates your challenge membership.
Once you pass the pre-assessment for your cohort, the GitHub connection step will open.
If you connect GitHub first, the verification of organization permissions and the preparation of a personal private repository will be automatically scheduled.
Connecting Discord sets up the Spring Challenge Cohort 1 category and configures your permissions for announcements, discussions, questions, and the lounge.
On the website, create a submit/<mission> branch, push your code, and submit a PR with a single click.
Once automatic checks and AI reviews are applied, only passing commits are merged, and the results are displayed in the shared announcements for Dingco, GitHub, and Discord.
Read Permissions for the Same Cohort Participants in the same cohort can read and refer to the repository, while write permissions are granted only to their own repository.
FIT CHECK
Who this is for, and who it isn't
We recommend it.
Those who have built a Spring Boot API but struggle to explain its internal workings.
For those who want to speak based on their own code and tests rather than memorizing interview answers.
Those who need small weekly PRs and automated reviews to stay motivated and push through to the end.
Not recommended
Those who have never worked with Java syntax or HTTP requests and responses.
Those who just want to browse the content without submitting code or tests
COMPLETION
We will disclose the completion criteria before the start.
Submit all 4 weekly integrated mission PRs over 4 weeks.
For each PR, include the implementation, test logs, the rationale for your choices, and answers to evidence-based questions.
In the same PR, address the gaps in explanation and verification flagged by the automated review.
Preparation Before Starting
Basic Java syntax and the fundamentals of Git branches and commits are required.
You are required to dedicate approximately 4 to 6 hours each week to implementation, revising descriptions, and incorporating review feedback.
FAQ
Most Frequently Asked Questions Before Joining
Is it the same program as the existing 10-week bootcamp?
No. This challenge is a separate track where you complete a single subject over four weeks. It only leads to the 10-week bootcamp if you need a longer, project- and career-focused program.
Are lectures or textbooks provided as well?
No. The challenge provides weekly assignments, a private practice repository, submission criteria, and a review loop. The associated lectures are optional preparatory materials available for separate purchase, and taking them is not mandatory.
Can I submit via the homepage or by pasting a link?
Submissions are accepted exclusively via GitHub PRs. However, you can easily set up your repository, branch, and PR, and check your reviews directly via buttons on the Dingco website.
What is made public on Discord?
Scores and key feedback are posted in the shared cohort announcements, allowing everyone to track each other's progress. Rather than through personal DMs, you can review these together in the shared channel for Spring Challenge Cohort 1.
CREATOR NOTE
In the AI era, what should junior developers study?
You can first watch the video to see what criteria should be used to execute and verify this problem.