12.4K 155 1.0K

Đã đăng vào khoảng 4 giờ trước 19 phút đọc

Từ Giảng Đường Đến Công Ty: Lộ Trình 4 Giai Đoạn Cho Sinh Viên IT

Chuyển từ môi trường đại học (Academic) sang môi trường làm việc thực tế (Industry) tại các công ty công nghệ là một bước ngoặt lớn. Ở trường, bạn được đánh giá bằng điểm số. Ở công ty, bạn được đánh giá bằng giá trị bạn tạo ra cho sản phẩm và cho team.

Bài viết này chia hành trang cần chuẩn bị thành 4 giai đoạn cốt lõi. Bạn có thể dùng khung này để tự luyện tập, hoặc làm sườn nội dung khi chia sẻ lại cho các bạn khác.

Mục lục

Bức tranh tổng quan
Giai đoạn 1: Lấp khoảng trống kỹ thuật & công nghệ thực tế (Hard Skills)
Giai đoạn 2: Nâng tầm kỹ năng mềm & làm việc nhóm (Soft Skills)
Giai đoạn 3: Chiến lược tìm việc & vượt qua phỏng vấn (Job Hunting)
Giai đoạn 4: Sống sót và bứt phá trong 90 ngày đầu tiên (Onboarding)
Checklist tổng hợp

Bức tranh tổng quan

Tiêu chí	Ở đại học	Ở công ty
Mục tiêu	Chạy được, nộp đúng deadline	Chạy đúng, dễ bảo trì, không làm sập hệ thống
Codebase	Vài trăm – vài nghìn dòng, tự viết 100%	Hàng trăm nghìn dòng, do hàng chục người viết trước bạn
Đánh giá	Giảng viên chấm điểm một lần	Code review liên tục, mỗi tuần, bởi đồng nghiệp
Yêu cầu	Đề bài rõ ràng, cố định	Requirement mơ hồ, có thể thay đổi giữa sprint
Cách làm việc	Cá nhân hoặc nhóm 3–4 người	Cross-team: BA, QA, DevOps, PM, Designer
Thành công	Điểm A	Sản phẩm ra được, khách hàng dùng được

Hiểu bảng này rồi thì bốn giai đoạn phía dưới sẽ có ngữ cảnh rõ ràng hơn.

Giai đoạn 1: Lấp khoảng trống kỹ thuật & công nghệ thực tế (Hard Skills)

Ở đại học, chúng ta thường học lý thuyết nền tảng, thuật toán và các project nhỏ lẻ. Khi đi làm, bức tranh hoàn toàn khác.

1.1. Version Control nâng cao

Biết git commit / git push chỉ là mức khởi động. Trong team thật, bạn cần:

Nắm một Git Workflow cụ thể: Git Flow, GitHub Flow hoặc Trunk-based. Biết đâu là nhánh main / develop / feature / hotfix và luật đi kèm từng nhánh.
Pull Request tử tế: tiêu đề rõ ràng, mô tả tại sao thay đổi (không chỉ cái gì), PR nhỏ (khoảng dưới 400 dòng thay đổi) để người khác review nổi.
Xử lý conflict không hoảng: hiểu merge vs rebase, dùng thành thạo git log, git diff, git stash, và đặc biệt là git reflog — cái phao cứu sinh khi làm sai.
Commit message có ý nghĩa: tham khảo Conventional Commits (feat:, fix:, refactor:). Team nào cũng biết ơn người viết commit sạch.

Bài tập tự luyện: tạo hai repo local, tự tạo conflict rồi tự giải. Làm khoảng 5 lần cho đến khi không còn thấy sợ chữ CONFLICT nữa.

1.2. Làm quen với Agile/Scrum

Bạn sẽ không nhận "đề bài" nữa — bạn nhận ticket.

Sprint: chu kỳ 1–2 tuần với cam kết khối lượng công việc cụ thể.
Daily Standup: 10–15 phút, trả lời ba câu — hôm qua làm gì, hôm nay làm gì, đang bị block gì.
Jira / Trello / Azure DevOps: biết cách chuyển trạng thái ticket (To Do → In Progress → In Review → Done), log work, và comment cập nhật tiến độ ngay trên ticket.
Estimation: học cách ước lượng bằng story point. Mẹo cho người mới: ước lượng xong thì nhân 1.5–2 lần cho phần bạn chưa từng làm, vì hầu như ai cũng quên phần viết test, chờ review và sửa comment.

1.3. Tư duy Clean Code & Testing

Viết code không chỉ để "chạy được" mà còn phải dễ đọc, dễ bảo trì — vì người đọc code của bạn nhiều nhất chính là bạn của 6 tháng sau.

Đặt tên tự giải thích: getUserActiveOrders() thay vì getData2().
Hàm nhỏ, một nhiệm vụ: nếu phải dùng chữ "và" để mô tả một hàm, hàm đó nên được tách.
Đừng viết comment để cứu code tệ, hãy sửa code: comment nên giải thích tại sao, không phải cái gì.
Unit Test & Integration Test: đây là khác biệt lớn nhất so với thời sinh viên. Thay vì mở app bấm bằng mắt, hãy tập viết test tự động.
- Bắt đầu với pattern Arrange – Act – Assert.
- Học framework theo ngôn ngữ của bạn: JUnit (Java), pytest (Python), Jest/Vitest (JS/TS), xUnit (.NET), package testing (Go).
- Tập test cả happy path và edge case (null, rỗng, số âm, vượt giới hạn).

1.4. Công cụ & môi trường vận hành

Bạn không cần trở thành DevOps, nhưng phải đủ để không bị "mù" khi hệ thống có sự cố:

Mảng	Mức tối thiểu cần có
Linux / Bash	`cd`, `ls`, `grep`, `tail -f`, `ps`, `kill`, `chmod`, phân quyền file, pipe và redirect
Docker	Hiểu image vs container, viết được `Dockerfile` cơ bản, chạy `docker compose up` cho môi trường local
CI/CD	Đọc hiểu được một pipeline (GitHub Actions / GitLab CI / Jenkins), biết vì sao build fail
Log & Debug	Đọc được stack trace, xem log trên server, phân biệt log level (DEBUG/INFO/WARN/ERROR)
Database	Viết được `JOIN`, `GROUP BY`, hiểu index là gì và vì sao query chậm
API	Test API bằng Postman/curl, đọc được HTTP status code, hiểu request/response header

Cách luyện hiệu quả nhất: làm một side project nhỏ nhưng đi hết vòng đời — code → viết test → đóng Docker → đẩy qua CI/CD → deploy lên VPS/cloud. Một project như vậy giá trị hơn mười project chỉ chạy trên localhost.

Giai đoạn 2: Nâng tầm kỹ năng mềm & làm việc nhóm (Soft Skills)

Code giỏi chỉ chiếm khoảng 50% thành công. 50% còn lại — phần quyết định bạn có thăng tiến hay không — nằm ở giao tiếp và thái độ.

2.1. Nghệ thuật giao tiếp kỹ thuật

Quản lý không thích nghe "em đang làm". Họ cần thông tin để ra quyết định.

❌ Cách báo cáo khiến sếp lo:

"Em đang làm ạ."

✅ Cách báo cáo khiến sếp tin:

"Em đã hoàn thành API đăng nhập và đã viết unit test (X). Hiện em đang vướng ở chỗ refresh token hết hạn sớm hơn dự kiến (Y). Em cần anh cho em 15 phút xem lại config phía auth service, hoặc chỉ em ai đang phụ trách phần đó (Z). Nếu gỡ được hôm nay thì task vẫn kịp deadline thứ Sáu."

Công thức: X đã xong – Y đang vướng – Z cần hỗ trợ – ảnh hưởng tới deadline.

Vài nguyên tắc kèm theo:

Báo tin xấu sớm. Task trễ mà báo trước 3 ngày thì team còn xử lý được; báo vào chiều deadline thì đó là sự cố.
Viết trước khi nói: gõ lại vấn đề thành 3–4 dòng trước khi đi hỏi. Nhiều khi viết xong bạn tự tìm ra câu trả lời.
Nói ngôn ngữ của người nghe: với PM/BA hãy nói về ảnh hưởng đến người dùng và thời gian, đừng nói về NullPointerException.

2.2. Kỹ năng nhận Feedback & Code Review

Code review là nơi nhiều bạn mới bị "sốc" nhất. Hãy nhớ: review là về code, không phải về bạn.

Đừng phòng vệ. Câu trả lời tốt là: "Cảm ơn anh, em chưa nghĩ tới case đó, em sửa lại nhé."
Nếu không đồng ý, hãy tranh luận bằng dữ liệu và ngữ cảnh, đừng bằng cảm xúc: "Em chọn cách này vì đoạn đó đang được gọi trong vòng lặp, làm theo cách kia sẽ bị N+1 query. Anh xem giúp em có hướng nào tốt hơn không?"
Ghi lại feedback lặp lại. Nếu 3 PR liên tiếp bị nhắc về đặt tên biến, đó không phải chuyện nhỏ — đó là điểm cần sửa một cách hệ thống.
Tập tự review trước khi tạo PR: đọc lại diff của chính mình. Bạn sẽ tự bắt được phần lớn lỗi mà reviewer định nhắc.

2.3. Chủ động (Proactiveness)

Đây là phẩm chất được nhắc nhiều nhất trong các buổi đánh giá thử việc.

Đừng ngồi chờ giao việc từng chút một. Xong task thì chủ động hỏi: "Em xong ticket A rồi, em nhận thêm được gì ạ?"
Quy tắc 30–45 phút: khi bế tắc, tự debug trong 30–45 phút. Hết khoảng thời gian đó thì phải hỏi — cày một mình 2 ngày cho vấn đề senior giải trong 5 phút không phải là cố gắng, đó là làm chậm cả team.
Hỏi đúng cách: kèm theo (1) bạn đang làm gì, (2) bạn mong đợi điều gì, (3) thực tế xảy ra gì, (4) bạn đã thử những gì. Cách hỏi này khiến senior sẵn sàng giúp bạn ở những lần sau.
Ghi chú lại mọi thứ bạn được chỉ. Tự xây một file notes.md cá nhân. Đừng hỏi lại cùng một câu hỏi hai lần.
Đọc code của người khác. Mỗi ngày dành 20 phút đọc PR của đồng nghiệp — cách học nghề nhanh nhất mà lại miễn phí.

Giai đoạn 3: Chiến lược tìm việc & vượt qua phỏng vấn (Job Hunting)

Biết việc thôi chưa đủ, phải biết cách "bán" năng lực của bản thân qua CV và buổi phỏng vấn.

3.1. Tối ưu hóa CV cho lập trình viên

Nguyên tắc chung:

Gói gọn trong 1 trang đối với sinh viên mới ra trường. Nhà tuyển dụng thường đọc CV dưới 30 giây.
Nhấn mạnh vào Project thực tế (đồ án tốt nghiệp, đồ án môn lớn, side project, open source) thay vì kể lể các môn đại học đã học.
Bỏ những thứ không tạo ra thông tin: ảnh thẻ mờ, sở thích chung chung, thanh đánh giá kỹ năng dạng 4/5 sao (không ai biết 4 sao nghĩa là gì).
Ghi rõ tech stack ở đầu CV, phân tầng thật thà: Thành thạo / Đã dùng trong project / Đang tìm hiểu.
Kèm link sống: GitHub, bản demo deploy được, blog. Một link demo chạy thật ăn điểm hơn cả một trang mô tả.

Công thức mô tả project (P-T-R-R):

Thành phần	Câu hỏi cần trả lời
Project	Dự án làm gì? Giải quyết vấn đề gì, cho ai?
Tech	Dùng công nghệ, kiến trúc, database gì?
Role	Vai trò của bạn là gì? Bạn tự tay làm phần nào?
Result	Kết quả đạt được — càng có con số định lượng càng tốt

Ví dụ so sánh:

❌ "Làm website bán hàng bằng Java Spring Boot. Có chức năng đăng nhập, giỏ hàng, thanh toán."

✅ E-commerce API — hệ thống bán hàng cho cửa hàng nhỏ (đồ án nhóm 4 người).

Tech: Java Spring Boot, PostgreSQL, Redis, Docker, GitHub Actions.

Vai trò: phụ trách module đặt hàng & thanh toán; tự thiết kế schema và viết hơn 40 unit test (coverage 78%).

Kết quả: tối ưu query danh sách sản phẩm bằng index kết hợp cache Redis, giảm thời gian phản hồi từ 1.2s xuống 180ms; hệ thống chịu được 200 request/giây khi test bằng k6.

Cùng một project, cách viết thứ hai cho thấy bạn hiểu việc mình đã làm.

3.2. Chinh phục phỏng vấn kỹ thuật

a) Cấu trúc dữ liệu & Giải thuật (DSA)

Mục tiêu thực tế cho fresher: nắm chắc mức Easy và làm được phần lớn Medium trên LeetCode.
Ưu tiên theo thứ tự: Array & String → Hash Map → Two Pointers → Stack/Queue → Linked List → Binary Search → Tree (BFS/DFS) → Đệ quy & quy hoạch động cơ bản.
Học cách nghĩ, không học thuộc đáp án. Luôn nói to suy nghĩ của mình khi giải: người phỏng vấn quan tâm quá trình tư duy hơn là kết quả cuối.
Luôn phân tích được độ phức tạp thời gian và bộ nhớ của giải pháp bạn vừa viết.

b) Kiến thức cốt lõi theo hướng bạn theo đuổi

Nhóm	Cần nắm vững
Ngôn ngữ	OOP (bốn tính chất, hiểu thật sự chứ không đọc thuộc), quản lý bộ nhớ, xử lý ngoại lệ, collection/generic
Database	Thiết kế bảng, chuẩn hóa, index, transaction & ACID, `JOIN`, vấn đề N+1 query
Web / API	HTTP method & status code, quy ước RESTful, authentication (JWT/session/OAuth2), CORS
Kiến trúc	MVC, layered architecture, phân biệt monolith vs microservice và khi nào nên dùng cái nào
Ăn điểm thêm	Caching, message queue, kiến thức cơ bản về concurrency

c) Phỏng vấn hành vi (Behavioral Interview)

Đây là phần nhiều bạn kỹ thuật tốt lại mất điểm. Dùng công thức STAR: Situation – Task – Action – Result.

Chuẩn bị sẵn câu trả lời cho:

Kể về một lần bạn mâu thuẫn với thành viên trong nhóm và cách bạn xử lý.
Kể về một lỗi bạn từng gây ra và bạn học được gì. (Đừng nói "em chưa từng sai".)
Vì sao bạn chọn công ty chúng tôi? (Hãy tìm hiểu sản phẩm của họ trước — chỉ cần 15 phút, nhưng rất ít ứng viên làm.)
Kế hoạch 1–2 năm tới của bạn là gì?
Và cuối buổi, hãy có câu hỏi để hỏi lại họ: quy trình review code của team, cách onboarding, ai sẽ là mentor. Không có câu hỏi nào thường bị hiểu là bạn không thật sự quan tâm.

d) Vài lưu ý thực chiến

Xin feedback sau mỗi buổi phỏng vấn, kể cả khi bị từ chối. Đây là nguồn học miễn phí và chính xác nhất.
Bị từ chối 5–10 công ty là bình thường, không phải dấu hiệu bạn không đủ giỏi. Coi mỗi buổi là một lần luyện tập.
Trung thực về những gì bạn không biết. Nói "Phần này em chưa làm qua, nhưng em hiểu nguyên lý là..." ăn điểm hơn nhiều so với đoán bừa.

Giai đoạn 4: Sống sót và bứt phá trong 90 ngày đầu tiên (Onboarding)

Vào được công ty chỉ là khởi đầu. Giai đoạn thử việc mới là thử thách thực sự.

Tuần 1–2: Đừng nản lòng

Codebase sẽ lớn và phức tạp hơn mọi thứ bạn từng thấy. Cảm giác "mình chẳng hiểu gì" là hoàn toàn bình thường — người vào trước bạn cũng từng như vậy.

Mục tiêu của giai đoạn này rất khiêm tốn và rất cụ thể:

[ ] Cài đặt thành công môi trường local và chạy được project lên.
[ ] Đọc tài liệu nội bộ, wiki, README; nắm được hệ thống làm gì và cho ai.
[ ] Vẽ ra giấy luồng chạy của một chức năng chính: request đi từ đâu, qua tầng nào, ghi vào bảng nào.
[ ] Biết ai là ai: mentor, team lead, QA, DevOps, người hiểu rõ nhất module bạn sẽ làm.
[ ] Nắm quy trình của team: nhận ticket ở đâu, tạo branch theo quy ước nào, ai review, deploy thế nào.

Mẹo cực kỳ hiệu quả: trong lúc setup, hãy ghi lại mọi lỗi bạn gặp và cách khắc phục, rồi cập nhật vào tài liệu onboarding của team. Đây là đóng góp giá trị đầu tiên bạn có thể tạo ra ngay trong tuần đầu — và người sau bạn sẽ nhớ điều đó.

Tháng đầu tiên: Chạy trọn một vòng quy trình

Nhận và hoàn thành các task nhỏ: fix bug đơn giản, chỉnh sửa giao diện, thêm field cho một API.
Mục tiêu không phải là task lớn, mà là đi trọn vòng quy trình của công ty: nhận ticket → code → viết test → tạo PR → sửa theo review → merge → deploy → xác nhận trên môi trường thật.
Chấp nhận việc PR đầu tiên bị nhiều comment. Chuyện đó xảy ra với tất cả mọi người.
Bắt đầu tự tin đặt câu hỏi trong standup và trong các buổi họp.

Tháng 2–3: Đi sâu vào nghiệp vụ (Business Domain)

Đây chính là bước tạo ra khác biệt giữa một lập trình viên có giá trị cao và một "thợ gõ code".

Chủ động tìm hiểu nghiệp vụ của sản phẩm: doanh nghiệp kiếm tiền bằng cách nào, ai là người dùng, chỉ số nào quan trọng nhất.
Hiểu tại sao một tính năng được yêu cầu, chứ không chỉ phải code cái gì. Người hiểu nghiệp vụ có thể nói: "Nếu làm theo cách này thì trường hợp khách hủy đơn sau khi đã thanh toán sẽ bị sai số liệu" — đó là lúc bạn được tin tưởng.
Nhận một task vừa sức nhưng trọn vẹn end-to-end, tự chịu trách nhiệm từ đầu đến cuối.
Bắt đầu đóng góp ngược lại: viết tài liệu, bổ sung test, đề xuất refactor một chỗ khó bảo trì.

Bảng mục tiêu 90 ngày

Mốc	Mục tiêu chính	Dấu hiệu bạn đang đi đúng hướng
Tuần 1–2	Setup & hiểu bối cảnh	Chạy được project, mô tả được luồng hệ thống
Tuần 3–4	Merge PR đầu tiên	Đi trọn vòng ticket → deploy
Tháng 2	Làm task độc lập	Ít phải hỏi lại điều đã được chỉ, PR ít comment hơn
Tháng 3	Hiểu nghiệp vụ	Biết đặt câu hỏi về requirement, phát hiện được case còn thiếu

Checklist tổng hợp

Hard Skills

[ ] Thành thạo Git workflow, tự giải được conflict
[ ] Hiểu và tham gia được Sprint/Standup, biết ước lượng task
[ ] Viết được unit test và integration test
[ ] Dùng được Docker, đọc được log & CI pipeline
[ ] Viết được SQL có JOIN, hiểu index

Soft Skills

[ ] Báo cáo theo công thức "đã xong X – vướng Y – cần Z"
[ ] Nhận code review không phòng vệ, ghi lại feedback lặp lại
[ ] Áp dụng quy tắc 30–45 phút trước khi hỏi senior
[ ] Chủ động nhận việc, tự ghi chú kiến thức

Job Hunting

[ ] CV 1 trang, project viết theo P-T-R-R, có link demo/GitHub
[ ] Làm được LeetCode Easy và phần lớn Medium
[ ] Nắm chắc OOP, Database, RESTful API
[ ] Chuẩn bị 4–5 câu trả lời behavioral theo STAR, kèm câu hỏi hỏi lại nhà tuyển dụng

Onboarding

[ ] Tuần 1: setup xong, hiểu luồng hệ thống
[ ] Tháng 1: merge PR đầu tiên, đi trọn quy trình deploy
[ ] Tháng 3: hiểu business domain, làm task end-to-end độc lập

Lời kết

Không ai kỳ vọng một fresher biết hết mọi thứ. Điều các công ty thật sự tìm kiếm là tốc độ học và thái độ làm việc. Kiến thức thiếu thì bù được trong vài tuần; thái độ thụ động thì mất nhiều năm để sửa.

Hãy chọn ra ba gạch đầu dòng trong checklist trên mà bạn yếu nhất, và bắt đầu từ hôm nay. Đó là cách duy nhất khiến bài viết này có ích.

Chúc bạn có một khởi đầu vững vàng trong nghề. 🚀

chia sẻ