Dzung Nguyen - Software Engineer tại DoorDash
Techie có dịp ngồi lại với anh Dũng Nguyễn - software engineer @DoorDash, hiện đang sống và làm việc tại Nhật Bản.
“Nếu bây giờ được quay lại thời còn non người trẻ dạ, thì anh sẽ tin vào bản thân mình nhiều hơn… Báo chí thì ngày nào chả đưa tin người này giỏi, người kia thành công. Nhưng mà mình đâu có biết họ đã trải qua bao nhiêu gian nan thử thách đâu. Ai cũng có những mục tiêu khác nhau, nên mình cứ tập trung vào đường đi của mình thôi.”
Q: Trong quá trình làm việc, anh thường phát triển coding skills bằng những cách nào?
“Hồi còn làm việc ở Việt Nam, anh luôn muốn sang Nhật, Singapore hoặc Mỹ. Điều anh nghĩ tới đầu tiên, tất nhiên là học tiếng Anh. Thứ hai là coding skills. Nếu cùng một level, hẳn nhiên công ty sẽ chọn người ở nước họ để không phải sponsor visa. Vậy thì mình phải giỏi vượt trội hơn cả về thuật toán để phỏng vấn, và technical skill để làm việc. Cân bằng hai thứ này khó lắm à. Hồi đó, buổi tối anh sẽ luyện LeetCode, thuật toán. Còn lại sẽ tận dụng thời gian cải thiện technical skill bằng cách làm side project, giải quyết những vấn đề anh gặp ở công việc chính. Những giải pháp đó thường có thể tổng quát hoá, và anh cũng public ra open-source dưới sự cho phép của công ty. Vì muốn làm ra 1 open-source chất lượng mà technical skills của anh cũng tăng đáng kể. Chính cái lúc anh đi research và tham khảo hàng ngàn best practices để áp dụng vào project nhỏ của mình, anh có được kinh nghiệm và hiểu ra tại sao họ làm như vậy. Khi mình hiểu được ngọn nguồn rồi thì “sướng” lắm!
Phần technical skill này ngoài build và research nhiều để lấy kinh nghiệm thì mình phải tò mò nữa. Đừng dừng lại ở việc làm xong phần của mình rồi thôi! Ví dụ như task đó có liên quan đến team khác, thì mình nên tìm hiểu thêm toàn bộ cái features này vận hành thế nào. Tại sao đầu API này lại liên quan đầu API kia, vân vân mây mây. Khi hiểu được rồi thì sẽ làm rất nhanh, vì mình tự hình thành được cái flow trong đầu rồi. Còn trẻ mà, nếu không thông minh đọc cái hiểu liền thì mình gắng học nhiều làm nhiều.
Một số bạn sẽ thắc mắc tò mò là bản năng, hay có thể rèn luyện? Anh chỉ có thể nói là tuỳ vào mục đích của em. Lấy ví dụ như anh, mọi thứ anh làm ở trên đều để thực hiện mục tiêu ra nước ngoài, làm việc cho công ty lớn. Chắc chắn nó không hề dễ và có nhiều áp lực. Ngay cả việc phỏng vấn, không lý gì người ta sẽ hỏi những vấn đề cơ bản, ai cũng biết cả. Vậy nên việc mình có thể làm ngay là đào sâu vào công việc chính đang làm hằng ngày. Khi code JavaScript, mình có thể dễ dàng làm với biến này biến kia nhưng nhìn lại thì có tất cả bao nhiêu loại biến? Tại sao lại có hai loại biến đó? Và tại sao lại sinh ra Closure? Ngữ cảnh nào thì mình nên xài? Bắt đầu từ những cái nhỏ như vậy, mà cũng tốn của anh nhiều thời gian lắm.”
Q: Vậy là mọi thứ đều bắt nguồn từ mục đích bản thân mình đề ra. Anh có lời khuyên gì cho việc đặt mục tiêu từ trải nghiệm cá nhân không?
“Đúng là đặt ra mục tiêu trước khi làm gì rất quan trọng, vì từ đó em sẽ có những câu hỏi, làm sao đạt được nó và ra được hành động cụ thể. Thế nhưng đặt được một mục tiêu hợp lý và cụ thể khó lắm em. Chẳng hạn giờ bảo “tôi muốn làm việc ở Google tại Mỹ”. Trời ơi mơ hồ vậy biết làm gì bây giờ? Hãy chia nó thành nhiều goal nhỏ hơn, và hình thành một cái roadmap để đi đến cái mục tiêu mơ hồ lúc đầu. Mỗi cái mini win trên những goal nhỏ đó chính là motivation để em bước tiếp.
Một cái mini win gần đây của anh là https://www.spotit.page/ - 1 Spotify Extension anh build với 40k+ downloads tính tới nay. Các bạn có thể đọc quá trình build và cách nhìn product anh đã viết ở đây.
Nói thêm về Spotit, lúc mới đầu làm anh tính viết với mục đích cho mình xài thôi. Vì cơ bản anh cũng không biết là có demand hay không. Nhưng mà làm cách nào mình collect được data để chứng minh là có demand? Thế nên anh chỉ hỏi thêm vài người bạn, với 9/10 người nói muốn xài thì anh quyết định làm. Tổng thời gian anh dành cho nó là hơn một năm. Khi ra được version đầu tiên với khoảng 1000 users, bắt đầu có feedback này nọ là lúc anh có rất nhiều động lực để build tiếp.”
Q: Nếu được quay trở lại thời anh vừa mới ra trường và có công việc full-time đầu tiên, thì anh sẽ muốn nói với bản thân hay thay đổi điều gì không?
“Nếu bây giờ được quay lại thời còn “non người trẻ dạ”, thì anh sẽ tin vào bản thân mình nhiều hơn. Có một chuyện thế này. Hồi đó anh đặt một mục tiêu nhỏ là viết technical article cho một tạp chí công nghệ của Úc mà anh hay đọc. Lu bu nhiều việc mãi tới một năm sau, sau khi gửi mail trực tiếp đến toàn soạn đó và miệt mài viết trong một tháng, anh đã có bài viết đầu tiên được đăng tải. Vui sướng lắm em, nhuận bút không bao nhiêu nhưng nghĩ tới nhiều người đọc được bài mình viết thì phấn khởi lắm. Thế nên cái anh muốn nói ở đây là, sau khi đặt một cái mục tiêu thiết thực thì mình có đủ phấn đấu để làm hay không? Và nếu không ai tin mình, thì ít nhất còn bản thân tin mình. Nếu không xem trọng khả năng của bản thân thì còn ai xem trọng? Báo chí thì ngày nào chả đưa tin người này giỏi, người kia thành công. Hồi đó anh cũng so sánh, kiểu nó nhỏ hơn mình, hay bằng tuổi mình mà nó ghê vậy. Sau khi anh viết được bài article trên rồi thì anh không đọc những bài báo như vậy nữa. Ai cũng có những mục tiêu khác nhau, mình cứ tập trung vào đường đi của mình thôi. Thất bại thì có sao đâu nào, coi như học một bài học.”
Q: Quay về hiện tại, anh có nghĩ code đến một độ tuổi nào đó thì mình sẽ bị tới giới hạn?
“Hiện tại thì anh cũng là đàn anh trong nghề của nhiều bạn, dù không đu kịp tốc độ của các bạn trẻ hơn nhưng cũng chẳng có gì phải quan ngại. Trước khi gõ dòng code nào thì người có kinh nghiệm thường sẽ suy nghĩ kĩ hơn, cẩn thận hơn. Nhất là những task liên quan đến nhiều system, hay cần nhiều team ngồi lại để brainstorm. Giống như một vấn đề anh gặp gần đây nè. Cách mà công ty anh thiết kế software chưa thật sự tốt lắm. Nó không giúp kĩ sư dễ dàng test được. Anh tìm mãi tìm mãi mà không ra cách test, và nó còn liên quan đến rất nhiều team. Em thấy đó, công ty lớn quá, anh phải tốn cực kì nhiều thời gian để tìm chính xác người đang nắm cái vấn đề đó. Cuối cùng, tụi anh quyết định làm một cái version 2 có scale nhỏ hơn, mọi thứ dễ dàng linh hoạt, dễ test hơn.
Chung quy lại vấn đề vẫn nằm ở chỗ communication. Timezone giữa Nhật và Mỹ chênh nhau tận 13 tiếng, thế nên anh chỉ có giờ khuya hoặc sáng sớm để giao tiếp với team. Vì vậy, mình phải học cách đặt câu hỏi đúng và đủ để phục vụ cho công việc của bản thân. Với remote team, có 3 communication level thế này:
- Giao tiếp trong group/ channel của team giải quyết được vấn đề của mình
- Nếu không ai trả lời thì xem codebase, owner là ai, và ping trực tiếp người đó. Đương nhiên làm như vậy sẽ gây khó chịu cho cả mình và người khác, nhưng nó cần thiết để phục vụ công việc
- Nếu người đó cũng không trả lời luôn, thì hãy ping Manager của họ. Manager chắc chắn sẽ trả lời.
Vậy thì, làm sao để đặt câu hỏi đúng và đủ? Cái này phải học đấy, lắm lúc trả lời còn dễ hơn đặt câu hỏi ấy chớ. Thử tra google “How to ask a question” đi, nhiều lắm! Điều tiên quyết là, luôn phải biết output mình muốn là gì trước hỏi người khác.”
