Một bài đang nổi trong r/vibecoding có nội dung khá đời thường: tác giả sắp có buổi phỏng vấn lớn, đăng meme và xin mọi người follow GitHub. Nhìn qua thì giống một bài vui, nhưng mình nghĩ nó chạm vào một chuyện rất thật của thời vibe coding: GitHub, demo, follower và dấu vết công khai đang ngày càng bị kéo vào câu chuyện năng lực nghề nghiệp.
Trước đây, portfolio dev thường là vài repo cá nhân, một CV gọn và vài dòng mô tả dự án. Bây giờ, khi AI giúp ai cũng dựng được app nhanh hơn, câu hỏi không còn là “có repo không”, mà là “repo đó chứng minh được điều gì”.
Vì sao GitHub trước phỏng vấn lại trở nên nhạy cảm hơn
Với vibe coding, việc có nhiều project trên GitHub dễ hơn rất nhiều. Một người có thể tạo landing page, bot nhỏ, game mini, dashboard hoặc SaaS prototype trong vài ngày. Điều này tốt, vì rào cản học và thử nghiệm giảm mạnh.
Nhưng mặt trái là nhà tuyển dụng cũng khó đọc tín hiệu hơn:
- Repo có nhiều nhưng không rõ dự án nào chạy thật
- Commit nhiều nhưng phần lớn là generated code
- README đẹp nhưng thiếu hướng dẫn kiểm chứng
- Demo nhìn ổn nhưng không có test, issue hoặc quyết định kỹ thuật
- Chủ repo không giải thích được vì sao chọn kiến trúc đó
Vì vậy, xin follow GitHub có thể giúp tăng độ hiện diện, nhưng bản thân follower không thay thế được bằng chứng năng lực.
Thứ đáng chuẩn bị không phải là “GitHub nhìn đông”
Nếu đang chuẩn bị phỏng vấn, mình sẽ ưu tiên làm GitHub dễ đọc và dễ kiểm chứng hơn là cố làm nó trông đông vui.
Một repo tốt cho phỏng vấn nên trả lời nhanh 5 câu:
- Dự án giải quyết vấn đề gì?
- Chạy local như thế nào?
- Phần nào do mình quyết định thiết kế?
- Phần nào dùng AI hỗ trợ?
- Có test, log, demo hoặc checklist nghiệm thu nào không?
Nếu interviewer mở repo trong 3 phút, họ nên thấy ngay đường vào. Đừng bắt họ đoán file nào quan trọng, app chạy ra sao, hoặc project này là bài học, prototype hay sản phẩm thật.
Cách biến repo vibe coding thành tín hiệu tốt
Mình thấy anh em có thể làm vài việc rất thực dụng.
1. Viết README như tài liệu bàn giao
README không cần dài, nhưng nên có:
- mục tiêu dự án
- ảnh hoặc link demo nếu có
- cách cài và chạy
- kiến trúc ngắn gọn
- các trade-off đã chấp nhận
- phần “What I learned”
Đặc biệt, nếu dùng AI nhiều, cứ nói rõ. Ví dụ: “AI hỗ trợ scaffold UI và viết test case ban đầu; mình tự thiết kế data model, review bảo mật và sửa luồng deploy.” Cách nói này tạo niềm tin hơn là giả vờ mọi dòng code đều viết tay.
2. Có một file quyết định kỹ thuật
Một file DECISIONS.md nhỏ có thể tạo khác biệt lớn. Ghi lại những lựa chọn như:
- vì sao chọn SQLite/Postgres/Firebase
- vì sao tách service theo cách này
- vì sao chưa làm auth hoàn chỉnh
- giới hạn hiện tại của prototype
- nếu có thêm một tuần sẽ sửa gì
Phỏng vấn kỹ thuật thường xoay quanh judgment. File này giúp người xem thấy mình không chỉ prompt cho AI sinh code, mà có suy nghĩ về ràng buộc.
3. Đừng che lỗi, hãy quản lý lỗi
Một repo cá nhân không cần hoàn hảo. Nhưng nếu có issue rõ ràng, TODO có thứ tự ưu tiên, hoặc phần “Known limitations”, nó lại đáng tin hơn.
Ví dụ:
- “Chưa xử lý rate limit API”
- “Test mới cover happy path”
- “Mobile layout còn lỗi ở màn nhỏ”
- “Deploy hiện dùng biến môi trường thủ công”
Những ghi chú này cho thấy mình hiểu rủi ro. Trong thời AI code, nhận diện rủi ro là một phần năng lực rất quan trọng.
4. Chọn 2-3 repo để ghim thật kỹ
GitHub profile có thể có nhiều repo thử nghiệm, nhưng nên ghim ít thôi. Tốt nhất là:
- một repo thể hiện khả năng build sản phẩm end-to-end
- một repo thể hiện khả năng xử lý backend/data/API
- một repo thể hiện khả năng học nhanh hoặc giải quyết vấn đề lạ
Mỗi repo ghim nên có trạng thái rõ: demo, archived, learning project, production-like, hoặc experiment.
Vibe coding không làm portfolio mất giá, nó đổi tiêu chuẩn đọc portfolio
Tin tốt là AI không khiến portfolio vô nghĩa. Ngược lại, nó làm portfolio có thể giàu hơn: nhiều thử nghiệm hơn, nhiều demo hơn, nhiều bằng chứng học nhanh hơn.
Nhưng tiêu chuẩn cũng đổi. Một repo chỉ có code không còn đủ mạnh. Repo tốt cần kể được câu chuyện:
- mình gặp vấn đề gì
- mình dùng AI ở đâu
- mình kiểm chứng output thế nào
- mình hiểu giới hạn nào
- mình sẽ cải thiện gì nếu làm tiếp
Nếu chuẩn bị phỏng vấn, lời khuyên thực dụng của mình là: đừng chỉ xin follow. Hãy biến GitHub thành nơi người khác thấy được cách mình suy nghĩ. Follower có thể tạo chú ý ban đầu, nhưng chính README, quyết định kỹ thuật, test và khả năng giải thích mới là thứ giúp anh em đi qua vòng phỏng vấn.
Top comments (0)