“Vì sao mình chọn start-up sau Facebook?” Hiếu Phạm – Software Engineer tại ROCKSET

Trong mục “Chuyên gia nói” lần này, chúng ta sẽ trò chuyện cùng anh Hiếu Phạm – Software Engineer tại Rockset. Từng là nhân viên của 3 công ty công nghệ lớn như Google, Microsoft và Facebook, hãy cùng tìm hiểu vì sao anh Hiếu chọn Rockset là nơi phát triển sự nghiệp. 

Về khách mời Hiếu Phạm

• Hiện đang là Senior Software Engineer ở công ty Rockset, công ty làm về realtime database được 4 năm
• Công việc đầu tiên là ở tập đoàn Facebook.
• Và trước khi ra trường, anh thực tập ở 3 công ty, tập đoàn lớn là Google, Microsoft và Facebook.
• Rockset là 1 công ty khởi nghiệp software access và service về mảng realtime database. Rockset được thành lập bởi những kỹ sư ngày trước cũng từ facebook và google. Là những kỹ sư ban đầu thiết kế các hệ thống rất là lớn như là RocksDB, HDFS hay Gmail.

Rockset giải quyết vấn đề gì?

Rockset thực ra là 1 realtime database giúp khách hàng có thể chạy những sql query trên datahost mà trước giờ họ không support cái SQL query ấy, thí dụ như là DynamoDB, Kafka, hay S3 của Amazon hoặc là google course query của Google. 1 điểm hay của Rockset đó chính là realtime, có nghĩa là khi mà data đến mình query được luôn, chứ mình không phải đợi 1 đến 2 ngày.

Và cái hay nữa là khi khách hàng dùng Rockset không cần phải tune query, không phải tạo index để làm gì hết, khỏi cần phải data rockset và rockset sẽ tự động làm cho tới cái query họ nó nhanh hơn. Mình chỉ mới làm ở đây được mấy tháng và dự án mà mình thích nhất hiện giờ là giúp cho hệ thống Rocket chứa được hình nhiều thông tin hơn, và với 1 giá tiền rẻ hơn, vì mình càng chứa nhiều thông tin hơn AWSB của mình sẽ rất là lag, nên công việc của mình bây giờ là làm cho nó càng rẻ càng tốt. 

Anh hãy giới thiệu hoặc giải thích đơn giản về architecture của Rockset? Vai trò của một người làm về Search Engine là xử lý ở quá trình nào trong mô hình này?

Hệ thống của Rockset chia làm 3 phần, gọi là Tailer – Leaf – Aggregator. Tailer nói nôm na là nơi xử lý những dữ liệu thô, và đưa cái dữ liệu đã được xử lý đó vào leaf, và leaf là nơi chứa dữ liệu đó để cho aggregator đó query cái dữ liệu đó 1 cách hiệu quả. Sau khi aggregator query những dữ liệu đó xong sẽ làm các phép tính sequel đó rồi trả lại dữ liệu cho người dùng, đó là cái nhìn chung về architecture của rockset, thật ra cái architecture này được dùng ở rất nhiều nơi.

Ngày xưa khi mà mình làm ở bên search họ cũng dùng những cái architect như thế này và 1 trong những người đầu tiên khi mà xây dựng hệ thống search của Facebook hiện giờ cũng đang làm ở Rockset, cho nên đó là lý do vì sao mà 2 hệ thống trông rất là giống nhau.

Data-driven app là gì? Có ý nghĩa như thế nào đối với các doanh nghiệp?

Các doanh nghiệp hiện giờ khi phải quyết định chuyện gì, họ phải phân tích nhiều về data mới biết được vấn đề hiện giờ là gì và giải pháp nên là thế nào. Khi mà họ có nhiều data họ xem có đúng không và có cần phải thay đổi giải pháp đó không. Điểm mạnh ở Rockset là đưa data cho khách hàng 1 cách realtime, tức là hiện giờ để xây dựng 1 cái hệ thống để đọc được data từ phản hồi nhiều khi rất là khó là 1, cái thứ 2 là mình phải đợi 1-2 ngày để data có thể đến được, và 1-2 ngày cũng không còn là tức thời nữa, nên điểm mạnh của Rockset là khi mà data đến được luôn, data như thế nào, cái quyết định của mình có đúng hay không, mình có thể thay đổi quyết định 1 cách tức thời.

Hệ thống của anh sử dụng cloud nào và nó có khác gì với tailer vật lý hay không?

Hiện giờ ROckset sử dụng AWS và Kubernetes chạy trên AWS, và lý do mình dùng Kubernetes là tại vì sau này mình muốn gửi sang google cloud mình có thể chuyển sang 1 cách dễ dàng.
Lý do mình sử dụng cloud vật lý là vì economics của cloud giờ nó đã rất là khác rồi, giả sử bây giờ mà mình cần chạy 1 computation mất 100 tiếng chẳng hạn thì mình có thể thuê 1 trăm máy và mình chạy mất 1 tiếng thay vì ngược lại, và khi mình thuê xong và trả lại cho AWS mình chỉ trả cho 1 tiếng đó thôi nó sẽ rẻ hơn rất là nhiều. Đó là lý do mà Rockset build for the cloud, tức là khi khách hàng cần bao nhiêu, mình thuê bấy nhiêu đó máy hỗ trợ khách hàng, sau đó mình sẽ tắt đi để tiết kiệm chi phí, như thế rất là tiết kiệm cho khách hàng cũng như Rockset.

Anh hay dùng ngôn ngữ nào và anh có thể tiết lộ về Database?

Ở Rockest có 2 phần, 1 phần người ta gọi là injection đưa data từ khách hàng vào Rockset, phần đó mình dùng Java, còn phần Leaf và Aggregator mà mình nói thì database mình dùng C++, query khi dùng C++, nó sẽ nhanh hơn và rockset được build on top of RocksDB và vì có anh engineer, ngày xưa là 1 trong những người viết ra RocksDB cũng như về HDFS. Hiện giờ anh đang làm CTO của Rockset, nên cũng là lý do RS dùng RocksDB.

Đâu là đặc điểm khác nhau giữa data stream, data lake và data warehouse?

Thực ra nó chỉ là nơi mà mình chứa dữ liệu thô, tức là dữ liệu từ khách hàng, dữ liệu từ những cái mà mình thu thập, nó nằm hết vào data lake. Còn data warehouse họ lấy data từ data lake sau đó họ chế biến để họ xử lý sao cho query 1 cách hiệu quả nhất. Tức là lấy dữ liệu thô sao đó làm sau cho nó có thể query được. Còn stream là 1 khái niệm mới khác hẳn, mình có thể tưởng tượng nó như 1 luồng thông tin luôn luôn đi vào chẳng hạn, cái data lúc nào cũng vào người ta thường đưa data stream vào data lake, sau đó rồi datawarehouse sẽ mỗi ngày lấy data từ data lake đấy họ xử lý lại và data sẽ được query và data ngày hôm sau sẽ được query từ ngày hôm trước.

Anh có thể giải thích vai trò của data source là gì? Vì sao Rockset lại lựa chọn các data source như Amazon S3, Amazon Kinesis, Amazon DynamoDB, Apache Kafka, Google Cloud Storage, Amazon Redshift? Ưu điểm của mỗi loại này là như thế nào?

Data source mình chỉ hiểu đơn giản nó là nơi người ta để data thôi, nó cũng có ưu và khuyết điểm nhất định, nhưng nhìn chung lý do Rockset support những cái datasource này là rất nhiều data scientist họ thích dùng SQL, nhưng những data source này lại không support SQL thế nên rockset muốn họ khả năng query sql trên những data source này cho công việc họ đơn giản hơn, bởi vì data scientist xem sql như ngôn ngữ mẹ đẻ của họ vậy.

Query Lambdas của Rockset là gì?

Cơ bản nó chỉ là 1 cái hàm nằm trên Rockset thôi, và nó có nhiều tham số, bình thường 1 lập trình viên khi họ lập trình phần mềm của họ mà phải cần query sql, họ phải viết cái sql vào code page của họ nên là thành ra nó có khá nhiều bug, khiến nó cũng khó làm hơn bây giờ lập trình viên họ chỉ cần để sẵn cái sql query nằm trên rockset và họ cho Rockset cái tên cũng như tham số và rockset sẽ tự động biết chạy những cái sql nào và gửi trả lại đúng cái kết quả đó chứ không cần phải viết sql trong phần mềm của họ nữa. 

Một số công nghệ hữu ích trên thế giới mà ở Việt Nam ít người sử dụng là gì? (chẳng hạn như Kafka)

Nó cũng mới phát triển gần đây thôi, mình có thể hiểu sơ rằng Kafka là 1 luồng thông tin nó rất đáng tin cậy, tức là thông tin khi mình đã viết vào Kafka rồi chắc chắn thông tin nó ở đó, nên khi mà mình đọc Kafka mình sẽ thấy cái lượng thông tin đó.

Công dụng của Kafka là gì, thí dụ mình có 2 data center 1 cái ở TPHCM và 1 cái ở Hà Nội, và mình muốn 2 cái data center này có data giống hệt nhau tại vì khi mà mình hỗ trợ khách hàng ở TPHCM hay ở Hà Nội mình muốn là 2 data giống nhau, Kafka là cái để cho khách hàng có thể copy 1 data từ nơi này sang nơi khác 1 cách rất thuận tiện, và giả sử khi mà mình copy giữa chừng mà máy mình hỏng hay sao đó và khi mình restart có thể bắt đầu tiếp ngay từ chỗ đó chứ không cần phải bắt đầu lại từ đầu. Đó là công dụng của Kafka.

Và có 1 công dụng nữa mà mình thấy là gần đây có rất nhiều doanh nghiệp hiện giờ họ dùng 1 cái gọi là hybrid cloud, nó có nghĩa là 1 phần hệ thống nằm trong server vật lý ở công ty họ, và 1 phần nằm trên cloud, nhiều khi di chuyển dữ liệu giữa 2 phần này họ hay dùng Kafka vì nó rất đáng tin cậy. 

Anh có nhận xét thế nào về khác biệt trong tư duy, cách tổ chức và xây dựng hệ thống của Việt Nam và các công ty hàng đầu trên thế giới?

Mình chưa có cơ duyên làm việc ở các công ty công nghệ ở Việt Nam, nên mình chỉ có kinh nghiệm ở một vài công ty công nghệ ở Mỹ. Đương nhiên mỗi công ty công nghệ đều có văn hoá xây dựng hệ thống khác nhau, nhưng nhìn chung đều rất data-driven, dựa trên data để tìm ra điểm khắc phục hệ thống. 

Công ty chia ra nhiều nhóm nhỏ, mỗi nhóm làm 1 phần đặc trách, và coi các nhóm khác như khách hàng của mình. Mỗi lần hệ thống có vấn đề đều được phân tích kỹ lưỡng, tìm ra nguyên nhân cũng như làm sao để điều đó không xảy ra lần sau.

Cái mình học được lớn nhất là, khi hệ thống lớn như thế, cái gì có thể hỏng chắc chắn sẽ hỏng. Kỹ sư phải xây dựng hệ thống làm sao mà nếu 1 vài máy hệ thống  bị hỏng bất cứ lúc nào, hệ thống vẫn phải chạy một cách trơn tru.

Từng là Intern tại Google, Microsoft và Facebook nhưng đâu là lý do khiến anh dừng chân?

Mỗi công ty đều có cái hay riêng, và bản thân mình cũng học được nhiều điều khác nhau ở từng công ty. Cá nhân mình thích trải nghiệm ở Facebook nhất, cũng như cảm thấy ở Facebook mình sẽ được trải nghiệm ở nhiều vị trí và nhóm khác nhau nên sẽ học được nhiều hơn.

Một văn hóa mình thích ở Facebook là move fast – tức là nếu cần làm gì thì làm luôn, chứ không cần phải đợi cấp trên ra chỉ thị. Quyết định rất nhanh. Đương nhiên cũng có cái hay và cái dở, nhưng mà mình nghĩ điều này giúp mình làm việc hiệu quả hơn rất nhiều.

Facebook cũng có cái scale mà mình muốn được thử sức nữa, vì lượng người dùng và data rất lớn.

Theo em biết, Software Engineer không chỉ đơn thuần là coder hay programmer, mà còn cần biết thu thập dữ liệu, cân bằng, khắc phục rủi ro, cũng như là về tư duy, tối ưu hóa trình duyệt. Thì theo anh vị trí Software Engineer ở từng công ty khác nhau như thế nào?

Công việc software engineer của mình nhìn chung có 2 phần: 1 là quản trị hệ thống của nhóm mình và 2 là code cho dự án mà mình đang làm.

Phần 1 thường mình có setup alert cũng như dashboard. Khi có chuyện sẽ được thông báo qua điện thoại, rồi mình lên dashboard cũng như đọc log của cái hệ thống để xem chuyện gì đang xảy ra, cũng như cách khắc phục. Nếu không khắc phục được mình sẽ gọi ai đó trong cái nhóm khác có liên quan để giúp.

Phần 2 chiếm chủ yếu thời gian của mình. 

Các dự án được lập ra tùy vào mục tiêu của nhóm. Thông thường khi bắt đầu 1 quý, nhóm sẽ họp lại để nghĩ xem mục tiêu là gì và cần làm gì cho mục tiêu đó.

Sau đó chia ra làm nhóm nhỏ hơn, và chia việc nhau ra làm. Code xong đưa lên để review, và sau khi review xong sẽ submit, và 1 tuần 2 lần sẽ launch code mới ra production. Công ty mình launch như vậy để lỡ có bug catch nhanh và revert nhanh, cũng như mỗi lần push không có quá nhiều patch để push.

Anh hãy chia sẻ quá trình tôi luyện như thế nào để có thể có vị trí như ngày hôm nay? 

Hè năm 2, mình rất may mắn (gần như là trúng xổ số) được thực tập tại nhóm quản lý MySQL ở Google. Ở đó mình được làm việc với những kỹ sư hàng đầu về database. Từ dịp đó, mình cảm thấy rất thích mảng hệ thống cơ sở dữ liệu. Năm 3 mình thực tập ở nhóm xây dựng Windows 10 ở Microsoft, và nhóm cơ sở dữ liệu thời gian ở Facebook. Mỗi lần thực tập mình đều học được 1 mảng khác nhau, nhưng đều về hệ thống máy tính. 3 lần đó giúp mình có kiến thức về C++, cũng như làm sao để xây dựng hệ thống một cách hiệu quả khi phải nhận lượng data khổng lồ.

Sau khi tốt nghiệp, mình làm 3 năm rưỡi ở Facebook, ở khoảng 3, 4 nhóm khác nhau tại Facebook. Mỗi nhóm đều có đặc thù khác nhau, cho dù đều làm về cơ sở dữ liệu. Ví dụ nhóm Search, đặc thù dữ liệu gồm các post trên Facebook, lại khác nhóm TimeSeries, khi đặc thù dữ liệu chỉ là 1 chuỗi gồm thời gian và giá trị. 

Hơn nữa, mỗi nhóm lại có vấn đề riêng, có những tiêu chuẩn riêng. Ví dụ nhóm Search không cho phép thiếu bất cứ dữ liệu nào, nhưng nhóm TimeSeries ok với việc đó, nhưng phải chứa dữ liệu càng hiệu quả càng tốt. 

Điều này giúp mình học được nhiều dạng hệ thống khác nhau, cũng như cái hay và cái dỡ ở mỗi hệ thống.

Search là một công cụ không thể thiếu và mỗi user khi search thì lại có một kết quả riêng. Vì vậy người làm về search phải có sự tinh tế, nhạy cảm riêng. Anh có thể chia sẻ thêm hệ thống unicorn của Facebook khi anh còn đảm nhiệm vị trí search Infrastructure được không? 

Unicorn cũng khá là tương tự và giống với hệ thống của Rockset hiện giờ, tức là cũng có 3 phần: Tailer-Leaf-Aggregator architecture. Cốt lõi của unicorn gọi là inverted index, nghĩa là khi tìm một từ khóa, unicorn sẽ trả lại cho họ toàn bộ post liên quan đến từ khóa đó. Giả sử mình tìm kiếm Covid nó sẽ trả về hàng trăm, hàng ngàn post liên quan đến Covid. Ngoài phần đấy, unicorn còn có phần đặc biệt, đó là ranker. Giả sử khi mình tìm kiếm, mình không muốn kết quả trả về là một trăm, một nghìn post, mình chỉ cần 10 kết quả về covid thôi, và unicorn phải biết mình quan tâm đến cái gì, đối với riêng cá nhân mình chỉ quan tâm các bài post Covid liên quan đến bạn bè mình các tổ chức y tế đáng tin cậy, và unicorn phải biết được chuyện đó và đưa lại kết quả những bài post mà mình quan tâm, đó là điểm đặc biệt của unicorn, họ phải rank được các bài post đây mà tìm được cái nào relevant nhất đối với người tìm, đó là cái hay của unicorn.

Anh có vẻ ưu tiên về C++, có phải anh luôn tin tưởng và nhìn nhận tiềm năng của nó trong tương lai hay không? Và anh có thể chia sẻ khán giả về một dự án thành công nhờ vào C++ được không? 

Bao nhiêu dự án những năm nay mình cũng chỉ dùng C++, ở 3 công ty mình làm họ đều sử dụng C++ cho cơ sở dữ liệu của họ. Lý do mình cảm thấy mình thích C++ là vì nó rất là nhanh, chạy không cần run time hay gì hết, đó là điểm mạnh của C++. Và C++ giúp cho người ta rất là nhiều option để optimize ngôn ngữ của mình, code của mình. Nhưng mà vì họ có quá nhiều option thế nên dễ dẫn đến người dùng dùng sai cách. Khi dùng C++ sai sách dễ dẫn đến phần mềm của mình bị crash và dễ bị nhiều bug; đó là điểm mạnh và điểm yếu của C++, điểm mạnh rất là nhanh nhưng điểm yếu lại rất khó dùng. Mình thấy nhiều hệ thống hiện giờ dùng C++ rất nhiều nên mình nghĩ tương lai rất là sáng sủa. 

Làm thế nào để làm một big data, data thế nào thì được gọi là big, có phải những công ty lớn trên thế giới như Google, Facebook, hay chính phủ Trung Quốc mới có thể sở hữu big data.

Theo mình đây chỉ là tương đối. Đứng về quan điểm của quản trị viên của hệ thống, người ta quan tâm về “big” có một vài lý do sau:

1. Lượng data lớn dẫn đến số máy trong hệ thống phải lớn. Điều này có nghĩa là việc 1 trong những máy đó có vấn đề đi từ “có thể” lên “chắc chắn”. Hệ thống càng lớn thì vấn đề càng đến thường xuyên. Thế thì câu hỏi đặt ra là làm sao để xây dựng 1 hệ thống mà một vài thành phần trong hệ thống có vấn đề, nhưng cả hệ thống vẫn hoạt động bình thường.
2. Nhưng một góc nhìn khác là số lượng dữ liệu phải so với tài nguyên hệ thống là bao nhiêu. Lượng dữ liệu lớn đương nhiên dẫn đến lượng tài nguyên hệ thống khổng lồ. Nhưng như thế thì không ổn cho các doanh nghiệp, tại vì tài nguyên hệ thống là không hề rẻ. Thế nên câu hỏi đặt ra cho các quản trị viên hệ thống là, làm sao để quản lý lượng dữ liệu đó mà không dùng quá nhiều máy. Ví dụ như, ngày trước mình ở Facebook, hệ thống mình quản lý cực kỳ to, nhưng Facebook là một công ty khổng lồ, và mình xin bao nhiêu máy họ cũng cho (đương nhiên trong mức vừa phải). Bây giờ mình sang công y nhỏ hơn, lượng dữ liệu nhỏ hơn nhiều, nhưng lượng tài nguyên hệ thống còn nhỏ hơn gấp nhiều lần, cái khó khăn là làm sao để quản lý lượng dữ liệu đó với cái mình đang khó.

Thế nên, mình nghĩ cái mình nên quan tâm không phải là lượng dữ liệu lớn bao nhiêu, mà là làm sao để hệ thống của mình hoạt động hiệu quả, không phung phí tài nguyên, và có thể chịu được vấn đề khi mà một vài thành phần trong hệ thống đó có vấn đề.

Vậy anh có thể trình bày những kỹ thuật đặc trưng để duy trì hệ thống scale lớn như vậy được không? 

Ở đây mình có thể hơi đi sâu về chuyên môn. Thông thường bài toán scaling có 2 mặt: 1 là scale từng máy một, tức là làm cho mỗi cá nhân từng thành phần hiệu quả hơn, và 2 là làm cho hệ thống hiệu quả hơn. Tương tự như trục tung và trục hoành trong toán học.

Trục tung tức là từng máy hiệu quả hơn, thường nhiều khi người ta có thể dùng chip mạnh hơn, ít điện năng hơn, chọn máy có nhiều RAM/SSD hơn. Nhưng trục này có 1 điểm bất lợi là mình chỉ có thể nâng cấp máy tính của mình đến một mức nào đó, vì những con chip mạnh thường đắt hơn rất nhiều so với hiệu năng nó mang lại.

Trục hoành là tăng số lượng máy. Nhưng điều này không phải cứ cho thêm máy là được. Ở một vài hệ thống mình đang làm, cho thêm máy chẳng khác nào đổ dầu vào lửa, vì cho thêm máy có nghĩa là số lượng data chạy qua network nhiều hơn, khả năng 1 máy hỏng cao hơn, dẫn đến vấn đề của cả hệ thống. Muốn đạt được điều này (hay từ chuyên môn là horizontal scalability), hệ thống cần phải được thiết kế đúng.

Một phương pháp mình hay dùng đó là khi service đang chạy, mình sẽ xem cái CPU profile, để xem phần nào của service đang chậm, hoặc tốn nhiều tài nguyên hơn mức cần thiết, và sau đó hiểu phần đó làm gì, và tìm ra phương pháp để làm phần đó nhanh hơn.

Lời khuyên khi chinh phục lĩnh vực Solution Architect

Theo anh, những bạn có tuýp người như thế nào thì sẽ phù hợp với lĩnh vực này? 

Thực ra không có một tuýp người nhất định trong lĩnh vực này, lĩnh vực này khá là open và rất nhiều tuýp người có thể làm trong lĩnh vực này. Khi mình nhìn lại công việc của mình  mình thấy nó cũng không khác gì nhiều công việc của những người khác, tức là mình có những vấn đề thế này, và mình có một vài solution thế này, và thế là làm sao để mình chọn ra solution, mỗi solution có điểm hay điểm dở, nó giúp giải quyết vấn đề này nhưng cũng giúp tạo ra vấn đề khác, và mình chọn solution nào cho đúng thôi. Mình nghĩ ai thích giải quyết vấn đề technical đều có thể làm trong lĩnh vực này.

Để có được vị trí trong các tập đoàn công nghệ lớn như Google, Facebook hay Microsoft, mình có điểm nào nổi trội để thu hút và hấp dẫn các nhà tuyển dụng?

Cái đầu tiên mình nghĩ là giá trị mình đem lại cho công ty là gì. Mình đặt mình vào vị trí một nhà tuyển dụng, họ tìm người để làm gì, thứ nhất họ tìm người  giải quyết vấn đề giỏi, bình thường họ không tìm những người kiểu technology này, technology kia; họ không làm như thế vì mỗi công ty họ có technology riêng của họ.

Cái thứ hai là họ muốn biết kinh nghiệm của mình có liên quan đến vấn đề họ gặp phải không. Giả sử họ tìm thấy một ứng viên đã giải quyết những vấn đề tương tự vấn đề họ đang gặp, đó là một ứng viên tuyệt vời. Gần đây mình có nhận được một vài resume của nhiều bạn, cái mình cảm thấy được là các bạn đang cố cover rất nhiều technology đấy, mình sử dụng technology này cho dự án này, sử dụng technology kia cho dự án kia, các bạn muốn chứng minh có kinh nghiệm rất nhiều technology, nhưng cái nhà tuyển dụng quan tâm muốn biết bạn có phải là người giải quyết vấn đề tốt hay không, mình nghĩ các bạn nên tập trung vào bạn làm dự án gì, vấn đề các bạn giải quyết trong dự án đó là gì và kết quả dự án ấy như thế nào. Khi nhà tuyển dụng thấy được bạn là kỹ sư giỏi, có khả năng giải quyết vấn đề rất là khó, và nhiều khi vấn đề đó chính là vấn đề mà họ đang gặp phải, bạn chính là candidate tuyệt vời cho nhà tuyển dụng, mình nghĩ đó là cái mình góp ý đến các bạn khi nộp resume đó là đổi resume để tập trung hơn vào dự án bạn đang làm và show được kết quả các bạn đã làm như thế nào.

Anh có thể chia sẻ những tips nho nhỏ hoặc mẹo vặt giúp chinh phục công ty công nghệ ở Mỹ không? 

Cá nhân mình nghĩ các bạn lập trình viên Việt Nam hoàn toàn đủ khả năng làm cho các công ty công nghệ ở Mỹ. Các bạn lập trình viên Việt Nam thực ra rất là giỏi, cái mình cảm thấy rào cản lớn nhất không liên quan đến năng lực mà đó là pháp lý, chi phí. Giả sử để có được visa đi làm ở Mỹ khá là khó, hoặc để phỏng vấn ở các công ty Mỹ họ sẽ đưa ứng viên đến tận headquarter để phỏng vấn trực tiếp. Vì chi phí đó khá lớn nên nhiều công ty không muốn đánh cược vào 1 thí sinh họ chưa chắc đã nhận. Nên thường nếu các bạn có referral từ những người đã làm bên này sẽ giúp cơ hội được phỏng vấn và nhận cao hơn nhiều.

Xin được cảm ơn những chia sẻ rất tâm huyết từ anh Hiếu, hy vọng qua bài viết này các bạn lập trình viên càng hiểu hơn về vai trò của một software engineer, hay “bỏ túi” những bí kíp giúp ứng tuyển các công ty công nghệ tại Mỹ. Hẹn gặp lại các bạn kỳ sau và đừng quên đón đọc “Chuyên gia nói” cùng Station D nhé.

Tham khảo tuyển dụng software engineer lương cao tại Station D