Hiếu Phạm – Software Engineer tại Rockset: “Vì sao chọn start-up sau Facebook?”
Ngày trước ở Facebook, hệ thống quản lý cực kỳ lớn, tôi xin bao nhiêu máy họ cũng cho (đương nhiên trong mức vừa phải). Bây giờ sang công ty 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 đó.
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.
* Chào anh Hiếu, trước tiên anh hãy giới thiệu về bản thân mình nhé.
Hiện giờ tôi là Senior Software Engineer ở công ty Rockset, công ty làm về realtime database, tôi đã đi làm được 4 năm từ sau khi ra trường. Đây là công việc thứ 2 của tôi, và công việc đầu tiên là ở tập đoàn Facebook. Trước khi ra trường tôi cũng nhờ may mắn nên được 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 lớn như là RocksDB, HDFS hay Gmail.
* Rockset là công ty 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, ví dụ như DynamoDB, Kafka, hay S3 của Amazon hoặc Hoogle course query của Google. Một điểm hay của Rockset đó chính là realtime, có nghĩa là khi có data sẽ query được ngay, không phải đợi 1 đến 2 ngày.
Thêm nữa, khi khách hàng dùng Rockset không cần phải tune query, không phải tạo index hay data rockset mà Rockset sẽ tự động làm cho tới query nhanh hơn. Tôi chỉ làm ở Rockset được vài tháng và dự án mà tôi thích nhất hiện giờ là giúp cho hệ thống Rockset chứa được hình nhiều thông tin hơn với mức chi phí rẻ hơn. Vì chứa nhiều thông tin hơn AWSB nên sẽ khá là lag, vì vậy công việc của tôi 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 dữ liệu đã được xử lý đó vào leaf, leaf là nơi chứa dữ liệu đó để cho aggregator query một cách hiệu quả. Sau khi aggregator query những dữ liệu này 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, và thật ra architecture này được dùng ở rất nhiều nơi.
Ngày xưa khi tôi làm ở mảng 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 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 giống nhau.
* Data-driven app là gì? Có ý nghĩa như thế nào đối với các doanh nghiệp?
Khi phải đưa ra quyết định, các doanh nghiệp phải phân tích nhiều về data mới biết được vấn đề hiện tại là gì và giải pháp nên là thế nào. Khi có nhiều data, họ phải xem có chính xác 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 một cách realtime, tức là hiện giờ để xây dựng hệ thống để đọc được data từ phản hồi nhiều khi rất là khó, ngoài ra 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. Điểm mạnh của Rockset là data đến được luôn, data như thế nào, quyết định của mình có đúng hay không, có thể thay đổi quyết định một 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. Lý do dùng Kubernetes là nếu sau này chúng tôi muốn gửi sang Google cloud thì công chuyện sẽ nhẹ nhàng hơn.
Lý do cho việc sử dụng cloud vật lý là vì economics của cloud hiện nay đã rất khác. Giả sử bây giờ bạn cần chạy 1 computation mất 100 tiếng chẳng hạn, có thể thuê 100 máy và chạy mất 1 tiếng thay vì ngược lại, khi thuê xong và trả lại cho AWS bạn chỉ phải trả cho 1 tiếng đó thôi, sẽ rẻ hơn rất nhiều. 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ế sẽ tiết kiệm cho khách hàng cũng như Rockset.
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ế sẽ 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 đó tôi dùng Java; còn phần Leaf và Aggregator thì database tôi dùng C++. Query khi dùng C++ sẽ nhanh hơn và Rockset được build on top of RocksDB vì có một anh engineer, ngày xưa là một 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, đó cũng là lý do Rockset dùng RocksDB.
* Có một khái niệm mà trước đây rất ít khi thấy xuất hiện trên thị trường Việt Nam, đó là data stream. Vậy đâ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 để chúng ta chứa dữ liệu thô, tức là dữ liệu từ khách hàng, từ thu thập của team, nó nằm hết vào data lake. Từ data lake rút được data warehouse, sau đó chế biến 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, bạn 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. Người ta thường đưa data stream vào data lake, sau đó data warehouse mỗi ngày sẽ lấy data từ data lake rồi sẽ được query; và data ngày hôm sau sẽ được query từ ngày hôm trước cứ tiếp tục như vậy.
* 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 chỉ hiểu đơn giản là nơi để chứa data thôi, nó cũng có ưu và khuyết điểm nhất định. Nhìn chung lý do Rockset support những data source 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 nên Rockset muốn query SQL 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 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 lập trình phần mềm cần query SQL, họ phải viết SQL vào code page của họ vì vậy mà nó có khá nhiều bug, ít nhiều cũng khiến khó làm hơn. Bây giờ lập trình viên chỉ cần để sẵn SQL query nằm trên Rockset, cho Rockset một cái tên cũng như tham số thì Rockset sẽ tự động biết chạy những 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)
Có thể hiểu sơ rằng Kafka là 1 luồng thông tin rất đáng tin cậy, tức là khi chúng ta đã viết thông tin vào Kafka rồi chắc chắn chúng sẽ tồn tại ở đó.
Ví dụ tôi có 2 data center, 1 ở TP.HCM và 1 ở Hà Nội, bất kể hỗ trợ khách hàng ở TP.HCM hay ở Hà Nội tôi muốn data đều 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 một cách rất thuận tiện. Thêm nữa giả sử khi đang copy giữa chừng mà bị gián đoạn do máy hỏng, nhưng nếu restart được thì có thể tiếp tục chạy 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, tôi thấy gần đây có rất nhiều doanh nghiệp hiện giờ dùng hybrid cloud, 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?
Tôi chưa có cơ duyên làm việc ở các công ty công nghệ ở Việt Nam, nhưng đươ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 và 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 tôi 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 nếu có một vài máy hệ thống bị hỏng đột ngột thì 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 tại Facebook cũng như gắn bó trong hơn 3 năm?
Mỗi công ty đều có cái hay riêng, và bản thân tôi cũng học được nhiều điều khác nhau ở từng công ty. Cá nhân tôi thích trải nghiệm ở Facebook nhất, cũng như cảm thấy ở Facebook tôi 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 tôi thích ở Facebook là move fast – tức là nếu cần làm gì thì làm ngay 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à chưa hay, nhưng tôi nghĩ điều này giúp chúng tôi làm việc hiệu quả hơn rất nhiều.
Facebook cũng có cái scale mà tôi 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 tôi 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 tôi có setup alert cũng như dashboard. Khi có chuyện sẽ được thông báo qua điện thoại, sau đó sẽ lên dashboard cũng như đọc log của hệ thống để xem chuyện gì đang xảy ra, cũng như tìm 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 cũng trải qua nhiều vị trí về chuyên môn, nhất là mảng search, có thể kể đến công cụ truy vấn chuỗi thời gian hay cơ sở dữ liệu chuỗi thời gian. Anh có thể chia sẻ quá trình tôi luyện như thế nào để có thể có vị trí như ngày hôm nay?
Mùa hè sinh viên năm 2, tôi 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. Ở đó tôi được làm việc với những kỹ sư hàng đầu về database. Từ dịp đó, tôi cảm thấy rất thích mảng hệ thống cơ sở dữ liệu. Năm 3 tôi 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 tôi đề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, tôi làm 3 năm rưỡi ở Facebook, ở khoảng 3, 4 nhóm khác nhau. Mỗi nhóm đều có đặc thù riêng, 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 lại ổn 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 tôi học được nhiều dạng hệ thống khác nhau, cũng như cái hay và cái chưa hay ở 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. Ví dụ như Facebook chẳng hạn, hàng ngày có hàng nghìn tỷ edges với một tỷ user với hàng ngàn commodity server, vì thế Elasticsearch sẽ không bao giờ đủ. Vì thế 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 khá là tương tự 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 bạn toàn bộ post liên quan đến từ khóa đó. Giả sử khi 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 tìm kiếm, bạn không muốn kết quả trả về là một trăm, một nghìn post mà chỉ cần 10 kết quả, và unicorn sẽ biết bạn quan tâm đến cái gì. Đối với riêng cá nhân tôi 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 relevant nhất, đó là điểm đặc biệt của unicorn.
* Như anh có trao đổi thì 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ẻ với khán giả về một dự án thành công nhờ vào C++ được không?
Bao nhiêu dự án trong những năm nay tôi cũng chỉ dùng C++, ở 3 công ty tôi làm họ đều sử dụng C++ cho cơ sở dữ liệu của họ. Lý do tôi thích C++ là vì nó nhanh, không cần run time hay gì khác. C++ cũng hỗ trợ cho người sử dụng rất nhiều option để optimize ngôn ngữ, code. Tuy nhiên vì 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 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. Tôi thấy nhiều hệ thống hiện giờ dùng C++ rất nhiều nên tôi nghĩ tương lai của C++ sẽ rất sáng sủa.
* Hiện nay em có nghe một luồng tranh cãi 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? Anh nghĩ như thế nào về quan điểm này?
Theo tôi đâ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” theo một vài lý do sau:
Việc 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 hoạt động hiệu quả, không phung phí tài nguyên, và có thể chịu được áp lực khi mà một vài thành phần trong hệ thống có vấn đề.
- 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à rủi ro 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.
- 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 lớn mà không dùng quá nhiều máy. Ví dụ như, ngày trước tôi ở Facebook, hệ thống tôi quản lý cực kỳ lớn, nhưng Facebook là một công ty khổng lồ, và tôi xin bao nhiêu máy họ cũng cho (đương nhiên trong mức vừa phải). Bây giờ sang công ty 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 đó.
Thế nên, tôi nghĩ việc 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 hoạt động hiệu quả, không phung phí tài nguyên, và có thể chịu được áp lực 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 tôi 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; 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 tôi đ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 tôi hay dùng đó là khi service đang chạy, tôi sẽ kiểm tra CPU profile để biết được 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ì rồi tìm ra phương pháp để làm nó nhanh hơn.
* 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, có phải là những bạn thích giải quyết vấn đề theo technical hay những người thích đưa ra giải pháp cho những vấn đề phức tạp?
Thực ra lĩnh vực này khá là open và rất nhiều tuýp người có thể làm việc được trong lĩnh vực này. Khi tôi nhìn lại công việc của mình, tôi thấy nó cũng không khác gì nhiều so với công việc của những người khác. Tức là tôi có những vấn đề thế này, và tôi cũng 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. Tôi 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 tôi nghĩ là giá trị mình đem lại cho công ty là gì. Hãy đặ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 tôi có nhận được một vài resume, cái tôi cảm thấy được là các bạn đang cố cover rất nhiều technology, 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 là bạn có phải là người giải quyết vấn đề tốt hay không.
Tôi nghĩ các bạn nên tập trung vào việc 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 đề 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. Vài lời 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 thực ra rất giỏi. Tuy nhiên thứ mà tôi cảm thấy là 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 ở Mỹ sẽ giúp bạn có cơ hội được phỏng vấn và khả năng được nhận sẽ 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 TopDev nhé.
* Nguồn: TopDev blog