Wavi Books · Lộ trình học lập trình & nghề IT

Portfolio Developer nên có gì? Cách trình bày dự án để xin việc IT

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Cách làm portfolio developer: chọn dự án, viết README, mô tả kiến trúc, triển khai demo và chứng minh kỹ năng khi xin việc IT.

## Portfolio Developer nên có gì

Portfolio developer là tập hợp bằng chứng cho thấy bạn có thể phân tích vấn đề, xây giải pháp và hoàn thiện sản phẩm. Một dự án sâu, có tài liệu và vận hành được thường giá trị hơn nhiều demo giống tutorial.

Nhà tuyển dụng cần hiểu bạn đã làm gì, quyết định kỹ thuật nào quan trọng và kết quả ra sao. Vì vậy portfolio phải kể được câu chuyện từ bài toán đến kiến trúc, code, test và triển khai.

## Những khái niệm cốt lõi cần nắm

- README nêu vấn đề, tính năng và cách chạy.

- Sơ đồ kiến trúc giải thích thành phần.

- Test và CI chứng minh chất lượng.

- Demo hoặc ảnh chụp giúp kiểm tra kết quả.

## Lộ trình thực hành từng bước

- Bước 1: Chọn dự án gần vị trí muốn ứng tuyển.

- Bước 2: Hoàn thiện một luồng end-to-end và triển khai.

- Bước 3: Viết case study ngắn về quyết định và bài học.

## Những sai lầm thường gặp

- Sao chép dự án khóa học không tùy biến.

- Đăng khóa bí mật hoặc dữ liệu nhạy cảm.

- Liệt kê công nghệ mà không giải thích vai trò.

## Góc nhìn dành cho người học và developer Việt Nam

Ứng viên tại Việt Nam nên viết README song ngữ nếu nhắm công ty quốc tế và ưu tiên dự án giải quyết bối cảnh quen thuộc như bán hàng, giáo dục, logistics hoặc dữ liệu tiếng Việt.

## Nên học tiếp như thế nào?

Sau khi nắm phần cốt lõi, bạn nên tự xây một dự án nhỏ, ghi lại giả định, tiêu chí đánh giá và giới hạn của giải pháp. Các sách liên quan được Wavi Books gợi ý trong bài giúp bạn đào sâu kiến thức theo lộ trình có hệ thống thay vì chỉ ghép các hướng dẫn rời rạc.

## Portfolio là bằng chứng, không phải phòng trưng bày công nghệ

Một portfolio mạnh trả lời bốn câu hỏi: bạn giải quyết vấn đề gì, quyết định kỹ thuật nào do bạn đưa ra, chất lượng được kiểm chứng thế nào và sản phẩm vận hành ra sao. Screenshot đẹp có ích, nhưng code, test, tài liệu và trade-off mới chứng minh năng lực developer.

Nhà tuyển dụng thường chỉ có vài phút cho lượt xem đầu. Trang đầu README cần nêu vấn đề, đối tượng, tính năng chính, demo, kiến trúc và cách chạy. Sau đó mới đi sâu vào database, API, test và bài học.

## Chọn dự án theo vị trí mục tiêu

Backend nên thể hiện API, transaction, database, cache, job nền, bảo mật và observability. Data Engineer cần ingestion, transformation, data quality, orchestration và lineage. AI Engineer cần dataset, baseline, evaluation, serving và monitoring. Frontend cần accessibility, state, performance, test và responsive.

Một dự án gần nghiệp vụ thật tốt hơn clone mạng xã hội chung chung. Ví dụ quản lý đơn sách có tồn kho, voucher, thanh toán, trạng thái vận chuyển và dashboard; dữ liệu đủ phức tạp để nói về transaction, idempotency và analytics.

## Cấu trúc case study nên có

### 1. Bối cảnh và ràng buộc

Nêu người dùng, vấn đề, quy mô giả định và tiêu chí thành công. Ví dụ 10.000 sản phẩm, 500 request/phút, đơn không được tạo trùng và p95 dưới 400 ms. Con số có thể là giả định nhưng phải ghi rõ.

### 2. Kiến trúc và quyết định

Vẽ sơ đồ nhỏ, mô tả luồng dữ liệu và vì sao chọn monolith/module, SQL/NoSQL, cache hay queue. Ghi cả phương án đã cân nhắc và lý do không chọn. Trade-off thể hiện trình độ tốt hơn câu “dùng công nghệ X vì phổ biến”.

```text Browser -> Web/API -> PostgreSQL | \-> Redis Cache \----> Queue -> Worker -> Email \----> Logs / Metrics / Traces ```

### 3. Chất lượng và vận hành

Liệt kê test quan trọng, CI pipeline, migration, secret management, logging, metric và cách deploy. Cung cấp tài khoản demo an toàn hoặc dữ liệu seed. Nếu demo có thể ngừng do giới hạn miễn phí, ghi rõ video và ảnh dự phòng.

### 4. Kết quả và bài học

Đưa benchmark, coverage có ý nghĩa, số scenario test hoặc cải thiện latency. Không bịa người dùng hay doanh thu. Với dự án cá nhân, kết quả kỹ thuật trung thực vẫn có giá trị: xử lý được race condition, giảm query từ 120 xuống 8, hoặc phục hồi sau lỗi worker.

## README mẫu có thể áp dụng

- Problem và target user.

- Live demo, video ngắn và ảnh.

- Feature quan trọng và phạm vi không làm.

- Architecture diagram và data model.

- API documentation hoặc user flow.

- Cách chạy local bằng một vài lệnh rõ ràng.

- Test, CI/CD, observability và security.

- Trade-off, limitation và roadmap.

## Những chi tiết khiến portfolio mất điểm

Secret nằm trong repository, commit message hỗn loạn, README không chạy được, demo lỗi, phụ thuộc package cũ có lỗ hổng, không có license, sao chép tutorial và không giải thích phần bản thân làm. Hãy dùng tài khoản khác hoặc chế độ ẩn danh để thử toàn bộ hướng dẫn như một người lạ.

## Chuẩn bị kể dự án trong phỏng vấn

Dùng cấu trúc: bối cảnh → thách thức → quyết định → kết quả → bài học. Chuẩn bị câu hỏi về lỗi lớn nhất, bottleneck, bảo mật, cách scale gấp 10, thay đổi nếu làm lại và phần đóng góp cá nhân. Nếu bạn tự xây dự án, đừng nói “chúng em” mơ hồ.

## Kế hoạch hoàn thiện trong 14 ngày

Ngày 1–2 chốt scope và schema; ngày 3–7 hoàn thiện luồng chính cùng test; ngày 8–9 thêm auth, logging và error handling; ngày 10 deploy; ngày 11 load test; ngày 12 viết README và sơ đồ; ngày 13 quay demo; ngày 14 nhờ một developer khác chạy thử. Sau đó cải thiện dựa trên phản hồi thay vì mở dự án mới.