Bí kíp sống còn trong giới lập trình viên

Bài viết gốc tại: A Software Engineering survival guide của tác giả Valeri Alexiev.

Dịch giả: Togahepi a.k.a Hà Hiệp.

Những bí kíp sinh tồn giúp bạn khởi đầu suôn sẻ sự nghiệp

Sublime Text on a computer of a geek

Những năm đầu sự nghiệp của tôi là quãng thời gian học tập căng thẳng nhất.

Tôi nhận ra hiện thực phũ phàng của một kĩ sư phần mềm là phải có rất nhiều kĩ năng mà tôi chẳng hề biết tới. Nhìn lại, tôi ước gì mình biết mọi thứ sớm hơn.

Vì vậy, tôi viết bí kíp này dựa trên những trải nghiệm lập trình mà tôi đã trải qua trong năm đầu tiên sự nghiệp, cũng như tham khảo của những đồng nghiệp của tôi.

Có 3 bí kíp chính:

Những cuộc phỏng vấn

Khi bạn bắt đầu sự nghiệp Kĩ Sư Phần Mềm, bạn sẽ đối mặt với một thực tế phũ phàng. Các cuộc phỏng vấn dở hơi!!!

Nó dở hơi với tất cả mọi người luôn. Cả nhà tuyển dụng lẫn người đi phỏng vấn, tôi thề là mọi cuộc phỏng vấn là một đống bầy nhầy mất thời gian, cực kì stress và chẳng giúp chỉ ra năng lực cho công việc tương lai. Tuy nhiên, nó lại vô cùng cần thiết phải chuẩn bị cho bạn và CV của bạn.

Sẵn sàng chiến đấu

Nếu bạn muốn trở thành một Kĩ Sư Phần Mềm, hãy đảm bảo đã chuẩn bị những câu hỏi lập trình ví dụ như câu "FizzBuzz":

"Viết một chương trình mà in ra các số nguyên từ 1 đến 100. Nhưng với những số là bội của 3 thì thay nó bằng từ "Fizz", tương tự thay bội của 5 bằng từ "Buzz". Mà nếu nó là bội của cả 3 và 5 thì thay bằng "FizzBuzz"".

(Coding Horror)

Nghe có vẻ đơn giản nhỉ?

Thế mà, phần lớn ứng viên đi phỏng vấn đã không qua nổi bài test đơn giản này.

Tôi đã tận mắt chứng kiến nhiều ứng viên cho vị trí Senior đã trượt bài test này thậm chí cả khi được tra cứu trên internet. Vậy nên hãy đảm bảo rằng với bất kì ngôn ngữ lập trình nào được liệt kê trong CV của bạn thì bạn phải biết làm bài "FizzBuzz" với nó. Không thì, bạn đang lãng phí thời gian của mọi người đó!

Đương nhiên, bạn sẽ cần biết nhiều hơn là chỉ bài "FizzBuzz" nếu muốn sống sót qua cuộc phỏng vấn. Bạn cần đảm bảo rằng mình biết rõ:

  • Cấu trúc dữ liệu và các thuật toán cơ bản: như là linked list - danh sách liên kết, array - mảng, tree - cây dữ liệu và sort - sắp xếp.
  • Những hiểu biết cơ bản về ngôn ngữ bạn thông thạo, như là khi nào thì chuỗi biến đổi, và quản lý bộ nhớ ra sao.
  • Lập trình hướng đối tượng như lớp - class, đối tượng - object, hay kế thừa - inheritance.

Khi mới vào nghề, bạn phải sẵn sàng với những câu hỏi loại này, bởi bạn không có nhiều kinh nghiệm để chứng minh mình phù hợp với công việc. Có 2 nguồn tài liệu mà tôi luôn khuyên các bạn phải chuẩn bị cho các cuộc phỏng vấn:

  • "Cracking the Coding Interview", một cuốn sách tuyệt vời gồm nhiều bài thuật toán cách giải quyết, cũng như những điều cơ bản mà bạn cần để giải quyết chúng.
  • CodeWars, một trang web có một tấn các bài thuật toán mà bạn có thể giải trực tiếp trên trình duyệt với nhiều ngôn ngữ khác nhau. Điểm hay của trang này là bạn có thể tham khảo những cách làm khác của mọi người. Bạn sẽ học hỏi được nhiều phương án tiếp cận đối với cùng một vấn đề.

Kiếm thêm lợi thế cho bản thân

Có vài thứ mà bạn có thể làm để thêm lợi thế trên bàn phỏng vấn.

Resume or CV

Đầu tiên, học cách thể hiện kinh nghiệm bản thân. Bạn nên chuẩn bị một bản tóm tắt CV của mình giống như một mẩu chuyện ngắn gọn và logic.

Bạn là người biết rõ CV của mình nhất! Ấy thế mà, tôi gặp rất nhiều trường hợp khó khăn khi giải thích CV của chính họ. Bạn nên chuẩn bị sẵn sàng giải thích mọi kinh nghiệm mà bạn đã viết ra trong CV của bạn và thể hiện mình là một ứng viên tốt cho công việc.

Điều tiếp theo, nên có những đoạn code trên GitHub (hoặc một trang lưu trữ công khai tương tự).

Trăm nghe không bằng một thấy, nhà tuyển dụng luôn muốn tận mắt nhìn thấy những dòng code của bạn. Thêm vào đó, nó sẽ cho thấy bạn hiểu rõ hệ thống kiểm soát phiên bản.

Những đoạn code mẫu không nhất thiết phải quá phức tạp, nhưng chúng cần rõ ràng và thể hiện bạn luyện code tốt. Đây là cơ hội để bạn thể hiện khả năng code của bạn khi không phải chịu áp lực từ cuộc phỏng vấn.

Một khi bạn đã hoàn thành mọi việc trên, đã đến lúc cân nhắc tham gia vào một dự án mã nguồn mở. Nó sẽ cho thấy khả năng của bạn khi làm việc với những đoạn code cũ và sự phối hợp với các lập trình viên khác.

Đó là cách tốt nhất mà bạn có thể làm quen với môi trường lập trình công nghiệp mà chưa cần thực sự gia nhập nó. Nhưng nó cũng vô cùng khó khăn và tốn thời gian, vì thế hãy để dành nó sau khi đã hoàn thành những nhiệm vụ nhỏ mà tôi đã nêu ở trên.

Phỏng vấn lại phỏng vấn viên

Trong cuộc chiến săn việc đầy căm go và căng thẳng, rất nhiều ứng viên quên mất rằng cuộc phỏng vấn là con đường 2 chiều. Điều đó như là công ty đang tìm người phù hợp với công việc nhưng bạn cũng cần hiểu đó có phải là công ty phù hợp với bạn.

Hãy chắc chắn bạn phải hỏi những câu hỏi dưới đây, kể cả trong email sau phỏng vấn.

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

"Một ngày làm việc thường nhật của em sẽ như thế nào ạ?"

Một điều quan trong là bạn nên biết rõ vị trí của mình sẽ làm bởi Kĩ Sư Phần Mềm là công việc bao hàm nhiều thứ. Bạn có thể làm bảo trì server hay phải nói chuyện trực tiếp với khách hàng.

Tín hiệu nguy hiểm: "Tôi không chắc" => Có nghĩa là người đang phỏng vấn bạn sẽ không nằm chung 1 đội với bạn và họ không chắc vì sao họ sẽ thuê bạn.

"Công ty mình kiểm tra phần mềm như thế nào?"

Lý tưởng nhất là tập hợp của kiểm tra tổng thể, kiểm tra thủ công và kiểm tra tự động nên có để đánh giá chất lượng code.

Tín hiệu nguy hiểm: "Chúng tôi không viết bug, haha" => Những người này chính xác là những kẻ tạo ra lỗi.

"Hệ thống kiểm soát phiên bản công ty sử dụng là gì?"

Hệ thống kiểm soát phiên bản vô cùng hữu ích khi phối hợp với đồng nghiệp và không có lý do gì lại không sử dụng trong môi trường chuyên nghiệp.

Tín hiệu nguy hiểm #1: "Hệ thống kiểm soát phiên bản ư?" => Chạy ngay đi!!!

Git version system contrl
Luôn luôn sử dụng hệ thống kiểm soát phiên bản.

Tín hiệu nguy hiểm #2: "<không chắc chắn hoặc sử dụng hệ thống kiểm soát phiên bản tùy biến>" => Điều này nghĩa là họ không thường xuyên cập nhật xu hướng và đã không cập nhật cơ sở hạ tầng trong thời gian dài.

"Công ty bạn có đánh giá code cho nhau?"

Đánh giá ngang hàng, là có một ai khác kiểm tra code của bạn lần cuối trước khi nó nhập vào code base, là một cách tuyệt vời để tránh những lỗi sai ngớ ngẩn cũng như là một cơ hội tuyệt vời để được huấn luyện khi bạn mới bắt đầu sự nghiệp.

Tín hiệu nguy hiểm: "Chúng tôi tin tưởng lẫn nhau!" => Giống như là những lập trình viên Senior đang bảo vệ code của họ và không hào hứng đưa ra những phản hồi.

"Công ty bạn có những chương trình đào tạo liên tục không?"

Trở thành kĩ sư phần mềm nghĩa là bạn phải liên tục học hỏi bởi công nghệ xuất hiện, trưởng thành và trở nên lỗi thời nhanh đến chóng mặt. Do đó, rất nhiều công ty phải có ngân quỹ cho đào tạo để chi trả cho các trường đào tạo và các lớp học online, hội nghị hay những buổi nói chuyện riêng.

Tín hiệu nguy hiểm: "Ý bạn là đọc tài liệu trên mạng trong thời gian rảnh" => Công ty này hoặc là đang ngập trong nợ nần hoặc chỉ xem lập trình viên có thể thay thế dễ dàng và không đầu tư về lâu về dài.

Manager Work
Các nền tảng quản lý dự án/công việc

"Quy trình phát triển phần mềm công ty bạn sử dụng là gì?"

Quy trình là điều sống còn đối với kĩ sư phần mềm, bất kể chi tiết thực sự là gì. Chi tiết của việc tạo ra quy trình tối ưu là chủ đề cần thảo luận nghiêm túc, nhưng sự tồn tại của những thỏa thuận làm việc đơn giản cho một dự án cũng giảm thiểu tối đa những hỗn loạn và đưa mọi người vào cùng 1 guồng quay công việc.

Tín hiệu nguy hiểm: "Quy trình của chúng tôi tạo cảm hứng tự do như nhạc jazz vậy." => Giống như là mọi phòng ban đang trong chế độ sẵn sàng khai hỏa, nhảy từ việc khẩn cấp này sang việc khẩn cấp khác mà chẳng có mục tiêu rõ ràng gì.

"Công ty bạn đương đầu với những món nợ công nghệ ra sao?"

Món nợ công nghệ là sự tích lũy của những công nghệ lỗi thời, những giải pháp nhanh chóng nhưng đầy vết nhơ ở trong code base. Nhìn nhận ra sự quan trong của những dòng code có tuổi thọ lâu dài và nên được tiếp tục hoàn thành.

old code
Bạn nghĩ rằng hàm này là cũ kĩ và thừa thãi. Có thể bạn
đúng đó nhưng khi chúng ta xóa nó đi, vì một lý do nào
đó cả chương trình crash và chúng ta chẳng thể hiểu vì
sao, vì vậy là nó vẫn nên ở lại.
"Code đang chạy ngon thì đừng động vào" :))

Tín hiệu nguy hiểm: "Chúng tôi chỉ tập trung cho những tính năng mới." => Code base của họ là một mớ hỗn độn hoặc sớm trở nên hỗn độn. :))

"Văn hóa của công ty bạn là gì?"

Văn hóa của công ty nghe vẻ như một khái niệm mơ hồ, nhưng như một ví dụ nhỏ là một văn phòng rộng mở so với những ô làm việc sẽ quyết định cách bạn tương tác ngày qua ngày với đồng nghiệp của mình vô cùng khác biệt. Không có cảnh báo nguy hiểm nào ở đây, nhưng đảm bảo câu trả lời phải thỏa mãn để bạn có thể làm việc hơn 40 giờ 1 tuần trong nhiều năm.

Làm việc như một kỹ sư phần mềm

Tới được giai đoạn này, nếu bạn trải qua tốt cuộc phỏng vấn cũng như thỏa mãi với những câu hỏi của mình, bạn gần như chắc chắn được tuyển dụng.

Chúc mừng, bạn đã chính thức trở thành kỹ sư!

Lập trình chẳng căng thẳng tí nào - John 26 tuồi cho hay
Trở thành lập trình viên chẳng stress tẹo nào - John - 26 tuổi cho hay :))

Giờ thì làm thao? Có lẽ tới lúc phải học lại mọi thứ về coding cũng như cách làm việc. Và chúng là những lập trình viên, hãy bắt đầu thảo luận về code nào.

Chuẩn code công nghiệp

Chuẩn code công nghiệp phải có những đặc tính sau đây, theo thứ tự:

  • Dễ đọc, bởi code phải được đọc và bảo trì nhiều hơn là quá trình nó viết ra. Code viết ra phải rõ ràng, sáng để những lập trình viên khác sau nhiều năm vẫn hiểu bạn đã viết cái quỷ gì vậy. :v
  • Tính phòng thủ, luyện tập để code luôn đúng. Tính phòng thủ trong code có ý chính là: Bạn phải đảm bảo rằng không có những class hay method không hợp lệ dẫn tới crash chương trình.
  • Tối ưu, là bước cuối cùng trong danh sách bởi bạn sẽ chẳng phải bận tâm tới nó trong phần lớn thời gian. Điều đó cũng không có nghĩa bạn viết ra những dòng code ẩu như là O(n3) khi mà phương pháp tuyến tính tồn tại. Nhưng nhiều lập trình viên cũng cố gắng quá mức để tối ưu nhưng khi mà chẳng cần thiết lại còn giảm tính dễ đọc và tính đúng của code. Bạn nên luôn cân nhắc khi mà tối ưu thì lại phải hi sinh những tính chất cần thiết khác của code.

Giờ thì bạn đã biết viết code chuẩn công nghiệp ra sao:

Chúng ta thực sự không viết code nhiều đâu

Có thể bạn thấy bất ngờ, nhưng hầu hết thời gian bạn không dành để viết code mới, mà thay vào đó bạn sẽ:

  • Debugging: Tìm lỗi
  • Đọc những dòng code cũ
  • Họp hành hoặc viết email
  • Nghiên cứu những việc để bạn không phải viết code

Do đó những kĩ năng khác ngoài code lại vô cùng quan trọng đối với sự nghiệp của bạn.

Tìm lỗi và đọc code cũ

My code
Code của tôi...In ra ("Tới đây được rồi")
  • Bạn sẽ cần nhiều hơn là tìm lỗi bằng câu lệnh in ra. Những ngôn ngữ được sử dụng phổ biến và những tech stack đều có nhiều công cụ mạnh mẽ. Sử dụng chúng và bạn sẽ thấy việc tìm lỗi nhẹ nhàng và giảm đi hàng giờ vô ích.
  • Hiểu rõ code base. Hầu hết tech stack đều có công cụ tạo bản đồ code giúp bạn hiểu rõ cấu trúc của code base. Những IDE chuyên nghiệp đều có tính năng này đi kèm. Bạn có thể khám phá code bằng những công cụ như  ReSharpergrep or Sourcegraph.
  • Hiểu rõ sản phẩm. Bạn sẽ ngạc nhiên thay vì nhiều lập trình viên không biết phần mềm hoạt động chính xác như thế nào cho tới khi họ cố gắng sửa nó. Hãy đọc tài liệu đính kèm.

Tổ chức lại suy nghĩ của bạn

Vì phần lớn thời gian bạn sẽ dành cho giao tiếp, nghiên cứu và những hoạt động phối hợp, bạn cần công cụ để giữ mọi việc trật tự.

  • Danh sách việc cần làm / nhiệm vụ: Công ty của bạn nên có những phần mềm quản lý nhiệm vụ, đồng thời sẽ rất hữu ích nếu có cản hệ thống quản lý cá nhân. Dùng những ghi chú dính nhanh hay phần mềm như Trello or Todoist.
  • Ghi chú: Luôn luôn ghi chú trong những buổi họp, làm việc để cải thiện những tài liệu có sẵn và tạo ra những kiến thức nền cá nhân. Sử dụng EvernoteOneNote, hoặc 1 cuốn sổ ghi chú như những ngày xưa ấy. Có vẻ hơi quá, nhưng bạn sẽ thầm cảm ơn mình 1 năm trước khi bạn xem lại quy trình rối rắm mà bạn mất tới 3 ngày để hiểu ra trong lần đầu tiên. Tôi chưa từng gặp một Kĩ sư phần mềm nào giỏi mà không ghi chú cẩn thận cả!
  • Đồ thị/Hình ảnh trực quan: Con người là một sinh vật quan sát và việc tạo ra đồ thị của một quy trình hay cấu trúc sẽ giúp bạn và những người khác hiểu những vấn đề phức tạp. Những biểu đồ vô cùng hữu ích khi cần thảo luận với những đồng nghiệp không chuyên kĩ thuật. Hãy sử dụng LucidchartVisio hoặc viết lên bảng trắng.

Biết khi nào thì nên sử dụng những thư viện

Trả lời ngắn gọn: Hầu hết mọi lúc.

Trả lời có tâm: 99% thời gian, bạn sẽ không phải phát minh lại cái bánh xe. Trong bất cứ vị trí nào của kĩ sư phần mềm, viết lại code vô cùng lãng phí thời gian. Điều đó không có nghĩa là bạn không cần biết thuật toán hay cấu trúc dữ liệu mà bạn dùng hoạt động ra sao, nó vẫn cần thiết để bạn lựa chọn sử dụng cái gì và khi nào.

Để trở thành một Kĩ sư phần mềm hiệu quả, bạn cần hiểu rõ các thư viện mà bạn có sẵn. Những thư viện chuẩn của các ngôn ngữ phổ biến cực kỳ hữu dụng và có nhiều hơn là bạn mong đợi. Thêm vào đó, code base có thể cũng sử dụng những thư viện bổ sung, đặc biệt. Hãy đọc tài liệu của chúng và hiểu rõ cách sử dụng chúng.

Bạn đừng nên sợ sệt khi phải dùng thêm các thư viện nếu việc đó giúp tiết kiệm thời gian. Tuy nhiên bạn cũng nên cân nhắc lựa chọn thư viện tốt cho mục đích chuẩn công nghiệp. Một thư viện tốt là:

  • Mã nguồn mở, để bạn có thể đánh giá chất lượng code của mình cũng như khả năng sửa lỗi nghiêm trọng trong ứng dụng của bạn.
  • Được cấp phép dưới sự cho phép của MIT hay BSD, để công ty bạn không gặp vấn đề nào khi sử dụng chúng. Cẩn thận với GPL, bạn có thể mã nguồn mở toàn bộ code base của mình ngoài ý muốn.
  • Trưởng thành, đã ra đời khá lâu và có đầy đủ tính năng.
  • Được bảo trì, vẫn ra những phiên bản mới thường xuyên.
  • Được sử dụng bởi công ty hay dự án khác, thể hiện là nó được hỗ trợ chuyên nghiệp và liên tục được bảo trì.

Tiến bộ không ngừng

Để học hỏi thêm những kĩ năng mà giúp bạn ngày càng tiến bộ trong công việc, bạn cần liên tục nâng cao kĩ năng và học kiến thức mới, để có thể tạo cơ hội nghề nghiệp mới cho bản thân.

Cơ hội để học có rất nhiều và chúng cũng rất dễ dàng để tiếp cận:

  • Khóa học online: Cơ hội được học từ những chuyên gia hàng đầu trong mọi lĩnh vực thì không nên bỏ qua. Hãy ghé thăm CourseraUdacity hoặc edX  cho những khóa học bổ sung thêm kĩ năng cho bạn.
  • Bằng tiến sĩ trực tuyến: Một xu hướng gần đây nổi lên của các trường đại học top đầu, bằng tiến sĩ trực tuyến là một cách tiếp cận linh hoạt để bạn tiếp tục con đường học vấn của mình. Nó cũng rẻ hơn rất nhiều so với bằng cấp khi học tại trường, thường chỉ tốn ~10.000 Đô cho cả khóa học. Georgia TechUT, và UC San Diego là một trong những đại học có chương trình này. Tôi thì đề nghị Georgia Tech vì tôi đã tốt nghiệp từ đây. :))
  • Blogs: Blog vô cùng quan trong trong giới lập trình viên (không bất ngờ gì bạn đang lượn lờ và đọc những dòng này). Blog như là  Coding HorrorJoel on Software, hoặc thậm chí là những website châm biếm như The Daily WTF có thể giúp bạn có những ý tưởng tốt về việc nên và không nên làm khi trở thành kĩ sư phần mềm. Lướt Medium, r/programming, HackerNews hoặc những trang tin khác cũng sẽ dẫn bạn tới những chủ đề và blog tốt.
  • Hội nghị: Cuối cùng, nhưng không kém quan trọng, các hội nghị là nơi tuyệt vời với những cơ hội học tập và bạn nên tận dụng ngân sách đào tạo của công ty để tới dự chúng. Một danh sách các hội nghị xịn sò nên check-in nè: GOTO; (General), Strange Loop(General), PyCon (Python), CPPCon (C++), DEF CON (Security), Fluent(Web dev). Tất cả chúng đều có video nói chuyện trên Youtube nên bạn có thể học được nhiều thứ mà không cần tới tham dự!

Hy vọng rằng, với bài viết này sẽ dẫn lối bạn trên con đường bắt đầu trở thành một kĩ sư phần mềm và cung cấp cho bạn những công cụ để trở nên giỏi giang trên cuộc hành trình thú vị này! Cảm ơn vì đã đọc! Nếu bạn có câu hỏi hay hỏi ngay để được đáp luôn dưới bình luận nhé!
 

DevOps DevOps Techmaster team Blog Home Một lập trình viên nên biết 6 công nghệ cần học trong 2013 Một lập trình viên nên biết 6 công nghệ cần học trong 2013 Techmaster team
Hà Văn Hiệp

Yêu công nghệ! Yêu thiên nhiên! Yêu gia đình! Yêu và yêu có thế thôi!