Nên chọn hướng đi nghề nghiệp nào cho programmer?

GuideKhoảng 6765 từKhoảng 23 phút

Lời khuyên: Khi chọn hướng nghề nghiệp, nhiều bạn thích hỏi nhất là “Hướng nào có tương lai hơn?”. Câu hỏi này rất khó trả lời ngay. Backend, frontend, full-stack, phát triển ứng dụng AI, database kernel, algorithm, middleware, test development, platform engineering, architect, tên gọi đều khá quen thuộc nhưng công việc hằng ngày khác nhau rất nhiều. Thay vì tranh luận trước xem hướng nào “tốt hơn”, hãy xem trước bạn có muốn xử lý lâu dài loại vấn đề đó không, sau đó xem số lượng vị trí trong nước có nhiều không, ngưỡng gia nhập có cao không và sau này có thể chuyển đổi được không.

Khi mới vào nghề, mọi người rất dễ bị tên vị trí dẫn dắt: backend, frontend, full-stack, algorithm, test development, vận hành, architect. Tên gọi đương nhiên hữu ích, vì nộp CV và tìm việc đều dựa vào nó. Nhưng sau khi thực sự đi làm, trải nghiệm có tốt hay không phần lớn phụ thuộc vào việc hằng ngày bạn phải làm việc với điều gì: yêu cầu nghiệp vụ, tương tác trên trang, sự cố production, chỉ số dữ liệu, source code tầng dưới, platform tự động hóa hay một loạt ràng buộc liên team.

Ví dụ, backend và frontend gần nghiệp vụ, yêu cầu thay đổi nhanh, phản hồi cũng nhanh. Phát triển ứng dụng AI trông có vẻ mới mẻ, nhưng khi triển khai trong công ty, phần lớn thời gian vẫn là tích hợp năng lực của model vào hệ thống nghiệp vụ. Các vị trí tầng dưới có chu kỳ dài, ngưỡng gia nhập cao, trong ngắn hạn chưa chắc có cảm giác thành tựu. Test development và platform engineering nghe có vẻ không phải “viết nghiệp vụ”, nhưng phần lớn thời gian lại dành cho việc viết automation, công cụ platform và chuỗi chất lượng/release.

Architect nghe có vẻ cấp cao, nhưng thực chất giống kết quả được tích lũy từ kinh nghiệm và trách nhiệm hơn, không phù hợp để người mới theo đuổi danh xưng này ngay từ đầu.

Vì vậy, bài viết này không xếp hạng và cũng không khuyên bạn nhất định phải chọn hướng nào. Bài viết chỉ nói sơ lược công việc thực tế là gì, phù hợp với ai và dễ mắc những lỗi nào.

Đừng chỉ nhìn tên vị trí

Nếu bạn chưa vào nghề, tôi sẽ xem số lượng vị trí trước.

Điều này nghe có vẻ thực dụng nhưng rất thực tế. Các vị trí như backend, frontend, test development có nhiều cửa vào hơn, CV gửi đi ít nhất cũng có nơi tiếp nhận. Các hướng như database kernel, middleware, hệ thống tầng dưới, algorithm platform phụ thuộc nhiều hơn vào nghiệp vụ và quy mô team của công ty, số lượng vị trí sẽ không nhiều như phát triển nghiệp vụ. Có thể chọn, nhưng trước hết phải chấp nhận việc vị trí ít và phản hồi chậm.

Cơ hội phát triển ứng dụng AI tăng lên trong hai năm gần đây, nhưng tôi không khuyến nghị các bạn chưa có nền tảng bắt đầu bằng việc coi đây là mục tiêu duy nhất. Khi tuyển phát triển ứng dụng AI, nhiều công ty sẽ xem trước bạn có nền tảng engineering về backend, full-stack, platform hoặc test development hay không. Model API chỉ là một mắt xích, còn permission, log, cost, evaluation và stability cuối cùng đều phải có người chịu trách nhiệm.

Cũng cần nhìn rõ ngưỡng gia nhập. Các hướng như database kernel, compiler, storage, distributed middleware thực sự có thể rèn luyện năng lực tầng dưới rất tốt, nhưng thời gian học cũng dài. Hướng gần nghiệp vụ dễ tìm được cửa vào hơn; nếu muốn tạo khác biệt, hiểu nghiệp vụ, chất lượng engineering và năng lực xử lý vấn đề production sẽ hữu ích hơn.

Không gian chuyển đổi cũng rất quan trọng. Với các hướng như middleware, infrastructure, platform engineering và architecture design, sau khi đào sâu thì việc hiểu hệ thống nghiệp vụ thường không khó. Hướng thuần nghiệp vụ cũng không phải không có giá trị, chỉ là bạn phải chủ động tích lũy, chẳng hạn như domain modeling, performance optimization, stability governance và thúc đẩy dự án phức tạp. Nếu không, sau vài năm chỉ viết nghiệp vụ, CV sẽ chỉ còn một loạt tên dự án.

Cuối cùng, hãy tự hỏi mình một câu cụ thể hơn: Bạn có thể chấp nhận công việc hằng ngày của hướng này không?

Nhiều người thích danh xưng algorithm engineer nhưng không thích làm sạch dữ liệu, điều chỉnh feature và xem chỉ số production. Thích cách gọi architect nhưng không muốn nhiều lần thống nhất ràng buộc với nghiệp vụ, test, vận hành và product. Thích sự tự do của full-stack nhưng lại khó chịu ngay khi gặp state ở frontend, permission, error state và vấn đề deploy. Đừng xem hướng đi như một nhãn trên CV, nó là tập hợp công việc thực tế mỗi ngày.

Backend development

Backend development là một trong những hướng có nhiều vị trí nhất, nhiều tài liệu học nhất và cũng cạnh tranh gay gắt nhất trong nước. Nhiều bạn bắt đầu với Java rồi cuối cùng sẽ đi vào con đường này.

“Backend có phải chỉ là CRUD không?” Tôi đã nghe câu này rất nhiều lần. Khi mới bắt đầu, backend đúng là thường bắt đầu từ các chức năng CRUD, login authentication, truy vấn phân trang và upload file. Nhưng sau vài năm làm việc, khoảng cách sẽ dần mở ra: có người chỉ biết gọi API của framework, có người có thể kết nối business rules, data model, cache, message queue, transaction, permission, monitoring, release và troubleshooting.

Các vị trí Java backend trong nước vẫn còn rất nhiều, đặc biệt có thể thấy trong enterprise service, fintech, e-commerce, local life, industrial internet và dự án government-enterprise. Nhưng nhiều vị trí không có nghĩa là dễ. CV backend junior rất dễ trùng lặp: Spring Boot, MySQL, Redis, hệ thống quản lý dự án, e-commerce, flash sale giống nhau, interviewer nhìn qua gần như không thấy khác biệt.

Muốn tạo khác biệt trong backend, trọng tâm không chỉ là học thuộc thêm vài tên framework mà là có thể giải thích rõ những vấn đề sau:

Từ lúc request đi vào đến khi trả về kết quả, một API đi qua những layer nào?
Vì sao thiết kế table như vậy, vì sao xây index như vậy?
Cache penetration, cache breakdown và cache avalanche xử lý lần lượt thế nào, cái giá phải trả là gì?
Sau khi async message thất bại thì bù trừ thế nào, xử lý duplicate consumption ra sao?
Khi API production chậm đi, làm thế nào lần lượt điều tra từ log, trace, SQL đến thread pool?

Nếu bạn chưa vào nghề, backend vẫn là một cửa vào rất thực tế. Hãy xây chắc Java Basics, database, Spring, Redis, message queue và thực hành dự án trước, sau đó cân nhắc mở rộng sang phát triển ứng dụng AI, middleware, platform engineering hoặc architecture, sẽ vững vàng hơn nhiều. Đừng vội gắn nhãn “architect” hay “AI” cho bản thân ngay từ đầu; nếu nền tảng chưa tốt, sau này đổi sang hướng nào cũng khó.

Frontend development

Frontend development thường bị hiểu nhầm là “cắt trang”. Nhiều bạn backend lần đầu tiếp xúc với frontend nhìn thấy form, table, button và style nên dễ đánh giá thấp nó.

Các công việc frontend thường gặp trong công ty trong nước gồm hệ thống quản trị backend, H5 phía người dùng, mini program, website chính thức, trang hoạt động vận hành, data dashboard, low-code/platform dựng trang, component library và visual editor. Nghiệp vụ càng phức tạp, frontend càng phải xử lý state, permission, error state, performance, compatibility và ranh giới phối hợp.

Công cụ lập trình AI thực sự đã hạ thấp ngưỡng viết trang. Hiện nay, để AI tạo bản đầu tiên của một trang table, form hay detail page không khó. Vấn đề là chạy được không đồng nghĩa với có thể bảo trì lâu dài.

Những phiền phức của frontend trong dự án thực tế thường ẩn ở các chỗ sau: điều kiện truy vấn, phân trang, popup và giá trị tạm của form rốt cuộc nên đặt ở đâu; có nên tách component không, tách đến mức nào; khi API thất bại, dữ liệu rỗng, không có quyền hoặc đang loading thì hiển thị thế nào; khi field giữa frontend và backend không nhất quán thì thu gọn type definition ra sao. Khi trang ngày càng chậm, còn phải kiểm tra rendering, bundle size và request trace.

Frontend phù hợp với người nhạy cảm với trải nghiệm tương tác, cấu trúc trang và chi tiết. Phản hồi của nó rất nhanh, sửa xong có thể thấy hiệu quả ngay; áp lực cũng nằm ở đây, thay đổi yêu cầu, kiểm tra giao diện, vấn đề compatibility và trang hoạt động làm gấp đều có thể rất vụn vặt. Có người rất thích kiểu phản hồi này, có người thấy mình bị bào mòn bởi chi tiết; tốt nhất nên đánh giá sớm.

Nếu bạn chưa có nền tảng, có thể chọn một trong Vue hoặc React, không nên học cả hai cùng lúc. Trước tiên hãy làm một trang quản trị thực tế, bao gồm list, query, pagination, create, edit, delete, permission và error state. Có thể giải thích rõ trang này sẽ hữu ích hơn việc chỉ học tutorial syntax.

Full-stack development

Full-stack development là hướng dễ bị hiểu nhầm nhất. Nó không phải là dán thêm một nhãn lên CV, cũng không có nghĩa là “backend biết một chút frontend, frontend biết một chút backend”.

Với phần lớn developer, nơi full-stack phát huy tác dụng nhất là có thể độc lập bàn giao một chức năng hoàn chỉnh: hiểu yêu cầu, cấu trúc trang, thiết kế API, data modeling, kiểm soát permission, integration test, deploy production và troubleshooting đều có thể kết nối thành một chuỗi. Với developer backend, full-stack không nhất thiết yêu cầu bạn đạt độ sâu của frontend chuyên nghiệp trong thời gian ngắn, nhưng ít nhất phải đọc hiểu trang, sửa được component và giải thích rõ data flow.

Trong các team nhỏ, team startup, công cụ nội bộ, hệ thống quản trị và prototype ứng dụng AI trong nước, năng lực full-stack rất thực dụng. Khi sếp hoặc phía nghiệp vụ cần một chức năng, bạn không cần chờ lịch của frontend và backend hoàn toàn khớp nhau mà có thể tự chạy được bản đầu tiên. Điều này cũng đúng với dự án cá nhân, open source và phát triển độc lập; năng lực full-stack sẽ ảnh hưởng trực tiếp đến tốc độ bàn giao.

Tuy nhiên, full-stack cũng rất dễ học thành “biết một chút về mọi thứ”. Nếu chưa có main stack, tốt nhất hãy chọn một hướng để đứng vững trước: developer backend bổ sung frontend, developer frontend bổ sung backend. Main stack phụ trách chiều sâu, phía còn lại phụ trách hoàn thiện chuỗi bàn giao. Full-stack học theo cách này mới không bị nông ở cả hai phía.

AI có thể giúp bạn tạo page, API, SQL và script deploy, nhưng cuối cùng bạn vẫn phải chịu trách nhiệm về kết quả. Field đã khớp chưa, permission có bị sót không, error có được xử lý dự phòng không, sau khi deploy thì điều tra vấn đề thế nào, tất cả đều không thể giao cho tool tự đoán.

Phát triển ứng dụng AI

Phát triển ứng dụng AI đang rất được quan tâm trong hai năm gần đây, nhưng phần lớn công ty tuyển không phải “người biết làm demo chatbot”. Demo dễ viết, còn có thể deploy, chạy ổn định và điều tra được khi xảy ra vấn đề mới là điểm khó trong công việc.

Trong bối cảnh trong nước, phát triển ứng dụng AI chủ yếu là kết hợp năng lực của LLM với hệ thống nghiệp vụ. Bạn có thể phải tích hợp LLM API, làm hội thoại streaming, thiết kế Prompt, xây RAG knowledge base, cũng có thể phải làm Agent tool calling, structured output, evaluation set, permission, audit, log, cost tracking và bảo đảm stability.

Với developer backend, hướng này khá thân thiện: kinh nghiệm engineering trước đây vẫn dùng được. Database, cache, queue, rate limiting, authentication, async task, distributed tracing và canary release đều không biến mất trong ứng dụng AI. Chỉ là trước đây bạn tích hợp API HTTP/RPC có tính xác định, còn bây giờ có thêm một model API chậm hơn, đắt hơn và kém ổn định hơn.

Các vấn đề của phát triển ứng dụng AI cũng khá tập trung. Chỉ biết gọi model API nhưng không biết xử lý timeout, retry, fallback và cost control thì sẽ nhanh chóng mắc kẹt trong vấn đề production. Chỉ biết viết Prompt nhưng không biết đánh giá chất lượng kết quả cũng như quản lý version thì mỗi lần sửa prompt có thể làm hỏng câu hỏi trước đây vốn trả lời được. Nếu RAG chỉ dừng ở demo vector retrieval mà không xử lý chunking, recall, reranking, permission và update thì hiệu quả trong knowledge base thực tế sẽ rất thất thường. Agent cũng vậy, demo chạy được không có gì lạ, khó là state tracking, failure recovery, security boundary và human confirmation.

Nếu muốn chuyển từ backend Java/Go sang phát triển ứng dụng AI, không nên ngay từ đầu nhồi cả machine learning, deep learning và model training vào. Thứ tự ổn định hơn là: trước tiên bổ sung LLM API, Token, context window và structured output, sau đó làm RAG và Agent, cuối cùng bổ sung evaluation, log, cost, permission và stability sau khi deploy.

Phát triển database kernel

Phát triển database kernel thuộc nhóm phát triển tầng dưới, ngưỡng gia nhập cao và phản hồi trong ngắn hạn cũng chậm.

Công việc hằng ngày của hướng này là đối diện với quá trình thực thi phía sau SQL: storage engine tổ chức dữ liệu thế nào, index truy vấn ra sao, concurrency của transaction được kiểm soát thế nào, log và recovery bảo đảm dữ liệu không mất ra sao, query optimizer chọn execution plan thế nào. Khi bạn viết một câu SQL trong phát triển nghiệp vụ, developer database kernel phải quan tâm đến việc câu SQL đó thực sự chạy như thế nào ở phía sau.

Trong nước không có nhiều team làm database kernel lâu dài như phát triển nghiệp vụ, số lượng vị trí đương nhiên cũng ít hơn. Người phù hợp với hướng này thường có thể chấp nhận đọc paper, đọc source code, điều chỉnh performance, xử lý vấn đề rất khó tái hiện và chấp nhận một chức năng phải sửa rất lâu mới được deploy.

Lợi ích của hướng này thường đến về sau. Khi đã hiểu rõ database kernel, storage system và distributed consistency, việc tiếp tục hiểu business system, middleware hoặc architecture design thường sẽ không quá khó.

Nếu muốn thử hướng này, có thể bắt đầu từ ba việc:

Học một khóa học về system, chẳng hạn CMU 15-445/645, trước tiên nắm được các mạch chính về storage, index, transaction, recovery và query optimization.
Chọn một open source database hoặc database component để đọc source code, đừng đọc toàn bộ ngay từ đầu; hãy theo dõi một lần query, một lần write hoặc một lần transaction commit.
Làm một dự án database nhỏ; dù chỉ triển khai buffer pool, B+ tree hoặc executor đơn giản cũng hữu ích hơn chỉ đọc bài viết.

Algorithm engineer

Algorithm engineer gần như không thể chỉ làm algorithm. Chỉ cần model được đưa vào product, bạn sẽ gặp data, engineering, nghiệp vụ, evaluation, deploy và monitoring.

Khi đưa algorithm vào thực tế, các năng lực engineering như MLOps là không thể tránh. Model chỉ là một phần của system, train xong mới chỉ là bắt đầu; phía sau còn có deploy, monitoring, rollback, suy giảm hiệu quả, data drift và vấn đề cost.

Công việc của nhiều vị trí algorithm sẽ rơi vào những việc sau: hiểu mục tiêu nghiệp vụ, lấy dữ liệu có thể sử dụng, xử lý feature và sample, train và evaluation model, tích hợp model vào online service, theo dõi metric và xử lý suy giảm hiệu quả.

Các vị trí liên quan đến generative AI cũng tương tự, ngoài bản thân model còn phải làm RAG, evaluation, Agent engineering, prompt, data governance, kiểm soát cost và latency.

Algorithm contest có hữu ích không? Có, nhưng đừng phóng đại.

Contest có thể rèn luyện năng lực trừu tượng, data structure và ý thức về complexity, hữu ích với một số vị trí liên quan nhiều đến algorithm. Tuy nhiên, phần lớn software engineer không cần coi algorithm contest là điều kiện cần cho phát triển nghề nghiệp. Công việc algorithm trong nghiệp vụ thực tế hiếm khi chỉ kiểm tra bạn có giải được một bài toán hay không, mà thường hỏi: bạn có thể phân rã một vấn đề không ổn định thành các experiment có thể kiểm chứng, cuối cùng giúp nó tạo ra lợi ích ổn định trong production hay không.

Nếu muốn đi theo hướng algorithm, hãy sớm xác nhận mình có thể chấp nhận hai việc:

Có sẵn sàng bổ sung năng lực engineering, chẳng hạn Python/Java/C++, data pipeline, model service, online evaluation và monitoring alert hay không.
Có sẵn sàng hiểu business metric hay không. Dù algorithm hiệu quả đến đâu, nếu không thể giải thích ảnh hưởng của nó với nghiệp vụ là gì thì rất khó đứng vững lâu dài trong team.

Phát triển middleware

Có thể tạm hiểu middleware là “một tầng phần mềm làm nền cho business system”. Các middleware thường gặp gồm message queue, RPC framework, configuration center, service registry, task scheduling, gateway, component sharding database, data synchronization tool và cache proxy.

Phát triển nghiệp vụ thường làm “người dùng cần chức năng gì”, còn phát triển middleware thường làm “làm thế nào để nhiều business system có thể phát triển và vận hành ổn định hơn, hiệu quả hơn và ít tốn kém hơn”. Đối tượng phục vụ thường là các business team nội bộ công ty, cũng có thể là developer bên ngoài, chẳng hạn người dùng open source project hoặc cloud product.

Vị trí phát triển middleware thường thuộc team infrastructure. Công việc hằng ngày không nhất thiết là viết một MQ hoặc RPC framework từ đầu, mà thường là duy trì system hiện có, xử lý sự cố production, performance bottleneck và vấn đề compatibility; sau khi lưu lượng tăng lên thì tiếp tục cải tiến throughput, latency, multi-datacenter và multi-tenant. Làm tốt hay không cũng không chỉ phụ thuộc vào implementation tầng dưới; API, SDK, console và tool vận hành có dễ dùng hay không sẽ được business team phản hồi trực tiếp.

Phát triển middleware và phát triển nghiệp vụ không có bên nào cao hơn, chỉ là giải quyết các vấn đề khác nhau. Người làm middleware tốt thường nhạy bén với distributed system, network, concurrency, serialization, protocol, observability và performance optimization. Developer nghiệp vụ chuyển sang middleware cũng không phải không thể, nhưng nếu chỉ biết gọi API của MQ, RPC và Redis mà chưa từng nghiên cứu thread model, storage model, failure recovery và trade-off về consistency của chúng thì sẽ khá bất lợi khi phỏng vấn.

Muốn làm phát triển middleware, có thể bắt đầu đào sâu từ một middleware. Ví dụ khi học message queue, đừng chỉ dừng ở các câu trả lời kiểu “giảm đỉnh, lấp đáy, tách rời bất đồng bộ”, mà hãy tiếp tục tìm hiểu: message được lưu thế nào, consumer offset được duy trì ra sao, xử lý duplicate consumption thế nào, ordered message phải trả giá gì và sau khi Broker bị lỗi thì khôi phục ra sao.

Test development

Test development không phải là hướng “không có hàm lượng kỹ thuật”.

Trong tuyển dụng trong nước, vị trí test development thường xuất hiện nhiều hơn ở các công ty lớn, công ty Internet vừa và lớn, công ty fintech, cloud vendor và các team có quy trình R&D tương đối chuẩn hóa. Công ty nhỏ đương nhiên cũng cần bảo đảm chất lượng, nhưng nhiều khi không duy trì riêng một team test development hoàn chỉnh mà để developer, tester và vận hành cùng chia sẻ việc automation và chất lượng release. Đây cũng là lý do công việc của các vị trí cùng gọi là “test” có thể khác nhau rất nhiều giữa các công ty.

Test development trong bối cảnh trong nước thường thiên về development hơn manual test truyền thống. Tên vị trí có thể là test development, quality efficiency, test platform hoặc QA Infra, nhưng công việc nhìn chung tương tự: viết automation test framework, làm API test, performance test, stability test, test data platform, tích hợp CI/CD, duy trì test environment và quality dashboard.

Tech stack thường gặp của test development gồm Python/Java, Linux, Docker, Jenkins, GitLab CI, API automation, UI automation, performance stress test, log analysis và monitoring alert. Nếu đào sâu hơn, còn có thể gặp chaos engineering, traffic replay, precise testing, quality platform và R&D efficiency platform. Hướng này không phải không viết code, mà code được viết thiên về quality, efficiency và stability hơn.

Nếu chuẩn bị ứng tuyển test development, đừng chỉ sửa tên vị trí trên CV backend rồi nộp. Phỏng vấn test development rất dễ hỏi:

Bạn thiết kế test case thế nào?
Đưa automation test vào CI thế nào?
Khi test environment không ổn định thì định vị vấn đề ra sao?
Kiểm thử các tình huống như idempotency của API, async message và distributed transaction thế nào?
Sau khi vấn đề production được phát hiện, quy trình quality nên thay đổi ra sao?

Nếu sau này còn muốn chuyển sang development, cũng cần thiết kế dự án từ sớm. Hãy cố gắng để dự án test development của mình có nội dung development thực tế, chẳng hạn test platform, data generation tool, stress test platform, API recording/replay tool, thay vì chỉ viết “phụ trách thực thi automation test”. Đưa mô tả kiểu này lên CV, interviewer rất khó đánh giá năng lực development của bạn.

Vận hành, DevOps và platform engineering

Các vị trí vận hành truyền thống thực sự đang thay đổi. Sau khi số lượng server tăng, cloud native phổ biến và tần suất release cao hơn, cách đăng nhập máy thủ công, sửa config thủ công và điều tra vấn đề thủ công ngày càng khó đáp ứng nhịp độ R&D. Công ty càng lớn, điều này càng rõ ràng.

Hiện nay, tên vị trí thường gặp hơn là DevOps, SRE và platform engineering.

DevOps nhấn mạnh sự phối hợp giữa development và vận hành, tự động hóa các khâu compile, test, release, monitoring và rollback. SRE tập trung hơn vào service reliability, dùng phương pháp engineering để quản lý availability, latency, capacity và failure response. Platform engineering thiên về xây dựng platform nội bộ, các công việc thường gặp gồm resource request, release system, monitoring alert, permission, log, config, security scanning và self-service tool.

Không thể chỉ hiểu platform engineering là vận hành truyền thống đổi tên.

Platform engineering làm tốt thì business team không cần gửi ticket mỗi lần request resource, cũng không cần mỗi project tự nghiên cứu lại release, monitoring, permission, log, config và security scanning. Platform team biến các năng lực thường dùng thành self-service, template, CLI, API hoặc portal, để business team tập trung vào business logic.

Platform nội bộ không phải cứ triển khai là tự động tốt lên. Xét trong các team trong nước, platform engineering không thể biến thành “showroom công nghệ mới”. Business team có thể bớt gửi ticket, bớt lục tài liệu, release và troubleshooting ổn định hơn thì mới có ích; nếu platform ngày càng nặng nề, ngược lại sẽ làm chậm nhịp độ thay đổi.

Người thích infrastructure và automation có thể chú ý đến hướng này. Bạn cần nắm vững Linux, network, container, Kubernetes, CI/CD, observability và security cơ bản, đồng thời phải sẵn sàng làm platform như một product, lắng nghe phản hồi của business team và giảm gánh nặng nhận thức cho họ. Người chỉ muốn tránh xa yêu cầu nghiệp vụ chưa chắc phù hợp với platform engineering, vì bản thân platform cũng có “user”.

Architect

Cách gọi “architect” rất dễ khiến người ta hiểu nhầm. Nó không phải một chứng chỉ, cũng không phải danh xưng tách rời khỏi việc viết code.

Nói về công việc hằng ngày, software architecture là một tập hợp quyết định thiết kế ảnh hưởng đến cấu trúc, hành vi và các thuộc tính chất lượng của system. Architect không phải trả lời “có dùng công nghệ mới nào đó không”, mà là các câu hỏi sau:

System cần được tách thành những module nào, vì sao tách như vậy?
Cân bằng giữa data consistency, performance, availability và security thế nào?
Khi yêu cầu thay đổi, nơi nào nên dễ sửa, nơi nào không đáng thiết kế trước?
System này được test, deploy, observe và rollback thế nào?
Các role khác nhau trong team phối hợp xoay quanh thiết kế này ra sao?

Architect giỏi thường vẫn viết code ở tuyến đầu, ít nhất phải đọc hiểu code quan trọng. Họ không nhất thiết mỗi ngày viết nhiều business code nhất, nhưng không thể chỉ vẽ sơ đồ, họp và nói về nguyên tắc. Architecture design nếu rời khỏi code thực tế và nghiệp vụ thực tế sẽ nhanh chóng biến thành lời nói suông. Đây cũng là lý do người mới không cần vội theo đuổi danh xưng này.

Có thể bắt đầu từ những điểm nhỏ hơn: khi phụ trách một module, hãy nghĩ rõ input, output, data model, error handling, performance bottleneck và cách mở rộng của nó; khi làm một yêu cầu, không chỉ hoàn thành chức năng mà còn phải biết sau khi deploy thì quan sát thế nào, sau khi thất bại thì rollback ra sao. Làm tốt những việc này thực tế hơn nhiều so với nói suông về “tư duy architecture”.

Rốt cuộc nên chọn thế nào?

Nếu bạn chưa vào nghề, hãy ưu tiên xem số lượng vị trí và khả năng gia nhập. Các hướng như Java backend, frontend, test development và phát triển nghiệp vụ cơ bản thường có nhiều cửa vào hơn. Trước tiên hãy lấy kinh nghiệm dự án thực tế, sau đó tùy theo sở thích mà chuyển sang phát triển ứng dụng AI, middleware, platform engineering, architecture, algorithm hoặc system tầng dưới, rủi ro sẽ nhỏ hơn nhiều.

Nếu muốn đi theo hướng phát triển ứng dụng AI, đừng chỉ xem nó là “hướng mới”. Cách tốt hơn là trước tiên có một main stack về engineering: backend, full-stack, test development và platform engineering đều được. Không có nền tảng engineering, rất khó thực sự làm vững các vấn đề về RAG, Agent, evaluation, cost, permission và stability.

Nếu đã có một hoặc hai năm kinh nghiệm, hãy xem trong công việc mình sẵn sàng chủ động làm thêm điều gì nhất. Có người thích lần theo một slow SQL đến index và execution plan; có người thích biến quy trình release lặp đi lặp lại thành tool; có người thích phân tích sự cố production đến tận monitoring và stress test; có người thích trừu tượng hóa vấn đề nghiệp vụ thành model và metric. Những gì bạn sẵn sàng suy ngẫm lặp đi lặp lại thường nói rõ hướng đi hơn tên vị trí.

Nếu muốn đi theo hướng tầng dưới hoặc infrastructure, đừng chỉ lưu tài liệu. Hãy chọn một nhiệm vụ rõ ràng, chẳng hạn:

Theo dõi một lần thực thi query của MySQL.
Gửi một PR nhỏ cho một middleware open source.
Làm một CI/CD demo có thể chạy được.
Viết một test automation platform đơn giản cho API.
Tổng hợp architecture diagram, call chain, kết quả stress test và phương án dự phòng sự cố của một business module.

Sau hai đến bốn tuần, về cơ bản bạn có thể phán đoán mình có muốn tiếp tục hay không.

Việc chọn hướng đi cũng không cần quyết định một lần cho cả đời. Trong những năm đầu sự nghiệp, điều quan trọng hơn là rèn chắc nền tảng engineering: code quality, computer fundamentals, troubleshooting, giao tiếp và phối hợp, hiểu nghiệp vụ, học tập liên tục. Nền tảng đủ dày thì sau này đổi hướng sẽ không quá bị động.

Lộ trình học trong site

Tài liệu tham khảo

Lời cuối

Nếu nội dung hữu ích với bạn, hãy tiện tay tặng JavaGuide một Star miễn phí để ủng hộ: GitHub | Gitee.

JavaGuide đã được duy trì gần bảy năm, tích lũy 6100+ commit, với sự chung tay hoàn thiện của 620+ contributor. Star, phản hồi và PR của bạn đều là động lực để dự án tiếp tục cập nhật.

Nếu bạn đang chuẩn bị phỏng vấn backend / phát triển ứng dụng AI, có thể tham khảo Knowledge Planet của tôi, bao gồm các project thực tế về backend và AI, tối ưu CV, hỏi đáp 1-1 và tài liệu về các trọng điểm thường gặp, đã được duy trì liên tục sáu năm.