Từ Intern đến Junior Developer, bạn cần chứng minh khả năng hiểu yêu cầu, hoàn tất thay đổi có kiểm tra, trao đổi khi gặp trở ngại và tiếp nhận review. Cấp bậc khác nhau giữa nơi làm việc; đối chiếu mô tả vị trí, trình bày đóng góp cá nhân qua dự án, test, pull request và tài liệu.
Intern và Junior khác nhau ở đâu?
Tên cấp bậc không có định nghĩa thống nhất giữa mọi công ty. Có nơi “intern” là chương trình học ngắn hạn có mentor; nơi khác giao dự án thực tế với trách nhiệm khác nhau. “Junior” cũng khác theo nhóm, sản phẩm, mức hỗ trợ và rủi ro của vị trí. Vì vậy, hãy đọc mô tả tuyển dụng hoặc tiêu chí nội bộ của nơi ứng tuyển thay vì dựa vào một checklist phổ quát.
Dù cấp bậc có khác, người tuyển thường cần hiểu ứng viên có thể đóng góp loại công việc nào và cần hướng dẫn ở đâu. Portfolio và câu chuyện dự án hữu ích khi chúng chỉ ra nhiệm vụ, quyết định, cách xác minh và giới hạn. Chúng không nên phóng đại quy mô sản phẩm hay nhận phần công của cả nhóm.
Ở giai đoạn đầu, có thể cần người hướng dẫn để phân tích codebase, chia nhỏ việc, review và giải thích convention. Dấu hiệu tiến bộ là bạn ngày càng chuẩn bị câu hỏi có ngữ cảnh, thử kiểm tra giả thuyết trước, nêu tác động và tự hoàn tất những bước nhỏ trong phạm vi đã giao. Điều đó không đồng nghĩa phải làm mọi thứ một mình hay không được hỏi.
Ownership ở cấp nhỏ có nghĩa là theo việc tới khi có trạng thái rõ: hiểu yêu cầu, báo rủi ro, thử nghiệm, xin review, sửa feedback và cập nhật tài liệu. Nó không phải tự ý mở rộng phạm vi, sửa mọi module hoặc cam kết deadline thay nhóm. Biết lúc nào cần xin quyết định cũng là một phần của năng lực làm việc đáng tin.
Nhóm năng lực cần thể hiện
Nền tảng lập trình và debug
Bạn cần giải thích code mình viết làm gì, dữ liệu đi qua các bước nào và những giả định quan trọng. Không cần thuộc lòng mọi API. Có thể tra tài liệu, nhưng cần biết đọc thông báo lỗi, thu thập bước tái hiện, đặt giả thuyết và kiểm tra giả thuyết bằng cách nhỏ có kiểm soát.
Chọn một dự án cho phép trình bày luồng hoàn chỉnh: nhận input, validate, xử lý nghiệp vụ, lưu/hiển thị dữ liệu và xử lý lỗi. Người phỏng vấn có thể hỏi một quyết định cụ thể; hãy nêu phương án đã chọn, phương án khác cân nhắc, trade-off và điều bạn muốn thay đổi khi hiểu thêm.
Chất lượng, test và review
Chứng minh bạn kiểm tra hành vi bằng test phù hợp với phạm vi. Nói rõ lệnh chạy và kết quả; nếu chưa test một môi trường nào, nói điều đó. Kỹ năng quan trọng không phải làm mọi dự án có coverage tuyệt đối mà biết rủi ro nào đang kiểm tra, ca biên nào dễ lỗi và giới hạn còn lại là gì.
Code review thể hiện cách bạn cộng tác. Một pull request dễ đọc nêu vấn đề, giải pháp, phần thay đổi, test và điểm cần reviewer chú ý. Khi nhận feedback, hãy xác nhận mình hiểu ý, sửa hoặc giải thích bằng dữ kiện, rồi kiểm tra lại. Chất lượng phản hồi không đo bằng việc đồng ý hết mà bằng khả năng trao đổi về hành vi và rủi ro.
Giao tiếp và học từ phản hồi
Trao đổi tốt làm giảm thời gian đồng đội phải đoán. Khi gặp block, gửi thông báo gồm mục tiêu, việc đã thử, lỗi quan sát được, giả thuyết và câu hỏi cụ thể. Báo sớm khi yêu cầu hoặc estimate thay đổi; đừng chờ tới thời hạn mới nói một phụ thuộc chưa sẵn sàng.
Ghi lại các quyết định có thể ảnh hưởng người sau: cấu hình, API, migration, cách chạy dự án hoặc hướng giải quyết một issue. Tài liệu nhỏ, đúng lúc thường hữu ích hơn một README dài nhưng cũ. Với dự án cá nhân, README giúp reviewer hiểu cách cài, test và demo mà không cần hỏi tác giả.
Phạm vi và trách nhiệm
Một kỹ sư mới cần biết giới hạn quyền của mình. Không commit secret, không thay đổi dữ liệu production hay chia sẻ nội dung riêng tư trong portfolio. Nếu phát hiện vấn đề bảo mật hoặc thay đổi ảnh hưởng người dùng, dừng và hỏi người có trách nhiệm thay vì tự phán đoán rằng mức ảnh hưởng thấp.
Bảng năng lực và bằng chứng
Bảng sau giúp tự đánh giá theo hành vi có thể chỉ ra. Đây là khung phản tư; nó không thay thế tiêu chí của nhà tuyển dụng hay hệ thống cấp bậc tại một tổ chức cụ thể.
| Năng lực | Bằng chứng nên chuẩn bị | Câu hỏi tự kiểm |
|---|---|---|
| Hiểu yêu cầu | Issue, tiêu chí chấp nhận, bước tái hiện lỗi. | Tôi giải thích được ai gặp vấn đề và khi nào việc được xem là xong không? |
| Code có phạm vi | Diff nhỏ, commit có nội dung, cấu trúc có thể đọc. | Tôi tách phần cần thiết khỏi việc dọn code không liên quan không? |
| Kiểm chứng | Unit/integration test phù hợp, lệnh chạy, kết quả quan sát. | Test chứng minh yêu cầu nào và chưa kiểm tra điều gì? |
| Review | Pull request, comment, cách xử lý feedback. | Người khác hiểu thay đổi và rủi ro mà không cần đoán không? |
| Giao tiếp | Update tiến độ, câu hỏi có ngữ cảnh, thông báo block sớm. | Tôi nói rõ trạng thái, người cần phản hồi và bước tiếp theo không? |
| Ownership nhỏ | Tài liệu, xử lý bug tới khi xác nhận, bàn giao trạng thái. | Tôi biết lúc cần tự làm tiếp và lúc cần xin quyết định không? |
Ví dụ từ một nhiệm vụ nhỏ
Giả sử bạn được giao sửa lỗi form đăng ký chấp nhận số điện thoại có chữ cái. Thay vì chỉ đổi một biểu thức kiểm tra, trước tiên hỏi định dạng nào được chấp nhận, quốc gia nào thuộc phạm vi và thông báo lỗi cần thể hiện ra sao. Tái hiện lỗi, tìm nơi validation được thực hiện, kiểm tra cả frontend và backend, rồi xác nhận yêu cầu với người phụ trách nếu rule chưa rõ.
Sau khi hiểu contract, bạn thêm test cho số hợp lệ, ký tự chữ, khoảng trắng, dấu `+`, input rỗng và độ dài biên theo yêu cầu. Không tự đoán định dạng quốc tế nếu sản phẩm chưa quyết định. Diff tập trung vào validation cùng test; mô tả PR ghi trước/sau, ảnh nếu cần, test đã chạy và phần còn chưa xác minh.
Reviewer góp ý rằng API vẫn nhận giá trị không hợp lệ vì chỉ frontend được sửa. Thay vì coi đó là “ngoài việc của em” hoặc sửa luôn kiến trúc rộng, bạn xác nhận ranh giới với owner, bổ sung validation đúng tầng theo quyết định của nhóm và test đường request. Cuối cùng, cập nhật hướng dẫn khi cách nhập thay đổi. Đây là ví dụ cho thấy kỹ năng được thể hiện trong cách làm rõ, triển khai, kiểm tra và cộng tác.
Khi trình bày, nêu rõ bạn làm phần nào, ai review, điều gì được thay đổi sau feedback và test nào thực sự chạy. Nếu đây là bài tập cá nhân, nói rõ đó là bài tập. Người nghe đánh giá được năng lực thật hơn khi giới hạn được trình bày trung thực.
Tạo portfolio trung thực
Portfolio không cần nhiều dự án lặp lại cùng một tutorial. Chọn một hoặc hai sản phẩm nhỏ mà bạn có thể giải thích sâu. Mỗi dự án nên có mục tiêu, cách chạy, công nghệ, cấu trúc, quyết định chính, test, ảnh/demo phù hợp, giới hạn và phần bạn tự làm. Tránh đưa API key, thông tin khách hàng hoặc repo công ty nếu chưa được phép công khai.
GitHub README có thể bao gồm vấn đề giải quyết, prerequisite, các bước setup, lệnh test và cách sử dụng. Nếu có nhiều cộng tác viên, ghi đóng góp theo thực tế thay vì dùng câu “tôi xây toàn bộ” cho phần nhóm. Commit history hoặc pull request có thể hỗ trợ mô tả quá trình, nhưng không thay phần bạn giải thích được tư duy.
Trong buổi trao đổi, kể một tình huống cụ thể: yêu cầu ban đầu, điều chưa rõ, lựa chọn bạn đưa ra, kết quả test, feedback nhận được và điều học được. Chuẩn bị nói về lỗi mình từng gây ra và cách phát hiện/khắc phục. Kỹ năng phản tư thường hữu ích hơn việc nói dự án hoàn hảo.
Lỗi thường gặp
- Chạy theo số lượng: biết nhiều framework nhưng không có dự án giải thích được.
- Chỉ khoe giao diện: không nói cách dữ liệu, validation, test và lỗi được xử lý.
- Nói “đã test” chung chung: không nêu lệnh, môi trường hoặc ca kiểm tra.
- Nhận phần công của nhóm: làm người nghe không phân biệt đóng góp cá nhân.
- Đưa repo không thể chạy: thiếu README, môi trường hoặc dữ liệu mẫu phù hợp.
- Giấu giới hạn: nhận định sản phẩm an toàn/production-ready mà không có căn cứ.
Kế hoạch rèn luyện
- Chọn mô tả một vị trí cụ thể và trích ra các kỹ năng thực sự được yêu cầu.
- Chọn một dự án hiện có; sửa một vấn đề nhỏ với tiêu chí hoàn thành rõ.
- Viết issue và chia thay đổi thành commit/PR dễ xem.
- Bổ sung test theo hành vi và ghi kết quả chạy.
- Xin một người review; sửa hoặc phản hồi comment bằng lý do.
- Cập nhật README và tóm tắt vai trò cá nhân trung thực.
- Tập trình bày dự án trong vài phút và trả lời câu hỏi về trade-off.
Để kiểm tra các thành phần README, test và demo cần có trong hồ sơ, xem bài portfolio kỹ sư phần mềm. Với cách review thay đổi theo pull request, tham khảo hướng dẫn kiểm thử sản phẩm.
Nguồn tham khảo
Yêu cầu Junior Developer khác nhau giữa vị trí và doanh nghiệp. Đối chiếu năng lực với thông tin của đơn vị tuyển dụng và trình bày bằng chứng trung thực.
Câu hỏi thường gặp
Junior Developer khác Intern ở điểm nào?
Không có ranh giới giống nhau ở mọi công ty. Hãy đọc phạm vi nhiệm vụ và cách mentor/review của vị trí cụ thể. Thường nên trình bày khả năng hoàn thành một phần việc nhỏ với ít lần phải làm rõ lại, nhưng vẫn biết xin hỗ trợ khi vấn đề vượt phạm vi.
Cần biết bao nhiêu ngôn ngữ lập trình?
Không có con số chung. Ưu tiên hiểu nền tảng và làm một dự án hoàn chỉnh bằng ngôn ngữ phù hợp với vị trí quan tâm. Nếu mô tả công việc nêu stack cụ thể, hãy giải thích kinh nghiệm thật với stack đó và phần bạn đang học.
Portfolio nên có bao nhiêu dự án?
Ít dự án nhưng giải thích được mục tiêu, vai trò, quyết định và kiểm thử thường hữu ích hơn danh sách dài các bài tập không có ngữ cảnh. Chọn số dự án phù hợp với thời gian review, không cần một con số cố định.
Có thể ứng tuyển khi chưa có kinh nghiệm công ty không?
Điều kiện tùy đơn vị và vị trí. Có thể trình bày dự án học tập, đóng góp mã nguồn mở hoặc sản phẩm cá nhân như bằng chứng kỹ năng, nhưng cần ghi đúng bối cảnh và không mô tả như kinh nghiệm làm việc thương mại.
Làm sao thể hiện khả năng nhận feedback?
Đưa ví dụ về một comment cụ thể, cách bạn làm rõ ý, quyết định sửa hay trao đổi thêm, rồi kiểm tra lại kết quả. Giải thích thay đổi và điều học được thay vì chỉ nói “em luôn tiếp thu”.
Nên tự đo tiến bộ thế nào?
Theo dõi nhiệm vụ có thể làm độc lập hơn, số lần phải sửa do hiểu thiếu yêu cầu, chất lượng test, cách review và khả năng giải thích quyết định. Dùng phản hồi mentor và tiêu chí vị trí cụ thể; đừng tự đánh giá chỉ bằng số dòng code hoặc giờ học.
Bình luận (0
)