Dự án cá nhân cho junior developer: nhà tuyển dụng muốn xem gì

Dự án cá nhân cho junior developer nên là dự án gì? Đó là một dự án nhỏ giải quyết vấn đề thật của bạn, có bản chạy thử, có README kể lại các quyết định, và có một phần khó bạn giải thích được trong hai phút. Cùng mình chấm thử ba dự án của Minh nhé!

Minh đang mắc ở đâu?

Ở bài trước, Minh sửa xong 10 lỗi trong CV. Minh là nhân vật minh họa, ghép từ những tình huống rất quen thuộc của sinh viên IT mới ra trường, còn các lời khuyên thì áp dụng được ngay cho bạn.

CV mới đã sạch sẽ: một trang, một cột, kỹ năng chia nhóm, có link GitHub. Nhưng khi đặt cạnh tin tuyển dụng, Minh thấy mục dự án vẫn còn mỏng. Đồ án tốt nghiệp là dự án nhóm bốn người, phần của Minh chỉ là giỏ hàng và thanh toán. Netflix clone thì đã bị gạch khỏi CV. Dự án cá nhân về sổ chi tiêu thì mới có ý tưởng.

Câu hỏi của Minh cũng là câu mình được hỏi nhiều nhất: làm dự án gì, và làm đến đâu thì đủ?

Người xem dự án của bạn thực sự làm gì?

Trước khi chọn dự án, hãy hình dung người sẽ mở nó ra. Đó có thể là một developer trong team đang tuyển, được nhờ xem nhanh vài hồ sơ giữa hai việc khác. Họ không có cả buổi chiều cho bạn.

Mình không có số liệu chính thức về chuyện này, nhưng các bài chia sẻ của người tuyển dụng mà mình đọc được đều mô tả một thứ tự khá giống nhau. Đầu tiên họ bấm link bản chạy thử, xem app có mở được không và làm được gì. Sau đó họ đọc README để hiểu dự án giải quyết vấn đề gì. Nếu còn thời gian và còn tò mò, họ mới mở code, lướt qua một file quan trọng và lịch sử commit.

Từ thứ tự đó, bạn rút ra được một điều quan trọng: dự án cần thuyết phục ngay ở những bước đầu. Code đẹp mà không có bản chạy thử và README thì người xem thường dừng lại trước khi kịp thấy code đẹp.

Sáu câu hỏi để chấm một dự án

Để Minh không phải đoán, mình viết một bảng chấm gồm sáu câu hỏi, mỗi câu 0, 1 hoặc 2 điểm. Bảng này nằm trong file cham-diem-du-an.md của demo, bạn có thể chép về dùng.

Câu thứ nhất hỏi dự án giải quyết vấn đề của ai. Bài tập trên lớp hay dự án làm theo video được 0 điểm, vì vấn đề đã được người khác giải quyết sẵn. Dự án giải quyết một vấn đề có thật nhưng chưa ai dùng được 1 điểm. Có người dùng thật, kể cả chỉ là bạn và vài người quen, được 2 điểm. Người dùng thật quan trọng vì họ mang tới những lỗi mà bạn không tự nghĩ ra.

Câu thứ hai hỏi người đọc CV có mở thử được không. Không có link là 0, chỉ có repo là 1, có bản chạy thử mở được trên điện thoại là 2. Mình nhấn mạnh chữ "điện thoại" vì rất nhiều người xem CV bằng điện thoại, và một trang vỡ bố cục trên màn hình nhỏ để lại ấn tượng không tốt.

Câu thứ ba hỏi README trả lời được gì. Theo tài liệu của GitHub về README, một README thường cho biết dự án làm gì, vì sao nó hữu ích và bắt đầu dùng thế nào. Với dự án dùng để xin việc, mình muốn thêm một phần nữa là các quyết định kỹ thuật, vì đó là chỗ người xem thấy được cách bạn suy nghĩ.

Câu thứ tư hỏi phần khó nhất do ai làm. Không có phần khó là 0 điểm. Có nhưng bạn chưa giải thích được là 1. Giải thích được trong hai phút, gồm vì sao khó, đã thử gì, cuối cùng chọn gì, là 2 điểm.

Câu thứ năm hỏi có dấu vết làm việc nghiêm túc không. Commit nào cũng ghi "update", không có test nào, thì 0. Commit có ý nghĩa, có test cho phần khó, có xử lý lỗi, thì 2. Bài viết commit message dễ đọc có mẫu để bạn bắt đầu ngay hôm nay.

Câu thứ sáu hỏi dự án có khớp với vị trí ứng tuyển không. Ứng tuyển Frontend React mà dự án viết bằng PHP thì vẫn có giá trị, nhưng không chứng minh được điều người tuyển cần biết.

Tổng tối đa là 12. Từ 9 điểm trở lên thì đưa lên đầu mục Dự án. Từ 5 đến 8 thì giữ lại nếu còn chỗ, và sửa câu có điểm thấp nhất trước. Dưới 5 thì nên bỏ khỏi CV, hoặc làm tiếp cho tới khi đạt.

Bảng này không phải thang đo chính thức của công ty nào. Đó là cách mình gom những điều người xem dự án hay để ý thành một danh sách kiểm tra được.

Vì sao Netflix clone không giúp được Minh?

Minh chấm thử ba dự án của mình theo sáu câu hỏi ở trên. Điểm số dưới đây là minh họa, mỗi điểm kèm lý do để bạn tự chấm dự án của mình theo cùng cách.

Netflix clone làm theo video được 3 trên 12 điểm:

• Câu 1 được 0, vì dự án không giải quyết vấn đề của ai, chỉ chép lại một giao diện có sẵn.
• Câu 2 được 1, vì có repo nhưng bản chạy thử đã hỏng từ lâu.
• Câu 3 được 0, vì README vẫn là file mặc định do công cụ tạo ra.
• Câu 4 được 0, vì phần khó nhất do người làm video giải quyết.
• Câu 5 được 0, vì commit nào cũng ghi "update" và không có test.
• Câu 6 được 2, vì dự án viết bằng React, đúng công nghệ của vị trí ứng tuyển.

Website bán cà phê, đồ án tốt nghiệp nhóm bốn người, được 8 điểm:

• Câu 1 được 1, vì đây là đề tài do trường giao, chưa có người dùng thật.
• Câu 2 được 2, vì bản chạy thử vẫn mở được trên điện thoại.
• Câu 3 được 1, vì README có mô tả và lệnh chạy nhưng không có quyết định kỹ thuật nào.
• Câu 4 được 1, vì phần khó nhất là thanh toán mà Minh chỉ làm giao diện, phần kết nối cổng thanh toán do bạn khác làm.
• Câu 5 được 1, vì commit có ý nghĩa nhưng gần như không có test.
• Câu 6 được 2, vì dùng React như vị trí ứng tuyển.

Sổ chi tiêu qua tin nhắn, sau ba tuần làm buổi tối, được 11 điểm:

• Câu 1 được 2, vì Minh và vài người bạn dùng nó mỗi ngày.
• Câu 2 được 2, vì có bản chạy thử dùng được ngay trên điện thoại.
• Câu 3 được 2, vì README có vấn đề, ảnh minh họa, lệnh chạy và mục quyết định kỹ thuật.
• Câu 4 được 2, vì phần đọc số tiền do chính Minh làm và giải thích được.
• Câu 5 được 1, vì có 21 test nhưng chưa xử lý lỗi khi lưu dữ liệu thất bại.
• Câu 6 được 2, vì dùng TypeScript và Next.js, đúng tin tuyển dụng.

Netflix clone chỉ được 3 điểm, và 2 trong số đó đến từ việc dùng React. Vấn đề của nó không nằm ở chỗ làm theo video, vì làm theo video là một cách học tốt. Vấn đề là mọi quyết định khó trong dự án đều do người làm video đưa ra. Khi người phỏng vấn hỏi "vì sao em chia component như vậy", câu trả lời thật là "vì video làm thế", và cả hai bên đều biết điều đó.

Hàng trăm ứng viên khác cũng có đúng dự án này, với gần như đúng giao diện này. Nó không giúp người xem phân biệt bạn với người khác, mà đó lại là việc chính của mục Dự án.

Đồ án nhóm được 8 điểm, khá ổn. Điểm trừ đáng chú ý nhất là câu 4, vì phần khó nhất của dự án không phải do Minh làm. Vì vậy, như bài trước đã nói, CV cần ghi rõ phần của Minh, và Minh chỉ nên nhận những gì mình giải thích được.

Sổ chi tiêu là dự án Minh sẽ đặt lên đầu. Điều thú vị là nó nhỏ hơn hẳn hai dự án kia, không có giao diện cầu kỳ, không có thanh toán. Nó thắng nhờ ba thứ mà hai dự án kia thiếu: có người dùng thật, có phần khó do chính Minh giải quyết, và có câu chuyện để kể.

Tìm ý tưởng từ những thứ làm bạn thấy phiền

Câu hỏi khó nhất là nghĩ ra dự án gì. Cách mình hay gợi ý là đừng ngồi nghĩ, mà hãy để ý trong một tuần. Mỗi lần bạn thấy phiền vì một việc lặp đi lặp lại, một bảng tính lộn xộn, một nhóm chat cãi nhau vì tiền, hãy ghi một dòng vào điện thoại.

Cuối tuần, bạn lọc danh sách bằng bốn câu hỏi.

Có ít nhất một người, kể cả bạn, gặp chuyện này mỗi tuần không? Bản đầu tiên có làm xong trong hai, ba tuần buổi tối không? Có ít nhất một phần khó vừa sức không? Có dùng được công nghệ của vị trí bạn muốn ứng tuyển không?

Sau một tuần, danh sách của Minh (minh họa) có năm dòng. Mỗi dòng gồm điều làm Minh phiền, dự án có thể làm, và kết quả khi lọc qua bốn câu hỏi:

• Minh hay quên mình đã tiêu bao nhiêu trong tháng, nên có thể làm app ghi chi tiêu bằng tin nhắn. Ý tưởng này qua cả bốn câu, vì Minh gặp nó mỗi ngày, bản đầu làm được trong ba tuần, phần đọc số tiền là phần khó vừa sức, và làm được bằng React. Minh chọn ý tưởng này.
• Lớp của Minh chia tiền ăn qua nhóm chat và cuối tháng hay cãi nhau, nên có thể làm app chia tiền nhóm. Ý tưởng này cũng qua cả bốn câu, nhưng Minh để dành, vì chỉ nên làm một dự án chính mỗi lần.
• Câu lạc bộ điểm danh bằng Google Form rồi đếm tay, nên có thể làm app điểm danh bằng mã QR. Ý tưởng này qua về mặt kỹ thuật, nhưng cần người trong câu lạc bộ chịu dùng thì mới có người dùng thật, nên Minh chưa chọn.
• Minh muốn xem phim mới, nên nghĩ tới Netflix clone. Ý tưởng này trượt ngay câu đầu, vì nó không giải quyết vấn đề của ai.
• Minh muốn học Kubernetes, nên nghĩ tới việc dựng một cụm Kubernetes. Ý tưởng này trượt câu cuối, vì Minh đang ứng tuyển Frontend.

Hai dòng cuối là hai cái bẫy quen thuộc. Một là chọn dự án theo thứ mình thích xem chứ không theo vấn đề cần giải quyết. Hai là chọn dự án theo công nghệ đang hot chứ không theo vị trí đang ứng tuyển. Không có gì sai khi học Kubernetes, nhưng nó không giúp được Minh ở vòng hồ sơ Frontend.

Dự án giải quyết vấn đề của chính bạn có một lợi thế rất lớn: bạn là người dùng đầu tiên, nên bạn gặp lỗi thật. Dự án sổ chi tiêu của Minh cũng chính là dự án được làm thật trong series Làm side project cùng AI. Ở đó, chỉ trong hai buổi tối đã lộ ra hai lỗi rất "đời thường": nhắn "cà phê 35 nghìn" thì app ghi 35 đồng, và khoản chi lúc 6:30 sáng ngày 1/12 bị cộng vào tháng 11 vì máy chủ chạy theo giờ UTC. Không bài tập nào cho bạn những lỗi như vậy, và chính chúng là thứ đáng kể trong phỏng vấn.

Phạm vi nhỏ đến mức làm xong được

Lỗi phổ biến nhất mình thấy ở dự án cá nhân không phải là chọn sai ý tưởng, mà là làm không xong. Một app chi tiêu có đăng nhập, danh mục, biểu đồ, ngân sách, xuất Excel, làm được 60% mỗi thứ, thì không có bản chạy thử nào dùng được. Theo bảng chấm ở trên, nó mất điểm ngay ở câu 2.

Cách cắt phạm vi mà mình thấy hiệu quả nhất là viết đúng một câu theo mẫu "người dùng làm được X trong Y giây". Câu của Minh là: mình ghi được một khoản chi trong 5 giây, không cần mở app. Mọi tính năng không phục vụ câu đó đều để sang bản sau. Danh mục, biểu đồ, nhiều người dùng đều ra khỏi bản đầu tiên.

Bản đầu tiên nhỏ thì làm xong trong ba tuần buổi tối, có người dùng sớm, và có lỗi thật để sửa. Một dự án nhỏ đã xong luôn có giá trị hơn một dự án lớn còn dang dở.

Phần khó vừa sức là phần đáng kể nhất

Ở vòng phỏng vấn, câu "kể về dự án của bạn" gần như chắc chắn sẽ xuất hiện, và người phỏng vấn sẽ đào vào phần khó nhất. Vì vậy, khi chọn dự án, bạn nên chắc rằng nó có một phần khó do chính bạn giải quyết.

"Khó" ở đây không có nghĩa là thuật toán phức tạp. Với dự án của Minh, phần khó là đọc số tiền theo đủ kiểu người Việt hay viết: "35k", "45.000", "1tr2", "35 nghìn". Nó vừa sức một junior, nhưng đủ để có quyết định, có thử nghiệm, có sai lầm. Một câu trả lời hai phút về phần này có thể đi theo bốn bước (đây là ví dụ minh họa):

Khó nhất là đọc số tiền, vì người Việt viết rất nhiều kiểu, và dấu chấm trong "45.000" là dấu ngăn hàng nghìn chứ không phải dấu thập phân. Bản đầu tiên em viết vội đọc "trà sữa 32K" thành 32 tỷ, vì hàm thấy chữ "tr" là nhân thêm một triệu. Em chuyển sang viết một bảng ví dụ trước, mỗi dòng là một test, rồi mới viết code. Có một quyết định em cân nhắc khá lâu: khi tin nhắn có hai số tiền thì em chọn từ chối, vì ghi sai số tiền tệ hơn bắt người dùng nhắn lại. Hiện app vẫn chưa hiểu "1 triệu 2", em ghi lại trong spec là chưa hỗ trợ.

Câu trả lời này có vấn đề, có lần thử sai, có quyết định kèm lý do, và có giới hạn được thừa nhận. Người phỏng vấn không cần dự án hoàn hảo. Họ cần thấy bạn suy nghĩ thế nào khi gặp vấn đề.

README biến dự án thành một câu chuyện

README là trang đầu tiên người xem đọc sau bản chạy thử, nên mình coi nó là một phần của dự án chứ không phải việc làm thêm. Dưới đây là README đầy đủ cho dự án sổ chi tiêu của Minh. Bạn có thể chép về làm khung, rồi thay nội dung bằng dự án của mình. Link và ảnh trong mẫu là ví dụ:

# Sổ chi tiêu qua tin nhắn

Nhắn `cà phê 35k` là ghi xong một khoản chi. Nhắn `/tong` để xem tổng tháng này.

Bản chạy thử: so-chi-tieu.vercel.app · Ảnh: docs/demo.gif (nhắn 3 khoản rồi xem tổng)

## Vì sao làm
Mình hay quên đã tiêu bao nhiêu, và lười mở app ghi chép có form 5 ô. Nhắn một dòng thì không lười được.

## Làm được gì
- Đọc số tiền theo cách người Việt hay viết: `35k`, `45.000`, `1tr2`, `35 nghìn`.
- Không hiểu thì hỏi lại, không đoán: `cà phê 35k 40k` bị từ chối vì có hai số tiền.
- `/tong` cộng theo tháng giờ Việt Nam, kể cả khi máy chủ chạy giờ UTC.

## Quyết định kỹ thuật
- Tự viết phần đọc số tiền, không dùng thư viện, vì quy tắc đặc thù tiếng Việt. Mỗi quy tắc là một dòng trong SPEC.md và một test.
- Từ chối khi mơ hồ, vì ghi sai số tiền tệ hơn bắt người dùng nhắn lại.
- Tính tháng theo Asia/Ho_Chi_Minh. Đây là lỗi thật đã gặp: khoản chi 6:30 sáng 1/12 bị tính vào tháng 11 vì máy chủ chạy giờ UTC.

## Chạy trên máy
npm install
npm test
npm run dev

## Tiếp theo
Lưu vào database; nhận tin nhắn qua Telegram.

Mục mình muốn bạn chú ý nhất là "Quyết định kỹ thuật". Ba dòng trong mục này làm được việc mà code không làm được, là cho người xem thấy lý do đằng sau từng lựa chọn. Một người lướt qua README trong một phút đã biết Minh viết test, biết cân nhắc trải nghiệm người dùng, và từng xử lý lỗi múi giờ. Đó cũng chính là ba câu hỏi phỏng vấn mà Minh đã chuẩn bị sẵn câu trả lời.

Các mục còn lại thì đơn giản hơn, nhưng thứ tự của chúng có lý do. Câu mô tả và link bản chạy thử nằm trên cùng, vì đó là hai thứ người xem cần trong mười giây đầu. Lệnh chạy trên máy nằm gần cuối, vì chỉ người muốn đọc code mới cần tới. Bài README là điểm bắt đầu của một sản phẩm tốt có hướng dẫn chi tiết hơn cho từng phần.

Một dự án lớn hay nhiều dự án nhỏ?

Theo mình, với junior, một dự án chính thật tốt cộng thêm một hai dự án phụ là đủ. Ba dự án 11 điểm khó làm hơn rất nhiều so với một dự án 11 điểm, và người xem cũng hiếm khi mở hết.

Dự án phụ có thể là đồ án nhóm, miễn ghi rõ phần của bạn, hoặc một công cụ nhỏ bạn viết cho chính mình. Những dự án dưới 5 điểm thì nên để trong GitHub, đừng đưa vào CV. Chúng không có hại, nhưng chiếm chỗ của thứ tốt hơn.

Cũng đừng quên rằng thời gian luôn có hạn. Ba tuần buổi tối cho dự án chính, rồi dừng lại, sửa README, gửi CV đi. Bạn có thể tiếp tục cải thiện dự án trong lúc chờ phản hồi, và mỗi lần cải thiện lại thành một câu chuyện mới để kể.

Có dự án rồi, trình bày ở đâu để người ta bấm vào?

Ba tuần sau, dự án sổ chi tiêu của Minh đã có bản chạy thử, README và 21 test. Nhưng trang GitHub của Minh vẫn lộn xộn: repo nào cũng được ghim, phần giới thiệu trống, và trên LinkedIn thì không ai biết dự án này tồn tại. GitHub cho phép ghim tối đa sáu repo và gist lên trang cá nhân, và chọn sáu thứ đó thế nào lại là một câu chuyện khác.

Bài viết tiếp theo của series sẽ cùng Minh sửa lại GitHub và LinkedIn để hồ sơ khiến người ta muốn bấm vào. Bạn theo dõi cả hành trình ở series Hành trình junior. Còn nếu muốn luyện trước câu "nếu làm lại dự án này, bạn sẽ đổi gì", câu hỏi đó có trong ngân hàng câu hỏi phỏng vấn.