A Backend Resume Proven by Numbers: The 6-Week Completion Challenge
This is a 6-week completion challenge where you will directly conduct experiments on observation, performance, indexing, concurrency, and caching, record the before-and-after metrics, and condense that evidence into a single line on your resume and an interview answer.
🚀 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.
Backend Resume 6-Week Challenge · Free · First 100 people
DINGCO CHALLENGE · 6 WEEKS
Instead of saying "I worked hard," create a resume where the numbers speak for themselves in 6 weeks.
You will directly conduct load testing, query plans, and concurrency and cache experiments to record before-and-after metrics, and based on that evidence, you will complete five resume bullet points and answers to follow-up questions.
Free · First 100 people
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 and submission before starting will take place in a private repository created by Dinko. It contains a project based on Java 17, Spring Boot, JPA, and MySQL, similar to the lecture, but the improved outputs presented as answers in the lecture are provided as empty blanks.
This is a 6-week execution track where you prove the concepts you have already learned through code, experiments, and explanations.
WHAT YOU SHIP
What you will have upon completion
3 to 5 defensible bullets where evidence and limitations within the repository are connected
Weekly lecture assignment answers and measurement records for execution plans, load, concurrency, and cache.
An interview answer package that connects unverifiable claims with potential follow-up questions.
BEFORE
First, create sentences that are difficult to verify, such as "I improved performance."
AFTER
After completing the course assignments as instructed and recording the execution plan, before-and-after metrics, and regression tests, compress them into resume bullet points.
RESUME PROOF CHAIN
Instead of writing good sentences, create a chain of evidence first
This is not about editing to make experiences look plausible. It involves re-simulating actual project problems, verifying choices and results, and then condensing them into the language of resumes and interviews.
01Problem DefinitionWhat was the problem and why
02Reproduction ExperimentRe-run under the same conditions
03Before & After MetricsLogs, Queries, and Load Results
04Rationale for SelectionAlternatives and Trade-offs
05One-line ResumeCondensed into action and impact
06Interview AnswersConnecting to follow-up questions
The original resume will not be made public. Before being shared with the crew, only you and the administrator have access; after being shared, read permissions are granted only to the same crew. Only de-identified weekly summaries and operational announcements are shared on Discord without individual reviews.
ACTUAL WORKFLOW
From application to review, in the order of the actual screens
You do not copy and submit the GitHub address. The Dingco website handles 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 my private repositoryThe homepage will guide you through creating a branch and PR for 'Creating problem situations in the base project and writing in numerical patterns.' You do not need to copy and paste the PR address.3Check the 88-point score and specific groundsReview the strengths and improvement points from the automated inspection and AI review in the Dingco detailed review and GitHub PR comments, then modify the same PR.4Backend Resume Challenge 1st Cohort Operation ChannelDetailed individual 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.
6-WEEK ROUTE
Weekly missions to transform what you already know into actual deliverables
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 must answer using the code and evidence you have just created.
W1
Turning features into problem-solving experiences
Follow the first week of the lecture to create a problem situation in the base project and write sentences using the quantification pattern.
Weekly Integrated PRCreating a problem situation in the base project and writing in a numerical pattern
[Required] Run the reference project using docker compose, select one frequently called feature such as the GET /api/studies list inquiry, and verify its normal operation. Following the "You must create a problem" section from Week 1 of the lecture, predict what will break first as the number of users increases for that feature.
[Required] Measure the current response time of the selected feature at least three times with the same input and record it in the evidence section of resume/resume.md. Use the definition of "What is Performance & Performance Measurement" from Week 1 of the lecture exactly as it is.
[Required] Write one resume sentence following the "Quantification Pattern" from Week 1 of the lecture, and link each number in that sentence to its source path within the repository. Mark any values that have not yet been measured as unconfirmable.
[Required] Add one regression test for that feature under src/test/ to ensure that improvements in subsequent weeks do not break the functionality.
[Optional Extension] Increase the number of potential problem scenarios up to 3 and include their priorities along with the supporting rationale.
Submission Evidence · Selected API path and docker compose execution/response confirmation records · Response times measured at least 3 times for the same input and measurement conditions · One quantified pattern sentence from resume/resume.md and the evidence for each figure within the repository · One regression test in src/test/ and its passing output · Answers to questions 1-4
함께 답할 근거형 질문 4개
If the number of users increases in this feature, what do you think will become the first bottleneck, and what is the basis for that?
How representative are the measured response times of actual usage patterns, and what are their limitations?
What evidence can be used to distinguish between the team's achievements and your individual contributions in the resume sentences you wrote?
What are the claims in the current sentence that cannot yet be verified, and what is the plan to supplement them?
W2
Observable Performance Improvement
Following the second week of the lecture, I will reproduce the bottleneck using Prometheus, Grafana, and k6, and record the metrics before and after.
Weekly Integrated PRAttaching Monitoring and Measuring TPS with k6
[Required] Run Prometheus and Grafana together using the docker compose of the base project, and verify that CPU and memory metrics are being collected according to the "Role of each container" in Week 2 of the lecture.
[Required] Measure the baseline TPS and response time distribution of the API selected in Week 1 using the load script under k6-scripts/. Use the definition of "What is TPS?" from Week 2 of the lecture exactly as it is.
[Required] Identify which resource reaches its limit first during the load test through metrics, and record the basis for determining it as a bottleneck in resume/resume.md.
[Required] Apply one of the infrastructure or application improvement methods from the Week 2 lecture "Then how do we improve performance?" and re-measure using the same script. Modify both src/main/ and src/test/.
[Optional Extension] Supplement the figures by benchmarking application code segments using JMH.
Submission Evidence · CPU and memory metrics collected from Prometheus and Grafana · k6 execution command and baseline TPS/response time distribution · Re-measurement results using the same script after applying improvements and a before-and-after comparison · Bottleneck determination logic and resume sentences in resume/resume.md · Answers to questions 1-3
함께 답할 근거형 질문 3개
What problems would arise if the number of users in the current project increases to over 400?
Are there any additional features that could be provided beyond the current ones? What changes would be necessary to provide those features?
If more users than expected flock to our current project, what should we study?
W3
Index and Query Plan
Following the 3rd week of the lecture, design an index based on the execution plan of the application search API and explain the costs.
Weekly Integrated PRImproving the Enrollment Search API with Execution Plans
[Required] When the app is first launched, enrollment data is populated according to the app.seed.* settings. Call GET /api/enrollments/search?from=&to=&status=&minFee= to reproduce the slow state, and record both the seed scale and the performance metrics from your own environment.
[Required] Generate the execution plan using EXPLAIN and identify where the costs are occurring based on the "Analysis by Query Plan Type" from Week 3 of the lecture.
[Required] Design a composite index yourself, add it as a DDL under src/main/resources/, and compare the execution plan and execution time of the same query before and after. Do not simply copy the index suggested as the answer in the lecture; instead, provide the rationale for determining the column order based on your own query patterns.
[Required] Measure the member-specific aggregation of GET /api/enrollments/stats in the same way, and if there are limitations with indexes alone, choose and apply either an aggregation table or denormalization.
[Required] Add a regression test for the improved query under src/test/ to verify that the results remain the same as before.
[Optional Extension] Separately measure INSERT·UPDATE performance after adding indexes and record the trade-offs numerically.
Submission Evidence · Seed scale (app.seed.enrollments) and execution time of search·stats before improvement · EXPLAIN execution plan output before and after improvement · Added index DDL and rationale for column order · src/test/ regression tests and pass output · Resume sentences reflected in resume/resume.md · Answers to questions 1–4
함께 답할 근거형 질문 4개
Where do you think the potential bottlenecks (performance degradation) might be in the current query?
If you were to add a new index (or a composite index), which column(s) would you like to add it to?
After applying indexes or tuning queries, how do you plan to measure and verify the performance?
If performance degradation occurs during data insertion or modification after applying an index, how would you handle it?
W4
Transactions and Concurrency
Following the 4th week of the lecture, reproduce the capacity competition in study applications and select a locking strategy.
Weekly Integrated PRReproducing capacity contention in study applications and preventing it with locks
[Required] Attach a multi-threaded test to POST /api/enrollments/studies/{studyId} to actually reproduce the capacity exceeded state. Just like in the 4th week of the lecture, "Verification with Multi-threaded Tests," show both cases: passing in a single thread and failing under concurrent requests.
[Required] Confirm that isolation levels alone cannot prevent this, and choose between optimistic locking and pessimistic locking as taught in Week 4's "Locking Methods" to implement in src/main/. Explain the reasoning for your choice based on consistency, success count, and retry count.
[Required] Verify that invariants are maintained after improvements using the same multi-threaded test, and record both the before and after results.
[Required] Check if there are any tasks that can be removed from within the transaction (e.g., external calls), and adjust the scope by referring to the Week 4 lecture "Improvement: Reducing Transaction Scope."
[Optional Extension] Compare a second strategy (such as Named Lock) under the same conditions, or intentionally reproduce and resolve a deadlock.
Submission Evidence · Test output showing both single-thread success and concurrent request failure · Implementation code of the chosen locking strategy and the rationale for the choice · Output showing that invariants are maintained in the same test after improvement · Details and rationale for transaction scope adjustment · Resume sentences reflected in resume/resume.md · Answers to questions 1-4
함께 답할 근거형 질문 4개
What are the potential scenarios where concurrency issues could occur in the current project?
If you were to apply concurrency control (Transaction Isolation, Locks, Optimistic Locks, etc.), what methods could you consider?
How can you set the transaction scope and remove unnecessary tasks (e.g., external API calls) from within the transaction?
How do you plan to test concurrency issues or measure and verify the results before and after the improvements?
W5
JPA·Collection·Asynchronous Performance
Following Lecture Week 5, count the number of execution queries and improve actual bottlenecks among N+1, bulk, or asynchronous processing.
Weekly Integrated PRCount the number of queries in the comment list and improve one of N+1, bulk, or asynchronous performance
[Required] Implement the "API Execution Query Monitoring" from Week 5 of the lecture to attach a device that counts execution queries, and record the current number of queries for GET /api/studies/{id}/comments.
[Required] Choose **one** among N+1, bulk operations, Stream filter overhead, or asynchronous processing, and first provide evidence that this point is an actual bottleneck using either the number of queries or response time. Since the comment list uses lazy loading for authors, if you choose N+1, start from here.
[Required] Improve the selected items in src/main/. If it is N+1, include the reason for choosing among BatchSize, fetch join, or EntityGraph; if it is asynchronous, include the rationale for the thread pool configuration.
[Required] Re-measure the number of queries and response time under the same conditions after improvement, and verify that the results are identical through regression testing in src/test/.
[Optional Extension] Improve up to the second item or visualize metrics with a Grafana dashboard.
Submission Evidence · Query count monitoring device and pre-improvement query count/response time · Evidence that the selected item was a bottleneck · Improved code and rationale for the chosen technique · Post-improvement measurement results under the same conditions and src/test/ regression test pass output · Resume sentences reflected in resume/resume.md · Answers to questions 1-4
함께 답할 근거형 질문 4개
Among N+1, bulk operations, stream FilterOverhead, and asynchronous processing, which items did you apply and why did you choose those specific parts?
Specifically, in what way did you improve (or apply) it?
Based on the monitoring (or log) results, what specifically improved before and after the enhancement, and by how much?
What problems did you encounter during the improvement process, or what considerations had to be taken into account?
W6
Caching and the Final Resume Story
Following the 6th week of the lecture, verify Redis caching and failure modes, and condense the 6-week evidence into a resume.
Weekly Integrated PRApplying Redis Caching and Compressing Week 6 Evidence into a Resume
[Required] Connect to Redis in docker compose, select one target for caching based on the Week 6 lecture "What data should be cached?", and apply it using RedisTemplate or @Cacheable. GET /api/studies/popular is a candidate as it is recalculated upon every call.
[Required] Compare the response time and the number of DB queries before and after applying the cache under the same conditions, and verify that cache hits and misses are actually observed.
[Required] State the rationale for the chosen TTL and invalidation strategy, and provide code demonstrating how data consistency is guaranteed when cached data changes.
[Required] Select one of the "representative problem cases" from Week 6 of the lecture—cache penetration, avalanche, or hot key—apply a prevention mechanism, and verify its operation.
[Required] Select only 3–5 defensible resume bullets based on the measurement evidence gathered over the 6 weeks and record them in resume/resume.md, along with the excluded claims and the reasons for their exclusion.
[Optional Extension] Configure a cache metrics dashboard using Redis Exporter and Grafana.
Submission Evidence · Rationale for selecting caching targets and application code · Comparison of response times and DB query counts before and after caching, along with hit/miss observation records · TTL/invalidation strategy and consistency assurance code · Prevention mechanisms and operation verification for selected cache problem cases · 3–5 resume bullets linked to evidence and excluded claims · Answers to questions 1–5
함께 답할 근거형 질문 5개
How did you select the data to be cached?
How did you set the TTL (Time To Live) / invalidation strategy?
How did the performance (response time, DB load, etc.) change before and after applying caching?
How can we prevent Cache Avalanche or Hot Key issues?
How can you ensure data consistency even when the data stored in the cache changes?
WEEKLY LOOP
Complete a week's worth of practical tasks within a single PR.
Check weekly practical problems
Perform the mission on your personal branch
Submit code, tests, and explanations 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 through GitHub PRs. Submission diffs and evidence are reviewed by GitHub organization administrators and automated review processors (currently Anthropic API). Personal information and company secrets must be removed before submission. The system automatically verifies whether the necessary evidence is included within the PR.
CREW ENGAGEMENT
We will talk for only 20 minutes using the mission comments.
Starting from week 2, leave a short comment on the PR, and crew members will share only their roadblocks and alternative approaches.
Mission comment starting from Week 2 Leave a comment of 10 to 300 characters about any difficulties encountered when submitting the 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–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 points are separate from individual completion.
LIVE SESSION
Once live, we will align on the process together
We will hold one live session during the challenge period. We will align on the completion criteria and check on the spot how the submission process flows on the screen.
KICKOFF LIVE8/24(Mon) 20:00
60 min · Online
Backend Resume Challenge Kickoff Live
Information on the 6-week process and completion criteria
Preparation of the first mission branch at the Monday kickoff and a demonstration of GitHub PR submission after the start on Wednesday
Real-time Q&A
The participation link will be posted in the Discord announcement before the start. Even if you cannot participate in 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 real-world problems and prove it through GitHub PRs.
The challenge provides
Weekly practical problems · Personal private practice repository · Clear passing criteria · Automated checks and AI reviews · Peer comparisons and completion records
What the participant prepares
Basic concepts in the relevant field · Experience with Git and GitHub PRs · Time to commit every week · An attitude to self-supplement lacking concepts
Optional Pre-learning · Separate Purchase · 22 hours 28 minutes
6 weeks to completion! 4 strategies to differentiate your backend resume
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 understanding of the concepts.
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 for each cohort, the GitHub connection step will open.
If you connect GitHub first, a private repository dedicated to your resume will be scheduled for preparation; it will be accessible only to you and the administrators before it is made public, and readable only by your fellow crew members after it is opened to the crew.
Connecting Discord will grant you access to the Backend Resume Challenge 1st Cohort category, along with permissions for the announcement, reading materials, Q&A, and free-talk channels.
Create a submit/<mission> branch on the homepage, push your experimental evidence and resume draft, and then submit the PR with a single click of a button.
Detailed automatic reviews are left on Dingko and private GitHub, while Discord provides non-identified weekly summaries and operational announcements instead of individual reviews. In the Crew Discord, questions and progress are shared together. Official reviews prioritize passing PRs from the same crew, but if none are available, they proceed to PRs from other crews in the same cohort. The scoreboard is tentatively updated during the week and finalized after the last cumulative review deadline.
Read-only for the same crew after disclosure Resume repositories are kept private, and after the results are disclosed, they can be viewed as read-only by members of the same crew. Before submission, please mask sensitive information such as contact details, company names, and client names, and do not post original resumes or private reviews on Discord. Detailed scorecards will not be disclosed, and only the winning crews who have consented will be introduced in the Hall of Fame, with GitHub badges, and by their public names after the final scores are confirmed. Participation registration closes at 19:00 on the Wednesday of the starting week. For tracks with a preliminary diagnosis, 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 weeks 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 fully connected their GitHub and Discord accounts will remain in their assigned crew.
FIT CHECK
This is suitable for these people, but not for others
I recommend this to
Those who have taken lectures but have never measured anything themselves, and thus lack evidence to include in their resume.
Those who have projects but end up only listing CRUD functions on their resume
Those who write that they have improved performance but find it difficult to explain the reproduction conditions and numerical data.
Not recommended
Those who intend to run load or failure tests on production servers or third-party services
Those who intend to upload company code, actual user data, or personal information to the repository
Those who want to submit automatically generated sentences as they are
COMPLETION
The completion criteria will be disclosed before the start.
Submit all 6 weekly integrated mission PRs over the course of 6 weeks.
Submit official reviews for passing PRs from 5 different weeks.
Preparation before starting
Submissions will be made through a personal private repository created by Dingco. The repository contains a project based on Java 17, Spring Boot, JPA, and MySQL, consistent with the course. The improved deliverables presented as answers in the course are provided as empty states.
The language and framework are fixed based on the lecture. You cannot submit using a different stack.
Every week, you must spend approximately 6 to 10 hours following the corresponding week of the lecture, measuring progress and refining sentences.
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 designed to complete one subject over the course of 6 weeks. It leads to the 10-week bootcamp only 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 connected 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 accepted only 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?
Individual detailed reviews are not posted on Discord; only weekly summaries and operational announcements are shared. The Backend Resume Challenge 1st Cohort public channel is a space for reading materials, questions, free conversation, and operational guidance.
CREATOR NOTE
Analyzing the resume of a developer who was accepted by 5 companies simultaneously
You can first check the video to see what criteria should be used to execute and verify this problem.
- Optimized database query performance by 40% through indexing and query restructuring, reducing API response time from 500ms to 300ms. [https://github.com/username/project-repo]
- Scaled system architecture to handle a 200% increase in concurrent users (from 5,000 to 15,000) by implementing Redis caching and load balancing. [https://project-demo-link.com]
- Reduced server infrastructure costs by 25% by migrating monolithic services to a microservices architecture (MSA) using Docker and Kubernetes. [https://github.com/username/msa-migration]
- Improved test coverage from 65% to 92% by implementing automated unit and integration tests, resulting in a 30% decrease in production bug reports. [https://github.com/username/test-automation]
- Integrated a third-party payment gateway API, successfully processing over 10,000 transactions with a 99.9% success rate. [https://github.com/username/payment-service]
Load, Query Plan, Concurrency, and Cache Experiment Report
An interview answer package linked with an evidence inventory and follow-up questions
Recommended for these people
Who is this course right for?
Those who have projects but end up only listing CRUD functions on their resume
Those who write that they have improved performance but find it difficult to explain the reproduction conditions and numerical data.
Those who want to manage their resumes and interview answers in a single evidence repository
Need to know before starting?
I need one individual or team backend project to use on my resume.
Every week, you must repeat the process of experimenting, measuring, and revising sentences for approximately 6 to 10 hours.
Secure a study time of 10–12 hours per week.
취소 및 환불 규정 챌린지는 지식공유자가 설정한 수업 최소 정원이 충족되지 않을 경우, 폐강 안내가 고지되며 결제 내역이 자동취소됩니다.
