Dưới đây là 5 ví dụ về các dòng mô tả (bullet points) trong CV cho vị trí Backend Developer, có kết hợp số liệu cụ thể và liên kết minh chứng:
1. **Tối ưu hóa hiệu suất hệ thống:** Cải thiện 40% tốc độ phản hồi API (từ 500ms xuống 300ms) bằng cách thiết kế lại cấu trúc database và áp dụng Redis caching. [Link GitHub/Case Study]
2. **Xử lý dữ liệu lớn:** Xây dựng hệ thống xử lý dữ liệu thời gian thực bằng Kafka, giúp xử lý hơn 1 triệu sự kiện mỗi ngày với tỷ lệ lỗi dưới 0.01%. [Link Project]
3. **Tiết kiệm chi phí hạ tầng:** Giảm 30% chi phí vận hành server hàng tháng thông qua việc chuyển đổi sang kiến trúc Microservices và triển khai Auto-scaling trên AWS. [Link Blog kỹ thuật]
4. **Nâng cao độ tin cậy:** Thiết lập hệ thống CI/CD tự động giúp giảm thời gian triển khai (deployment time) đi 50% và đạt tỷ lệ uptime 99.9% cho hệ thống. [Link Repository]
5. **Phát triển tính năng cốt lõi:** Trực tiếp phát triển hệ thống thanh toán tích hợp, xử lý thành công hơn 50.000 giao dịch trong tháng đầu tiên ra mắt mà không xảy ra sự cố bảo mật nào. [Link Demo/Portfolio]
Báo cáo thử nghiệm tải, kế hoạch truy vấn, tính đồng thời và bộ nhớ đệm
Gói câu trả lời phỏng vấn kết nối từ danh mục bằng chứng đến các câu hỏi phụ.
Tốt nghiệp Đại học Khoa học và Công nghệ Pohang · Có kinh nghiệm phát triển backend tại Toss · Giảng viên Inflearn
20.000+ học viên tích lũy trên Inflearn · 2.000+ đánh giá khóa học · xếp hạng 4,9
Giải thích dễ hiểu từ lý do cần dùng cho đến cách sử dụng trong giao diện thực tế. Bắt đầu từ những chỗ người mới học thường gặp khó khăn, tôi sẽ cho bạn thấy quá trình tự tay tạo ra, nhấn thử và sửa lỗi. Trong thử thách này cũng vậy, hãy giao phần mã và hình ảnh cho Codex, còn bạn tập trung vào việc phán đoán luật chơi và kết quả.
Thử thách 6 tuần viết CV Backend · Miễn phí · 100 người đăng ký sớm nhất
THỬ THÁCH DINGCO · 6 TUẦN
Thay vì nói “Tôi đã làm việc chăm chỉ”, hãy tạo một bản hồ sơ năng lực biết nói bằng những con số trong 6 tuần.
Trực tiếp thực hiện thử nghiệm tải (load test), kế hoạch truy vấn (query plan), tính đồng thời (concurrency) và bộ nhớ đệm (cache) để lưu lại các số liệu trước và sau, từ đó hoàn thiện 5 gạch đầu dòng trong sơ yếu lý lịch và các câu trả lời cho câu hỏi đào sâu làm bằng chứng.
Miễn phí · 100 người đầu tiên
Được tạo bởi DingcoDingco, người có tổng cộng 18.000+ học viên trên Inflearn · mức độ hài lòng trung bình 4.9 · và kinh nghiệm trúng tuyển vào 38 doanh nghiệp
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 thi nhằm chứng minh những nội dung bạn đã biết hoặc tự học thông qua các bài toán thực tế và GitHub PR. Chuẩn bị trước khi bắt đầu · Việc nộp bài sẽ được thực hiện trên kho lưu trữ (repository) cá nhân riêng tư do Dingco tạo ra. Kho lưu trữ này chứa dự án dựa trên Java 17, Spring Boot, JPA, MySQL giống như trong bài giảng, và các sản phẩm cải tiến mà bài giảng đưa ra làm đáp án sẽ được để trống.
Đây là lộ trình thực thi trong 6 tuần nhằm chứng minh các khái niệm đã học thông qua mã nguồn, thực nghiệm và giải thích.
SẢN PHẨM BẠN BÀN GIAO
Những gì còn lại sau khi hoàn thành
3~5 gạch đầu dòng có khả năng phòng thủ, kết nối giữa căn cứ và giới hạn bên trong kho lưu trữ
Đáp án bài tập theo từng tuần của bài giảng và hồ sơ đo lường kế hoạch thực hiện·tải·tính đồng thời·cache
Gói câu trả lời phỏng vấn kết nối từ những khẳng định không thể xác minh cho đến các câu hỏi phụ.
BEFORE
Tạo ra những câu khó kiểm chứng trước, chẳng hạn như “Tôi đã cải thiện hiệu suất”.
AFTER
Thực hiện đúng theo bài tập của bài giảng để lại kế hoạch triển khai, chỉ số trước sau và kiểm thử hồi quy (regression test), sau đó nén lại thành các bullet point trong sơ yếu lý lịch.
RESUME PROOF CHAIN
Thay vì viết những câu văn hay, hãy tạo ra một chuỗi bằng chứng trước tiên
Đây không phải là việc chỉnh sửa để bao bọc kinh nghiệm sao cho có vẻ hay ho. Đây là quá trình tái hiện lại vấn đề thực tế của dự án, kiểm chứng các lựa chọn và kết quả, sau đó nén chúng lại thành ngôn ngữ dùng cho sơ yếu lý lịch và phỏng vấn.
01Định nghĩa vấn đềVấn đề là gì và tại sao
02Thí nghiệm tái hiệnThực hiện lại trong cùng điều kiện
03Số liệu trước và sauKết quả log·truy vấn·tải
04Căn cứ lựa chọnCác phương án thay thế và sự đánh đổi
05Một dòng trong sơ yếu lý lịchĐúc kết bằng hành động và tác động
06Câu trả lời phỏng vấnKết nối đến cả câu hỏi phụ
Nguyên văn sơ yếu lý lịch sẽ không được công khai. Trước khi công khai cho các thành viên (crew), chỉ có bản thân bạn và người quản trị mới có quyền truy cập, sau khi công khai, quyền đọc chỉ được mở cho các thành viên trong cùng nhóm. Trên Discord, chúng tôi chỉ chia sẻ các bản tóm tắt hàng tuần đã được ẩn danh và thông báo vận hành mà không có đánh giá cá nhân.
QUY TRÌNH LÀM VIỆC THỰC TẾ
Từ khi đăng ký đến lúc đánh giá, theo đúng trình tự màn hình thực tế
Bạn không cần sao chép và nộp địa chỉ GitHub. Trang chủ Dingco sẽ kết nối từ việc chuẩn bị kho lưu trữ cá nhân, tạo nhánh nhiệm vụ và PR, cho đến việc kiểm tra đánh giá chi tiết.
1GitHub trước, Discord sau cùngSau khi hoàn tất đăng nhập Kakao và chẩn đoán sơ bộ, hãy chuẩn bị kho lưu trữ cá nhân (private repository), còn vai trò Discord và kênh theo khóa học sẽ được kết nối sau cùng.2Thực hiện nhiệm vụ trong kho lưu trữ private của tôiTrang chủ sẽ kết nối việc tạo nhánh và PR cho 'Tạo tình huống vấn đề từ dự án tiêu chuẩn và viết theo mô hình định lượng'. Không sao chép và dán địa chỉ PR.3Kiểm tra 88 điểm và căn cứ cụ thểKiểm tra các điểm tốt và điểm cần cải thiện từ kiểm tra tự động và đánh giá của AI trong phần đánh giá chi tiết của Dingco và nhận xét trên GitHub PR, sau đó tiến hành chỉnh sửa trên cùng một PR đó.4Kênh vận hành Thử thách Viết CV Backend khóa 1Các đánh giá chi tiết cho từng cá nhân sẽ không được đăng 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 giao diện vận hành thực tế và quy tắc của kho lưu trữ/kênh. Tên kho lưu trữ, số thứ tự khóa học và điểm đánh giá sẽ thay đổi tùy theo người tham gia và khóa học.
LỘ TRÌNH 6 TUẦN
Nhiệm vụ hàng tuần giúp chuyển đổi những nội dung đã biết thành thành quả thực tế
Mỗi tuần, bạn sẽ nộp các nội dung bao gồm triển khai/thử nghiệm, kiểm thử/log, căn cứ lựa chọn và câu trả lời cho các câu hỏi vào trong một PR duy nhất. Các câu hỏi không phải là bài tập về nhà để nộp những câu trả lời đã học thuộc lòng, mà phải được trả lời dựa trên mã nguồn và bằng chứng mà bạn vừa tạo ra.
W1
Biến tính năng thành trải nghiệm giải quyết vấn đề
Theo sát tuần 1 của bài giảng, hãy tạo ra một tình huống vấn đề từ dự án cơ sở và viết các câu theo mô hình định lượng hóa.
PR tổng hợp hàng tuầnTạo tình huống vấn đề từ dự án cơ sở và viết theo mô hình định lượng
[필수] Chạy dự án cơ sở bằng docker compose và chọn 1 chức năng thường xuyên được gọi, chẳng hạn như truy vấn danh sách GET /api/studies, để xác nhận hoạt động bình thường. Làm theo phần "Phải tạo ra vấn đề" của tuần 1 bài giảng để dự đoán điều gì sẽ bị hỏng trước tiên khi số lượng người dùng của chức năng đó tăng lên.
[Bắt buộc] Đo thời gian phản hồi hiện tại của tính năng đã chọn ít nhất 3 lần với cùng một đầu vào và ghi lại vào phần căn cứ trong resume/resume.md. Sử dụng đúng định nghĩa về "Hiệu suất & Đo lường hiệu suất" từ tuần 1 của bài giảng.
[필수] 강의 1주차 "수치화 패턴"에 맞춰 이력서 문장 1개를 작성하고, 그 문장의 각 수치가 어디서 나왔는지 저장소 안 경로로 연결합니다. 아직 측정하지 못한 값은 확인 불가로 표시합니다.
[필수] src/test/ 아래에 그 기능의 회귀 테스트 1개를 추가해 이후 주차의 개선이 기능을 깨지 않는지 확인할 수 있게 만듭니다.
[Lựa chọn mở rộng] Tăng số lượng tình huống vấn đề ứng cử viên lên tối đa 3 và ghi lại cùng với thứ tự ưu tiên cũng như căn cứ.
Bằng chứng nộp bài · Đường dẫn API đã chọn và bản ghi kiểm tra thực thi/phản hồi docker compose · Thời gian phản hồi đo được ít nhất 3 lần cho cùng một đầu vào và điều kiện đo lường · 1 câu theo mẫu định lượng trong resume/resume.md và căn cứ cho mỗi con số trong kho lưu trữ · 1 bài kiểm tra hồi quy trong src/test/ và kết quả đầu ra đạt yêu cầu · Câu trả lời cho các câu hỏi từ 1 đến 4
함께 답할 근거형 질문 4개
Trong tính năng này, nếu số lượng người dùng tăng lên, bạn nghĩ điều gì sẽ trở thành điểm nghẽn (bottleneck) đầu tiên, và cơ sở cho dự đoán đó là gì?
Thời gian phản hồi đã đo lường đại diện cho mô hình sử dụng thực tế đến mức nào và có những hạn chế gì?
Trong những câu đã viết trong sơ yếu lý lịch, dựa trên bằng chứng nào để có thể phân biệt giữa thành quả của nhóm và sự đóng góp của bản thân bạn?
Trong câu hiện tại, những khẳng định nào vẫn chưa thể kiểm chứng được và kế hoạch để bổ sung chúng là gì?
W2
Cải thiện hiệu suất có thể quan sát được
Theo dõi tuần 2 của bài giảng, tôi sẽ tái hiện nghẽn cổ chai bằng Prometheus·Grafana và k6, sau đó lưu lại các chỉ số trước và sau khi thực hiện.
PR tổng hợp hàng tuầnThiết lập giám sát và đo lường TPS bằng k6
[필수] Chạy Prometheus và Grafana cùng với docker compose của dự án cơ sở, sau đó xác nhận rằng các chỉ số CPU·Bộ nhớ đang được thu thập theo đúng "Vai trò của từng container" trong tuần thứ 2 của bài giảng.
[필수] k6-scripts/ 아래 부하 스크립트로 1주차에 고른 API의 기준선 TPS와 응답 시간 분포를 측정합니다. 강의 2주차 "TPS 가 뭘까?"의 정의를 그대로 씁니다.
[Bắt buộc] Xác nhận thông qua các chỉ số xem tài nguyên nào chạm ngưỡng giới hạn trước trong quá trình tải, và ghi lại căn cứ đánh giá đó là điểm nghẽn vào file resume/resume.md.
[필수] Áp dụng một trong các phương pháp cải thiện hạ tầng · ứng dụng từ bài giảng tuần 2 "Vậy thì làm thế nào để cải thiện hiệu suất" và đo lường lại bằng cùng một kịch bản. Thay đổi đồng thời cả src/main/ và src/test/.
[Tùy chọn mở rộng] Sử dụng JMH để đo điểm chuẩn (benchmarking) các đoạn mã ứng dụng nhằm bổ sung số liệu.
Bằng chứng nộp bài · Chỉ số CPU·Bộ nhớ thu thập từ Prometheus·Grafana · Lệnh thực thi k6 và mức cơ sở TPS·Phân phối thời gian phản hồi · Kết quả đo lại bằng cùng một kịch bản sau khi áp dụng cải tiến và so sánh trước sau · Căn cứ phán đoán điểm nghẽn và câu văn trong hồ sơ tại resume/resume.md · Câu trả lời cho các câu hỏi từ 1~3
함께 답할 근거형 질문 3개
Nếu số lượng người dùng trong dự án hiện tại tăng lên hơn 400 người, những vấn đề gì sẽ phát sinh?
Nếu có thêm những tính năng nào có thể cung cấp bổ sung từ các tính năng hiện tại thì đó là gì? Để cung cấp tính năng đó thì cần có những thay đổi nào?
Nếu dự án hiện tại có lượng người dùng truy cập nhiều hơn dự kiến, chúng ta nên nghiên cứu về những vấn đề gì?
W3
Chỉ mục và Kế hoạch truy vấn (Index và Query Plan)
Dựa trên kế hoạch thực thi của API tìm kiếm đơn đăng ký theo tuần thứ 3 của bài giảng, thiết kế chỉ mục (index) và giải thích về chi phí.
PR tổng hợp hàng tuầnCải thiện API tìm kiếm đăng ký bằng kế hoạch thực thi
[필수] Khi chạy ứng dụng lần đầu, dữ liệu đăng ký sẽ được lấp đầy theo thiết lập app.seed.*. Hãy gọi GET /api/enrollments/search?from=&to=&status=&minFee= để tái hiện trạng thái chậm, đồng thời ghi lại quy mô seed và các chỉ số trong môi trường của bạn.
[Bắt buộc] Sử dụng EXPLAIN để lấy kế hoạch thực thi và chỉ ra chi phí phát sinh ở đâu dựa trên nội dung "Phân tích theo loại Query Plan" của tuần thứ 3 trong bài giảng.
[필수] Tự thiết kế chỉ mục hỗn hợp (composite index) và thêm vào DDL dưới thư mục src/main/resources/, sau đó so sánh kế hoạch thực thi và thời gian thực thi của cùng một câu truy vấn trước và sau khi áp dụng. Đừng sao chép nguyên văn chỉ mục mà bài giảng đưa ra làm đáp án, hãy để lại căn cứ quyết định thứ tự các cột dựa trên mẫu truy vấn (query pattern) của bản thân.
[필수] Đo lường số liệu thống kê theo từng thành viên của GET /api/enrollments/stats theo cách tương tự, và nếu chỉ sử dụng chỉ mục (index) vẫn còn hạn chế, hãy chọn và áp dụng một trong hai phương pháp: bảng tổng hợp (aggregation table) hoặc phi chuẩn hóa (denormalization).
[Bắt buộc] Thêm kiểm thử hồi quy (regression test) cho các truy vấn đã cải thiện bên dưới src/test/ để xác nhận kết quả vẫn giống như trước đó.
[선택 확장] 인덱스 추가 후 INSERT·UPDATE 성능을 별도로 측정해 트레이드오프를 수치로 남깁니다.
Bằng chứng nộp bài · Quy mô dữ liệu mẫu (app.seed.enrollments) và thời gian thực thi search·stats trước khi cải thiện · Kết quả EXPLAIN kế hoạch thực thi trước và sau khi cải thiện · DDL của chỉ mục (index) đã thêm và cơ sở quyết định thứ tự các cột · Kiểm thử hồi quy (regression test) trong src/test/ và kết quả vượt qua kiểm thử · Câu văn trong sơ yếu lý lịch đã phản ánh vào resume/resume.md · Câu trả lời cho các câu hỏi từ 1~4
함께 답할 근거형 질문 4개
Bạn nghĩ phần nào trong truy vấn hiện tại có khả năng gây ra nghẽn cổ chai (suy giảm hiệu suất)?
Nếu thêm mới index (hoặc index hỗn hợp), bạn muốn thêm vào (những) cột nào?
Sau khi áp dụng chỉ mục (index) hoặc tối ưu hóa truy vấn (query tuning), bạn có kế hoạch đo lường và kiểm chứng hiệu suất như thế nào?
Nếu sau khi áp dụng chỉ mục (index) mà xảy ra tình trạng giảm hiệu suất khi chèn hoặc chỉnh sửa dữ liệu, bạn sẽ đối phó như thế nào?
W4
Giao dịch và Tính đồng thời
Theo sát tuần thứ 4 của bài giảng, tái hiện lại sự tranh chấp số lượng người tham gia trong việc đăng ký học nhóm và lựa chọn chiến lược khóa (lock).
PR tổng hợp hàng tuầnTái hiện tranh chấp số lượng người đăng ký học và ngăn chặn bằng Lock
[필수] Gắn kiểm thử đa luồng (multi-thread test) vào POST /api/enrollments/studies/{studyId} để tái hiện thực tế tình trạng vượt quá số lượng người đăng ký tối đa. Giống như phần "Xác nhận bằng kiểm thử đa luồng" trong tuần thứ 4 của bài giảng, hãy cho thấy cả hai trường hợp: vượt qua khi chạy đơn luồng và thất bại khi có các yêu cầu đồng thời.
[Bắt buộc] Xác nhận rằng chỉ riêng mức độ cô lập (isolation level) là không đủ để ngăn chặn vấn đề, sau đó chọn một trong hai phương thức là Khóa lạc quan (Optimistic Lock) hoặc Khóa bi quan (Pessimistic Lock) từ bài giảng tuần 4 "Phương thức đặt khóa" để triển khai vào src/main/. Giải thích căn cứ lựa chọn dựa trên các yếu tố: tính nhất quán, số lượng thành công và số lượng thử lại.
[필수] Xác nhận rằng các bất biến (invariants) vẫn được duy trì sau khi cải thiện bằng cùng một bài kiểm tra đa luồng (multi-thread test) và lưu lại kết quả trước và sau khi thực hiện.
[필수] 점검하여 트랜잭션 안에서 제거할 수 있는 작업(예: 외부 호출)이 있는지 확인하고, 강의 4주차 "개선 : 트랜잭션 범위 줄이기"를 참고해 범위를 조정합니다.
[Lựa chọn mở rộng] So sánh chiến lược thứ hai (như Named Lock, v.v.) trong cùng điều kiện hoặc giải quyết bằng cách cố ý tái hiện tình trạng Deadlock.
Bằng chứng nộp bài · Kết quả test cho thấy trường hợp đơn luồng thành công và yêu cầu đồng thời thất bại · Mã nguồn triển khai chiến lược Lock đã chọn và căn cứ lựa chọn · Kết quả test sau khi cải thiện cho thấy tính bất biến được duy trì · Nội dung và căn cứ điều chỉnh phạm vi giao dịch (transaction) · Câu văn trong sơ yếu lý lịch đã được phản ánh vào resume/resume.md · Câu trả lời cho các câu hỏi từ 1 đến 4
함께 답할 근거형 질문 4개
Trong dự án hiện tại, những kịch bản nào có khả năng xảy ra vấn đề về tranh chấp đồng thời (concurrency)?
Nếu áp dụng kiểm soát đồng thời (Transaction Isolation, Lock, Optimistic Lock, v.v.), bạn có thể cân nhắc những phương pháp nào?
Làm thế nào để thiết lập phạm vi transaction và loại bỏ các tác vụ không cần thiết (ví dụ: gọi API bên ngoài) trong transaction?
Bạn có kế hoạch kiểm tra các vấn đề về đồng thời (concurrency issue) hoặc đo lường và kiểm chứng trước và sau khi cải thiện như thế nào?
W5
Hiệu suất JPA·Collection·Bất đồng bộ
Theo dõi tuần 5 của bài giảng để đếm số lượng truy vấn thực thi và cải thiện các điểm nghẽn thực tế trong số N+1, Bulk hoặc Bất đồng bộ.
PR tổng hợp hàng tuầnĐếm số lượng truy vấn của danh sách bình luận và cải thiện một trong các vấn đề N+1, Bulk hoặc Bất đồng bộ
[필수] Theo dõi bài giảng tuần 5 "Triển khai giám sát truy vấn thực thi theo từng API" để gắn thiết bị đếm số lượng truy vấn thực thi, và ghi lại số lượng truy vấn hiện tại của GET /api/studies/{id}/comments.
[필수] N+1, thao tác bulk, overhead của bộ lọc Stream, xử lý bất đồng bộ, hãy chọn **một** trong số đó và đưa ra bằng chứng cho thấy điểm đó thực sự là nút thắt cổ chai (bottleneck) thông qua số lượng truy vấn hoặc thời gian phản hồi trước. Danh sách bình luận thực hiện tải chậm (lazy loading) người viết, vì vậy nếu chọn N+1 thì hãy bắt đầu từ đây.
[필수] 고른 항목을 src/main/에서 개선합니다. N+1이라면 BatchSize·fetch join·EntityGraph 중 선택한 이유를, 비동기라면 스레드 풀 설정 근거를 함께 적습니다.
[bắt buộc] Đo lường lại số lượng truy vấn và thời gian phản hồi sau khi cải thiện trong cùng một điều kiện, đồng thời xác nhận kết quả có đồng nhất hay không thông qua kiểm thử hồi quy (regression test) trong src/test/.
[Tùy chọn mở rộng] Cải thiện cho đến mục thứ hai hoặc trực quan hóa các chỉ số bằng bảng điều khiển Grafana.
Bằng chứng nộp bài · Thiết bị giám sát số lượng truy vấn và số lượng truy vấn·thời gian phản hồi trước khi cải thiện · Căn cứ cho thấy mục đã chọn là điểm nghẽn · Mã nguồn đã cải thiện và căn cứ của kỹ thuật đã chọn · Kết quả đo lường lại trong cùng điều kiện sau khi cải thiện và kết quả đầu ra vượt qua kiểm thử hồi quy src/test/ · Câu văn trong sơ yếu lý lịch đã được phản ánh vào resume/resume.md · Câu trả lời cho các câu hỏi từ 1~4
함께 답할 근거형 질문 4개
Trong số các mục N+1 / Thao tác Bulk / Stream FilterOverhead / Xử lý bất đồng bộ, bạn đã áp dụng hạng mục nào và tại sao lại chọn phần đó?
Cụ thể bạn đã cải thiện (hoặc áp dụng) theo cách nào?
Kết quả giám sát (hoặc log) cho thấy điều gì đã được cải thiện trước và sau khi thực hiện, và cải thiện được bao nhiêu?
Những vấn đề gặp phải hoặc những điều cần lưu ý trong quá trình cải thiện là gì?
W6
Caching và câu chuyện sơ yếu lý lịch cuối cùng
Theo sát tuần thứ 6 của bài giảng để kiểm chứng Redis caching và failover mode, đồng thời đúc kết các minh chứng của 6 tuần vào sơ yếu lý lịch.
PR tổng hợp hàng tuầnÁp dụng Redis caching và nén minh chứng tuần 6 vào sơ yếu lý lịch
[필수] Kết nối với Redis trong docker compose, chọn một đối tượng để áp dụng caching bằng RedisTemplate hoặc @Cacheable dựa trên tiêu chuẩn "Nên caching dữ liệu nào?" của tuần thứ 6. GET /api/studies/popular là một ứng cử viên vì nó được tính toán lại mỗi khi gọi.
[필수] 캐시 적용 전후의 응답 시간과 DB 조회 수를 같은 조건에서 비교하고, 캐시 히트·미스가 실제로 관측되는 것을 확인합니다.
[필수] TTL과 무효화 전략을 정한 근거를 적고, 캐시된 데이터가 변경될 때 정합성을 어떻게 보장하는지 코드로 남깁니다.
[필수] Chọn một trong các "Trường hợp vấn đề điển hình" từ tuần thứ 6 của bài giảng bao gồm cache penetration, avalanche, hoặc Hot Key để áp dụng cơ chế ngăn chặn và xác nhận hoạt động.
[필수] 6주간 남긴 측정 근거에서 방어 가능한 이력서 bullet 3~5개만 resume/resume.md에 남기고, 제외한 주장과 그 이유를 함께 적습니다.
[tùy chọn mở rộng] Cấu hình dashboard chỉ số cache với Redis Exporter và Grafana.
Bằng chứng nộp bài · Căn cứ lựa chọn đối tượng caching và mã nguồn áp dụng · So sánh thời gian phản hồi, số lần truy vấn DB trước và sau khi cache cùng hồ sơ quan sát Hit/Miss · TTL, chiến lược vô hiệu hóa và mã nguồn đảm bảo tính nhất quán · Cơ chế ngăn chặn và xác nhận hoạt động cho các trường hợp sự cố cache đã chọn · 3~5 bullet trong sơ yếu lý lịch có liên kết với bằng chứng và các lập luận bị loại bỏ · Đáp án cho câu hỏi từ 1~5
함께 답할 근거형 질문 5개
Bạn đã lựa chọn dữ liệu để lưu vào bộ nhớ đệm (caching) như thế nào?
Bạn đã thiết lập chiến lược TTL (thời gian hết hạn) / vô hiệu hóa (invalidation) như thế nào?
Hiệu suất trước và sau khi áp dụng caching (thời gian phản hồi, tải trọng DB, v.v.) đã thay đổi như thế nào?
Làm thế nào để có thể ngăn chặn vấn đề Cache avalanche (tuyết lở bộ nhớ đệm) hay Hot Key?
Làm thế nào để đảm bảo tính nhất quán của dữ liệu (정합성) ngay cả khi dữ liệu được lưu trong bộ nhớ cache thay đổi?
WEEKLY LOOP
Hoàn thành thực hành của một tuần trong cùng một PR
Kiểm tra vấn đề thực tế theo từng tuần
Thực hiện nhiệm vụ trên nhánh (branch) cá nhân
Nộp PR bao gồm mã nguồn, bài kiểm tra và phần giải thích
Kiểm tra tự động và xác nhận đánh giá của AI
Sửa cùng một PR và tự động hợp nhất
Kiểm tra PR đã thông qua và 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 phi hành đoàn
Việc nộp bài chỉ sử dụng GitHub PR. Diff nộp bài và bằng chứng (evidence) sẽ được xem xét bởi người quản trị tổ chức GitHub và trình xử lý đánh giá tự động (hiện tại là Anthropic API). Thông tin cá nhân và bí mật công ty phải được loại bỏ trước khi nộp. 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ỉ thảo luận trong 20 phút về phần "Lời nhắn 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 (crew) chỉ chia sẻ về những điểm đang bị tắc nghẽn và các cách tiếp cận khác.
Từ tuần thứ 2, để lại một lời nhắn về nhiệm vụ Khi nộp PR, hãy để lại những điểm còn vướng mắc trong khoảng 10~300 ký tự.
20 phút vào thời gian nhóm đã định Mặc định là 21:15 thứ Ba, chỉ chia sẻ những điểm bị tắc nghẽn và các cách tiếp cận khác.
Trưởng nhóm tóm tắt trong 1~30 ký tự Từ tuần thứ 2, thành viên hoàn thành được +5 điểm, tách biệt với việc hoàn thành cá nhân.
Hoạt động thưởng cho nhóm Người tham gia không viết thêm bài viết nào khác ngoài lời nhắn thực hiện nhiệm vụ. Điểm thưởng Crew +5 được tính riêng biệt với việc hoàn thành cá nhân.
BUỔI LIVE (LIVE SESSION)
Một lần trực tiếp, cùng nhau thống nhất cách thức tiến hành
Trong thời gian diễn ra thử thách, một buổi Live Session sẽ được tổ chức. Chúng ta sẽ cùng nhau thống nhất các tiêu chuẩn hoàn thành và kiểm tra trực tiếp tại chỗ quy trình nộp bài hiển thị trên màn hình như thế nào.
KICKOFF LIVE20:00 Thứ Hai, ngày 24/8
60 phút · Trực tuyến
Kick-off Live Thử thách Viết CV Backend
Hướng dẫn về phương thức tiến hành và tiêu chuẩn hoàn thành trong 6 tuần
Chuẩn bị nhánh (branch) cho nhiệm vụ đầu tiên tại buổi Kick-off thứ Hai và demo cách nộp GitHub PR sau khi bắt đầu vào thứ Tư
Q&A trực tuyến
Link tham gia sẽ được đăng trên thông báo Discord trước khi bắt đầu. Ngay cả khi không thể tham gia trực tiếp, bạn vẫn có thể kiểm tra tiêu chuẩn hoàn thành và cách thức nộp bài trên trang chủ Dingco và thông báo Discord.
BẢN CAM KẾT THỬ THÁCH
Tự học khái niệm, cùng nhau thực chiến và 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 nội dung đã biết hoặc tự học vào các vấn đề thực tế và chứng minh thông qua GitHub PR.
Thử thách cung cấp
Các vấn đề thực tế theo từng tuần · Kho lưu trữ thực hành cá nhân (private) · Tiêu chuẩn vượt qua rõ ràng · Kiểm tra tự động và đánh giá bằng AI · So sánh với đồng nghiệp và kỷ lục hoàn thành
Người tham gia chuẩn bị
Khái niệm cơ bản trong 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 độ tự bổ sung các khái niệm còn thiếu
Học tập bổ trợ tự chọn · Mua riêng · 22 giờ 28 phút
Hoàn thành trong 6 tuần! 4 chiến lược tạo sự khác biệt cho CV Backend
Bài giảng và giáo trình này không bao gồm trong thử thách và việc học cũng không bắt buộc. Chỉ lựa chọn khi bạn có lĩnh vực còn thiếu trong chẩn đoán trước đó hoặc khi cần bổ sung khái niệm.
Bất kể bạn đã đăng ký trên Inflearn hay chưa, hãy kiểm tra trạng thái tuyển sinh của khóa hiện tại thông qua nút ‘Xác nhận tuyển sinh·tham gia’ ở trên. Khi bạn đăng nhập bằng Kakao trên Dingco, vị trí của bạn sẽ được đảm bảo, và sau khi hoàn tất tất cả các kết nối, việc chuẩn bị tham gia sẽ sẵn sàng.
Tại trang xác nhận tuyển sinh và tham gia của Dingco, hãy chọn khóa hiện tại và đăng nhập bằng Kakao, tư cách thành viên thử thách sẽ được tạo ngay lập tức và vị trí của bạn sẽ được đảm bảo.
Sau khi vượt qua bài kiểm tra đầu vào theo từng khóa, bước kết nối GitHub sẽ được mở.
Nếu bạn kết nối GitHub trước, một kho lưu trữ riêng tư (private repository) dành riêng cho sơ yếu lý lịch sẽ được chuẩn bị sẵn, nơi chỉ bạn và người quản trị mới có quyền truy cập trước khi công khai, và sau khi công khai cho đội ngũ, chỉ các thành viên trong cùng đội mới có thể đọc được.
Khi kết nối Discord, quyền truy cập vào danh mục Backend Resume Challenge khóa 1 và các kênh thông báo, tài liệu đọc, câu hỏi, tự do sẽ được thiết lập.
Trên trang chủ, hãy tạo nhánh submit/<nhiệm vụ>, push bằng chứng thực nghiệm và bản thảo sơ yếu lý lịch, sau đó gửi PR chỉ bằng một nút bấm.
Đánh giá chi tiết tự động sẽ được lưu lại trên Dingco và GitHub riêng tư (private), còn trên Discord sẽ không thông báo đánh giá cá nhân mà chỉ hướng dẫn tóm tắt hàng tuần đã được ẩn danh và các thông báo vận hành. Tại Discord của Crew, mọi người cùng chia sẻ câu hỏi và tiến độ công việc; đối với đánh giá chính thức, các PR đã vượt qua của cùng một Crew sẽ được ưu tiên mở trước, nếu không có sẽ tiếp tục với các PR của Crew khác trong cùng khóa. Bảng điểm sẽ được phản ánh tạm thời trong tuần và sẽ được chốt chính thức sau khi kết thúc đợt đánh giá tích lũy cuối cùng.
Chỉ cho phép cùng thành viên (crew) đọc sau khi công khai Kho lưu trữ sơ yếu lý lịch được giữ ở chế độ riêng tư (private) và sau khi kết quả được công bố, chỉ các thành viên trong cùng nhóm mới có thể xem ở chế độ chỉ đọc. Trước khi nộp, vui lòng che các thông tin nhạy cảm như thông tin liên lạc, tên công ty, tên khách hàng; đồng thời không đăng sơ yếu lý lịch gốc và các đánh giá riêng tư lên Discord. Bảng điểm chi tiết sẽ không được công khai, và sau khi điểm số cuối cùng được xác định, chỉ những thành viên chiến thắng đã đồng ý mới được giới thiệu trong Hall of Fame, huy hiệu GitHub và tên công khai. Hạn chót đăng ký tham gia là 19:00 thứ Tư của tuần bắt đầu. Các lộ trình có bài kiểm tra chẩn đoán trước phải vượt qua trước cùng thời điểm đó, danh sách thành viên và kênh Discord riêng sẽ được công bố vào lúc 20:00. Thời gian bắt đầu chính thức và công bố nhiệm vụ tuần 1 là 21:00 cùng ngày, sau đó các nhiệm vụ mới sẽ được mở vào 21:00 thứ Tư hàng tuần và hạn chót nộp bài là 21:00 thứ Ba tuần kế tiếp. Việc đánh giá (review) chính thức không nhất thiết phải thực hiện ngay mỗi tuần, nhưng phải hoàn thành số lượng đánh giá 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. Các bài toán tuần 1, kho lưu trữ cá nhân và nhánh nhiệm vụ có thể được chuẩn bị trước, nút nộp PR sẽ tự động được kích hoạt sau khi việc chuẩn bị kênh nhóm hoàn tất. Những người tham gia chưa hoàn tất kết nối GitHub/Discord vẫn sẽ được giữ nguyên nhóm đã phân bổ.
KIỂM TRA ĐỘ PHÙ HỢP
Phù hợp với những người này, và không phù hợp với những người này
Đề xuất cho những người sau
Những người đã nghe giảng nhưng chưa từng trực tiếp đo lường nên không có căn cứ để ghi vào sơ yếu lý lịch
Những người có dự án nhưng trong sơ yếu lý lịch chỉ liệt kê các chức năng CRUD
Những người viết rằng đã cải thiện hiệu suất nhưng lại gặp khó khăn trong việc giải thích điều kiện tái hiện và các con số cụ thể.
Không đề xuất
Những người định thực hiện thí nghiệm về tải trọng hoặc sự cố trên máy chủ vận hành hoặc dịch vụ của bên thứ ba
Những người định tải mã nguồn công ty, dữ liệu người dùng thực tế hoặc thông tin cá nhân lên kho lưu trữ
Những người muốn nộp nguyên văn các câu văn được tạo tự động
HOÀN THÀNH
Công bố tiêu chuẩn hoàn thành trước khi bắt đầu
Trong vòng 6 tuần, nộp tất cả 6 PR nhiệm vụ tích hợp theo từng tuần.
Gửi đánh giá chính thức (official review) cho các PR đã vượt qua của 5 tuần khác nhau.
Chuẩn bị trước khi bắt đầu
Việc nộp bài sẽ được thực hiện trên kho lưu trữ (repository) cá nhân riêng tư do Dingco tạo ra. Kho lưu trữ này đã bao gồm dự án mẫu dựa trên Java 17, Spring Boot, JPA và MySQL giống như trong bài giảng, và các phần sản phẩm cải tiến mà bài giảng đưa ra làm đáp án sẽ được để trống.
Ngôn ngữ và framework được cố định theo tiêu chuẩn của bài giảng. Bạn không thể nộp bài bằng các stack khác.
Mỗi tuần, bạn cần dành khoảng 6 đến 10 tiếng để theo dõi nội dung bài giảng của tuần đó, thực hiện đo lường và trau chuốt lại các câu văn.
FAQ
Những điều được hỏi nhiều nhất trước khi tham gia
Đây có phải là khóa học giống với Bootcamp 10 tuần trước đây không?
Không phải vậy. Thử thách này là một lộ trình riêng biệt để hoàn thành một môn học trong vòng 6 tuần. Chỉ trong trường hợp cần khóa học tập trung vào dự án dài hạn hoặc tìm việc làm thì mới tiếp nối bằng bootcamp 10 tuần.
Có bao gồm bài giảng hay giáo trình không?
Không phải vậy. Thử thách cung cấp các bài toán theo từng tuần, kho lưu trữ thực hành riêng tư (private repository), tiêu chuẩn nộp bài và quy trình đánh giá (review loop). Các bài giảng liên quan là phần học trước tùy chọn có thể mua riêng và việc tham gia học không phải là bắt buộc.
Có thể nộp bài trên trang chủ hoặc dán link vào được không?
Kết quả nộp bài chỉ được chấp nhận thông qua GitHub PR. Tuy nhiên, việc chuẩn bị kho lưu trữ (repository), nhánh (branch), PR và kiểm tra review có thể được thực hiện dễ dàng thông qua các nút bấm trên trang chủ Dingco.
Những gì sẽ được công khai trên Discord?
Trên Discord sẽ không đăng các bài đánh giá chi tiết cho từng cá nhân, mà chỉ chia sẻ các bản tóm tắt hàng tuần và thông báo vận hành. Kênh chung của Backend Resume Challenge khóa 1 là không gian dành cho các bài đọc, đặt câu hỏi, trò chuyện tự do và hướng dẫn vận hành.
GHI CHÚ CỦA NGƯỜI SÁNG TẠO
Phân tích hồ sơ của lập trình viên đã đỗ 5 công ty cùng lúc
Bạn có thể xem trước trong video về các tiêu chí để thực hiện và kiểm chứng vấn đề này.
