Một tuần làm việc của Engineering Manager (p3)

~ conmotsach ~ Leave a comment

Thứ năm – phỏng vấn và high-level org coordination

Dạo gần đây hay có phỏng vấn để mở rộng team. Bản thân mình sau gần 1 năm không tuyển người cũng bắt đầu làm quen lại với các quy trình từ viết JD, đăng tuyển, lọc CV, phỏng vấn, offer, … và phát hiện ra sau gần 1 năm quan điểm cũng ít nhiều thay đổi về quy trình này.

Viết JD. Sau một thời gian dài chỉ dùng những mẫu JD trên mạng hoặc viết những câu chung chung, mình bắt đầu phát hiện ra là để viết JD được tốt thì bản thân người manager phải thực sự hiểu nhu cầu của mình. Việc viết JD chi tiết và thực tế sẽ giúp cho ứng viên tự xác định bản thân có phù hợp không, hoặc các bạn talent acquisition, headhunter có thể dựa vào đó để sàng lọc người phù hợp. Chi tiết ở đây là cần mô tả:

  • Giới thiệu tổng quan ngắn gọn về dự án và team đang tuyển
  • Tổng quan về vai trò đang đăng tuyển
  • Trách nhiệm cụ thể của vai trò này
  • Yêu cầu
    • Kỹ năng mềm
    • Kinh nghiệm ở vị trí liên quan
    • Học vấn

Phỏng vấn. Khi đã hiểu nhu cầu của mình thì việc phỏng vấn cũng cần được sắp xếp dựa theo nhu cầu thực tế. Có một cuộc tranh luận lâu đời trong ngành là phỏng vấn developer/engineer thì có cần phỏng vấn thuật toán sâu hoặc hỏi xoáy đáp xoay kiểu “Google” hay không? Phỏng vấn thì sẽ cần bao nhiêu vòng là đủ, …

Khó có thể nói đâu là cách tốt nhất. Tuy nhiên gần đây team mình cũng bắt đầu bỏ các bài phỏng vấn theo hướng competitive programming, hoặc phỏng vấn những thứ sẽ không thực sự được dùng trong công việc hằng ngày ở công ty. Suy cho cùng, phỏng vấn là để tuyển người vào làm những công việc hàng ngày, nếu quá trình phỏng vấn tập trung quá nhiều vào competitive programming hoặc hỏi những thứ mà công việc hàng ngày không cần thì thứ nhất là người tuyển chưa chắc đã phù hợp mà có khi lại vượt quá yêu cầu, thứ hai là người phỏng vấn đậu sẽ có “expectation” sai về công việc họ phải làm hằng ngày. Phỏng vấn quá khó hoặc cao siêu mà công việc hàng ngày không cần có thể gây mất tinh thần về lâu về dài.

Offer. Phỏng vấn xong rồi, offer ai cũng là một vấn đề. Những câu hỏi cần phải trả lời khi chọn người để offer cũng như mức offer có thể bao gồm:

  • Phỏng vấn đậu là offer ngay? Tùy vào tình hình thị trường và lượng ứng viên cũng như nhu cầu thực tế mà người manager có thể chọn offer ngay khi gặp ứng viên phù hợp hay sẽ chờ các ứng viên trong cùng batch phỏng vấn được phỏng vấn hết.
  • Offer nên ở mức nào? Các công ty lớn thường sẽ có range lương và có policy về việc tăng lương định kỳ. Nhưng sẽ hiếm khi bạn offer ở mức tối đa ở range lương vì nếu làm vậy sẽ khó tăng lương định kỳ cho ứng viên nên thường mức offer sẽ ở mức vừa phải.
  • Ứng viên này sẽ đóng góp cho team như thế nào? Tuỳ vào tình hình cụ thể của team mà có khi người manager sẽ cần người năng nổ để giao tiếp, hoặc người thiên về hạ tầng để xử lý các tasks hạ tầng, hoặc người có chuyên môn về AI để lái định hướng của team sang hướng AI, hoặc có khi cần một bạn trẻ nhưng năng nổ và học hỏi nhanh để đẩy nhanh tốc độ thử nghiệm công nghệ mới, …

Kinh nghiệm dành cho các bạn ứng viên:

  • Project, team, quản lý của bạn rất quan trọng, đặc biệt là trong môi trường công ty lớn nơi có nhiều team và nhiều projects khác nhau. Hãy tìm hiểu về project bạn sẽ làm vì trong môi trường quy mô lớn, việc đổi project sẽ không dễ. Hãy hỏi những câu hỏi cụ thể như stack công nghệ là gì, bài toán hoặc project mà bạn đang phỏng vấn là gì, có những challenge gì, …
  • Hãy đặt câu hỏi khôn ngoan để lựa chọn môi trường phù hợp. Phỏng vấn là một quá trình hai chiều trong đó công ty tìm người phù hợp và ở chiều ngược lại bạn cũng muốn tìm môi trường phù hợp cho mình. Hãy hỏi những câu hỏi dạng STAR với những tình huống cụ thể cho người phỏng vấn để khai thác thông tin tốt hơn. Ví dụ như:
    • Đừng hỏi: anh/chị có thể chia sẻ thêm về văn hoá công ty không?
    • Hãy hỏi: công ty có OT nhiều không? Công ty có những loại hình training nào? Một ngày làm việc điển hình của một bạn có vai trò tương tự trong team anh/chị?
  • Quan trọng là hợp tính. Bạn không đậu phỏng vấn team này chưa chắc đã là do bạn kém mà có khi là do không hợp với team hoặc không hợp thời điểm, bạn vẫn có thể thử đề xuất phỏng vấn với team khác.
  • Các loại benefit ngoài lương như thưởng, stock, … cũng rất quan trọng. Khi thương lượng nên cân nhắc tổng thu nhập năm thay vì chỉ ưu tiên lương cứng. Một số công ty có thể offer lương cứng thấp nhưng bù lại tổng thu nhập năm lại cao do các phần khác như stock và bonus nhiều. Có một số công ty thì ngược lại.

Một tuần làm việc của Engineering Manager (p2)

~ conmotsach ~ Leave a comment

Thứ tư – ngày không họp hành

Qua hai ngày đầu tuần thì hẳn các bạn sẽ đặt dấu hỏi, ủa, vậy EM thấy họp suốt ngày vậy thì còn làm gì khác không? Thật ra thì cũng có đấy. Ngoài các khoảng nghỉ giữa các cuộc họp thì EM sẽ có những tasks của riêng mình, và những tasks này thường sẽ tận dụng các khoảng thời gian rảnh giữa các meeting, hoặc là tận dụng no-meeting day để hoàn thành.

(1) Làm các tasks liên quan đến engineering. Cụ thể là viết thinking document hoặc design document để nêu hoặc phân tích một vấn đề nào đó. Các vấn đề phân tích mà vai trò EM phụ trách thường sẽ mang tính tổng quan hoặc chiến lược hơn so với các bài toán vận hành hàng ngày. Ví dụ như một vài vấn đề mình sẽ phải viết gần đây:

  • Chia sẻ quan điểm về vai trò của low-code platform trong tổ chức? Có nên dùng hay không? Nếu dùng thì nên dùng như thế nào?
  • Bài toán workflow automation là bài toán của ai (trong tổ chức lớn hơn), nên được giao cho ai?
  • Đề xuất cho một platform khác có liên quan đề platform của mình

(2) Thực hiện vai trò giám sát và coaching. Một trong những trách nhiệm lớn nhất của EM là phải giám sát và chịu trách nhiệm cho sự phát triển của team mình. Để thực hiện vai trò này thì bản thân cần liên tục theo dõi các kênh thông tin của team mình trên Slack để xem các thành viên đang trao đổi về vấn đề gì, có thể nhảy vào cùng trao đổi và tìm cách đưa cuộc thảo luận theo đúng hướng (nếu bản thân thấy chưa đúng hướng).

Ngoài ra cũng sẽ dùng các nội dung trao đổi này để mang ra thảo luận với từng cá nhân trong quá trình 1:1 để góp ý và chia sẻ quan điểm của mình. Sẽ có những tình huống bản thân thấy một thành viên A nào đó phản hồi chưa hợp lý, hoặc chưa trọn vẹn, ví dụ như bạn ấy đang giải thích về một vấn đề cho một người dùng non-tech nhưng lại dùng quá nhiều thuật ngữ kỹ thuật. Trong những tình huống như vậy thì mình sẽ cần ghi nhận và thảo luận với bạn ấy trong những buổi gặp mặt để bạn lưu ý hơn.

Bên cạnh đó, EM cũng sẽ cần phải giúp các thành viên phát triển thông qua việc thảo luận về career path, cũng như xác định độ ưu tiên cho các thành viên và cân bằng giữa nhu cầu phát triển bản thân và nhu cầu của công ty. Bên công ty mình thì trong thời gian gần đây có triển khai một hoạt động gọi là Plan & Priority, trong đó mỗi thành viên sẽ cần tự đặt ra các mục tiêu phát triển bản thân cũng như các ưu tiên trong sự nghiệp hiện tại. EM sẽ dựa vào nhu cầu của từng thành viên để từ đó có sự phân công các tasks phù hợp.

Ví dụ như nếu một bạn trong 6 tháng tới muốn đầu tư nhiều quanh hệ thống Data, vậy thì EM cần tìm cách để đưa bạn vào nhóm làm task liên quan đến Data nhiều hơn. Hoặc một bạn quan tâm đến DevOps thì EM cần tìm cách phân các tasks liên quan đến DevOps nhiều hơn cho bạn, …

(3) Thực hiện vai trò lên kế hoạch. Lập và thực thi kế hoạch là một trong những vai trò quan trọng mà EM cần phải đảm đương, đặc biệt là việc lên kế hoạch dài hạn với chu kỳ 3-6 tháng trở lên. Trong một tổ chức lớn như nơi bản thân đang làm việc, việc có những chiến lược và kế hoạch dài hạn 2-3 năm là cần thiết vì nhiều lý do. Nhiệm vụ của EM lúc này là phải hiểu được platform hoặc team mình đang phụ trách đang đứng ở đâu trong bức tranh toàn cảnh của công ty, phòng ban của mình để tự đó đưa ra được các kế hoạch phù hợp.

Trong vai trò này, bản thân sẽ cần phải tham gia chuẩn bị những thứ như

  • Budget planning. Dự toán xem hạ tầng của team đang quản lý cần kinh phí bao nhiêu trong 6 tháng – 1 năm tới.
  • OKR planning. Mỗi 6 tháng một lần, sẽ phải thống nhất OKR của team để review với các manager cùng các stakeholders liên quan.
  • Vision and Strategy docs. 1 năm một lần sẽ cần phải review lại về chiến lược dài hơi của team, platform để coi team đang ở đâu và cần phát triển theo hướng nào.
  • Execution plan. Tham gia vào soạn thảo các kế hoạch thực thi ở phía engineering từ một kế hoạch lớn ảnh hưởng đến nhiều bộ phận khác nhau.

(4) Các task khác lặt vặt không tên. Tùy vào quy mô và quy trình của tổ chức mà số lượng task lặt vặt có thể nhiều hoặc ít, nhưng sẽ có kha khá các tasks có thể kể tên như: review và approve request xin quyền từ team, support một bạn user của platform, xin budget engagement, …

Một tuần làm việc của Engineering Manager

~ conmotsach ~ Leave a comment

Lâu rồi không viết bài mới vì nhiều lý do như sức khỏe, công việc, nhiều mối quan tâm khác, … nhưng thật ra lý do lớn nhất vẫn là lười… Nhìn chung, có những thứ bản thân biết là cần thiết nhưng không hiểu sao cứ luôn tự trì hoãn theo cách này hay cách khác. Chắc nhiều bạn cũng giống mình (hy vọng vậy …).

Dạo này gặp áp lực phải viết lại, nên thôi chọn một chủ đề nào đó dễ viết mà không cần phải suy nghĩ quá nhiều, đó là kể lại công việc hàng ngày của mình.

Hiện giờ mình đang làm việc ở một công ty công nghệ với quy mô trên 1000 nhân sự dưới vai trò Engineer Manager.  Mình đang phụ trách một team nhỏ có khoảng 15-16 người. Team của mình chịu trách nhiệm vận hành và phát triển cho một platform nội bộ bên trong công ty.

Thứ hai – ngày của planning

Sáng đầu tuần khởi động bằng hai cuộc họp sprint planning cho hai team đang phụ trách. Thường thứ hai sẽ được dùng cho sprint planning hoặc backlog grooming, xen kẽ mỗi tuần. Tuỳ vào lượng công việc mà có thể mình sẽ bỏ qua cuộc họp này mà chỉ theo dõi tình trạng backlog sau khi mọi người trong team đã họp xong.

Ở team mình, một sprint sẽ kéo dài hai tuần. Đầu sprint mọi người sẽ cùng duyệt qua backlog để chọn ra các task quan trọng cần phải hoàn thành trong sprint này. Sau đó mọi người cũng sẽ duyệt qua các project quan trọng và điều chỉnh lịch release dự kiến nếu cần thiết. Thông thường, backlog khá dài nên việc review các task và độ ưu tiên sẽ được làm trước trong các buổi backlog grooming của tuần trước đó để khi làm sprint planning thì sẽ không tốn thời gian review độ ưu tiên lại.

Chiều thứ hai thường sẽ có cuộc họp giao ban ngắn giữa oncall tuần trước và oncall tuần này. Ở công ty mình, tại một thời điểm sẽ luôn có người phụ trách trực cho một service hoặc một platform, người này sẽ được gọi là oncall. Tuỳ team mà ca trực oncall theo ngày hoặc theo tuần. Nhiệm vụ của oncall sẽ là theo dõi tình hình hệ thống, phản ứng khi có các cảnh báo sự cố hoặc vấn đề xảy ra, trả lời các câu hỏi của team khác liên quan đến các phần hệ thống của team mình. Trong buổi họp giao ban này, người phụ trách oncall tuần trước sẽ điểm qua những vấn đề phát sinh của tuần rồi và các điều cần lưu ý tiếp.

Trong chiều thứ hai này team mình có một buổi họp đột xuất để review một Post-mortem được viết bởi một bạn trong team, trình bày về nguyên nhân dẫn đến sự cố service bị nghẽn trong 2 ngày liên tục, mỗi lần nghẽn diễn ra trong 5 phút dẫn đến một loạt các service liên quan cũng bị nghẽn theo. Mọi người sẽ cùng review Post-mortem của bạn phụ trách và đưa ra góp ý, phản biện cũng như đặt các câu hỏi để làm rõ hơn về nguyên nhân sự cố.

Sự cố này thú vị vì sau khi điều tra cụ thể thì phát hiện ra mặt dù dấu hiệu ban đầu của việc bị nghẽn trong 2 ngày là giống nhau, nhưng nguyên nhân sâu xa gây ra lại hoàn toàn khác nhau. Ở ngày đầu tiên, service bị nghẽn vì một node trong cụm server không phục vụ được traffic cho các service khác dẫn đến mất cân bằng tải. Lý do là trong quá trình node này khởi động thì quá trình đăng ký node này vào danh mục service discovery bị lỗi, dẫn đến cụm server có 3 servers nhưng chỉ có 2 servers phục vụ được traffic thông qua service discovery. Điều này dẫn đến thuật toán auto-scaling của cụm server vốn dựa vào CPU trung bình không hoạt động đúng.

Ở ngày thứ hai, service bị nghẽn cũng vì một node trong cụm không phục vụ được traffic cho các service khác thông qua ELB nhưng do quá trình khởi tạo và đánh nhãn bị lỗi nên không bị thay thế kịp lúc. Quá trình này cũng dẫn đến mất cân bằng tải.

Thời gian còn lại của buổi chiều có thể xen kẽ các session 1:1 ngắn với các thành viên đang quản lý trực tiếp, gián tiếp hoặc đang mentor.

Thứ ba – ngày của Operational Excellence

Sáng thứ ba thường sẽ bắt đầu bằng họp stand-up online với team nhỏ đang trực tiếp phụ trách. Trong buổi stand up các thành viên sẽ mở tasks board ra, sau đó từng thành viên sẽ lần lượt điểm qua các việc đã làm ngày hôm trước cũng như nêu ra các vấn đề cần xử lý. Nếu có vấn đề cần thảo luận thì các thành viên có thể tự hẹn để thảo luận riêng sau đó. Trong hoạt động này thì với vai trò EM, bản thân chỉ tham gia để cập nhật thông tin là chủ yếu, hoặc thỉnh thoảng có thể đưa ra góp ý về hướng xử lý một ticket là thoả đáng hay chưa.

Phần còn lại của buổi sáng sẽ là họp Operational Excellent của toàn công ty. Trong buổi họp này, các team phụ trách về vận hàng sẽ điểm qua nhiều vấn đề như tình hình cost, các incidents, các vấn đề về security, các vấn đề về độ ổn định chung của toàn hệ thống theo các nhóm service khác nhau. Ngoài ra, các team nào có sự cố sẽ trình bày Post Mortem của team mình.

Nói thêm một tí về Post-Mortem (PM), cấu trúc thường có của một PM thường bao gồm:

  • Giới thiệu tổng quan về sự cố
  • Timestamp các sự kiện diễn ra trước, trong và sau khi sự cố
  • Phân tích sâu về nguyên nhân gốc rễ dẫn đến sự cố
  • Các hành động đã làm để phục hồi hệ thống cũng như giảm thiểu thiệt hại (mitigate)
  • Bài học kinh nghiệm cần rút ra.

Đối với một tổ chức lớn vận hành nhiều service phức tạp thì các PM là một hoạt động rất quan trọng vì nó sẽ giúp chúng ta rút kinh nghiệm mỗi khi có sự cố xảy ra. Một PM tốt cần phân tích sâu và đến gốc rễ vấn đề (Root-cause) để từ đó có thể rút ra bài học cho các service khác có thể áp dụng. Quá trình phân tích cũng có thể áp dụng nhiều kỹ thuật nhưng phổ biến nhất là 5-whys: đặt liên tục 5+ câu hỏi tại sao cho đến khi có thể chạm đến gốc rễ.

Ví dụ về quá trình đặt câu hỏi 5-whys được đơn giản hoá để có thể dễ hình dung:

  • Tại sao lại service A lại có gặp lỗi 500 liên tục trong khung thời gian 15 phút từ thời điểm 11:00am đến 11:15am? → Tại vì service A gọi đến service B, service B trả về kết quả với độ trễ p99=800ms trong khi yêu cầu từ service A là 150ms.
  • Tại sao service B lại trả về kết quả với độ trễ p99=800ms trong khung thời gian đó? → Tại vì database service B đang dùng trả về kết quả cho endpoint XX với độ trễ p99=700ms, cao hơn thường lệ.
  • Tại sao database service B đang dùng lại trả về kết quả có độ trễ cao p99=700ms và cao hơn thường lệ? → Tại vì một partition của database đang dùng bị overload dẫn đến các request đến partition này có độ trễ cao hơn.
  • Tại sao partition lại bị overload? → Tại vì có một lượng request tăng đột biến đến từ service C cũng gọi qua service B, trong lượng request này có kèm một số lệnh update đến từ partition tương ứng dẫn đến overload partition này.
  • Tại sao lại có một lượng request tăng đột biến đến từ service C? → Tại vì redis cluster của service C bị down dẫn đến một lượng lớn request vốn nên được cache bởi service C bị đẩy sang service B.

Trong thực tế, việc đặt câu hỏi có thể nhiều hơn hoặc ít hơn. Nhưng nhìn chung khi phân tích, đặt câu hỏi đúng thì sẽ dẫn đến các bài học kinh nghiệm phù hợp để từ đó ngăn chặn các vấn đề phát sinh trong tương lai.

Kết thúc buổi sáng thứ ba, buổi chiều thường sẽ bắt đầu bằng buổi họp Operational Excellent của platform đang phụ trách. Trong đó, các thành viên sẽ review các thông số vận hành như SLI, SLO, các vấn đề mới phát sinh cần đào sâu, … Nếu chỉ số nào không đạt SLO thì sẽ cần điều tra nguyên nhân. 

Tiếp đến sẽ là họp dành cho leader của platform đang phụ trách trong đó sẽ điểm qua các chủ đề tổng quan của platform như các use-case mới cần xử lý, thông tin từ các platform liên quan, chốt OKR, thảo luận milestone tiếp theo của các dự án đang triển khai, …

Phần còn lại của buổi chiều là xen kẽ 1:1 với leader hoặc coordinator cùng team, team khác để cập nhật tình hình lẫn nhau cũng như thảo luận về các dự án đang phụ trách của nhau. Đối với bản thân thì các buổi 1:1 là một hoạt động không thể thiếu đặc biệt là đối với các team liên quan để có thể tập trung thảo luận các chủ đề tổng quan về problem space của từng team, hoặc các vấn đề mang tính chất dài hạn hơn (3-6 tháng) thay vì các hoạt động hàng ngày vốn đã có quy trình tương ứng để xử lý.

(còn tiếp)

Thế nào là một ứng dụng tốt?

~ conmotsach ~ Leave a comment

Đọc bài viết gốc: http://coding-geek.com/what-is-a-good-application/

Gần đây, tôi ứng tuyển vào một vị trí kỹ thuật ở công ty đang làm hiện tại. Một trong những câu hỏi mà người phỏng vấn hỏi tôi đó là “Thế nào là một ứng dụng tốt?”.

Hơi bất ngờ vì tôi chưa thực sự nghĩ về điều này trước đây. Vì thế tôi nghĩ đây sẽ là một bài tập tốt cho bản thân mình khi tổng hợp lại góc nhìn của mình về “Thế nào là một ứng dụng tốt?”. Thời điểm được phỏng vấn, tôi đã đưa ra một câu trả lời từ góc nhìn của một dân kỹ thuật. Và bây giờ, tôi lại nghĩ về câu hỏi đó một lần nữa, và đây là những suy nghĩ mới nhất của tôi cho câu hỏi này.

Continue reading “Thế nào là một ứng dụng tốt?” →