Những nguồn lực sẽ giúp bạn vào những năm tháng bắt đầu sự nghiệp

Bản dịch của bài viết “A Software Engineering survival guide” của tác giả Valeri Alexiev đăng trên Medium

Những năm đầu tiên trong sự nghiệp của tôi là khoảng thời gian học hỏi mãnh liệt. Tôi đã nhận ra nhiều sự thật khi là một lập trình viên và bắt buộc phải tiếp thu nhiều kĩ năng mà tôi không nghĩ rằng mình cần. Nhìn lại thì chắc chắn sẽ tốt hơn nếu được biết những điều đến bây giờ tôi mới biết.

Vì vậy tôi viết bài này để giúp những người khác dựa trên kinh nghiệm của những lập trình viên tôi đã hướng dẫn trong những năm đầu với vai trò là giáo sư và một vài kinh nghiệm của chính bản thân và từ đồng nghiệp.

Tôi sẽ chia sẻ về:

• Cách vượt qua vòng Phỏng Vấn tốt nhất
• Làm sao để sống sót (và phát triển) trong công việc là một lập trình viên
• Và những nguồn lực nào bạn cần xem xét khi có những bước tiến tiếp theo trong sự nghiệp

Interviews/ Phỏng vấn

Khi bạn bắt đầu sự nghiệp lập trình viên của mình, bạn sẽ phải đối mặt với 1 sự thật phũ phàng. Những lần phỏng vấn dở tệ J))))

Chúng có thể tệ cho bất cứ ai tham gia vào. Đã từng là người phỏng vấn và người đi phỏng vấn, tôi có thể kiểm chứng được rằng những cuộc phỏng vấn là một khoảng thời gian khó khăn, rất căng thẳng và là một chỉ số tệ hại đối với hiệu năng của công việc tương lai. Tuy đây, đây là một điều cần thiết mà bạn và bản CV của bản thân cần phải có sự chuẩn bị kĩ càng.

Hãy chuẩn bị cho trận chiến

Nếu bạn đang xem xét trở thành một lập trình viên, hãy đảm bảo rằng bạn phải học một vãi câu hỏi phỏng vấn phổ biến như “FizzBuzz”:

“Hãy viết một chương trình cho ra kết quả từ 1 – 100. Nhưng với bội số của 3, hãy trả về”Fizz” thay vì số và bội số của 5 thì trả về”Buzz”. Số nào là bội số của cả 3 và 5 thì trả về “FizzBuzz” (Coding Horror)

Nghe có vẻ rất đơn giản đúng không?

Thật ra thì hầu hết các ứng viên đều fail bài test này, và cho ra các biến thể phức tạp hơn.

Cá nhân tôi đã thấy nhiều ứng viên ở các vị trí Senior fail bài test này trong khi họ vẫn đang truy cập internet bình thường. Vì vậy, hãy đảm bảo là nếu bạn liệt kê bất kì ngôn ngữ nào trong CV của mình, thì bạn ít nhất phải biết làm FizzBuzz bằng ngôn ngữ đó. Nếu không, bạn chỉ đang làm tốn thời gian của mọi người, bao gồm cả của bản thân.

Tất nhiên là để vượt qua được vòng phỏng vấn thì bạn cần phải biết nhiều hơn là FizzBuzz. Bạn cũng cần phải đảm bảo rằng  mình có kiến thức về:

• Các thuật toán và cấu trúc dữ liệu đơn giản: như là linked lists, arrays, trees và sorts
• Các “gochats” phổ biến trong ngôn ngữ lập trình của bạn, như là khi nào strings không thay đổi và các quản lí bộ nhớ
• OOP (Lập trình hướng đối tượng) như là class vs object và tính kế thừa

Khi bắt đầu công việc, bạn cần phải tỏa sáng trong những câu hỏi như này, vì bạn không có kinh nghiệm để chứng minh rằng mình sẽ làm tốt công việc này. Có 2 nguồn lực mà tôi luôn đề xuất khi chuẩn bị cho các cuộc phỏng vấn:

• “Cracking the Coding Interview” một quyển sách tuyệt vời bao gồm nhiều vấn đề khi code và giải pháp của nọ và tóm tắt những điều bạn cần phải làm để giải quyết vấn đề.
• CodeWars – một website chứa nhiều vấn đề khi code mà bạn có thể giải quyết trên trình duyệt sử dụng nhiều ngôn ngữ lập trình khác nhau. Phần hữu ích nhất là xem cách những người khác giải quyết chung một vấn đề. Bạn sẽ học hỏi được nhiều cách tiếp cận khác nhau với cùng 1 vấn đề và học được các tools mới với ngôn ngữ của mình.

Hãy tạo thêm điểm cộng cho bản thân

Có một số điều bạn có thể làm để có thể tạo thêm điểm cộng của mình.

Đầu tiên, hãy học cách giao tiếp về kinh nghiệm của bạn. Bạn nên có một sơ đồ tổng hợp CV của bạn thành một câu chuyện mạch lạc và hấp dẫn.

Thêm vào đó, hãy biết rõ CV của mình! Nghe có vẻ buồn cười nhưng mà tôi đã thấy rất nhiều người đi phỏng vấn gặp khó khăn trong việc giải thích một yếu tố nào đó trong CV của mình. Bạn nên có khả năng trả lời tất cả các câu hỏi về bất kì kinh nghiệm nào bạn đã liệt kê trong CV và giải thích tại sao điều đó lại khiến bạn trở thành một ứng cử viên sáng giá.

Tiếp theo, có code samples trên GitHub (Hoặc bất kì nơi lưu trữ công cộng nào khác)

Có thấy mới tin, nếu người phỏng vấn có thể thấy code của bạn sẽ có tác dụng lớn. Thêm nữa là nó cho thấy bạn có hiểu biết về version control systems.

Mẫu code không cần phải quá phức tạp, nhưng nó cần phải sạch và cho thấy kĩ năng code tốt của bạn. Đây là cơ hội để bạn show code của mình mà không bị áp lực về thời gian.

Một khi bạn đã làm xong hết thảy những điều phía trên, đã đến lúc xem xét đến việc tham gia vào một dự án open source. Đây sẽ là cách giúp bạn làm việc vói code base có sẵn và hợp tác với các lập trình viên khác.

Đây là cách gần nhất để bạn có thể lập trình trong môi trường thực tế mà không cần thực sự làm trong đó. Cho tới thời điểm hiện tại, đây là một trong những item khó khăn và tốn thời gian nhất nên hãy để dành nó cho đến khi hoàn thành tất cả những thứ tôi đã đề cập ở trên.

Hãy hỏi lại người Phỏng Vấn bạn

Trong quá trình tìm việc vội vàng, nhiều ứng viên quên rằng phỏng vấn là một cuộc đối thoại 2 chiều.Trong khi công ty cố gắng tìm ra liệu bạn có phải là người tốt nhất cho công việc đó không, bạn cũng nên tìm ra xem liệu công ty ấy có thực sự phù hợp với bản thân không.

Hãy đảm bảo rằng bạn đã hỏi một trong số các câu hỏi dưới đây, cho dù là trong các email sau cuộc phỏng vấn đi chăng nữa. Hãy thường xuyên để ý trong khoảng thời gian này vì các công ty thường sẽ không cố gắng chạy theo những người có lợi thế về mặt technical hơn đâu nên hãy đọc kĩ những dòng này.

Đây là một số câu hỏi ví dụ mà bạn nên hỏi:

“Một ngày làm việc tiêu biểu sẽ như thế nào?”

Việc biết được công việc hàng ngày cụ thể là gì rất quan trọng vì công việc lập trình viên rất rộng, có người thích bảo trì server hoặc có người lại thích làm việc trực tiếp với khách hàng.

Lưu ý: “Tôi không chắc” à Có thể người phỏng vấn bạn không nằm trong team bạn sẽ làm việc hoặc họ không có khái niệm quá rõ ràng tại sao họ lại thuê bạn.

“Bên anh test software như thế nào?”

Lý tưởng là, một sự kết hợp giữa unit test, manual test và automated test nên được sử dụng để xác định chất lượng code

Lưu ý: “Chúng tôi không viết ra bug đâu, haha J” à Đây chính xác là người luôn gây ra bugs

“Bên anh sử dụng version control system nào?”

Version control system rất hữu ích khi hợp tác với nhau và không có lí do gì để không sử dụng chúng cả

Lưu ý #1: “Ừ, version control system á?” --? Chạy ngay đi, trước khi…

Lưu ý #2: “<insert obscure or custom VCS>” à cho thấy họ không theo kịp thời đại và đã không update hệ thống từ lâu lắm rồi

“Bên anh có người peer review không?”

Peer review hay có một người khác check code của bạn trước khi được đưa vào codebase là cách rất hữu ích để chỉ ra các lỗi ngớ ngẩn và là một cơ hội training quan trọng khi bạn bắt đầu sự nghiệp.

Lưu ý: “Chúng tôi tin tưởng lẫn nhau” à Rất có thể là các senior dev rất bảo vệ code của mình và không giỏi đưa ra feedback.

“Công ty có các chương trình training cho nhân viên không?”

Khi là một lập trình viên, bạn phải học hỏi liên tục từ khi công nghệ mới bắt đầu xuất hiện, tới thời kì bùng nổ và trở nên lạc hậu. Vì vậy mà nhiều công ty có budget cho việc training nhân viên bằng hợp tác với các trường đại học, các khóa học online và hội nghị hoặc là các buổi chia sẻ trong nội bộ công ty.

Lưu ý: “Ý của bạn là đọc ba thứ online trong giờ rảnh ấy à?” à Công ty này đang không dành chi phí cho việc này hoặc chỉ coi các lập trình viên là một thứ dễ thay thế chứ không phải là một sự đầu tư lâu dài.

“Công ty sử dụng process nào cho công việc?”

Process rất quan trọng trong quá trình phát triển phần mềm, bất kể các chi tiết thực tế. Những chi tiết cấu thành một process tối ưu có thể gây tranh cãi, tuy nhiên cách làm việc thống nhất trên một project sẽ giảm thiếu tối ưu sự hỗn loạn và đảm bảo mọi người sẽ bắt kịp với nhau.

Lưu ý: “Process của chúng tôi được truyền cảm hứng từ sự tự do” à Có thể là toàn bộ các bộ phận còn lại đang trong trạng thái dập lửa, nhảy từ cái khẩn cấp này sang cái khẩn cấp khác mà không có một mục đích rõ ràng nào cả”

“Làm thế nào để giải quyết nợ kĩ thuật (technical debt)?”

Nợ kỹ thuật là sự tích lũy của những công nghệ lỗi thời và những code base nhanh nhưng không sạch. Việc giải quyết nó rất quan trọng đối với sức khỏe lâu dài của code và phải được thực hiện liên tục.

Lưu ý: “Chúng tôi chỉ tập trung vào những tính năng mới” à Code base của họ là một đống hỗn độn hoặc sớm thôi nó sẽ trở thành như vậy

“Văn hóa công ty như thế nào?”

Văn hóa công ty có thể là một khái niệm rất mơ hồ nhưng thậm chí những thử nhỏ nhặt như một không gian mở so với phòng khép kín sẽ thay đổi cách bạn tương tác với đồng nghiệp hàng ngày theo một cách rất đặc biệt. Không có Lưu ý nào cả, tuy nhiên hãy đảm bảo rằng câu trả lời của họ là thứ gì đó có thể khiến bạn làm việc 40 tiếng/ tuần trong hàng năm trời.

(Cont...)

Via Medium