Explaining Spring Boot Fluently in Interviews — 4-Week Practical Challenge
This is a 4-week practical challenge designed to help you reproduce the API you built—from request flow, beans, and proxies to transaction boundaries—using tests and logs, so you can explain it fluently during interviews.
🚀 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 Boot, which I used to write just to make it work, I'm going to be able to explain it within 4 weeks.
You will reproduce request flows, beans and proxies, and transaction boundaries through hands-on tests and logs, submitting one PR each week. After four weeks, you will have 18 interview answers ready that you can confidently explain using your own code.
Free · First 100 people (First-come, first-served)
Created by DingcoDingco, who has 18,000+ cumulative students on Inflearn, an average satisfaction rating of 4.9, and experience passing interviews at 38 companies.
This challenge does not provide lectures or textbooks. It is an execution track where you prove what you already know or have learned on your own through practical problems and GitHub PRs. Preparation before starting · Basic Java syntax and a fundamental understanding of Git branching and commits are required.
This is a 4-week execution track where you prove concepts you have already learned through code, experimentation, and explanation.
WHAT YOU SHIP
What you will have after completion
Operational User–Todo API and Integration Testing
Verification code and logs demonstrating bean, proxy, and transaction behavior
18 Spring interview answers linked to actual code evidence
BEFORE
Finish the implementation once the annotation is attached and the response is received.
AFTER
Reproduce the request flow, proxies, beans, and transaction boundaries through tests and logs, and explain the reasoning behind your choices.
ACTUAL WORKFLOW
From application to review, in the order of the actual screens
Do not copy and submit the GitHub address. The Dingco website will handle everything from preparing your private repository and creating mission branches and PRs to checking detailed reviews.
1GitHub first, Discord lastAfter completing Kakao login and the pre-diagnosis, prepare your personal private repository; Discord roles and cohort channels will be connected at the end.2Perform the mission in your private repositoryThe website will guide you through creating the 'Todo API with Visible Request Flow and Evidence-based Answers' branch and PR. Do not copy and paste the PR address.3Check the score of 92 and specific groundsCheck the strengths and improvement points of the automated inspection and AI review in the Dingco detailed review and GitHub PR comments, and modify the same PR.4Spring Challenge 1st Cohort Operation ChannelIndividual 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 scores will vary depending on the participant and the cohort.
4-WEEK ROUTE
Weekly missions to transform what you already know into actual results
Every week, you will submit your implementation/experiments, tests/logs, reasoning for choices, and answers to questions in a single PR. Questions are not homework where you provide memorized answers; instead, you answer using the code and evidence you have just created.
W1
From Web Request to the First API
Observe HTTP and JSON and connect them to a directly executable Spring Boot API.
Weekly Integrated PRTodo API with Visible 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 status for valid input, and a 400 common error for invalid input.
[Required] GET /todos/{id} must return 200 for an existing Todo and a 404 common error for a non-existent id, and these three boundaries must be fixed with integration tests in the actual application context.
[Required] Explain the roles of DispatcherServlet, validation, and HttpMessageConverter in the process from a request becoming a controller argument to becoming a JSON response, by linking them to your own code and tests.
[Optional Extension] Replace the memory storage with H2·JdbcTemplate storage and verify that the same API contract tests are maintained.
Submission Evidence · Executable API code implementing 201, 400, and 404 contracts · Integration test results for success, validation failure, and 404 executed in an actual application context · Explanation of the request flow citing your own files and tests · Answers to this week's evidence-based questions 1–5 · Commits and verification results reflecting review feedback, or a record of "no feedback" if none was received
함께 답할 근거형 질문 5개
Through what process does an HTTP request become an argument for a controller method?
Who converts Java objects into JSON responses, and how did you verify that fact?
What is the reason for not using direct branching in the controller code to handle input validation failures?
What were the boundaries that absolutely had to be verified through integration testing rather than unit testing?
What is the part of the current API contract most likely to break first, and what is the method for verifying it?
W2
Understanding the Spring Container through Proxies, Beans, and DI
Verify Spring's automation through proxy, bean lifecycle, and dependency injection code.
Weekly Integrated PRDissecting Spring Container Automation and Evidence-Based Answers
[Required] Create two implementations of the same interface in the Todo use case, specify the selection criteria using @Qualifier or @Primary, and compare the ambiguity failure before selection with the successful injection after selection through isolated context tests.
[Required] Show through a test a scenario where either the dependency, lifecycle, or additional functionality actually differs between a bean connected via constructor injection and an object created directly using 'new'.
[Required] Apply AOP additional functionality to the Todo service, verify the proxy status and target class using AopUtils, and validate that the advice and target calls are recorded in the expected order and frequency only when called through the proxy.
[Optional Extension] Add bean lifecycle callbacks or scope proxies to compare one more boundary managed by the container.
Submission Evidence · Isolated context tests demonstrating both ambiguity failure and explicit bean selection · Test results asserting proxy type/target class and advice/target invocation order and frequency · Documentation linking observable differences between manually instantiated objects and container beans · Answers to this week's evidence-based questions 1–5 · Commits/verification results reflecting review feedback, or a record of "no feedback" if none was received
함께 답할 근거형 질문 5개
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 compared to field injection?
What is the most important difference between an object managed by a container and an object created manually?
How can you check whether it is a proxy object or the original object through code?
If the call sequence logs for this experiment had been missing, which explanation would you have been unable to verify?
W3
Layer Separation and Transactions
Verify the responsibilities of the service layer and transaction boundaries through failure scenarios.
Weekly Integrated PRServices that preserve consistency even in failure and evidence-based answers
[Required] Implement a repository that saves User and Todo using H2 and JdbcTemplate, and a service use case that coordinates both changes.
[Required] Call a service without a transaction so that it throws an exception immediately after saving a User, and verify partial storage (1 User, 0 Todos) after the exception while the test method is not annotated with @Transactional.
[Required] Ensure that a @Transactional service called from the outside via a Spring proxy fails at the same point, and prove the rollback of both changes by verifying 0 Users and 0 Todos through a separate query after exception handling.
[Optional Extension] Compare the default behavior of checked exceptions before and after applying rollbackFor, or proxy bypass for internal calls within the same class, through separate tests.
Submission Evidence · User/Todo JDBC repository and service layer code · Results of non-transactional User 1/Todo 0 vs. transactional User 0/Todo 0 verified outside the test transaction · Explanation of transaction boundaries connecting external proxy calls and database state queries · Answers to this week's evidence-based questions 1–4 · Commit/verification results reflecting review feedback, or a record of "no feedback" if none was received
함께 답할 근거형 질문 4개
What is the reason for placing the transaction boundary in the service layer rather than the controller or repository?
How do the default rollback behaviors differ between checked and unchecked exceptions, and how did you verify them?
Why can internal calls within the same class bypass the transaction proxy?
Why should rollback tests verify the actual state of the database?
W4
Completion of an operational API
Complete the API to be presented as a portfolio by applying exceptions, validation, logging, and paging.
Weekly Integrated PROperational User–Todo API and Final Rationale Package
[Required] Complete POST /users, POST /users/{userId}/todos, GET /todos/{id}, and GET /users/{userId}/todos as a single User–Todo contract, and record the reasons for maintaining or changing the Week 1 POST /todos contract.
[Required] Implement all 400 and 404 responses in a common format containing code, message, and requestId fields. For list retrieval, implement it to include default values of page=0 and size=20, a maximum size, ascending order by id, and metadata for totalElements and hasNext.
[Required] Fix empty lists, multiple pages, stable sorting, invalid page/size, validation failures, and 404s with integration tests.
[Required] Validate and reuse an external X-Request-Id or generate a new one, ensuring the same value is linked across response headers, error responses, and structured logs, while excluding request bodies and authentication information from the logs.
[Optional Extension] Add a comparison experiment for cursor paging or include the first observation metrics among request count, error rate, and latency.
Submission Evidence · Compatibility determination between the four specified User–Todo endpoints and the previous contract · Common error specifications for code, message, and requestId, and stable ID ascending paging specifications · API and paging integration tests including boundary values and execution results · Observational evidence confirming the same requestId across responses, errors, and logs · Answers to this week's evidence-based questions 1–4 · Commits and verification results reflecting review feedback, or a record of "no feedback" if none was received
함께 답할 근거형 질문 4개
What are the benefits for clients and operators when error response formats are standardized?
Why did you choose between page-based and cursor-based pagination for 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 actual operation?
WEEKLY LOOP
Complete a week's worth of practical tasks within a single PR.
Check weekly practical problems
Perform missions on your individual branch
Submit code, tests, and descriptions via PR
Check automatic inspection and AI reviews
Modify the same PR and merge automatically
Check passed PRs and official explanations
Reflecting cumulative peer reviews and crew learning records
Submissions are made only via GitHub PR. The challenge screen and GitHub are linked throughout the process, from branch creation to review and merging the correct head SHA. It automatically verifies whether the necessary evidence is included within the PR.
CREW ENGAGEMENT
Talk for only 20 minutes using the mission comments.
Starting from Week 2, leave a short comment on the PR, and the crew will share only the points where they got stuck and different approaches.
Mission comment starting from Week 2 Leave a comment of 10–300 characters about any difficulties encountered when submitting a PR.
20 minutes at a time set by the team Starting at 21:15 on Tuesdays by default, share only the points where you got stuck and alternative approaches.
Leader wraps up in 1 to 30 characters From Week 2, +5 for completed crews, separate from individual completion.
Team Bonus Activity Participants do not write separate posts other than the mission comment. The Crew +5 bonus is separate from individual completion.
LIVE SESSION
Once live, we will align on the process together
A live session will be held once during the challenge period. We will align on the completion criteria together and check on the spot how the submission process flows on the screen.
KICKOFF LIVE8/10(Mon) 20:00
60 min · Online
Spring Challenge Kickoff Live
Information on the 4-week process and completion criteria
Monday Kickoff: Preparing the first mission branch and a demo on submitting GitHub PRs after the Wednesday start
Real-time 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 check the completion criteria and submission methods on the Dingco website and Discord announcements.
CHALLENGE CONTRACT
Learn concepts individually, practice and feedback together
This challenge does not provide lectures, textbooks, Notion pages, or bonus materials. You apply what you already know or have learned on your own to actual problems and prove it through GitHub PRs.
The challenge provides
Weekly practical problems · Individual private practice repository · Clear passing criteria · Automated testing and AI review · Peer comparison and completion records
Participants prepare
Basic concepts in the relevant field · Experience with Git and GitHub PRs · Time to commit every week · An attitude of self-supplementing lacking concepts
Optional Pre-learning · Separate Purchase · 9 hours 58 minutes
[Lv1] Spring Boot that you can "explain" in an interview
This lecture and textbook are not included in the challenge, and enrollment is not mandatory. Please choose them only if you have areas of weakness identified in the pre-diagnosis or if you need to supplement your conceptual understanding.
Regardless of whether you have applied on Inflearn, check the recruitment status of the current cohort via the ‘Check Recruitment/Participation’ button above. Once you log in with Kakao on Dingco, your spot will be secured, and you will be ready to participate after completing all connections.
Select the current cohort on the Dingco recruitment and participation confirmation page and log in with Kakao to immediately create your challenge membership and secure your spot.
Once you pass the pre-diagnostic test for each cohort, the GitHub connection step will be unlocked.
If you connect GitHub first, organization permission verification and personal private repository preparation will be automatically scheduled.
Connecting Discord will grant you access to the Spring Challenge 1st cohort category and permissions for the announcement, reading material, question, and free-talk channels.
Create a submit/<mission> branch on the website, push your code, and submit a PR with a single button click.
Dingco automatically merges the latest commits that pass the automated checks and AI reviews, and we celebrate together in the free channel. On the Crew Discord, we share questions and progress; for official reviews, PRs passed by members of the same crew are opened first, but if none are available, it proceeds to PRs from other crews in the same cohort. The scoreboard is provisionally updated during the week and finalized after the last cumulative review deadline.
Read access for the same cohort Personal repositories are kept private, and participants from the same cohort can refer to them as read-only after the weekly results are released. Write access is granted only to your own repository. Crews usually consist of 5–6 members, and the roster is hidden until it is revealed. Detailed scorecards are not disclosed; only the winning crews who have consented after the final scores are confirmed will be introduced in the Hall of Fame with GitHub badges and public names. Registration closes at 19:00 on the Wednesday of the starting week. For tracks with a preliminary assessment, you must pass by the same time, and the crew list and dedicated Discord channel will be revealed at 20:00. The official start and the release of the Week 1 mission are at 21:00 on the same day. Thereafter, new missions open every Wednesday at 21:00, and submissions close the following Tuesday at 21:00. Official reviews do not have to be done immediately each week, but the required number of reviews based on different weekly criteria must be completed by 21:00 on the Sunday following the final week. Week 1 problems, personal repositories, and mission branches can be prepared in advance, and the PR submission button will be automatically activated once your crew channel setup is complete. Participants who have not finished linking GitHub and Discord will remain in their assigned crew.
FIT CHECK
Recommended for these types of people, and not recommended for these types of people
Recommended for
Those who have built Spring Boot APIs but find it difficult to explain their internal workings
Those who want to speak based on their own code and tests instead of memorizing interview answers.
Those who need small weekly PRs and automated reviews to push through to the end.
Not recommended
Those who have never handled Java syntax or HTTP requests and responses before.
Those who want to browse the content without submitting code and tests
COMPLETION
The completion criteria will be disclosed before the start.
Submit all 4 weekly integrated mission PRs over the course of 4 weeks.
Submit official reviews for passing PRs from three different weeks.
Preparation before starting
I need the basics of Java syntax and Git branching/committing.
You must participate in implementation, modifying explanations, and reflecting necessary reviews for approximately 4 to 6 hours each week.
FAQ
Most frequently asked questions before participating
Is this the same course as the existing 10-week bootcamp?
No. This challenge is a separate track where you complete one subject over four weeks. It only leads to the 10-week bootcamp if a longer project or job-focused curriculum is required.
Are lectures or textbooks also provided?
No. The challenge provides weekly problems, a private practice repository, submission criteria, and a review loop. The associated lectures are optional pre-learning materials available for separate purchase and are not mandatory to take.
Is it also possible to submit on the website or paste a link?
Submission results are only accepted via GitHub PR. However, preparing repositories, branches, and PRs, as well as checking reviews, can be easily accessed through buttons on the Dingco website.
What is shared on Discord?
Detailed individual reviews are not posted on Discord; only weekly summaries and operational announcements are shared. The Spring Challenge 1st cohort public channel is a space for reading materials, questions, free conversation, and operational guidance.
CREATOR NOTE
In the era of AI, what should junior developers study?
You can first check in the video which criteria should be used to execute and verify this problem.
Hello! Due to personal circumstances, I just started watching the recorded live lecture and tried to join the challenge via the invitation link, but it says it has expired. Is it too late to start now?
![[Lv1] 면접에서 "설명할 수 있는" Spring Boot 선택형 사전학습 강의 표지](https://cdn.inflearn.com/public/files/courses/339618/cover/01kc8ghjzfkvc8pjh0fzcx0jdd.gif?w=960)
