Con đường sự nghiệp của một kỹ sư phần mềm (phần 5)

[tiếp theo của phần 4]

Thực ra quyết định chọn công ty nào cũng tương đối dễ dàng.

Công ty Mỹ có quy trình phỏng vấn khó hơn hẳn. Vòng nào mình cũng cảm thấy hồi hộp và phải vắt óc suy nghĩ tối đa. Cho nên khi vượt qua được, mình trân trọng cơ hội đó hơn. Người ta nói: “cái gì khó có được thì mới biết quý trọng”, đúng là như vậy thật.

Ngoài ra, công ty Mỹ còn có một quy trình làm việc Agile chuyên nghiệp với phong cách “lập trình đôi” (pair programming) độc nhất vô nhị ở Việt Nam, slogan cũng rất ấn tượng nữa. Mình nghĩ mình sẽ học được nhiều ở đây.

Do đó, mình đành từ chối công ty Úc mặc dù chỉ còn 2 tuần nữa là tới ngày đi làm đầu tiên bên đó. Mình nói lý do huỷ hợp đồng là vì “tìm được cơ hội khác tốt hơn”. Chị nhân sự cố gặn hỏi xem là công ty nào, thậm chí còn đề nghị tăng lương cho mình. Mình rất áy náy nhưng cũng đành từ chối một cách dứt khoát.

Rồi mình bắt đầu vào làm ở công ty mới.

Vào đây mình thấy công ty toàn là người trẻ, đa số sinh năm 88 đến 95. Tuy trẻ nhưng ai cũng có điểm nổi trội đặc biệt: người thì là chủ tịch câu lạc bộ lập trình ở trường đại học, người làm trợ giảng, nhiều người tốt nghiệp thủ khoa, nhiều người đã đi du học nước ngoài, nhiều người sắp đi du học, nhiều người hay đi chia sẻ ở các meetup, v.v. Mình thấy hơi choáng ngợp vì mình không có thành tích gì nổi bật cả, bỗng dưng được gặp hàng loạt nhân tài tập trung hết vào một chỗ như thế này, mình cảm thấy thật may mắn.

Tuần đầu tiên, mình chủ yếu ngồi đọc tài liệu về quy trình làm việc Agile của công ty. Sau đó mình được cử đi Hà Nội công tác 3 tháng để làm một dự án mới, mình sẽ lập trình đôi với một chị ngoài đó.

Trong dự án này, mình không những phải code thật nhanh để kịp giao hàng cho khách mỗi tuần mà còn phải học cách viết “test tự động” nữa. Quy trình làm việc của công ty không có khâu QA nên kỹ sư được yêu cầu phải viết “test” để tự kiểm tra xem phần mềm có làm đúng chức năng hay không. Cứ có code là phải có test, thậm chí có khi còn viết test trước cả khi viết code, cái này thuật ngữ chuyên môn gọi là “Test-driven development”, viết tắt là “TDD”.

Mình như được khai sáng khi lần đầu tiếp xúc với thế giới “test” này. Ở thời điểm đó, mình chưa nghe công ty phần mềm nào ở Việt Nam nghĩ tới việc viết test, chứ nói gì tới việc tập trung gần một nửa thời gian để viết test như công ty mình.

Khi có test rồi thì không cần QA nữa, chỉ cần cho máy tự chạy test qua tất cả các trường hợp, nếu test fail ở đâu thì mình biết phải sửa code ở chỗ tương ứng để làm test pass. Bởi vì là test tự động nên mình muốn chạy bao nhiêu lần cũng được, ngày chạy 5 lần, 10 lần, 20 lần, hay chạy mỗi khi push code lên. Nhờ có test mà mình code ít bị lỗi hơn và khi có lỗi thì cũng biết sửa chỗ nào. Test trở thành lĩnh vực mình đam mê và muốn master.

Sau 3 tháng ở Hà Nội, mình hoàn thành dự án đúng thời hạn, đồng thời cũng học được rất nhiều thứ:

  • Học cách viết UI test cho iOS.
  • Học cách cài đặt CI (Continuous Integration) để chạy test tự động cho iOS.
  • Học cách chat tiếng Anh với khách hàng nước ngoài sao cho chuyên nghiệp.
  • Học cách nói chuyện tiếng Anh với khách hàng của chị đồng nghiệp và cách chị xử lý tình huống (lúc đó chị là người giao tiếp chính, chị có IELTS 8.5!).
  • Học cách “yêu xa” 😂.

Quay lại tp Hồ Chí Minh, mình thấy tự tin hơn với khả năng viết test tự động cũng như khả năng tiếng Anh của mình. Tuy nhiên, do không có dự án iOS nào mới nên mình được chuyển sang học làm web sử dụng “Ruby on Rails”. Mình chẳng biết tí gì về làm web hay “Ruby” hay “Rails” cả, nhưng thấy mọi người ai cũng giỏi cái này nên mình cũng phấn đấu học.

Sau đó, mình được phân công lập trình đôi với một bạn senior có nhiều năm kinh nghiệm làm “Rails” để bạn kèm cặp. Lúc này, mình mới thấy được lợi thế của việc lập trình đôi:

  • Lập trình đôi nghĩa là hai người cùng ngồi vào một máy tính, một người code, một người nói. Cả hai cùng thảo luận để giải quyết vấn đề.
  • Khi tiếp nhận vấn đề, mình có thể xem được cách một người senior suy nghĩ và giải quyết như nào, rồi xem cách họ code luôn.
  • Thường sau vài tiếng thì hai người sẽ đổi vai. Khi mình code thì người senior có thể review và góp ý ngay cho mình, đây chính là đỉnh cao của code review.
  • Tương tự, khi giao tiếp tiếng Anh với khách hàng, mình xem được cách người senior nói chuyện và trả lời các câu hỏi. Khi mình chat thì họ cũng review được cách mình dùng từ và xem thử câu trả lời của mình có hợp lý không.
  • Nói chung mình thấy “lập trình đôi” là cách hiệu quả nhất để trao đổi kiến thức giữa hai kỹ sư, đặc biệt là để huấn luyện nhân viên junior. Mình may mắn được làm chung với một bạn rất nhiệt tình, cái gì bạn đó cũng chỉ, thấy mình sai là bạn nhắc, bởi vậy chỉ sau vài tháng mà mình đã nhanh chóng nắm được các kỹ thuật làm web và backend cơ bản với “Ruby on Rails”.

Ngoài ra, nhờ học “Ruby on Rails” mà mình cũng học được luôn cách viết “unit test” theo phong cách Behaviour-driven development (hay BDD), cách viết “integration test” bằng Cucumber, cách sử dụng terminal/console hiệu quả, cách hoạt động của “git”, cách viết giao diện cho website bằng HTML và Javascript, cách debug & inspect website, cách gõ bằng “vim”, vân vân và vân vân.

Mình cảm thấy những điều mình học được ở công ty này trong vòng một năm có khi còn hơn cả 10 năm đi làm ở các công ty khác, thậm chí còn chưa chắc học hết được những điều đó.

Đây là công ty đã đưa mình lên một tầm cao mới trong sự nghiệp phát triển phần mềm.

[còn tiếp]

Đăng ký theo dõi blog

Nếu bạn cảm thấy blog mình có ích thì hãy đăng ký theo dõi để nhận email thông báo khi có bài viết mới nhé.

Các bài liên quan

Con đường sự nghiệp của một kỹ sư phần mềm (phần 6)

Con đường sự nghiệp của một kỹ sư phần mềm (phần 4)