Category: Dev’s Corner

Các bài viết nói lên cuộc sống, tâm tư, kinh nghiệm kỹ năng của Developer, một nguồn tài liệu hữu ích.

Startup tìm gì trong CV của bạn?

Post author By Gambaru
Post date 31 January, 2023
No Comments on Startup tìm gì trong CV của bạn?

Startup tìm kiếm điều gì trong CV của bạn?

Khi tích cực tuyển dụng, startup của chúng tôi nhận được 150 – 200 đơn đăng ký mỗi tháng. Tôi đọc từng cái một trong số chúng. Đôi khi, tôi nói chuyện với một ứng viên và thấy rằng những gì chúng tôi coi là điểm mạnh nhất của họ thực sự không được đưa vào CV của họ. Thỉnh thoảng, một ứng viên nói với tôi rằng họ không ngờ rằng CV của mình vẫn được con người sàng lọc – nếu họ biết, họ đã viết CV của mình theo cách khác.

Quá trình đánh giá CV gần như là một hộp đen đối với hầu hết các ứng viên. Và nó là như vậy bởi vì rất ít nhà tuyển dụng thảo luận công khai về điều này. Tôi nghĩ tôi nên bắt đầu cuộc trò chuyện.

“Resume” ở đây đề cập đến cả CV truyền thống và hồ sơ LinkedIn. Nếu LinkedIn của bạn đang được cập nhật và chứa tất cả thông tin bạn muốn chia sẻ, điều đó hoàn toàn ổn. Một số nhà quản lý tuyển dụng mà tôi biết ở các công ty khác thực sự thích xem LinkedIn hơn vì họ thấy thông tin họ cần nhanh hơn (ví dụ: logo công ty, thời gian làm việc tại mỗi công ty). Tôi cũng đã thấy những ứng viên sử dụng trang web cá nhân của họ làm hồ sơ xin việc, điều này cũng có tác dụng đó chứ.

Cho dù bạn có quan tâm đến việc ứng tuyển vào công ty khởi nghiệp của chúng tôi hay không, tôi hy vọng rằng quan điểm của tôi có thể làm sáng tỏ những gì đang xảy ra ở phía bên kia bàn đàm phán và cách tạo một bản lý lịch giúp bạn nỗ lực hết mình, không chỉ với chúng tôi, mà còn với các công ty khác. Hãy cẩn thận: Mỗi công ty tuyển dụng khác nhau. Những gì phù hợp với chúng tôi có thể không phù hợp với các công ty khác.

Tìm kiếm việc làm rất mệt mỏi và đôi khi giống như một phát súng trong bóng tối. Tôi ước nhiều công ty sẽ minh bạch hơn về những gì họ đang tìm kiếm để các ứng viên có thể quyết định xem họ có phù hợp hay không trước khi ứng tuyển.

Cách tiếp cận tổng thể

Các công ty khởi nghiệp như chúng tôi và các công ty lớn, chẳng hạn như Google, tuyển dụng rất khác nhau. Do đó, điều hợp lý là một ứng viên nên ứng tuyển vào một công ty khởi nghiệp khác với cách họ ứng tuyển vào một công ty lớn.

Đây là những gì chúng tôi làm, có thể khác với những gì các công ty lớn làm.

1. Chúng tôi không sử dụng hệ thống tự động để sàng lọc hồ sơ.

Chúng tôi đọc mọi CV. Điều này có nghĩa là rất nhiều thủ thuật bạn đã đọc về cách đánh bại quá trình sàng lọc tự động, chẳng hạn như đưa một số cụm từ mô tả công việc vào CV của bạn, lặp lại các từ khóa “hot”, điền vào CV của bạn bằng các số liệu ngẫu nhiên, v.v. chúng ta. Chúng thậm chí có thể gây hại khi bạn ứng tuyển vào những công ty như chúng tôi, bởi vì không gian trên CV được sử dụng cho những mánh khóe này là không gian bạn không sử dụng cho những thứ liên quan đến chúng tôi.

2. Chúng tôi tìm kiếm lý do để nói có

Đối với một công ty nhận được một lượng lớn hồ sơ (lớn hơn chúng tôi rất nhiều), họ sẽ cần một cách để nhanh chóng lọc ra các hồ sơ, hay còn gọi là cách nhanh chóng để từ chối. Ví dụ: thuật toán tự động của họ có thể từ chối một CV nếu nó thiếu một số năm kinh nghiệm nhất định hoặc thiếu một số từ khóa nhất định. Đối với chúng tôi, chúng tôi đánh giá từng ứng dụng một cách toàn diện và nếu ứng dụng của bạn thể hiện các khía cạnh mà chúng tôi đang tìm kiếm, như đã thảo luận trong bài viết này, thì chúng tôi muốn gọi điện để tìm hiểu thêm về bạn.

Tìm kiếm chuyên môn đã được chứng minh, không phải từ khóa

Khoảng 90% hồ sơ chúng tôi thấy có một danh sách dài các kỹ năng. Đây chỉ là một số ví dụ.

Ban đầu, tôi đã lúng túng về mục đích của danh sách này, bởi vì:

Nó không thuyết phục. Có một khoảng cách lớn giữa “nói rằng bạn biết điều gì đó” và “giỏi về điều đó”.
Nó có thể làm suy yếu CV của bạn. Ví dụ: nếu bạn xem xét các kỹ năng phổ biến như máy tính xách tay Jupyter và sử dụng lợi thế cạnh tranh của mình (lý do duy nhất để đưa chúng vào CV của bạn), tôi sẽ tự động cho rằng bạn không có lợi thế cạnh tranh nào khác.
Chuyên môn cần có thời gian để có được. Tôi nghi ngờ những người tự nhận mình là chuyên gia trong quá nhiều thứ.

Khi cố gắng tìm hiểu lý do tại sao, tôi đã tìm thấy vô số bài viết đưa ra các mẹo về cách đánh bại quá trình sàng lọc CV tự động. Các bài báo này cho rằng tại các công ty lớn nhận được nhiều hồ sơ xin việc, các nhà tuyển dụng đặt ra các quy tắc để hiển thị các hồ sơ có chứa các từ khóa nhất định. Các ứng viên, không chắc những từ khóa này là gì, điền vào CV của họ tất cả các từ khóa mà họ có thể nghĩ ra.

Đó là một chiến lược tồi để áp dụng tại các công ty khởi nghiệp như của chúng tôi. Chúng tôi không tìm kiếm từ khóa. Chúng tôi tìm kiếm chuyên môn đã được chứng minh. Dưới đây là một vài cách để thể hiện chuyên môn của bạn.

1. Chỉ ra cách bạn có được và sử dụng kỹ năng đó trong công việc của bạn

Hãy xem xét hai ứng viên này, cả hai đều đề cập đến Flink trong hồ sơ của họ. Bạn muốn nói chuyện với ai?

Ứng viên A có Flink là một trong 30 mục trên ô Kỹ năng kỹ thuật của họ.
Ứng viên B đã giải thích cách họ sử dụng Flink trong công việc trước đây của mình: “đã làm việc trên một nền tảng tính toán tính năng được xây dựng dựa trên Apache Flink, xử lý 100.000 sự kiện mỗi giây và phục vụ 10 mô hình ML khác nhau.”

Nếu trong cuộc phỏng vấn của chúng tôi, ứng viên B có thể cho tôi biết lý do tại sao họ chọn Flink thay vì các công cụ xử lý luồng khác, họ đã gặp phải vấn đề gì và họ muốn thấy những thay đổi nào trong Flink, thì tôi sẽ bị thuyết phục!

2. Chia sẻ kiến thức chuyên môn của bạn trên các kênh công khai như: câu trả lời của StackOverflow, đóng góp nguồn mở, bài báo, bài đăng trên blog

Dưới đây là một số ví dụ đã thuyết phục tôi về chuyên môn của ứng viên trong một số công nghệ nhất định:

Một ứng viên đã gửi cho chúng tôi hồ sơ StackOverflow của họ nơi họ đã trả lời hơn 100 câu hỏi về JavaScript.
Một người khác đã gửi cho chúng tôi danh sách các PR được hợp nhất của họ với PyTorch.
Một người khác đã gửi cho chúng tôi một bài đăng trên blog trình bày chi tiết chuyên sâu về X khiến nhóm của chúng tôi phải thốt lên: “Ồ, họ thực sự biết về X.”

Chúng tôi hiểu rằng không phải ai cũng có thời gian để đóng góp vào bài diễn thuyết công khai, vì vậy #2 là tùy chọn.

Tìm kiếm những người hoàn thành công việc

Rất nhiều người bị thu hút bởi một công ty khởi nghiệp vì tầm nhìn của nó: công ty khởi nghiệp này có thể trở thành cái gì trong 5 hoặc 10 năm tới. Tuy nhiên, khi bạn tham gia khởi nghiệp, điều thực sự quan trọng là việc thực hiện hàng ngày. Khi tôi còn ở Snorkel, Giám đốc điều hành của chúng tôi liên tục nói với chúng tôi: “Các công ty mới thành lập không phát triển nhanh hơn các công ty lớn chỉ vì họ là công ty mới thành lập. Các công ty khởi nghiệp di chuyển nhanh hơn bởi vì họ phải làm vậy.” Chúng ta phải hoàn thành công việc. Để có thể tiến nhanh, chúng tôi cần những người không ngại xắn tay áo và đương đầu với những thử thách khó khăn.

Có hai đặc điểm mà chúng tôi tìm kiếm để đánh giá liệu một ứng viên có thể hoàn thành công việc hay không: tính chủ động và tính kiên trì. Nếu bạn có kinh nghiệm chứng minh những điều này, vui lòng đưa chúng vào CV của bạn.

Khả năng khởi xướng

Để hoàn thành bất cứ điều gì, bạn cần phải bắt đầu nó. Có rất nhiều người có thể nhìn thấy một vấn đề, nhưng ít người sẵn sàng hành động để giải quyết vấn đề đó. Chúng tôi muốn những người, khi nhìn thấy một vấn đề, chủ động làm điều gì đó về vấn đề đó mà không cần chờ đợi để được nói. Chúng tôi tìm kiếm các sáng kiến mà ứng viên đã bắt đầu trước đó, chẳng hạn như:

Một câu lạc bộ sinh viên, một sự kiện, một nhóm, một dự án tại nơi làm việc. Một dự án mà bạn bắt đầu không nhất thiết phải là một điều gì đó mới mẻ. Các dự án như viết tài liệu hoặc cải thiện CI/CD hiện có cũng rất có giá trị.
Một công ty khởi nghiệp. Một nhà sáng lập nói với tôi rằng những người tuyển dụng tốt nhất của anh ấy là những người trước đây đã thành lập công ty, ngay cả khi công ty đó không thành công. Họ biết khoan.

Kiên trì

Khi chúng ta đã bắt đầu một việc gì đó, chúng ta cần kiên trì để hoàn thành nó. Một số tín hiệu của sự kiên trì mà tôi đã thấy:

Đóng góp hàng ngày cho GitHub trong cả năm.
Giỏi bất cứ thứ gì đòi hỏi nỗ lực nhất quán, ví dụ: một bậc thầy Kaggle, một bậc thầy cờ vua, một vận động viên chuyên nghiệp, v.v.
Trước đây đã từng tham gia một công ty khởi nghiệp sớm khác và bị mắc kẹt.

Tôi hơi do dự khi thấy những ứng viên thay đổi công việc quá thường xuyên, v.d. 5 công ty khác nhau trong 5 năm. Tôi hiểu rằng không phải công việc nào cũng suôn sẻ, vì vậy, đôi khi cần thiết, bạn vẫn có thể tiếp tục. Tuy nhiên, nhảy việc liên tục có thể ám chỉ rằng bạn cảm thấy nhàm chán hoặc dễ dàng bỏ cuộc. Một năm làm việc hầu như không đủ để đi sâu vào một không gian có vấn đề và có những đóng góp đáng kể.

Làm việc tại một công ty mới thành lập có thể rất khó khăn và chúng tôi không muốn ai đó tham gia rồi rời đi khi có dấu hiệu thử thách đầu tiên. Chúng tôi muốn ai đó ở bên cạnh và giúp chúng tôi vượt qua các giai đoạn khác nhau. Tôi hy vọng quá trình này cũng có thể cung cấp cho bạn một tập hợp kinh nghiệm đa dạng để chuẩn bị cho bạn bất cứ điều gì bạn muốn làm sau này.

Tìm kiếm những quan điểm độc đáo

Các công ty khởi nghiệp như của chúng tôi tồn tại để giải quyết một vấn đề mà ít người khác có thể giải quyết. Điều này đòi hỏi chúng ta phải nhìn vấn đề từ góc độ mà hầu hết mọi người không làm. Vì lý do đó, chúng tôi không tìm kiếm những người có tư duy nhóm hoặc những người theo đuổi sự cường điệu. Chúng tôi tìm kiếm những người có thể mang lại một quan điểm độc đáo cho tập thể.

Quan điểm độc đáo của bạn có thể được thể hiện trong các lựa chọn nghề nghiệp/cuộc sống, bài viết, dự án phụ của bạn.

Gần đây, tôi đã có một hội thảo thảo luận về việc sàng lọc CV trên MLOps Discord của chúng tôi và Kyle Kranen, một kỹ sư deep learning cao cấp của NVIDIA, không khuyến khích các ứng viên liệt kê các dự án kém nổi bật trong CV của họ, vì chúng lấy đi không gian cho những thứ là thế mạnh độc đáo của bạn .

Các dự án này xảy ra khi ai đó chỉ đơn giản sao chép một giải pháp chung cho một dự án phổ biến – phân tích tâm lý, cảm tính của các tweet, giao dịch chứng khoán, chatbot – mà không có bất kỳ cách tiếp cận hoặc thông tin chi tiết mới nào. Tôi thấy chúng trong khoảng ⅓ hồ sơ chúng tôi nhận được. Những dự án này là tốt để thực hành. Bản thân tôi đã thực hành chúng khi tôi bắt đầu. Tuy nhiên, chúng sẽ không giúp bạn trở thành một ứng viên nổi bật.

Ví dụ về các dự án thú vị mà tôi đã thấy:

Một trang web cá nhân trông giống hệt MacOS.
Một công cụ CLI để tự động hoàn thành các lệnh bash của bạn.
Cánh tay robot làm matcha.

Quan tâm đến tác động chứ không phải những số liệu vô nghĩa

Gần đây, tôi đã hỏi trên LinkedIn về việc tại sao hồ sơ lại trở nên thiên về số liệu như vậy. Hầu như tất cả các CV mà tôi đã xem đều có đầy đủ các chỉ số. Số liệu là tốt khi chúng giúp nói lên một điểm. Tuy nhiên, nhiều số liệu trong số này khiến tôi bối rối hơn là ấn tượng. Ví dụ: đây là một số chỉ số thực tế mà tôi đã thấy:

Đã xây dựng mô hình dựa trên Máy biến áp đạt được độ chính xác 89% (không có thông tin về nhiệm vụ hoặc đường cơ sở)
Làm việc trên 15 tên miền khác nhau.
Đã tham gia hơn 300 bài đánh giá mã (không chắc điều này sẽ thể hiện điều gì. Nếu tôi thực hiện đánh giá mã một ngày, thì tôi chỉ mất một năm để đạt được con số này, điều này thực sự không nói lên nhiều điều.)

Mọi người đã nhanh chóng chỉ ra cho tôi: lời khuyên phổ biến nhất để viết CV là “định lượng tác động của bạn”, ví dụ: bạn đã tiết kiệm được bao nhiêu tiền cho công ty của mình, bạn đã thực hiện chương trình của mình nhanh hơn bao nhiêu. Do lời khuyên này, nhiều ứng viên đã nói với tôi rằng họ cần phải có các số liệu trong hồ sơ của mình. Đôi khi, khi không thể định lượng được tác động của mình, họ chấp nhận những gì họ có thể định lượng được.

Thật không may, không phải tất cả những gì có thể định lượng đều có tác động. Hiển thị số lượng đánh giá mã mà bạn đã tham gia, không có bất kỳ ngữ cảnh nào, không nói lên điều gì tâng bốc. Sẽ tốt hơn nếu bạn có thể chỉ ra cách học hỏi từ tất cả các bài đánh giá mã này có liên quan như thế nào đến vai trò mà bạn đang ứng tuyển: ví dụ: chúng đã giúp bạn trở thành một kỹ sư giỏi hơn như thế nào.

Làm rõ những đóng góp của bạn

Mọi người tìm việc nên làm cho CV của họ trông đẹp nhất có thể. Tôi đã nói chuyện với nhiều ứng viên không thoải mái khi nói về thành tích của họ, có thể là do khiêm tốn hoặc nhút nhát. Điều này đặc biệt phổ biến ở các ứng viên nữ mà tôi đã nói chuyện.

Mặt khác, tôi đã thấy nhiều ứng viên đi quá xa. Ví dụ: tuần trước, một ứng viên đã viết rằng họ có nhiều kinh nghiệm trong việc triển khai các hệ thống quy mô lớn nhờ một lần thực tập tại Amazon.

Thông thường, tôi thấy một ứng viên ghi công cho cả nhóm. Một ứng viên cho biết trong CV của mình rằng anh ấy “đã triển khai một mô hình dự đoán trực tuyến phục vụ 10 triệu người dùng hoạt động hàng ngày.” Trong cuộc phỏng vấn của chúng tôi, tôi phát hiện ra rằng anh ấy hoàn toàn không tham gia vào việc triển khai cũng như mở rộng dịch vụ dự đoán. Nhiệm vụ của anh ấy là sắp xếp dữ liệu từ một thùng S3. Rõ ràng, đây là một kỹ năng quan trọng, chỉ không phải là kỹ năng chúng tôi đang tìm kiếm. Chúng tôi đã nói rõ ràng rằng chúng tôi đang tìm kiếm kinh nghiệm trong việc triển khai các mô hình trong sản xuất. Cuộc phỏng vấn này là một sự lãng phí thời gian cho cả hai chúng tôi.

Số liệu mà chúng tôi muốn xem

Tôi quan tâm đến số liệu. Tôi đặc biệt đánh giá cao các số liệu được trình bày với hai thành phần:

Làm thế nào chúng có thể được gắn với các mục tiêu kinh doanh.
Đóng góp của bạn trong việc đạt được số liệu đó.

Dưới đây là một số số liệu mà chúng tôi thấy thuyết phục:

Là thành viên của nhóm 2 nhà khoa học dữ liệu sở hữu kỹ thuật tính năng cho hệ thống phát hiện gian lận. Đã thêm 200 tính năng mới, giúp giảm tỷ lệ dương tính giả từ 20% xuống 15%, trong khi vẫn giữ nguyên tỷ lệ âm tính giả.
Chiến lược bộ nhớ đệm được xây dựng bằng cách sử dụng bộ nhớ đệm cấp ứng dụng & Redis cho 2000 QPS, giúp giảm 50% thời gian phản hồi.

Ảnh chụp màn hình từ các CV được gửi đến phiên đánh giá CV của chúng tôi

Không phải tất cả các tác động đều có số liệu

Sửa lỗi hoặc giúp đỡ đồng nghiệp có tác động lớn nhưng khó đo lường. Đó là một tín hiệu tuyệt vời khi tác phẩm của bạn nhận được giải thưởng và sự công nhận, chẳng hạn như:

Giải thưởng nội bộ của công ty (ví dụ: thực tập sinh của năm, MVP, giải thưởng người sáng lập, chiến thắng hackathon)
Thăng chức, ví dụ: Tôi rất ấn tượng với một ứng viên đã đi từ nhà khoa học dữ liệu lên MLE cấp cao rồi trở thành MLE nhân viên trong vòng 4 năm.
Khuyến nghị tuyệt vời từ các đồng đội và người quản lý trước đó. Chúng tôi thực sự đã đưa ra lời đề nghị cho một ứng viên sau khi hai người giới thiệu của họ nói về việc ứng viên này đã giúp đỡ và cố vấn cho họ nhiều như thế nào.

Câu hỏi thường gặp

CV có phải là một trang không?

Trong cuộc phỏng vấn của chúng tôi, một ứng viên đã nói với tôi rằng anh ấy đã không đưa các dự án phụ vào CV của mình vì anh ấy lo lắng rằng điều đó sẽ khiến anh ấy vượt quá giới hạn một trang. Nói rõ hơn, tôi sẽ KHÔNG từ chối một ứng viên chỉ vì CV của họ dài hơn một trang.

Đề xuất giới hạn một trang là để giúp bạn ngắn gọn. Giống như nhà toán học người Pháp Blaise Pascal đã từng nói: “Tôi chỉ làm bức thư này dài hơn vì tôi không có thời gian để làm cho nó ngắn hơn.” CV của bạn càng dài thì càng có nhiều khả năng những điểm mạnh nhất của bạn sẽ bị chôn vùi trong những chi tiết ít quan trọng hơn.

Mục tiêu của CV không phải là thể hiện mọi thứ về bạn. Mục tiêu là nỗ lực hết mình để cho công ty thấy tại sao bạn lại là một sự bổ sung tuyệt vời cho đội ngũ của họ. Hiếm khi tôi thấy một ứng cử viên nào có thành tích tốt nhất lại không thể chứa đựng trong một trang giấy.

Nếu bạn có nhiều kinh nghiệm, bạn nên có nhiều phương án hơn để lựa chọn để làm nổi bật thế mạnh của mình. Một bản CV dài 3 trang mà không có bất kỳ tiêu điểm hay điểm nhấn nào cho thấy bạn thiếu khả năng phán đoán xem điều gì là quan trọng và thông tin ngắn gọn.

Điều mà tôi thấy khó khăn hơn nhiều đối với các ứng viên mới tham gia lĩnh vực này là phải có đủ thông tin để điền vào một trang.

Một số mẹo để rút ngắn CV của bạn

Tìm sự lặp lại và loại bỏ chúng. Ví dụ: bạn có cần liệt kê tất cả 5 dự án cá nhân của mình hay 3 dự án hàng đầu là đủ?
Loại bỏ kinh nghiệm không liên quan, ngay cả khi điều đó tạo ra những khoảng trống trong CV của bạn. Cá nhân tôi không quan tâm đến những khoảng trống – ai cũng cần thời gian để nạp lại năng lượng và giải quyết những vấn đề cá nhân.
Hầu hết các CV mà tôi đã xem có thể có các phần trình độ học vấn ngắn hơn.
Loại bỏ các kỹ năng phổ biến, ví dụ: git, sổ ghi chép, MS Word/Excel.
Tìm định dạng hiệu quả hơn, ví dụ: sử dụng nhiều cột.
Giảm cỡ chữ, lề trang.

Những gì để đưa vào CV của tôi nếu tôi chưa có kinh nghiệm?

Đây là một câu hỏi khó. Nếu bạn không có kinh nghiệm mà một vai trò cần, thì bạn viết gì trong CV của mình không quan trọng, vai trò đó sẽ không phù hợp với bạn.

Tuy nhiên, tôi đã bị ấn tượng bởi những ứng viên bù đắp cho sự thiếu kinh nghiệm của họ trong lĩnh vực của chúng tôi bằng những kinh nghiệm ấn tượng trong các lĩnh vực khác.

Cá nhân tôi đã từng được nhận thực tập tại một công ty khởi nghiệp, mặc dù tôi không có kinh nghiệm nào mà họ yêu cầu. Tôi đã liên hệ với Giám đốc điều hành để giải thích cho ông ấy những vấn đề mà tôi đã giải quyết trong quá khứ và cách những kỹ năng tôi có được có thể được chuyển giao cho những vấn đề mà công ty ông ấy đang giải quyết.

Đó là một cú sút xa, nhưng đó là một cú sút.

Tôi có cần thư xin việc không?

Thứ tự tôi đọc đơn xin việc: CV -> thư xin việc. Nếu bạn có kinh nghiệm và kỹ năng xuất sắc, chúng tôi muốn nói chuyện với bạn ngay cả khi bạn không có thư xin việc. Một số nhà tuyển dụng nói với tôi rằng họ không hề đọc thư xin việc.

Tuy nhiên, tôi đánh giá cao khi một ứng viên viết thư xin việc giải thích lý do tại sao họ muốn tham gia cùng chúng tôi và tại sao họ nghĩ rằng họ phù hợp với vai trò này. Đối với những ứng viên có quá trình chuyển đổi bất thường (ví dụ: chuyển từ nghề nghiệp khác sang học máy), thư xin việc cũng có thể là một nơi tuyệt vời để giải thích quá trình chuyển đổi của họ.

Nếu bạn viết một lá thư xin việc, hãy viết thật ngắn gọn. Thư xin việc không nhất thiết phải là PDF. Nó chỉ có thể là một email.

Nếu một thông tin quan trọng, hãy đưa nó vào CV của bạn thay vì thư xin việc. Đôi khi, các ứng viên đưa thông tin quan trọng vào email mà họ đã gửi đến địa chỉ email của nhóm chúng tôi, thông tin này có thể không được nhập chính xác vào hệ thống theo dõi ứng dụng của chúng tôi.

Mẹo linh tinh

Chung

Nếu bạn đang ứng tuyển vào một công ty khởi nghiệp nhỏ, chẳng hạn như dưới 20 người, hãy dành thời gian nghiên cứu những người làm việc tại công ty khởi nghiệp đó và gửi email trực tiếp cho họ.
Gửi CV của bạn dưới dạng PDF thay vì định dạng có thể chỉnh sửa như Microsoft Word hoặc Google Docs. Định dạng có thể chỉnh sửa có thể không hiển thị chính xác trên máy tính của người khác.
Nếu bạn có thể nhờ ai đó từng giám sát bạn nói về việc bạn tuyệt vời như thế nào, hãy đưa trích dẫn của họ vào CV của bạn. Trích dẫn từ bạn bè / gia đình không được tính.
Đừng sử dụng từ viết tắt trừ khi bạn biết chắc chắn khán giả của mình biết bạn đang nói về điều gì.

Liên kết công khai

Nếu bạn đã đóng góp cho các dự án nguồn mở, hãy bao gồm các liên kết đến PR hoặc thiết kế kiến trúc công cộng mà bạn tự hào nhất.
Nếu GitHub của bạn có nhiều repo, hãy ghim những cái quan trọng trên trang chủ của bạn (bạn có thể ghim tối đa 6). Bạn cũng có thể viết README để hướng dẫn khách truy cập của mình về những kho lưu trữ mà họ sẽ xem xét.
Không bao gồm liên kết đến liên kết GitHub của bạn nếu nó trống.
Nếu bạn có ấn phẩm, hãy liên kết tới hồ sơ Google Scholar của bạn.
Nếu bạn là đồng tác giả của một bài báo với nhiều tác giả, hãy in đậm tên của bạn trong danh sách tác giả.
Nếu bạn có nhiều thứ để thể hiện hơn mức cho phép của CV, hãy tạo một trang web cá nhân. Giả sử rằng bạn có kỹ năng mã hóa cơ bản, việc tạo một trang web cá nhân miễn phí bằng Trang GitHub là khá dễ dàng.

Giáo dục

Nếu bạn vẫn còn đi học, hãy đưa trình độ học vấn sớm hơn vào CV của bạn, vì nó giúp người sàng lọc CV của bạn biết bạn đang ở đâu và bạn đang tìm kiếm điều gì. Nếu bạn đã đi làm, hãy đặt kinh nghiệm làm việc của bạn lên hàng đầu.
Nếu bạn vẫn còn đi học, hãy liệt kê ngày tốt nghiệp dự kiến của bạn để các công ty biết khi nào bạn có thể bắt đầu làm việc toàn thời gian.
Nếu bạn đã làm việc hơn 2 năm, hãy xóa điểm trung bình và các môn học của bạn. Tôi quan tâm nhiều hơn đến kinh nghiệm làm việc của bạn.
Tương tự như vậy, các dự án khóa học chỉ nên được liệt kê nếu bạn nghĩ rằng chúng tốt hơn dự án khóa học trung bình.

Tài liệu về CV

Có rất nhiều tài nguyên về cách viết CV. Dưới đây là một số trong số chúng:

Reddit có một hướng dẫn tuyệt vời về CV kỹ thuật
Viết một bản CV tuyệt vời : Hướng dẫn công việc khởi nghiệp YC Ultimate
Các nhà tuyển dụng của Google cho biết việc sử dụng công thức X-Y-Z trong CV của bạn sẽ cải thiện khả năng bạn được tuyển dụng tại Google
Tại sao sàng lọc CV không hoạt động
Các công ty cần nhiều công nhân hơn. Tại sao họ từ chối hàng triệu hồ sơ xin việc? – WSJ

Kết luận

Viết CV là một quá trình chỉ diễn ra một lần: đó là nghệ thuật sắp xếp những gì bạn đã có theo cách giúp bạn nổi bật nhất. Thật khó để viết một CV tốt mà không có những thứ để đưa vào đó.

Xây dựng CV là một quá trình liên tục: liên tục cải thiện kinh nghiệm, kỹ năng, đề xuất, v.v. mà bạn có. Nếu bạn giỏi xây dựng, bạn thậm chí có thể không phải viết CV. Nếu công việc của bạn thu hút sự chú ý của các công ty, họ sẽ liên hệ với bạn.

Một vài người bạn nói với tôi rằng “xây dựng CV” có hàm ý xấu, vì nó có thể gợi ý rằng chúng ta chỉ nên làm những việc để đưa vào CV của họ và bỏ qua những việc quan trọng nhưng kém sáng sủa hơn như sửa lỗi hoặc giúp đỡ đồng nghiệp.

Điều chúng tôi thực sự tìm kiếm không phải là CV tốt nhất hay người xây dựng CV tốt nhất, mà là một thành viên trong nhóm, một người biết quan tâm. CV có thể không phải là công cụ hoàn hảo để thể hiện điều đó, và đó là lý do tại sao chúng ta sai lầm khi nói chuyện với người đó để tìm hiểu.

Nguồn: Huyền Chip (huyenchip.com)

Tags cv, resume

Dev's Corner

Vì sao họ không xài Software Framework của tôi?

Post author By Gambaru
Post date 23 December, 2022
No Comments on Vì sao họ không xài Software Framework của tôi?

Vì sao người ta không dùng software framework của bạn?

Hiệu ứng ban đầu rất tuyệt: Bạn nhận được hàng trăm sao bầu chọn trên GitHub và 50 lượt ủng hộ trên Reddit. Nhưng sau đó tăng trưởng bắt đầu bão hoà và rồi giảm xuống. Tại sao họ không xài software framework của bạn?

– Ba tháng trước –

“… và AI ngày nay hoàn toàn là về engineering. Bây giờ, chúng ta hãy kết thúc bài học tại đây. Nếu bạn thích kênh của chúng tôi, đừng quên…”

Bạn thở hổn hển, nhấn nút ‘tạm dừng’ trên Airpods của mình và dừng lại. Một khái niệm tuyệt vời vừa nảy nở trong tâm trí bạn:

“Mình cần xây dựng một AI framework!”, bạn thốt lên với chính mình, tràn đầy hứng thú và năng lượng đột ngột bùng nổ. Bạn tự hỏi sao mình chưa từng nghĩ về nó trước đây!

Tâm trí của bạn đang chạy đua, đặt ra các bước và chuyển các bộ phận cần thiết để đưa sản phẩm này thành hiện thực. Với đôi tay run rẩy, bạn vội vàng cởi giày chạy bộ, phớt lờ những giọt mồ hôi nhỏ đọng lại sau tai.

Thế giới xung quanh bạn đột ngột dừng lại: những chú chim ngừng hót líu lo; các xe ngừng bóp còi; những người chạy bộ khác biến mất. Nó giống như bạn đã được đưa ra khỏi sự hối hả và nhộn nhịp của thành phố, và bước vào một thế giới của khả năng và thành công.

Các ngón tay của bạn di chuyển dữ dội, vuốt và gõ vào điện thoại khi bạn gõ các ghi chú, ý tưởng và suy nghĩ ngẫu nhiên. Bạn mơ về các nhà đầu tư tiềm năng, các ứng dụng mới và tường thuật về lần ra mắt đầu tiên của bạn trên Hacker News và Product Hunt. Tim bạn đập thình thịch khi bạn viết, gần giống như bạn có thể thể hiện thành công với mỗi lần nhấn phím. Tâm trí bạn quay cuồng vì phấn khích, và không có gì, KHÔNG CÓ GÌ, có thể ngăn cản bạn lúc này. Airpods của bạn rơi xuống đất khi bạn cất cánh, hướng tới tương lai tươi sáng và thành công mới đạt được của bạn.

– Đây không phải là ngày của bạn –

Hiệu ứng ban đầu là tuyệt vời. Trong vài ngày đầu tiên kể từ khi ra mắt, hàng nghìn người dùng đã dùng thử framework của bạn và chia sẻ trải nghiệm của họ. Bạn đã nhận được hàng trăm sao GitHub và 50 lượt upvote trên r/machinelearning. Không tệ. Không tệ chút nào.

Nhưng rồi… cái gì đó xảy ra. Điều gì đó không mong đợi – tốc độ tăng trưởng người dùng bắt đầu chững lại và sau đó giảm xuống. Nhiều tuần qua đi nhưng bạn không thấy bất kỳ sự tăng trưởng nào nữa. Bạn bắt đầu lo lắng rằng phần mềm mà bạn đã dồn hết tâm huyết vào không bền vững.

Điều này không thể như vậy được. Phải có vấn đề với Google Analytics hoặc phương thức đo lường mà bạn thiết lập. Có thể giờ đang là thời điểm vui vẻ trong năm – nhiều người đang trong kỳ nghỉ và không sử dụng phần mềm của bạn khi làm việc. Bạn đã làm mọi thứ theo cuốn sách. Không có cách nào mà điều này có thể đi ra khỏi cuộc chơi sớm như vậy.

Nhưng trong sâu thẳm, trái tim bạn thắt lại. Bạn biết đây chỉ là những cái cớ mỏng manh.

Bây giờ bạn đi lang thang trên phố, đầu cúi xuống và hai tay đút túi, tâm trạng của bạn xám xịt như bầu trời nhiều mây. Bạn nghĩ lại ngày ra mắt phần mềm của mình và cảm giác phấn khích, mong đợi vào ngày hôm đó, giống như bạn sẽ ra đời một cậu bé bụ bẫm. Bạn đã tạo ra thứ gì đó mà bạn đam mê, thứ gì đó mà bạn tin tưởng, nhưng bất chấp tiếng vang và sự hiệu ứng ban đầu, nó đã thất bại. Nhưng bạn vẫn tiếp tục, quyết tâm tìm hiểu tận cùng những gì đã sai.

“Tại sao họ không sử dụng nó?” Bạn nhìn lên bầu trời và cầu xin, cố gắng hiểu chuyện gì đã xảy ra. Chúa biết bạn đã nỗ lực – có thể (chắc chắn là vậy) rất nhiều. Bạn chỉ ước mình có thể làm điều gì đó, bất cứ điều gì khác đi, để làm cho phần mềm của bạn thành công.

Cuối cùng, bạn thấy mình đang ngồi trên một chiếc ghế dài trong công viên. Mặt trời bắt đầu ló dạng sau những đám mây, gần như thể nó biết được tâm trạng của bạn và đang cố gắng thắp sáng một ngày của bạn. Bạn thở dài thườn thượt mà bạn không biết là mình đã nín thở, và nhắm mắt lại, cảm nhận ánh nắng ấm áp trên khuôn mặt và làn gió mát trên da.

Bạn ngồi trong im lặng, cân nhắc hành động tiếp theo của mình.

Biến mất.

– Kết thúc? –

3 Sai lầm phổ biến

Những câu chuyện thành công thường giống nhau; còn thất bại, ngược lại, thường là duy nhất.

Khi nói đến phần mềm như AI framework ít được phổ biến, có 3 lỗi thường thấy trong giai đoạn đầu: tập trung kém, onboarding kém và thiếu tính năng. Trong bài viết này, tôi sẽ giải thích chúng từng bước bằng hình ảnh minh họa và quan trọng nhất là chỉ cho bạn cách khắc phục chúng.

Không gian giải pháp AI

Mọi vấn đề thực đều cần một giải pháp.

Có rất nhiều vấn đề về AI, dù lớn hay nhỏ, dễ hay phức tạp; miễn là chúng có thật, tất cả chúng đều cần giải pháp.

Hãy dùng dấu chấm để đại diện cho một giải pháp. Bạn có thể hình dung không gian giải pháp AI như bên dưới:

Trên thực tế, các giải pháp không được phân bổ đồng đều. Chúng được nhóm lại. Điều này là do các vấn đề khác nhau có thể dẫn đến các giải pháp tương tự.

Ví dụ: cả phân tích tình cảm và phân loại văn bản đều có thể được giải quyết bằng một mô hình ngôn ngữ với các nhãn đào tạo khác nhau. Phân đoạn hình ảnh và phát hiện đối tượng có thể được giải quyết bằng cách đào tạo ResNet. Do đó, không gian giải pháp AI thực sự trông như thế này:

Bản chất nhóm của không gian giải pháp AI chứng minh sự tồn tại của các framework phần mềm, phần trừu tượng cung cấp chức năng chung được chia sẻ bởi một nhóm giải pháp và có thể được thay đổi có chọn lọc bằng mã bổ sung do người dùng viết, cung cấp cách thức tiêu chuẩn để xây dựng và triển khai các giải pháp.

Nếu các giải pháp được phân bổ đồng đều trong không gian giải pháp AI, thì không có mô hình chung nào có thể được trừu tượng hóa, không cần đến các framework.

*Tổng thể của LF AI & Data Foundation, bao gồm 332 AI framework với tổng số 2.765.397 sao, vốn hóa thị trường là 13,3 nghìn tỷ đô la và kinh phí là 19,6 tỷ đô la.*

Hãy tóm tắt mối quan hệ giữa vấn đề, giải pháp và khuôn khổ trong hình minh họa dưới đây:

Kết nối giữa Vấn đề - Giải pháp - Framework — *Kết nối giữa Vấn đề – Giải pháp – Framework*

Việc có những khái niệm minh họa rõ ràng đó giúp chúng ta nhận ra sai lầm đầu tiên khi xây framework phần mềm.

Sai lầm 1: Không tập trung vào một ngách nhỏ

Trong hình bên dưới, các bong bóng A, B, C và D đại diện cho bốn framework.

Về mật độ, dễ dàng nhận thấy rằng A > B > C > D, vì A cho phép nhiều giải pháp nhất và đáp ứng nhu cầu của hầu hết các vấn đề trong thế giới thực. D là tồi tệ nhất vì nó có những yêu cầu hư cấu không phù hợp với vấn đề thực tế.

Do đó, A sẽ có tỷ lệ chấp nhận cao nhất trong thời gian dài, trong khi D sẽ có tỷ lệ chấp nhận thấp/không có bất kể bạn gửi bao nhiêu bài đăng cho Hacker News và bạn nhận được bao nhiêu sao trên GitHub.

“Ai lại khờ đến mức chọn C hay D?” bạn có thể hỏi.

Sự thật đáng lo ngại là nếu bạn nảy ra một ý tưởng lung linh trong lúc chạy bộ, hoặc nếu bạn đang xây dựng một framework mới khi đọc bài viết này, thì rất có thể bạn đang ở C hoặc D. Đây là lý do:

Bạn không thể nhìn thấy bức tranh toàn cảnh về không gian giải pháp AI. Không gian quan sát của bạn bị giới hạn bởi kiến thức và chuyên môn của bạn về AI và ngành.
Các thị trường đằng sau A và B là những đại dương đầy cá lớn (và đói khát). Bạn không có tài nguyên để bơi nhanh như vậy hoặc cắn mạnh như vậy.
Kinh nghiệm và kiến thức của bạn khiến bạn đánh giá quá cao số lượng giải pháp và yêu cầu trong C và D.
Là một kỹ sư, bạn dễ dàng bị ám ảnh bởi chính ý tưởng về framework, quên rằng nó không có bất kỳ ứng dụng thực tế nào trong thế giới thực.

Trong bất kỳ trường hợp nào, đừng ở D. Đừng buồn nếu bạn ở C. Không gian giải pháp rất lớn và năng động; nó liên tục thay đổi theo thời gian. Các vấn đề và yêu cầu mới xuất hiện; yêu cầu cũ sẽ không cần thiết.

Một ví dụ điển hình là thị trường AI sáng tạo vào năm 2021 so với năm 2022.

Chúng tôi hiếm khi thấy bất kỳ tìm kiếm nào về AI sáng tạo/sáng tạo trở lại vào năm 2021 và hiện tại nó đang bùng nổ.

Giả sử bạn có một focus tốt và framework của bạn về mặt khái niệm đáp ứng một số nhu cầu thực tế. Xin chúc mừng! Hãy tiếp tục với 2 cái bẫy phổ biến khác mà bạn có thể rơi vào.

Sai lầm 2: Trải nghiệm onboarding và tài nguyên giáo dục nghèo nàn

Hãy phóng to một “bong bóng” framework:

*Có thể quan sát và không thể quan sát đối với user*

Điều đầu tiên cần nhấn mạnh là khoảng cách kiến thức giữa bạn và người dùng của bạn. Framework của bạn có thể bao gồm tất cả các chức năng mà người dùng cần. Tuy nhiên, do thiếu tài liệu và trải nghiệm onboarding kém, người dùng không biết framework của bạn có thể giải quyết vấn đề của họ. Hậu quả? Khả năng đón nhận thấp.

Không giống như bạn (với tư cách là người biết tất cả về framework của mình), người dùng quan sát framework từ một góc độ hoàn toàn khác: họ chỉ có thể tìm hiểu nó từ các tài liệu, hướng dẫn, tài liệu tham khảo, video và code mà bạn cho họ xem. Trên thực tế, những người dùng thiếu kiên nhẫn chỉ học được từ các tài nguyên được viết tốt. Nếu họ cảm thấy việc onboarding khó khăn, họ sẽ ngay lập tức từ bỏ và tìm kiếm các giải pháp thay thế. Họ không quyết tâm và đam mê như bạn đâu.

Một sai lầm phổ biến mà các nhà phát triển mắc phải là bỏ qua tầm quan trọng của tài nguyên giáo dục và DocOps khi xây dựng framework. Họ ngây thơ tin rằng miễn là họ commit một function cho nhánh chính, thì người dùng sẽ sử dụng nó; miễn là bạn viết một vài từ khóa mơ hồ về một tính năng trong tin commit, người dùng sẽ hiểu tính năng đó; miễn là bạn thực hiện các thay đổi đột phá, người dùng sẽ điều chỉnh mã của họ cho phù hợp.

Họ không vậy đâu.

Họ sẽ không mất thời gian đào sâu vào các bài kiểm thử đơn vị để hiểu cách thức hoạt động của một chức năng.
Họ sẽ không đọc câu đố về tin commit của bạn và tiêu đề của pull request để đoán tính năng mới.
Người dùng sẽ không kiểm tra các bộ lọc thư rác để đọc bản tin mà bạn thông báo về các thay đổi.
Người dùng sẽ không đọc các tài liệu được viết kém với các đoạn mã không thể thực thi được và báo cáo lỗi cho bạn.

Người dùng sẽ không lãng phí thời gian của họ vào phần mềm của bạn nếu bạn không “lãng phí” thời gian của mình vào việc giáo dục họ.

Vì vậy, bạn đã tìm mọi cách để thu nhỏ lỗ hổng kiến thức: tài liệu hay, hướng dẫn chi tiết, video hướng dẫn, gặp gỡ offline/online, thuyết trình hội nghị, tweet hàng ngày và bản tin hàng tuần.

Đó là điều xử lý. Và bạn đã sửa focus của mình (từ sai lầm thứ nhất). Nhưng bạn vẫn thấy việc khả năng đón nhận thấp. Bây giờ là mấy giờ?

Sai lầm 3: Các tính năng lỗi thời và thiếu sót

AI đang phát triển nhanh chóng và thị trường có tính cạnh tranh cao. Mặt khác, bạn đã lỗi thời. Bị đào thải. Một di vật.

Mỗi ngày, hàng trăm bài báo mới được xuất bản trên ArXiv; bảng xếp hạng điểm chuẩn được làm mới; xu hướng kho lưu trữ mới trên GitHub. Nếu bạn không thể cập nhật kiến thức của mình, framework của bạn sẽ nhanh chóng trở nên lỗi thời. Nó sẽ không thu hút sự chú ý của người dùng nữa.

So với sai lầm thứ hai, nơi người dùng không biết họ có thể làm điều đó với framework của bạn, thì trong trường hợp này, người dùng biết họ không thể làm gì với framework của bạn. Game over.

Mệt mỏi vì phải cạnh tranh? Vâng, nhưng bạn đã chọn nó, phải không? Đó là thị trường nóng hổi tràn ngập cơ hội và tiền. Bạn sẽ đối phó với sức nóng đó hay bị cóng và bỏ chạy? Còn giấc mơ insert_country_name của bạn thì sao?

Cách khắc phục những sai lầm đó

Lịch sử đầy sai lầm; đó là cách chúng ta học.

Đừng sợ những sai lầm đó. Đối đầu với chúng chỉ là một phần trong cuộc sống của bạn.

Bạn không nên e sợ những sai lầm đó, nhưng nếu quản lý nói thế này với bạn, có lẽ bạn nên xem xét lại sự nghiệp của mình.

Bước đầu tiên là nhận ra bạn đã phạm sai lầm nào. Nghe có vẻ dễ dàng, nhưng dưới áp lực rất lớn của khả năng đón nhận thấp, rất có thể bạn sẽ đi đến kết luận rằng mình đã phạm phải tất cả sai lầm.

Việc thú nhận rằng bạn đã mắc phải tất cả những sai lầm cũng dễ như việc bảo rằng “nó không hiệu quả”. Không phá vỡ nó, lời thú nhận này dẫn đến không có điểm hành động. Tùy thuộc vào bạn để ưu tiên và giải quyết từng vấn đề một, với nguồn lực hạn chế của bạn.

Nhắm mục tiêu vì nhu cầu lớn hơn

Nếu bạn tập trung không tốt, bạn cần phải nhắm lại mục tiêu. Tìm hiểu về những gì mọi người cần và từ bỏ nỗi ám ảnh về việc tạo ra một framework. Xây dựng thêm các giải pháp đặc biệt và nhận ra các kết nối của chúng trước khi động đến framework. Làm thêm nghiên cứu người dùng và phân tích thị trường, tìm ra miếng bánh đủ lớn và thú vị.

Cũng có thể sự tập trung có chủ ý của bạn là đủ tốt, nhưng cách kể chuyện và thương hiệu của bạn quá tệ, điều này khiến người dùng nghĩ rằng framework không phù hợp với nhu cầu của họ. Trong trường hợp này, hãy xem xét lại câu chuyện, quảng cáo các tính năng thực sự quan trọng và che giấu những điểm phức tạp mà không ai (ngoài bạn) quan tâm.

Sửa đổi tài liệu để cải thiện trải nghiệm onboarding

Nếu trải nghiệm onboarding của bạn kém, bạn phải sửa đổi tài liệu và tổ chức các tài nguyên giáo dục. Một framework phần mềm cần tài nguyên giáo dục ở nhiều cấp độ – tham chiếu API, hướng dẫn, đoạn mã, các ứng dụng cấp cao và các đối sánh ngành. Nếu chỉ có một tham chiếu API được tạo tự động từ các chuỗi tài liệu là không đủ.

Hãy nghĩ lại cách bạn học ngôn ngữ thứ hai: Bạn sử dụng từ điển để tra cứu từ vựng (tức là tham chiếu API). Cuốn sách dành cho năm đầu tiên của bạn chứa đầy những cuộc trò chuyện cơ bản hàng ngày (tức là các đoạn mã) để dạy bạn cách chào hỏi và mua đồ. Cuốn sách năm thứ hai của bạn có những câu chuyện dài hơn (tức là các ứng dụng cấp cao) để giúp bạn nắm vững ngữ pháp và viết mô tả. Để nâng cao kỹ năng của mình, bạn xem phim hoặc đọc sách của các nhà văn nổi tiếng (tức là tiêu chuẩn ngành).

Người dùng của bạn cũng vậy. Vào ngày đầu tiên, họ chỉ là người mới. Nhưng theo thời gian, họ tiến bộ bằng cách sử dụng kiến thức bạn cung cấp. Nhiệm vụ của bạn là giúp người dùng phát triển nhanh nhất có thể bằng cách cung cấp tất cả các cấp tài nguyên mà họ cần. Khi họ đạt đến trình độ bậc thầy, bạn có thể thư giãn một chút, vì lúc này họ có thể bênh vực người khác; họ có thể sản xuất nội dung giáo dục chất lượng cao mà không cần bạn.

Đừng chỉ dính vào văn bản; đi đa phương thức! Hãy thử podcast, video, buổi gặp mặt và thuyết trình tại hội nghị nếu bạn có tài nguyên.

Tiến nhanh với học tập suốt đời

Nếu các tính năng của bạn đã lỗi thời, bạn cần tìm hiểu thêm về tính năng hiện đại nhất và cập nhật framework của mình. Tìm hiểu API, mẫu thiết kế và thuật toán từ các framework mã nguồn mở phổ biến. Theo dõi các pull request mới của họ và các tính năng mới trong ghi chú phát hành và suy nghĩ xem có hợp lý không khi thêm chúng vào framework. Luôn cập nhật kiến thức và cơ sở mã của bạn. Thỉnh thoảng, hãy thực hiện một số hồi tưởng về lộ trình tính năng: bạn có đang đi đúng hướng không? Bạn có thêm tính năng này vì mọi người thực sự cần nó không?

Trong thế giới mã nguồn mở, không có lợi thế tuyệt đối. Bạn luôn có thể học hỏi từ các phần mềm khác và tất cả nằm ở tốc độ. Nếu bạn tụt lại phía sau nhưng di chuyển nhanh hơn cả, cuối cùng bạn có thể đuổi kịp. Nếu bạn đang dẫn đầu nhưng lại ngừng cập nhật, một kẻ săn mồi sẽ biến bạn thành bữa trưa. Tốc độ là huyết mạch của phần mềm mã nguồn mở.

Nguồn: jina.ai

Tags khung phần mềm, software framework

Dev's Corner

Các thách thức kỹ thuật trong thế giới thực: Chọn lựa công nghệ

Post author By Gambaru
Post date 18 December, 2022
No Comments on Các thách thức kỹ thuật trong thế giới thực: Chọn lựa công nghệ

“Thách thức kỹ thuật trong thế giới thực’ là loạt bài trong đó tôi diễn giải các case study thú vị trong lĩnh vực kỹ thuật phần mềm (software engineering) hoặc quản lý kỹ thuật (engineering management) từ các công ty công nghệ. Rất mong bạn sẽ học được nhiều điều mới mẻ trong các bài viết này khi chúng ta đi sâu vào các khái niệm mà chúng chứa đựng.

Trong bài này, tôi đã thực hiện một cách tiếp cận hơi khác so với các bài trước, bằng việc đặt câu hỏi cho tác giả các bài blog về kỹ thuật, để chia sẻ các chi tiết chưa được công bố trước đây cũng như bài học từ họ.

4 Tình huống lựa chọn công nghệ

Hôm nay, chúng ta sẽ tìm hiểu:

Trello chọn Kafka thay vì RabbitMQ để nhắn tin. Trello đã sử dụng RabbitMQ để chạy websocket trong nhiều năm. Tuy nhiên, sau khi nhận thấy các vấn đề về độ tin cậy và mức sử dụng tài nguyên cao, họ đã quyết định giải quyết vấn đề này – và đánh giá 5 giải pháp thay thế.
Tại sao Birdie chuyển sang Micro Frontends. Birdie là một ứng dụng web phức tạp dành cho các nhà cung cấp dịch vụ chăm sóc sức khỏe. Họ đã thất vọng vì các bài kiểm thử chạy chậm mỗi khi có sự thay đổi, vì vậy họ đã nghiên cứu cách mô đun hóa cơ sở mã và giảm sự liên kết chặt chẽ giữa các phần của nó.
Tại sao MetalBear chọn Rust. Là một công ty mới thành lập được 6 tháng, MetalBear đã chọn khá nhiều ngôn ngữ lập trình cho các stack của mình và đã chọn Rust. Ngoài hiệu suất, các cân nhắc về mặt tuyển dụng cũng là một phần của quyết định.
Tại sao Motive chuyển sang Kotlin Multiplatform Mobile (KMM). Nhóm đã xây dựng ứng dụng Motive Fleet cho các doanh nghiệp vận tải, trên iOS và Android. Tuy nhiên, iOS luôn chậm hơn 1-2 tháng và logic nghiệp vụ hơi khác so với Android. Họ đã khám phá các phương án thay thế để chia sẻ logic nghiệp vụ giữa iOS và Android.

1. Trello chọn Kafka thay vì RabbitMQ

Để chạy chức năng websocket, Trello đã sử dụng phương thức Redis Pub/Sub cho đến năm 2015, sau đó là RabbitMQ từ năm 2015-2018. Vào năm 2018, đã xảy ra sự cố phân vùng mạng với RabbitMQ buộc họ phải đánh giá lại lựa chọn công nghệ.

Tổng quan ngắn về RabbitMQ. Để hiểu vấn đề mà nhóm Trello gặp phải với RabbitMQ, trước tiên chúng ta cần hiểu một số điều cơ bản về RabbitMQ:

Exchange (sàn): đây là entry point mà tin nhắn được xuất bản.
Queue (hàng đợi): Exchange được liên kết với một hoặc nhiều message queue (hàng đợi tin nhắn). Một hàng đợi tin nhắn theo nghĩa đen.
Binding (liên kết): kết nối giữa Exchange và Queue. Các binding có thể có các khóa binding (binding key).
Routing policy (chính sách định tuyến): chiến lược về cách exchange xử lý định tuyến.

*Cách các exchange, binding, queue và routing policy được kết nối trong RabbitMQ*

Có bốn chính sách định tuyến phổ biến mà RabbitMQ hỗ trợ:

Fanout: gửi tất cả các tin nhắn đến Exchange và tất cả các Queue liên kết với nó, mà không quan tâm các khóa định tuyến (routing keys). Cách tiếp cận này bỏ qua các khóa định tuyến.
Direct: tin nhắn được gửi đến hàng đợi mà khóa định tuyến khớp với khóa liên kết (binding keys).
Topic: cho phép kết hợp ký tự đại diện giữa khóa định tuyến và khóa liên kết. Ví dụ: bạn có thể thiết lập chủ đề về “tác vụ” và điều này sẽ định tuyến đến cả liên kết “task.important” và “task.unimportant”.
Header: sử dụng tiêu đề của yêu cầu để quyết định định tuyến.

Các Queue có thể tạm thời trong RabbitMQ, nghĩa là chúng có thể bị hủy ngay khi kết nối TCP tạo ra chúng đóng lại.

Việc triển khai websocket của Trello hỗ trợ đăng ký và hủy đăng ký và từ một kênh thông báo, có thể dành cho ban quản lý, thành viên, tổ chức, thẻ của Trello hoặc các mô hình dữ liệu Trello khác. Model_id được sử dụng làm mã định danh.

Kiến trúc ban đầu. Trello đã sử dụng RabbitMQ để phân đoạn các tin nhắn gửi đến vào một trong 16 queue. Ở hậu trường, họ đã chạy 3 phiên bản (instance) để xử lý các tin nhắn inbound phân phối đến một trong 16 queue. Sau đó, họ sử dụng plugin Shovel của RabbitMQ để ánh xạ 16 queue này thành 4 cụm outbound. Mỗi cụm tin nhắn gửi đi chạy trên 3 phiên bản và xử lý 4 hàng đợi outbound.

*Kiến trúc websocket của Trello, được xây dựng trên RabbitMQ giai đoạn 2015-2018.*

Vấn đề: gián đoạn cụm và hiệu suất. Team Trello nhận thấy các sự cố lớn xảy ra khi một cụm gặp sự cố do gián đoạn mạng hoặc khi một thành viên của cụm gặp sự cố. Khi điều này xảy ra, họ phải thiết lập lại toàn bộ; loại bỏ tất cả các socket và buộc các máy khách web kết nối lại. Tệ hơn nữa, các tin nhắn biến mất trong quá trình thiết lập lại này.

*Các vấn đề với hạ tầng này là cách dữ liệu biến mất trong các trường hợp lỗi đơn lẻ hoặc lỗi mạng.*

Một vấn đề khác là việc tạo queue và binding trong RabbitMQ chậm và tốn nhiều tài nguyên. Trong quá trình thiết lập lại hoàn toàn, phải mất khoảng thời gian đáng kể để tạo các queue và binding này.

Lựa chọn thay thế. Vì vậy, team Trello đã tìm kiếm các giải pháp thay thế cho RabbitMQ và đánh giá từng giải pháp dựa trên yêu cầu của họ, chẳng hạn như:

Khả năng chuyển đổi dự phòng
Gửi tin nhắn theo thứ tự trên mỗi phân đoạn
Hỗ trợ phân phối tin nhắn fanout
Độ trễ thấp
Hỗ trợ thông lượng yêu cầu 2.000 tin nhắn/giây

Nhóm đã khám phá 5 lựa chọn thay thế nhắn tin sau:

Kafka
Amazon SNS (Dịch vụ thông báo đơn giản) + SQS (Dịch vụ hàng đợi đơn giản)
Amazon SNS + FIFO (vào trước ra trước) SQS
Amazon Kinesis: dịch vụ truyền dữ liệu không cần máy chủ
Redis Streams

Sau khi đánh giá các tùy chọn, nhóm nhận thấy Kafka và Redis Streams phù hợp với yêu cầu của họ và chọn Kafka vì Redis Streams vẫn ở trạng thái không ổn định: chức năng Streams chỉ được cam kết trong một nhánh được đánh dấu là ‘không ổn định’. Nhóm Trello đã xây dựng lại kiến trúc websocket trên Kafka và hiện sử dụng kiến trúc chủ-khách.

Thật thú vị khi thấy rằng điểm yếu của công nghệ có thể không bộc lộ trong nhiều tháng hoặc thậm chí nhiều năm. Nhóm Trello đã chuyển sang RabbitMQ sau nhiều năm sử dụng giải pháp Redis Pub/Sub. Vì vậy, tại sao họ chuyển ra khỏi nó? Tôi đã hỏi kỹ sư phần mềm Sebastian Mayr – người viết bài – và anh ấy chia sẻ rằng vấn đề lớn nhất mà họ gặp phải là Redis phân cụm không đảm bảo phân phối trong trường hợp xảy ra sự cố mạng hoặc chuyển đổi dự phòng.

Khi Trello phát triển, vấn đề các node bị lỗi trở nên rõ ràng hơn, cũng như chi phí phần cứng để vận hành hạ tầng Websocket. Sau ba năm, Trello quyết định khám phá xem liệu họ có thể giải quyết cả hai vấn đề bằng một dịch vụ nhắn tin khác hay không.

Tôi thích cách nhóm kỹ sư đánh giá kỹ lưỡng nhiều tùy chọn nhắn tin. Họ liệt kê một loạt các lựa chọn thay thế và xem xét kỹ lưỡng từng lựa chọn, dựa trên các yêu cầu và vấn đề của riêng họ.

Điều tôi còn thiếu trong bài báo của Sebastian là thông tin chi tiết về chính quá trình chuyển đổi đó; Tôi chỉ có thể cho rằng công việc này không hề tầm thường. Một điều làm cho việc chuyển đổi như vậy trở nên dễ dàng hơn là ít nhất nó không phải là di chuyển dữ liệu. Vì vậy, tôi cho rằng nhóm có thể thử nghiệm kiến trúc mới trong thực tế bằng cách ẩn chức năng hoặc bằng cách triển khai cho số lượng người dùng ngày càng tăng.

2. Tại sao Birdie chuyển sang Micro Frontends

Birdie là một nền tảng công nghệ chăm sóc sức khỏe tại nhà, có trụ sở tại London. Công ty đã gọi vốn thành công vòng Series B trị giá 30 triệu đô la vào tháng 6 năm nay. Họ đã chia sẻ hành trình chuyển sang Micro Frontends trong bài blog gần đây. Tôi đã nói chuyện với tác giả của bài đăng này, Steve Heyes, một kỹ sư phần mềm tại Birdie.

Micro Frontends là một mẫu kiến trúc hơi giống với microservice. Thay vì giữ tất cả cơ sở mã của Ứng dụng một trang (SPA – Single Page Appplication) trong một cơ sở mã nguyên khối duy nhất, Micro Frontends chia cơ sở mã thành các thành phần riêng biệt được giữ với nhau bằng một trình bao (shell):

*Micro Frontends là một cách tiếp cận kiến trúc để cấu trúc các ứng dụng web.*

Birdie team có Ứng dụng một trang được tích hợp sẵn trong React, nói chuyện với một API ở backend. Đây là một ảnh chụp màn hình giao diện của ứng dụng:

*Ứng dụng Birdie React. Một ứng dụng được xây dựng cho chăm sóc sức khỏe tại nhà.*

Khi ứng dụng phát triển, nhóm kỹ sư nhận thấy một vấn đề ngày càng rõ ràng hơn: các bài kiểm thử mất nhiều thời gian để chạy. Đối với mỗi và mọi thay đổi, tất cả các kiểm thử trong cơ sở mã đều phải chạy, bao gồm một số ít bài kiểm thử đơn vị, nhiều bài kiểm thử tích hợp và một loạt kiểm thử từ đầu đến cuối bằng Cypress. Số lượng lớn các kiểm thử tự động này bắt đầu làm chậm quá trình phát triển, đó là lúc nhóm nảy ra ý tưởng chia ứng dụng thành các phần độc lập bằng cách sử dụng Micro Frontends, mà có thể được kiểm thử độc lập.

Steve rất tử tế khi chia sẻ thêm chi tiết về quá trình này. Anh nói:

‘Vào tháng 7 năm 2021, team đã chạy “sprint cải tiến kỹ thuật.” Mục tiêu là để giải quyết các vấn đề nền tảng đã tích tụ trong nhiều năm.

‘Trong tuần này, ba kỹ sư frontend đã xây dựng thành phần shell và biến đổi thành công một tình huống khá riêng biệt để trở thành Micro Frontend đầu tiên. Team đã chọn thành phần điều hướng nằm trên cùng của tất cả các trang trên ứng dụng web và code đã đủ tách biệt. Cũng trong tuần đó, team cũng trích xuất một tính năng khác, nhỏ hơn là Micro Frontend thứ hai. Trong cả hai trường hợp, rất ít khi cần tới refactoring, vì hầu hết công việc là chuyển mã hiện có sang cấu trúc mới.

‘Sau đó là hướng dẫn những người còn lại trong team về Micro Frontends. Thay vì chuyển sang một công cụ tái cấu trúc lớn, các kỹ sư đã thực hiện công việc tái cấu trúc ban đầu đã hướng dẫn đồng nghiệp về lý do tại sao Micro Frontends lại hữu ích và cách sử dụng chúng. Nhóm đã chia sẻ tài liệu, gửi các video hướng dẫn và tổ chức một số buổi “lunch and learn”. Khoảng một tháng sau, tất cả các kỹ sư frontend đã bắt kịp các khái niệm.

‘Trong tương lai, ý tưởng là xây dựng các tính năng mới cho ứng dụng trong Micro Frontend của riêng họ. Làm điều này ngay từ đầu sẽ dễ dàng hơn rất nhiều so với việc quay lại và cấu trúc lại mã hiện có. Trong năm qua, một số Micro Frontend mới đã được thêm vào khi sản phẩm phát triển.

Cấu trúc của ứng dụng web Birdie, sau khi giới thiệu Micro Frontends. Theo thời gian, mỗi tính năng có thể trở thành Micro Frontend của riêng nó và Điều hướng chính và Điều hướng phụ cũng là các thành phần riêng của chúng.

‘Quá trình chia nhỏ ứng dụng’ cũ’ thành Micro Frontends chậm hơn chúng tôi mong đợi. CÓ 2 lý do cho điều này là:

Khái niệm ‘trách nhiệm duy nhất’ là điều không phải tất cả các phần của ứng dụng đều tuân theo. Là một công ty khởi nghiệp, chúng tôi cần giao hàng nhanh, điều này khiến chúng tôi phải đánh đổi trong ứng dụng. Khi chúng tôi xây dựng SPA đầu tiên, chúng tôi chưa bao giờ tưởng tượng rằng mình sẽ cần chia nhỏ nó thành các ứng dụng nhỏ hơn. Chính vì điều này mà việc bỏ chọn các tính năng phức tạp hơn, nhưng không có nghĩa là không thể; nó chỉ làm việc nhiều hơn là sao chép mã hiện có từ tệp này sang tệp khác.

Chúng tôi phụ thuộc vào Redux để quản lý trạng thái chung. Khi SPA đầu tiên được xây dựng lần đầu tiên, chúng tôi đã sử dụng Redux và Redux-Saga – trình quản lý tác dụng phụ của Redux – để phát huy hết lợi thế của chúng. Tuy nhiên, vào thời điểm đó, đây là một quyết định đúng đắn, điều đó có nghĩa là rất nhiều logic kinh doanh của chúng tôi đan xen với nhau và việc bỏ chọn một tính năng cho thành phần của chính nó thường phải tái cấu trúc và viết lại rất nhiều.

‘Trong tương lai, chúng tôi sẽ loại bỏ các tính năng phụ thuộc vào Redux, trong đó một ví dụ điển hình là mã phân tích của chúng tôi, được sử dụng để ghi lại các tương tác của người dùng dựa trên các hành động của Redux.

‘Tuy nhiên, chúng tôi vẫn ghi nhớ mục tiêu chính của ứng dụng của chúng tôi là gì. Người dùng sẽ có thể hoàn thành các công việc họ cần. Đây là thước đo thành công đầu tiên của chúng tôi và mọi thứ, bao gồm cả kiến trúc ứng dụng, sẽ xuất hiện sau đó.”

Quyền tự chủ cho các nhóm là một lý do khác khiến Birdie chuyển sang Micro Frontends – và tôi không ngạc nhiên khi họ làm như vậy. Tôi thấy có sự tương đồng thú vị giữa microservice dành cho team backend và Micro Frontend cho team frontend, về cách những phương pháp này giúp các nhóm tự chủ hơn.

Các vấn đề với các ứng dụng backend hoặc frontend nguyên khối là mã được liên kết chặt chẽ, các bài kiểm thử có thể mất nhiều thời gian để chạy và việc thực hiện một thay đổi duy nhất trong ứng dụng có thể làm hỏng thứ gì đó, ở đâu đó không mong muốn.

Cả Micro Frontends và microservice đều giới thiệu nhiều giao diện giữa các phần của ứng dụng. Và miễn là các nhóm tôn trọng các giao diện này, họ có thể di chuyển nhanh hơn trong các phần mã của mình và ít lo lắng hơn về các Micro Frontends. Nhưng một nhược điểm rõ ràng có thể là nhiều nhóm “phát minh lại bánh xe” hoặc sử dụng các cách tiếp cận khác nhau để xây dựng Micro Frontends tương ứng của họ. Mặt khác, thật khó để vừa có quyền tự chủ vừa có cách làm việc chung.

Steve đã lưu ý một điều thú vị trong cuộc trò chuyện, đó là monorepos có thể giảm tải nhận thức khi chuyển ngữ cảnh, không chỉ với microservice mà còn với Micro Frontends. Bằng việc có tất cả mã của các thành phần khác nhau trong cùng một cơ sở mã – điều này giúp bất kỳ kỹ sư nào cũng dễ dàng duyệt qua chúng và thực hiện các thay đổi – tự nhiên có thể dẫn đến các thực hành tương tự giữa các nhóm, đặc biệt nếu có quá trình đánh giá mã diễn ra giữa các nhóm đang làm việc trên các Micro Frontend khác nhau.

Như với bất kỳ sự lựa chọn kiến trúc nào, có sự đánh đổi trong mỗi cách tiếp cận. Tôi thấy use-case của Birdie rất thú vị, đặc biệt là vì số lượng kiểm thử được chạy trong các thay đổi đã kích hoạt việc tìm kiếm các tùy chọn để chia nhỏ cơ sở mã.

3. Tại sao MetalBear quyết định sử dụng Rust

Metalbear là công ty khởi nghiệp xây dựng các công cụ nguồn mở dành cho backend developer. Công ty chỉ mới được thành lập vào tháng 4 năm nay và là một nhóm gồm 6 kỹ sư phần mềm rải rác trên toàn cầu, ở Brazil, Canada, Đức và Israel. Họ đã huy động được khoảng 1 triệu đô vòng tiền hạt giống (pre-seed).

Sản phẩm đầu tiên của họ là Mirrord. Phần mềm cho phép các kỹ sư phần mềm chạy các quy trình cục bộ, chẳng hạn như môi trường staging, trong môi trường đám mây mà không gặp rắc rối khi triển khai lên staging. Tôi biết về công ty sau khi vị đồng sáng lập, Aviram Hassan, viết một bài blog về lý do họ chọn Rust. Tôi thấy kinh nghiệm của một công ty khởi nghiệp nhỏ là một tình huống nghiên cứu thú vị.

Khi bắt đầu phát triển mirrord, nhóm không chọn ngôn ngữ nào trước. Thay vào đó, ba trong số bốn thành phần chính của nó – Agent,Layer, CLI và VS Code extension – mỗi cái đều sử dụng Rust vì những lý do khác nhau.

*Bốn thành phần của mirrord. Nguồn ảnh gốc: MetalBear blog.*

Dưới đây là những cân nhắc cho từng thành phần:

1. Agent: thành phần đóng vai trò đại diện cho người dùng

Chuyển đổi namespace. Namespace bao gồm Linux namespace và networking namespace. Mirrored kết nối các quy trình cục bộ với một pod từ xa (Kubernetes), hoạt động này thực hiện bằng cách sinh ra một agent trên cùng một node với nhóm hiện có. Sau đó, agent sinh ra các luồng cụ thể trong cùng một namespace của pod hiện tại. Bằng cách sử dụng cùng một namespace, agent được sinh ra có thể truy cập cùng tài nguyên mạng, tài nguyên tệp và tài nguyên quy trình. Làm việc với các Linux namespace dễ dàng hơn ở một số ngôn ngữ so với các ngôn ngữ khác. Nó dễ dàng hơn với Rust.
Mức chiếm dụng bộ nhớ nhỏ. Nhiều nhà phát triển phải làm việc trong cùng một môi trường bằng cách giảm thiểu tác động đến hiệu suất. Để làm như vậy, cần có một dung lượng bộ nhớ nhỏ, nghĩa là sử dụng một ngôn ngữ mà không cần bộ thu gom rác bộ nhớ. Rust là một trong những ngôn ngữ như vậy.
Phân luồng an toàn. Dữ liệu cần được di chuyển an toàn giữa các luồng, vì vậy nhóm cần một ngôn ngữ với các nguyên mẫu xung quanh việc quản lý tác vụ và đồng thời an toàn. Rust hỗ trợ Gửi để chuyển loại an toàn cho luồng và Đồng bộ hóa cho các loại để chia sẻ tham chiếu giữa các luồng.

2. Layer: thư viện dùng chung chạy trong local service. Kết nối các hoạt động đầu vào/đầu ra và ủy quyền chúng cho agent.

Yêu cầu cấp thấp. Do nhu cầu thao tác với socket và mọi thứ ở cấp hệ thống tệp, một ngôn ngữ cấp thấp có vẻ là lựa chọn phù hợp cho nhóm.
Mức chiếm dụng bộ nhớ nhỏ. Tương tự như Agent, mục tiêu là giảm thiểu việc sử dụng bộ nhớ.

3. CLI: đưa lớp vào quy trình mục tiêu.

Nhị phân độc lập (standalone binaries). Nhóm đã tìm kiếm một ngôn ngữ trong đó CLI sẽ được tạo dưới dạng tệp thực thi độc lập, lý tưởng nhất là không có phần phụ thuộc.
Bằng chứng trong tương lai. Ngay bây giờ, việc triển khai CLI sẽ trở nên tầm thường khi sử dụng hầu hết mọi ngôn ngữ. Tuy nhiên, nhìn về tiêm tinh vi hơn như sử dụng ptrace, lệnh gọi hệ thống Unix, một ngôn ngữ cấp thấp hơn như Rust cảm thấy phù hợp hơn trong tương lai.

4. Tiện ích VS Code: CLI cho Visual Studio Code

JavaScript. VS Code chỉ hỗ trợ JavaScript, vì vậy việc lựa chọn rất dễ dàng.

Làm cho việc tuyển dụng trở nên dễ dàng hơn bằng cách “Rust-only”. Là một startup, công nghệ có thể giúp cho việc tuyển kỹ sư phần mềm dễ hoặc khó hơn nhiều. Như Aviram đã nói:

“Tôi có cảm giác rằng việc cơ sở mã của chúng tôi chủ yếu ở Rust sẽ giúp việc tuyển dụng kỹ sư dễ dàng hơn rất nhiều. Là một người đam mê Rust, tôi rất thích làm việc ở một nơi mà tôi có thể làm việc với Rust thường xuyên và tôi nghi ngờ rằng nhiều người khác cũng cảm thấy như vậy.”

Câu chuyện của MetalBear là một lời nhắc nhở rằng những lựa chọn công nghệ ban đầu sẽ định hình văn hóa kỹ thuật của công ty – và tuyển dụng những khách hàng tiềm năng! Thực tế là, MetalBear có thể đã chọn viết phần lớn phần mềm của mình bằng C++, Go, hoặc C#, Java hoặc gần như bất kỳ ngôn ngữ nào khác mà mã có thể được tối ưu hóa để hoạt động hiệu quả. Tôi không nghi ngờ gì về việc họ có thể tạo ra mirrord chạy được bằng bất kỳ ngôn ngữ nào, ngay cả khi một số ngôn ngữ sẽ cần nhiều cách giải quyết hơn – bao gồm cả việc có thể chuyển sang kết nối chức năng ở cấp độ Hợp ngữ và sau đó điều chỉnh hiệu suất.

Tuy nhiên, bằng cách chọn ngôn ngữ một cách có mục đích, công ty đã đưa ra lựa chọn có tác động lâu dài đến văn hóa kỹ thuật, tuyển dụng và các lựa chọn trong tương lai.

Có vẻ như Rust đang trở nên phổ biến nhờ đạt được sự cân bằng tốt giữa việc cung cấp các tính năng cấp thấp theo cách thân thiện hơn, chẳng hạn như C hoặc C++. Nó cũng là ngôn ngữ mà nhiều kỹ sư backend muốn học và cân nhắc điều này là một bước đi thông minh; nghĩ xa hơn việc thuê những kỹ sư phần mềm đầu tiên.

4. Tại sao Motive chuyển sang Kotlin Multiplatform Mobile

Motive – trước đây là KeepTruckin – là một nền tảng hoạt động tự động cho lĩnh vực hậu cần. Họ xây dựng nhiều sản phẩm phần mềm hỗ trợ hoạt động vận tải đường bộ, quản lý đội xe và các use case khác mà phần cứng và phần mềm có thể giúp cải thiện cách thức hoạt động của các doanh nghiệp vận chuyển. Công ty đã huy động được khoản tài trợ Series F trị giá 150 triệu đô la vào tháng 5 năm nay.

Sunil Kumar, nhân viên kỹ sư phần mềm của công ty, đã viết một bài blog vào tháng 7 này về lý do tại sao nhóm kỹ sư quyết định chuyển sang Kotlin Multiplatform Mobile (KMM) như một cách tiếp cận để chia sẻ nhiều mã hơn giữa Android và iOS. Anh cũng nêu chi tiết kinh nghiệm của họ với sự thay đổi.

Nhóm kỹ sư xây dựng ứng dụng Motive Fleet muốn đảm bảo tính nhất quán trong logic kinh doanh trên các ứng dụng dành cho thiết bị di động và để thực hiện phát triển nhanh hơn. Họ đã đánh giá ba phương pháp phát triển đa nền tảng:

Flutter: một khung đa nền tảng do Google xây dựng bằng ngôn ngữ lập trình Dart, ngôn ngữ này cũng được Google phát triển.
React Native: một framework đa nền tảng do Facebook xây dựng ban đầu. Nó sử dụng ngôn ngữ lập trình JavaScript và có một số điểm tương đồng với khung web React.
KMM: Một khung được xây dựng bởi Jetbrains. Nó sử dụng ngôn ngữ lập trình Kotlin.

Nhóm đã so sánh thêm, xem xét các khía cạnh hỗ trợ giao diện người dùng và mức độ dễ dàng để xây dựng giao diện người dùng gốc, tích hợp với các ứng dụng hiện có và ý nghĩa hiệu suất. Đây là những gì nhóm đã đánh giá:

*So sánh KMM, Flutter và React Native về các thứ nguyên quan trọng đối với nhóm kỹ sư Motive. Nguồn: Blog kỹ thuật động lực.*

Nhóm đã quyết định sử dụng KMM, chủ yếu là vì đây là cách dễ dàng nhất để làm việc với mã hiện có của họ và họ cảm thấy mình có thể giữ quyền kiểm soát (gốc) nhiều nhất đối với ứng dụng.

Tôi đã liên hệ với Sunil để hỏi về cách họ đưa ra quyết định. Đây là những gì anh ấy chia sẻ:

Những lý do khác dẫn đến KMM?

‘Nhóm ứng dụng Motive Fleet được xây dựng chỉ vài ngày trước khi Covid-19 bắt đầu. Tuy nhiên, chúng tôi thiếu băng thông iOS, dẫn đến việc iOS luôn bị tụt hậu so với Android 1-2 tháng. Độ trễ này có nghĩa là một số tính năng có sự khác biệt về logic nghiệp vụ giữa các ứng dụng.

‘Để loại bỏ những khác biệt này và tăng tốc độ phát triển do thiếu tài nguyên, chúng tôi bắt đầu xem xét các giải pháp đa nền tảng. Tôi đã có kinh nghiệm trước đây với React Native. Khi tôi làm việc với React Native, hiệu suất của ứng dụng mà tôi xây dựng không được tốt. Trong trường hợp của chúng tôi, hiệu suất là một điểm quan trọng khi chúng tôi tương tác với bản đồ rất nhiều. Với Flutter, không ai trong nhóm của chúng tôi có bất kỳ kinh nghiệm nào với nó và sau khi đọc nhiều bài đăng trên blog, chúng tôi quyết định rằng việc học một công nghệ mới và một ngôn ngữ mới là không đáng.’

Bạn đã điều phối việc chuyển sang KMM như thế nào?

‘Chúng tôi đã không di chuyển tất cả mã của ứng dụng hiện có sang KMM. Thay vào đó, chúng tôi bắt đầu nhỏ. Chúng tôi đã viết mã mới cho lớp mạng bằng KMM và chuyển qua quản lý phiên sang KMM bằng cách loại bỏ các phụ thuộc JVM (Máy ảo Java) hiện có. Sau khi hoàn thành công việc này, chúng tôi chỉ sử dụng KMM cho các tính năng mới do chúng tôi xây dựng.

‘Cho đến nay, các tính năng trong ứng dụng sử dụng KMM là:

Trung tâm Thông báo. Đây là nơi người dùng có thể xem tổng quan về tất cả các cảnh báo về đội xe của họ. Thành phần này sử dụng cơ sở dữ liệu SQL được chia sẻ.
Lịch sử chuyến đi. Người dùng có thể xem lịch sử chuyến đi của phương tiện, tài xế và tài sản.
Cài đặt Push notification. Người dùng có thể kiểm soát những cảnh báo mà họ muốn nhận Thông báo đẩy trên thiết bị của họ.
Các nhóm. Người dùng có thể lọc dữ liệu nhóm của họ, dựa trên các nhóm khác nhau do người dùng tạo.’

Dưới đây là ảnh chụp màn hình về giao diện của các tính năng này trên iOS và Android:

*Nhóm và Trung tâm thông báo: cả hai tính năng được viết bằng Kotlin Multiplatform Mobile.*

*Cài đặt thông báo đẩy và Lịch sử chuyến đi trong ứng dụng Motive Fleets. Giao diện người dùng gần như giống hệt nhau trên iOS và Android.*

Việc xây dựng các ứng dụng iOS và Android riêng biệt dẫn đến câu hỏi: ‘chúng ta có thể không chỉ sử dụng mã dùng chung không?’ Đây là điều mà nhiều CEO, chuyên gia sản phẩm và thậm chí nhiều kỹ sư di động sẽ hỏi. Đối với khách hàng, họ thường không quan tâm ứng dụng dành cho thiết bị di động sử dụng công nghệ nào và mong đợi chức năng gần như giống nhau trên iOS, Android và thường là trên web.

Một tháng trước, chúng tôi đã khám phá liệu có sự sụt giảm tuyển dụng iOS và Android bản địa tại các startup hay không. Câu trả lời là sắc thái, nhưng tôi đã lưu ý rằng:

‘Ngày nay, Flutter và React Native cuối cùng cũng “đủ tốt” cho các ứng dụng không yêu cầu hiệu năng cao.’

Trong trường hợp của Motive, hiệu suất đủ quan trọng để không chuyển sang React Native hoặc Flutter, họ cũng không sẵn sàng vứt bỏ mã hiện có mà họ đã viết và chuyển sang một tech stack khác.

Tuy nhiên, việc giới thiệu KMM không phải là vấn đề nhỏ, vì hiện tại, một phần tốt của quá trình phát triển đã được thực hiện với Kotlin, đây là ngôn ngữ mà các kỹ sư iOS và Android đều phải làm quen. Và trong trường hợp ứng dụng dành cho thiết bị di động, lợi ích của việc không phải kiểm thử hai triển khai logic nghiệp vụ riêng biệt trên OS và Android là giúp tiết kiệm thời gian thử nghiệm và giảm khả năng xảy ra mâu thuẫn logic nghiệp vụ.

Tôi đã hỏi Sunil rằng anh ấy cảm thấy thế nào về việc di chuyển và thực hiện tất cả công việc để cấu trúc lại mã nhằm tận dụng KMM stack. Anh ấy nói rằng anh ấy hài lòng với quyết định này và ước tính chu kỳ phát triển của họ hiện nhanh hơn khoảng một phần ba so với trước đây, nhờ vào logic kinh doanh thống nhất của Android/iOS. Quan trọng nhất, họ không còn phải đợi trên iOS nữa, ngay cả khi họ có ít băng thông iOS hơn.

Tổng kết

Vấn đề Kỹ thuật trong thế giới thực số này tập trung vào các nghiên cứu điển hình trong đó các nhóm đã chọn công nghệ mới để giải quyết các vấn đề khó khăn hiện có. Với nhiều ví dụ khác nhau, tôi hy vọng nó làm nổi bật quá trình lựa chọn công nghệ mới và cách các nhóm xử lý việc thay đổi.

Chúng ta đã đề cập đến các nghiên cứu điển hình bao gồm việc chọn hàng đợi nhắn tin mới, tái cấu trúc ứng dụng web thành mô hình kiến trúc mới, chọn ngôn ngữ sẽ được sử dụng ở 1 startup và chuyển sang logic kinh doanh iOS và Android được chia sẻ. Đối với tôi, các yếu tố nổi bật là phương pháp đáng để xem xét, bao gồm:

Khi thay đổi công nghệ, hãy đảm bảo rằng bạn giải quyết được một điểm yếu đủ lớn. Thay đổi công nghệ – chẳng hạn như thay thế framework hoặc chọn cách tiếp cận kiến trúc mới – là những thay đổi tốn kém về thời gianài nguyên quá cao đã khiến nó trở nên đáng giá. Điều này có đúng trong trường hợp sử dụng của bạn không?
Khi xây dựng một dự án mới, hãy nghĩ về những điểm khó khăn trong tương lai. Khi bạn bắt đầu xây dựng một thứ gì đó mới, bạn cần ít lý do hơn để lựa chọn bất kỳ công nghệ nào vì bạn không phải trả bất kỳ chi phí nào cho việc chuyển đổi. Tuy nhiên, hãy cố gắng chọn một công nghệ giúp bạn tránh – hoặc giải quyết – các vấn đề nhức nhối trong tương lai. Đây là những gì MetalBear đã làm bằng cách dự đoán rằng Rust sẽ làm cho nhiều trường hợp sử dụng trong tương lai của họ trở nên dễ dàng hơn để giải quyết, trên hết là phù hợp ngay bây giờ.
Khi thay đổi công nghệ, hãy thực hiện từng bước một nếu có thể. Khi chuyển sang Micro Frontends và khi giới thiệu KMM, trước tiên, nhóm đã tạo nguyên mẫu cho phương pháp này, sau đó cung cấp một tính năng sử dụng nó, rồi bắt đầu xây dựng các tính năng mới với phương pháp mới.
Trở lại việc cấu trúc lại mọi thứ không nhất thiết là một cách tiếp cận thực dụng. Khi thay đổi hoàn toàn công nghệ – chẳng hạn như chọn phương thức nhắn tin mới – bạn có thể không có lựa chọn nào khác ngoài việc thay thế công nghệ hiện tại của mình. Tuy nhiên, khi thay đổi cách tiếp cận kiến trúc hoặc thực hiện những thay đổi lớn, cách tiếp cận “mọi thứ phải diễn ra” có thể có ý nghĩa hơn. Cả Birdie với Micro Frontends và Motive với KMM, đều chưa chuyển tất cả mã hiện có của họ sang phương pháp hoặc khung mới, ít nhất là chưa.

Tuy nhiên, bài học lớn nhất của tôi là:

Đừng quên ưu tiên số 1 của bạn, với tư cách là một nhóm kỹ sư. Thước đo thành công lớn nhất cho nhóm của bạn là gì? Đối với Birdie, Steve Heyes nói rằng “người dùng sẽ có thể hoàn thành công việc họ cần.” Hãy tự trả lời câu hỏi và đảm bảo rằng bạn ghi nhớ ưu tiên đó: nó chắc chắn đến trước công nghệ bạn chọn để làm việc.

Nguồn: Pragmaticengineer.com

Tags birdie, kafka, kotlin multiplatform mobile, metalbear, micro frontend, motive, trello

Dev's Corner

5 Tính năng hàng đầu trên Java 17. Không biết là không được đâu!

Post author By Gambaru
Post date 15 November, 2022
No Comments on 5 Tính năng hàng đầu trên Java 17. Không biết là không được đâu!

Thay đổi là điều duy nhất bất biến và theo Thuyết tiến hoá của Darwin, cá thể thích nghi với thế giới đang ngày càng phát triển sẽ có khả năng sinh tồn lâu dài. Có vẻ như lý thuyết này cũng đúng với Java, vì nó liên tục phát triển và phục vụ trong hơn hai thập kỷ.

Từ JDK 1.0 đến Java 17 (LTS), Java đã trải qua một chặng đường dài. Java 17 là bản phát hành hỗ trợ dài hạn (LTS) mới nhất cho nền tảng SE, được phát hành vào ngày 15 tháng 9 năm 2021 và có một gói tính năng mà chúng ta không nên bỏ qua nếu chưa tự tay khám phá.

Việc bổ sung tính năng trong bất kỳ ngôn ngữ lập trình nào sẽ cải thiện hiệu suất của nó và do đó giúp cho code phức tạp trở nên dễ dàng. Chẳng hạn, C# ban đầu là một bản sao của Java nhưng việc thêm nhiều tính năng hơn vào nó đã sinh ra C#.

Mặc dù có nhiều tính năng được giới thiệu trong Java 17, nhưng trong bài viết này, chúng ta sẽ thảo luận về…

5 Tính năng hàng đầu của Java 17

Dừng lại chút nào, nếu bạn đang #open_to_work, thử nghía qua các công việc đang tuyển trên Gamba nhé. Vào LINK NÀY để xem các job cần đến kỹ năng về Java hoặc scan QR Code ở bên dưới nhé.

1. Hạn chế triển khai với các Sealed classes và Giao diện

Sealed class là một tính năng xem trước trong JDK 15 và giờ đây đã trở thành một tính năng hoàn chỉnh trong JDK 17.

Khi tính kế thừa (inheritance) được giới thiệu, mọi người đã có nhiều ý kiến trái chiều vì nó không hạn chế số lượng triển khai. Các sealed class chấm dứt điều này vì đây là một tính năng mà người ta có thể hạn chế việc triển khai.

Để giải quyết vấn đề, sealed class cho chúng ta đặc quyền kiểm soát những lớp hoặc mô hình nào có thể triển khai hoặc mở rộng giao diện / lớp đó tương ứng. Nó đại diện cho các hệ thống phân cấp lớp bị hạn chế cung cấp quyền kiểm soát đối với tính kế thừa.

Đối với một sealed class, tất cả các lớp con trực tiếp cần phải được biết tại thời điểm biên dịch và ứng dụng khách bên thứ ba không thể mở rộng sealed class trong code của chúng.

Để tạo một lớp Java, một sealed Java class, cứ thêm sealed modifier vào khai báo của nó và từ khóa cho phép được đặt để chỉ ra các lớp được phép đối với sealed class đã cho.

Lớp niêm phong Fruit chỉ định ba lớp con được phép, Square, Rectangle, và Circle:

package com.geeksforgeeks.example.figures

public sealed class Shape permits, Square, Rectangle, Circle { }

2. Sử dụng Null trong Switch Case hiện đã hợp lệ

Trước đây, việc giữ biểu thức bộ chọn là null trong câu lệnh chuyển đổi và biểu thức được sử dụng để ném NullPointerException (NPE, là một ngoại lệ xảy ra khi lập trình viên tham chiếu đến đối tượng nhưng nó không có vị trí bộ nhớ) và về cơ bản chúng ta phải ném Null Pointer Exception vào phía an toàn hơn.

Để giải quyết vấn đề này, Java 17 đã đưa ra một tính năng mà trong đó chúng ta có thể đặt null làm biểu thức bộ chọn (selector expression) trong biểu thức switch case. Hãy xem ví dụ dưới đây, nơi chúng ta có thể chuyển null làm biểu thức bộ chọn.

switch(checkNumber) {

case 1,7 -> System.out.println(“odd number”) ;

case 2,8 -> System.out.println(“even number”) ;

case null -> System.out.println(“Not defined”) ;

default -> System.out.println(“not a number”) ;
}

Ở đây, biến checkNumber lấy một số làm đầu vào. Nếu null được truyền dưới dạng đầu vào, thì “Không được định nghĩa” được hiển thị dưới dạng đầu ra.

Lưu ý rằng, đối với trường hợp 1,7 và trường hợp 2,8, các số chẵn và lẻ khác cũng sẽ được sử dụng trong biểu thức bộ chọn để mã hoạt động đúng. Chỉ một số ít được thực hiện để duy trì tính đơn giản của ví dụ.

3. Chấm dứt việc đoán nguyên nhân của NPE

Có thể nó hoạt động với các danh sách được liên kết hoặc chỉ một đoạn mã có tham chiếu đến một đối tượng, luôn có nguy cơ tham chiếu đến một đối tượng rỗng có thể khiến mọi thứ trở nên tồi tệ nếu không được xử lý tốt.

Debugging và nhật ký Java có thể hữu ích nhưng bản thân debugging là một nhiệm vụ mất thời gian và nhật ký java không tốt trong việc cung cấp thông tin chi tiết về đối tượng thủ phạm đã gây ra NullPointerException.

Ở đây, tính năng hướng dẫn NullPointerException của Java 17 thực sự là một người bạn vì nó cung cấp tên chính xác của biến null từ stack trace (báo cáo) của ngoại lệ.

Do đó, tính năng này giúp chúng ta tránh khỏi rắc rối khi gỡ lỗi và kết thúc trò chơi mò mẫm tìm ra con trỏ không có giá trị.

4. Định nghĩa lại các biểu thức câu lệnh Switch (switch statement)

Quên một dấu ngắt giữa nhiều dòng câu lệnh switch-case hoàn toàn không phải là điều hay ho gì. Hơn nữa, mô hình case-break-case-break dường như không phải là một thỏa thuận tốt khi xử lý nhiều switch case.

Nhưng giờ thì chúng ta không cần phải break với việc sử dụng break thường xuyên nữa! Java đã giải quyết mối lo ngại này và ở đây chúng ta trình bày các biểu thức câu lệnh chuyển đổi mới trong Java 17.

Các biểu thức chuyển đổi mới ít bị lỗi hơn vì nó sạch và đơn giản hơn. Việc sử dụng các biểu tượng mũi tên không chỉ loại bỏ chức năng không chạy mà còn làm cho nó dễ đọc hơn và dễ gỡ lỗi hơn.

Chúng ta có thể đưa vào nhiều hơn một giá trị trong cùng một khối bằng dấu phẩy phân tách chúng.

Một trong những tính năng quan trọng là việc giới thiệu yield keyword. Trong đoạn code, khi thực thi câu lệnh mặc định, System.out.println() sẽ thực thi và biến identifyTyres sẽ kết thúc bằng “Unknown vehicle” vì đây là kết quả mặc định có nghĩa là mang lại.

String identifyTyres = switch (vehicle) {  

                                   case Car  -> “four”;  

                                   case Bike, Cycle  -> “two”;  

                                   case Autorickshaw  -> “three”;

                                   default  -> { System.out.println(“The vehicle could not be found.”);  

                                                      yield “Unknown Vehicle”;  

                                    };

5. Giảm dòng có với Lớp bản ghi (Record classes)

Các record class đã được xem trước trong Java 14. Mã POJO phức tạp và xấu nhất trông đẹp hơn khi được triển khai với Bản ghi. Cả hai đều bất biến và cuối cùng. Các trường của Bản ghi không thể thay đổi sau khi tạo và phần mở rộng của lớp Bản ghi cũng không được phép. Chúng chính là các lớp chỉ chứa dữ liệu quản lý mã soạn sẵn của POJO.

Bản ghi rất hữu ích bởi tất cả những gì chúng ta muốn là tạm thời giữ dữ liệu không thay đổi.

Trong đoạn mã, Dữ liệu là một bản ghi và a và b được gọi là các thành phần của bản ghi Dữ liệu. Khi định nghĩamột bản ghi, chúng ta nhận được một phương thức equals(), phương thức hashcode() đã được triển khai và triển khai phương thức toString() để in các thành phần bản ghi cùng với tên thành phần.

record Data(long a, long b) { }

Dữ liệu Bản ghi ở trên tương đương với các dòng mã sau:

public final class Data {

   private final long a;

   private final long b;

   Public Data(long a, long b) {

       this.a = a;

       this.b = b;

   }

   long a() { return this.a; }

   long b()  { return this.b; }

    // Implementation of equals() and hashCode(), which specify

     public boolean equals…

     public int hashCode…

    // An implementation of toString() that returns a string

     public String toString() {…}

}

Trên đây là 5 tính năng hàng đầu của Java 17 LTE.

Hãy thừa nhận rằng chúng ta luôn quan tâm đến các tính năng mới, có thể là điện thoại di động, tivi, máy giặt, v.v. Java cũng không kém trong trường hợp này và nó luôn khiến chúng ta ngạc nhiên với những cải tiến và giới thiệu các tính năng mới.

Việc thử nghiệm các tính năng mới trong mã Java không chỉ nâng cao kiến thức của chúng tôi trong lĩnh vực Java mà còn giúp chúng tôi có động lực học hỏi và nâng cao kỹ năng bản thân. Java 17 LTE là một điểm cộng lớn vì các tính năng này có thể chấp nhận được và giúp các nhà phát triển Java thực hiện các tác vụ dễ dàng hơn.

Tham khảo: GeeksforGeeks

Tags Java, java 17

Dev's Corner

Pen Test (trong Cyber Security) là gì?

Post author By Gambaru
Post date 3 November, 2022
No Comments on Pen Test (trong Cyber Security) là gì?

Kiểm tra thâm nhập, còn được gọi là Pen Test (Penetration Testing), là một quy trình an ninh mạng giúp bạn vượt lên trước tin tặc. Trong một pentest, một tin tặc (hacker) có “phẩm chất đạo đức” sẽ tìm ra các lỗ hổng bảo mật trong ứng dụng, mạng hoặc hệ thống của bạn và giúp bạn sửa chúng trước khi những kẻ tấn công nhận ra những vấn đề này và khai thác chúng.

Điều này làm cho Pen testing trở thành một bước cơ bản không thể thiếu đối với một trang web hoặc chủ sở hữu doanh nghiệp. Chúng ta hãy tìm hiểu sâu hơn về Pen Test và những gì mong đợi từ nó.

Pen test (trong An ninh mạng) là gì?

Pen Test (Kiểm tra thâm nhập) là phương pháp để đánh giá tính bảo mật của một ứng dụng hoặc mạng bằng cách khai thác một cách an toàn bất kỳ lỗ hổng bảo mật nào có trong hệ thống.

Các lỗi bảo mật này có thể xuất hiện trong nhiều khu vực khác nhau như cài đặt cấu hình hệ thống, phương thức đăng nhập và thậm chí cả các hành vi mang tính rủi ro của người dùng cuối.

Ngoài việc đánh giá an ninh, pen test rất cần thiết để đánh giá hiệu quả của các hệ thống phòng thủ và chiến lược an ninh.

Pen test thường bao gồm các bài kiểm tra thủ công và tự động, nhằm mục đích vi phạm tính bảo mật của ứng dụng với sự ủy quyền thích hợp.

Khi các lỗ hổng được phát hiện và khai thác, khách hàng sẽ được cung cấp một báo cáo kiểm tra thâm nhập chi tiết chứa thông tin về phạm vi kiểm tra, các lỗ hổng được tìm thấy, mức độ nghiêm trọng và các đề xuất để vá chúng.

Pen test khác với Đánh giá lỗ hổng như thế nào?

Đánh giá lỗ hổng (Vulnerability Assessment):

Đánh giá lỗ hổng tập trung vào việc phát hiện và phân loại các lỗ hổng trong hệ thống.
Đây là một quy trình chủ yếu tự động liên quan đến các công cụ quét lỗ hổng bảo mật.
Hầu như không thể đảm bảo dương tính giả zero (zero false positives) với đánh giá lỗ hổng bảo mật tự động.
Đánh giá lỗ hổng thường bỏ sót các lỗ hổng nghiêm trọng và phức tạp.
Đánh giá lỗ hổng bảo mật tự động tốn ít thời gian và tiền bạc hơn đáng kể so với pen test.

Pen test:

Pen test bao gồm việc khai thác các lỗ hổng để rút ra những hiểu biết sâu sắc về chúng.
Pen test yêu cầu can thiệp thủ công trên quét tự động.
Pen tester thủ công có thể đảm bảo dương tính giả zero.
Nhờ vào yếu tố con người của pen test, nó phát hiện các lỗi logic nghiệp vụ mà vẫn không bị phát hiện trong quá trình quét lỗ hổng.
Kiểm tra thâm nhập là một thủ tục tốn kém và tốn kém và vì lý do chính đáng.

Thuật ngữ Pen test xuất hiện trong nửa sau của thuật ngữ VAPT, là viết tắt của Đánh giá lỗ hổng và Kiểm tra thâm nhập (Vulnerability Assessment and Penetration Testing).

*Khác biệt giữa Pen test và Vulnerability Assessment*

Mọi người nhầm lẫn giữa VA (Đánh giá lỗ hổng) và PT (Kiểm tra thâm nhập) là cùng một quy trình và sử dụng chúng thay thế cho nhau. Thực ra, chúng không được và không nên đổi chỗ cho nhau. Sự khác biệt giữa chúng là rất quan trọng khi đánh giá xem nó phù hợp với các yêu cầu như thế nào. Cả hai đều là những phương thức đánh giá bảo mật cần thiết giúp củng cố vị thế bảo mật cho ứng dụng của bạn.
Mục đích của VA là để tìm và cảnh báo người dùng về bất kỳ lỗi bảo mật nào có trong mục tiêu. Trong khi Pen Test khai thác các lỗ hổng được tìm thấy trong VA để xác định mức độ thiệt hại có thể xảy ra. Các quy trình quét lỗ hổng thường là quy trình tự động, còn Pentest chủ yếu được thực hiện thủ công.
VA chủ yếu được thực hiện bởi các kỹ thuật viên có trình độ bằng cách sử dụng các công cụ tự động, kết quả của chúng sau đó được tổng hợp và chứng thực. Trong khi đó, PT thường được thực hiện bởi các hacker mũ trắng hoặc các hacker có đạo đức. Họ là những chuyên gia bảo mật và mang yếu tố con người để đột nhập vào một hệ thống. Trong Pen testing, đánh giá lỗ hổng có thể được sử dụng trong các bước ban đầu để xác định mục tiêu và các vectơ tấn công (attack vector) tiềm năng.
Chi phí là một yếu tố khác phân biệt hai yếu tố này. So với Pentesting, VA có chi phí thấp hơn. Các báo cáo quét lỗ hổng bảo mật chủ yếu chứa danh sách các lỗ hổng bảo mật và mô tả chi tiết về các lỗ hổng này. Mặc dù các báo cáo của PT thường chứa các lỗ hổng được xếp hạng theo mức độ nghiêm trọng, dễ khai thác và rủi ro.
Cả hai quy trình này đều có tính chất bổ sung và thường được thực hiện cùng nhau, trong một quy trình kết hợp được gọi là VAPT, hoặc Kiểm toán bảo mật (Security Audit).

Pen test cho các tổ chức và tại sao nó lại quan trọng?

Tại sao một tổ chức cần pen test thường xuyên?

Bối cảnh mối đe dọa mạng đang ở trong tình trạng thay đổi liên tục. Các lỗ hổng mới được phát hiện và khai thác thường xuyên, một số trong số chúng được công nhận công khai và một số thì không. Cảnh giác là điều tốt nhất bạn có thể làm.

Web pen test giúp bạn loại bỏ tận gốc các lỗ hổng trong hệ thống có thể dẫn đến vi phạm bảo mật, đánh cắp dữ liệu và từ chối dịch vụ.

Pen test không chỉ phát hiện ra các lỗ hổng thông thường với sự trợ giúp của các công cụ tự động và tìm ra các vấn đề bảo mật phức tạp hơn như lỗi logic nghiệp vụ và các vấn đề liên quan đến cổng thanh toán.

Nó giúp bạn có bức tranh rõ ràng hơn về tình hình bảo mật của tổ chức và khắc phục các vấn đề để tăng cường khả năng bảo mật của bạn.

Mục đích chính để tiến hành pentest thường xuyên là:

Bắt kịp với bối cảnh mối đe dọa mạng đang thay đổi
Tìm và giảm thiểu các lỗi logic nghiệp vụ
Chuẩn bị cho kiểm toán tuân thủ
Cứu doanh nghiệp của bạn khỏi vi phạm bảo mật.

Pen test có những cách tiếp cận nào?

*Các cách tiếp cận trong Pen test (Ảnh: Redscan)*

Có 3 cách tiếp cận được người kiểm tra áp dụng liên quan đến pen test, dựa trên thông tin có sẵn và loại điểm yếu được tìm thấy:

1. White box (hộp trắng)

Trong bài kiểm tra chiếc hộp trắng, người kiểm tra có đầy đủ kiến thức về hệ thống và có toàn quyền truy cập.

Mục tiêu của cách tiếp cận này là tiến hành kiểm tra sâu hệ thống và thu thập càng nhiều thông tin càng tốt.

Lợi thế, trong trường hợp này, là vì người thử nghiệm có quyền truy cập và kiến thức về hệ thống, bao gồm chất lượng mã và thiết kế bên trong, nên Pen test có thể xác định ngay cả các lỗ hổng được định vị từ xa, do đó đưa ra bức tranh gần như đầy đủ về bảo mật.

2. Black box (hộp đen)

Bạn đã đoán đúng, trong cách tiếp cận này, người kiểm tra không có kiến thức về hệ thống và thiết kế bài kiểm tra như một kẻ tấn công không được hiểu biết.

Cách tiếp cận này là gần nhất với một cuộc tấn công trong thế giới thực và liên quan đến mức độ kỹ thuật cao. Cách tiếp cận này có thời gian dài nhất và chi phí cao hơn so với phương pháp hộp trắng.

3. Gray box (Hộp xám)

Như tên cho thấy, cách tiếp cận này nằm giữa kiểm tra hộp trắng và hộp đen. Người kiểm tra chỉ có kiến thức hạn chế về hệ thống.

Ưu điểm của phương pháp này là với lượng kiến thức hạn chế, người thử nghiệm có khu vực tấn công tập trung hơn và do đó tránh được bất kỳ phương pháp tấn công thử-và-sai nào.

3 Loại Pen test

1. Network Pen Test

Mục tiêu của loại pen test này là tìm ra các lỗ hổng trong cơ sở hạ tầng mạng, môi trường on-premise hoặc môi trường đám mây như pen test trên Azure và AWS.

Đây là một trong những bài kiểm tra cơ bản và cũng là một bài kiểm tra quan trọng để bảo vệ dữ liệu của bạn và tính bảo mật của ứng dụng của bạn.

Trong thử nghiệm này, một loạt các lĩnh vực như cấu hình, mã hóa và các bản vá bảo mật lỗi thời sẽ được thử nghiệm và kiểm tra.

Network Pen test được chia thành các loại:

1.1 Pentest bên ngoài

Kịch bản này mô phỏng một cuộc tấn công từ người ngoài có quyền truy cập internet và không có kiến thức trước về hệ thống.

Người kiểm tra sẽ cố gắng đột nhập vào hệ thống của bạn bằng cách khai thác các lỗ hổng từ bên ngoài và truy cập vào dữ liệu và hệ thống nội bộ.

1.2 Pentest nội bộ

Loại này liên quan nhiều hơn đến việc kiểm tra ứng dụng của bạn từ bên trong và tập trung vào môi trường nội bộ.

Tiền giả định, trong trường hợp này, là những kẻ tấn công đã có thể xâm phạm lớp bên ngoài và đã ở trong mạng.

Các mối đe dọa bên ngoài rủi ro hơn các mối đe dọa bên trong vì việc giành quyền truy cập vào các mạng nội bộ là kết quả của việc vi phạm các giao thức bảo mật bên ngoài.

Vì vậy, việc bắt đầu với một pen test bên ngoài là một ý tưởng tốt.

Dưới đây là một số pen test mạng đã được thực hiện:

Kiểm tra bộ định tuyến
Bỏ qua tường lửa
Dấu chân DNS
Loại bỏ IPS / IDS
Quét và kiểm tra các cổng đang mở
Các cuộc tấn công SSH
Kiểm tra trên máy chủ proxy

2. Pen test ứng dụng web

Mục đích của việc này là phát hiện ra các lỗi bảo mật trong các trang web, nền tảng thương mại điện tử (như Magento, PrestaShop, v.v.), phần mềm quản lý quan hệ khách hàng và hệ thống quản lý nội dung,…

Thử nghiệm này kiểm tra toàn bộ ứng dụng bao gồm các chức năng được xây dựng tùy chỉnh và logic nghiệp vụ, để bảo vệ khỏi vi phạm dữ liệu và các cuộc tấn công khác.

Với sự gia tăng của các ứng dụng dựa trên web, không có gì lạ khi lượng dữ liệu khổng lồ được lưu trữ và truyền qua các ứng dụng này trở thành mục tiêu hấp dẫn đối với những kẻ tấn công mạng.

Các tổ chức và cá nhân có ứng dụng web phải tiến hành kiểm tra định kỳ để cập nhật các phương pháp tấn công mới nhất và các lỗi bảo mật. Một số lỗ hổng phổ biến bao gồm:

Mã hóa không dây và lưu lượng mạng
Các điểm truy cập và điểm phát sóng không được bảo vệ
Giả mạo địa chỉ MAC
Thông tin đăng nhập yếu
Các cuộc tấn công DDoS (Từ chối Dịch vụ Phân tán)
Các cuộc tấn công chèn mã / SQL
XSS (Cross-Site Scripting)
Máy chủ web bị định cấu hình sai
Cơ sở dữ liệu trang web

3. Social Engineering

Không giống như các kiểm tra ở trên, nơi khía cạnh kỹ thuật của ứng dụng được xem xét kỹ lưỡng, trong kỹ thuật xã hội (social engineering), tâm lý con người được rà soát tới.

Người thử nghiệm tận dụng và khai thác bản chất con người để đột nhập vào một hệ thống trong pen test kỹ thuật xã hội.

Thông qua thao tác, người kiểm tra sẽ dụ dỗ cá nhân tiết lộ thông tin nhạy cảm sẽ được sử dụng để xâm nhập hệ thống và lên kế hoạch cho các cuộc tấn công tiếp theo.

Một số phương pháp tấn công phổ biến là:

Tấn công lừa đảo
Giả làm đồng nghiệp, nhà thầu hoặc nhà cung cấp
Nối đuôi nhau
Lặn dumpster
Nghe trộm
Bluesnarfing

Mặc dù pen test loại này không được thực hiện rộng rãi, nhưng cần phải có một bức tranh toàn cảnh về các tiêu chuẩn bảo mật của ứng dụng của bạn.

7 Bước tiến hành Pen Test

Cần phải lập kế hoạch pen test chi tiết và chặt chẽ để việc thực thi được thành công.

Có 7 giai đoạn trong thử nghiệm thâm nhập:

Bước 1: Phân tích trước khi tương tác

Trước khi lập kế hoạch kiểm tra, bạn bắt buộc phải cùng với nhà cung cấp bảo mật của mình thảo luận về các chủ đề như phạm vi kiểm tra, ngân sách, mục tiêu, v.v. Nếu không có những điều này, sẽ không có đủ định hướng rõ ràng cho kiểm tra và sẽ dẫn đến rất nhiều nỗ lực lãng phí.

Bước 2: Thu thập thông tin tình báo

Trước khi bắt đầu áp dụng, người thử nghiệm sẽ cố gắng tìm tất cả thông tin công khai có sẵn về hệ thống và bất kỳ thông tin nào có thể giúp xâm nhập. Những thông tin này sẽ hỗ trợ việc tạo ra một kế hoạch hành động cũng như tiết lộ các mục tiêu tiềm năng.

Bước 3: Đánh giá lỗ hổng bảo mật

Trong giai đoạn này, ứng dụng của bạn được kiểm tra các lỗ hổng bảo mật bằng cách phân tích cấu hình và cơ sở hạ tầng bảo mật của bạn. Người kiểm tra tìm kiếm bất kỳ lỗ hổng bảo mật hoặc sơ hở nào có thể bị lợi dụng để đột nhập vào hệ thống.

Bước 4: Khai thác

Một khi người kiểm tra được trang bị kiến thức về các lỗ hổng có trong hệ thống, họ sẽ bắt đầu khai thác chúng. Điều này sẽ giúp xác định bản chất của các lỗ hổng bảo mật và nỗ lực cần thiết để khai thác chúng.

Bước 5: Hậu khai thác

Mục tiêu chính của pentest là mô phỏng một cuộc tấn công trong thế giới thực, trong đó những kẻ tấn công sẽ gây ra thiệt hại thực sự sau khi khai thác các lỗ hổng bảo mật trong hệ thống. Do đó, một khi người thử nghiệm có thể vào hệ thống, họ sẽ sử dụng tất cả các phương tiện có sẵn để nâng cao đặc quyền của họ.

Bước 6: Duy trì quyền truy cập

Khi những kẻ tấn công có quyền truy cập vào hệ thống, chúng cố gắng giữ cho một kênh mở để khai thác thêm thông qua backdoor và rootkit. Điều tương tự cũng được thực hiện bởi những người thử nghiệm. Họ cài đặt phần mềm độc hại và các chương trình khác để giữ cho hệ thống bị nhiễm và kiểm tra xem các chương trình này có bị ứng dụng phát hiện và gỡ bỏ hay không.

Bước 7: Báo cáo

Mọi thứ được thực hiện trong quá trình pen test đều được ghi lại một cách chi tiết cùng với các bước và đề xuất để sửa các lỗi bảo mật. Vì bản chất của báo cáo là rất nhạy cảm, nó được đảm bảo rằng nó được chuyển đến người có thẩm quyền một cách an toàn. Người kiểm tra thường có các cuộc họp và trao đổi với giám đốc điều hành và nhóm kỹ thuật để giúp họ hiểu báo cáo.

Tham khảo: Getastra

Tags kiểm tra thâm nhập, pen test, penetration testing, vulnerability assessment

Dev's Corner

Clean Code là gì? Tại sao developer nên quan tâm đến Clean code?

Post author By Gambaru
Post date 3 October, 2022
No Comments on Clean Code là gì? Tại sao developer nên quan tâm đến Clean code?

Những năm qua, tôi ngày càng quan tâm đến khái niệm Clean Code và Software Craftsmanship. Tuy nhiên, những khái niệm này thực sự có nghĩa là gì và tại sao các nhà phát triển phần mềm nên quan tâm đến chúng, hay thực sự có nên quan tâm đến chúng?

Trong bài này, tôi sẽ thảo luận về các vấn đề khác nhau liên quan đến khái niệm Clean Code và ý nghĩa thực sự của nó, hy vọng cung cấp một số hiểu biết hữu ích dựa trên kinh nghiệm của mình trong quá trình phát triển phần mềm doanh nghiệp.

*Clean Code là gì? Ảnh: cleancoders.com*

Hầu hết mọi thứ trong cuộc sống đều mang tính chủ quan.

Cho 3 người bất kỳ vào một phòng và hầu như bạn luôn có những ý kiến khác nhau về bất kỳ chủ đề nhất định nào.

Nếu có bất cứ điều gì mà con người chúng ta làm tốt, thì đó là khả năng bất đồng của chúng ta. Dù cuối cùng chúng ta có thể đạt được một số đồng thuận, nhưng nếu hỏi bất kỳ ai sau đó và bạn sẽ nhận ra rằng sự đồng thuận không gì khác hơn là một thỏa thuận cho sự bất đồng.

Trong phần lớn sự nghiệp làm phần mềm của mình, tôi tin rằng có một số luật bất thành văn, nếu bạn hỏi bất kỳ nhà phát triển nào về chất lượng code của một nhà phát triển khác, và bất kể họ đã xem hay chưa, họ gần như sẽ nói code dở tệ!

Các nhà phát triển phần mềm (software developer) thậm chí không thể đi đến đồng thuận về ngôn ngữ lập trình nào là tốt nhất.

Tôi đã từng là nhân chứng cho một trong những tranh luận lớn này, tại một thời điểm điên rồ của ban quản lý, ai đó đã quyết định đưa một loạt các Lập trình viên C++, C# và Java vào làm việc tất cả trong một phòng trong nhiều tháng. Tôi có thể nói với bạn rằng, cuộc tranh đấu đã diễn ra trong nhiều tháng, và tôi không nghĩ rằng họ đã đạt được sự đồng thuận!

Những người trong phòng nói trên, thậm chí không thể đi đến thống nhất về cách tốt nhất để pha cà phê hoặc cách phát âm. Tôi có thể nói, Java chắc chắn không được xếp hạng là loại cà phê ưa thích!

Theo như tôi biết, các lập trình viên Java vẫn lập trình bằng trong Java, C# thì vẫn bằng C# và C++ thì vẫn đang cố gắng tìm vị trí các con trỏ và tại sao bộ đệm lại bị tràn!

Clean Code là gì?

Điểm chung giữa 3 nhóm này là họ đều tin rằng chọn lựa và ngôn ngữ lập trình ưa thích của mình đã giúp họ viết được Clean Code!

Điều này chỉ khiến ai đó giả định rằng Clean Code, chỉ là một vấn đề mang tính chủ quan cao. Nó cũng có nghĩa là một cái gì đó hoàn toàn khác, tùy thuộc vào vị trí trong chuỗi Phát triển Phần mềm mà bạn ngồi.

Qua nhiều năm, tôi đã đi tới kết luận rằng có rất nhiều định nghĩa về clean code mà các developer dường như đồng ý với nhau.

Clean code là code dễ hiểu và dễ thay đổi.

Định nghĩa phổ biến nhất của clean code là code dễ hiểu và dễ thay đổi. Nhìn bề ngoài, điều này có thể khiến người ta phải gật đầu và vuốt cằm tán dương, nhưng cuối cùng thì đó là một trong những định nghĩa nói lên điều gì đó mà không thực sự nêu rõ bất cứ điều gì.

Theo định nghĩa đó, hoàn toàn bất kỳ code nào, đều có thể được phân loại là clean code. Ngay cả những code dưới đây có thể được coi là clean code. Nó dễ hiểu và tôi chắc chắn có thể thay đổi nó một cách dễ dàng.

void FixTheCondition(object aCondition, object someCriteria)
{
     if(aCondition != someCriteria)
     {
        doSomethingToFix(aCondition)
     }
}

Tôi chắc chắn rằng code này tuân thủ một số tiêu chí khiến nó dễ hiểu

dễ hiểu luồng thực thi của toàn bộ ứng dụng
dễ hiểu cách các đối tượng khác nhau cộng tác với nhau
dễ hiểu vai trò và trách nhiệm của từng lớp
dễ hiểu những gì mỗi phương pháp làm
dễ hiểu mục đích của từng biểu thức và biến là gì

Code này cũng dễ dàng mở rộng và refactor cũng như dễ dàng sửa các lỗi trong cơ sở mã. Điều này có thể đạt được nếu người thực hiện thay đổi hiểu được code và cũng cảm thấy tin tưởng rằng những thay đổi được giới thiệu trong code không phá vỡ bất kỳ chức năng hiện có nào.

Ai đó có thể lập luận rằng để code dễ thay đổi:

Các lớp và phương thức nhỏ và chỉ có trách nhiệm duy nhất
Các lớp có API công khai rõ ràng và ngắn gọn
Các lớp và phương thức có thể dự đoán được và hoạt động như mong đợi
Có dễ dàng kiểm tra và có các bài kiểm thử đơn vị (hoặc dễ dàng viết các bài kiểm thử)
Các bài kiểm thử dễ hiểu và dễ thay đổi

Đoạn code trên, phù hợp với tất cả các tiêu chí. Chúng ta có thể coi đây là Clean code, nhưng nó có thực sự như vậy không?

Trong cả sự nghiệp của mình, tôi đã thấy nhiều cách diễn giải về cùng một đoạn code, trong hàng trăm ứng dụng. Ngay cả trong những thứ mà một số người sẽ cân nhắc và thậm chí được bán như một phần mềm doanh nghiệp có quy mô lớn. Trên thực tế, nếu bạn mở hầu hết bất kỳ ứng dụng phần mềm nào, bạn có thể sẽ tìm thấy các ví dụ tương tự.

Điều này có nghĩa là code thực sự clean code?

Ai quan tâm đến Clean code?

Một trong những vấn đề lớn nhất trong ngành phát triển phần mềm là không có nhiều người thực sự quan tâm đến clean code.

Đúng là có thể một tỷ lệ nhất định các nhà phát triển quan tâm đến clean code, nhưng theo kinh nghiệm, không phải tất cả họ đều làm trong cùng một nhóm và hầu hết có thể không ở nhóm của bạn.

Sự thật là, clean code cần thời gian, công sức, chú ý và chăm sóc, cả bốn giá trị mà phía kinh doanh không thực sự quan tâm. Lý do là Clean Code nằm trong tiêu chí Chất lượng của Tam giác chất lượng, một biến thể Tam giác quản lý dự án.

*Tam giác chất lượng (Quality triangle)*

Tam giác dự án thể hiện các ràng buộc về thời gian, chi phí và chất lượng hoặc phạm vi phải được quản lý trong quá trình thực hiện dự án. Mỗi ràng buộc được kết nối và việc di chuyển một điểm của tam giác sẽ tác động đến hai điểm còn lại.

Vì vậy, bạn có thể cung cấp code và triển khai ứng dụng nhanh chóng để đáp ứng các mục tiêu kinh doanh hoặc bạn có thể mất nhiều thời gian hơn để đảm bảo chất lượng của code được phát hành. Vấn đề là bạn không bao giờ có thể có cả hai, một thời điểm nào đó, cái gì đó phải bị gạt bỏ. Trong phần mềm, thường xuyên nhất chính là chất lượng.

Lý do chính tại sao, code thường là khía cạnh ít được nhìn thấy nhất của phát triển phần mềm.

Chắc chắn các nhà phát triển quan tâm đến nó, bạn sẽ thường nghe các nhà phát triển nói về “code đẹp” hoặc thậm chí là “code thanh lịch”, nhưng rất hiếm khi và tôi sẽ là người đầu tiên thừa nhận rằng tôi chưa bao giờ nghe nhận xét của người dùng cuối về tính thẩm mỹ của code. Sự thật là họ không quá quan tâm.

Điều duy nhất mà người dùng thường quan tâm với các ứng dụng phần mềm là nó giải quyết được vấn đề mà họ gặp phải. Bạn không cần code sạch, đẹp hoặc thậm chí thanh lịch để giải quyết vấn đề, điều này có thể được thực hiện chỉ với code.

Viết phần mềm Máy tính là một trong những hoạt động sáng tạo thuần túy nhất trong lịch sử loài người. Các lập trình viên không bị ràng buộc bởi các giới hạn thực tế như các định luật vật lý; chúng ta có thể tạo ra những thế giới ảo thú vị với những hành vi không bao giờ có thể tồn tại trong thế giới thực. Lập trình không yêu cầu kỹ năng thể chất hoặc sự phối hợp tuyệt vời như múa Ba lê hay Bóng đá. Tất cả những gì lập trình yêu cầu là đầu óc sáng tạo và khả năng sắp xếp suy nghĩ của bạn. Nếu bạn có thể hình dung một hệ thống, bạn có thể triển khai nó trong một chương trình máy tính.
Triết lý thiết kế phần mềm – John Ousterhout

Quản lý độ phức tạp

Nhiều người nghĩ rằng nhiệm vụ chính của một nhà phát triển phần mềm là viết code nhằm tạo ra các ứng dụng, điều này không hoàn toàn chính xác, bởi vì nhiệm vụ chính của một nhà phát triển phần mềm là quản lý sự phức tạp (Complexity).

Các nhà phát triển phần mềm nên sử dụng code để giấu hoặc loại bỏ sự phức tạp khi phát triển ứng dụng.

Sự phức tạp là kẻ thù của các ứng dụng phần mềm có quy mô lớn, mạnh và đáng tin cậy và các nhà phát triển cần đảm bảo họ không viết mã phức tạp.

Sự phức tạp là bất cứ thứ gì liên quan đến cấu trúc của một hệ thống phần mềm khiến nó khó hiểu và khó sửa đổi hệ thống.

Chìa khóa để viết clean code tốt là hiểu các triệu chứng của sự phức tạp và cách tránh nó.

1. Khuếch đại thay đổi (change amplification)

Một thay đổi có vẻ đơn giản đòi hỏi phải sửa đổi code ở nhiều nơi khác nhau. Mục tiêu ở đây là giảm số lượng code bị ảnh hưởng bởi mỗi quyết định thiết kế, giảm tác động của những thay đổi trong quyết định thiết kế đòi hỏi nhiều sửa đổi code.

2. Tải nhận thức (cognitive load)

Đây là mức thông tin hoặc kiến thức hệ thống bắt buộc mà nhà phát triển cần biết để hoàn thành một nhiệm vụ. Yêu cầu tải nhận thức càng cao, càng làm tăng khả năng phát sinh lỗi và nhà phát triển sẽ cần thời gian để hoàn thành nhiệm vụ.

3. Quản lý các ẩn số không xác định (unknown unknowns)

Triệu chứng thứ ba của sự phức tạp là không rõ ràng những đoạn code nào phải được sửa đổi để hoàn thành một nhiệm vụ, hoặc thông tin nào mà nhà phát triển phải có để thực hiện nhiệm vụ thành công.

Trong ba biểu hiện của sự phức tạp, những ẩn số không xác định cho đến nay là tệ nhất. Điều này là do một ẩn số không xác định thường có nghĩa là có điều gì đó mà nhà phát triển cần biết, nhưng không có cách nào để họ tìm ra hoặc thậm chí liệu có vấn đề hay không.

Trong tất cả các khả năng, họ sẽ không phát hiện ra điều đó cho đến khi lỗi xuất hiện sau khi họ thực hiện thay đổi.

Khuếch đại thay đổi và tải nhận thức gây khó chịu và chắc chắn sẽ dẫn đến tăng chi phí thay đổi và bảo trì, nhưng chúng vẫn có thể quản lý được.

Tuy nhiên, với những ẩn số không xác định, một tổ chức thực sự không biết họ nên làm gì, hoặc tác động có thể xảy ra mà một thay đổi sẽ có hoặc liệu giải pháp được đề xuất có hiệu quả hay không.

Nguyên nhân của sự phức tạp

Nguyên nhân của sự phức tạp không phải lúc nào cũng trực tiếp do code xấu, cũng giống như việc code xấu không phải lúc nào cũng là kết quả trực tiếp của các nhà phát triển kém hoặc thậm chí có kỹ năng kém.

Tôi đã chứng kiến nhiều nhà phát triển có tay nghề cao tạo ra code xấu và điều này không phải lúc nào cũng xảy ra.

Nhiều người tin rằng sự phức tạp được gây ra bởi hai điều: Sự phụ thuộc và Sự mơ hồ.

Trên thực tế, nếu bạn nói chuyện với nhiều nhà phát triển về nguyên nhân của sự phức tạp, họ có thể sẽ làm nổi bật cả hai điểm này.

Sự thật là, mặc dù chúng đều làm tăng thêm độ phức tạp ở cấp độ code, nhưng chúng thường không phải là nguyên nhân trực tiếp giải thích tại sao độ phức tạp được nhắc đến ngay từ đầu.

Hai nguyên nhân này gây ra sự phức tạp trong các cơ sở mã, không phải lúc nào cũng do các lựa chọn hoặc hành động của nhà phát triển, mà thường là kết quả của các lực lượng bên ngoài tác động và buộc các nhà phát triển phải đưa ra các quyết định tồi.

Để hiểu và xác định những lực lượng này, trước tiên chúng ta nên hiểu các nguyên tắc đằng sau Sự phụ thuộc (Dependency) và Sự mơ hồ (Obscurity).

Ở mức độ cao, sự phụ thuộc tồn tại khi một đoạn code nhất định không thể được hiểu và sửa đổi một cách riêng biệt: code liên quan theo một cách nào đó với code khác và code khác phải được xem xét và / hoặc sửa đổi nếu code đã cho bị thay đổi.

Sự phụ thuộc là một phần cơ bản của phần mềm và không bao giờ có thể được loại bỏ hoàn toàn.

Chúng tôi thường giới thiệu các phụ thuộc như một phần của quá trình thiết kế phần mềm. Mỗi khi một lớp hoặc hàm mới được tạo, nó sẽ tạo ra các phụ thuộc xung quanh API cho lớp đó.

Tuy nhiên, một trong những mục tiêu của thiết kế phần mềm là giảm số lượng phụ thuộc và làm cho các phụ thuộc trở nên đơn giản và rõ ràng nhất có thể.

Sự mơ hồ xảy ra khi thông tin quan trọng không rõ ràng, thường gắn liền với các phụ thuộc, nơi không phải lúc nào cũng rõ ràng rằng có một phụ thuộc tồn tại. Nguyên nhân hàng đầu dẫn đến sự mơ hồ là sự không nhất quán, cũng thường là kết quả của việc tài liệu không hoàn chỉnh hoặc không đầy đủ. Sự mơ hồ cũng thường là một vấn đề thiết kế.

Nhiều tổ chức và nhà phát triển lập luận rằng nếu một hệ thống có thiết kế clean và rõ ràng, thì nó sẽ không cần nhiều tài liệu. Thường người ta lầm tưởng rằng nếu cần có tài liệu mở rộng, thì đây là một cảnh báo cho thấy thiết kế không hoàn toàn đúng.

Nhiều tổ chức chống lại điều này bằng cách triển khai các phương pháp luận Agile mà công bố một cach nhầm lẫn, rằng không cần tài liệu vì giá trị 2 trong 4 giá trị của Tuyên ngôn Agile nói rằng:

Phần mềm chạy được ưu tiên hơn Tài liệu toàn diện

Điều thường được đặt trước bằng cách nêu nguyên tắc 1 cũng nói:

Cá nhân và Tương tác ưu tiên hơn Quy trình và Công cụ

Đây thường là điểm khi các yếu tố phụ thuộc và mơ hồ len lỏi vào các cơ sở mã, bởi những gì hầu như luôn bị bỏ qua trong code và không phải lúc nào cũng dễ dàng giải mã khi đọc code, đó là Ý định, Lập luận và Mục tiêu.

Sự phụ thuộc và Sự mơ hồ là nguyên nhân cho ba biểu hiện của sự phức tạp. Sự phụ thuộc đưa đến sự khuếch đại thay đổi và tải trọng nhận thức cao. Sự mơ hồ tạo ra những ẩn số chưa biết, góp phần vào tải trọng nhận thức. Nếu chúng ta có thể tìm thấy các kỹ thuật thiết kế để giảm thiểu sự phụ thuộc và mơ hồ, chúng ta có thể giảm độ phức tạp của phần mềm.

Độ phức tạp gia tăng lặp đi lặp lại

Sự phức tạp không chỉ xảy ra thôi đâu, mà nó tích lũy dần dần. Bản thân một sự phụ thuộc đơn lẻ hoặc một chút mơ hồ không có ảnh hưởng đáng kể đến khả năng bảo trì của một hệ thống phần mềm.

Sự phức tạp xuất hiện do hàng trăm hoặc hàng nghìn phụ thuộc nhỏ và những mơ hồ tích tụ theo thời gian. Cuối cùng, có rất nhiều thay đổi có thể xảy ra đối với một hệ thống đều bị ảnh hưởng bởi một số thay đổi trong số đó.

Đó là bản chất phức tạp ngày càng tăng khiến việc kiểm soát khó khăn và thường rất phức tạp để xác định.

Các nhóm phát triển phần mềm dễ dàng đánh lừa bản thân rằng một chút phức tạp được tạo ra bởi một thay đổi hiện tại không phải là vấn đề lớn. Mặt hạn chế, là điều này trở nên dễ dàng cho phép về mặt văn hóa và sau đó nó tích lũy nhanh chóng!

Một khi sự phức tạp đã tích tụ, thật khó để loại bỏ vì việc sửa chữa một sự phụ thuộc hoặc sự mơ hồ duy nhất sẽ không tạo ra sự khác biệt.

Cuối cùng cả team xôn xao. Họ báo cho ban quản lý rằng họ không thể tiếp tục phát triển trong cơ sở mã đáng sợ này. Họ yêu cầu thiết kế lại.
Robert C Martin – Clean Code

Kết luận

Sự phức tạp đến từ sự tích tụ của các phụ thuộc và sự mơ hồ, dẫn đến sự khuếch trương thay đổi, tải nhận thức cao và những ẩn số không xác định! Điều này thường dẫn đến nhiều sửa đổi hơn để triển khai từng tính năng mới và để khắc phục các sự cố được tạo ra bằng cách triển khai các tính năng trước đó.

Các nhà phát triển được yêu cầu dành nhiều thời gian hơn để thu thập đủ thông tin để thực hiện các thay đổi một cách an toàn, thường gặp khó khăn vì họ không bao giờ có thể tìm thấy tất cả thông tin họ cần vì phần lớn thông tin đó không tồn tại!

Về cốt lõi, clena code và các phương pháp thực hành là nhằm loại bỏ hoặc ít nhất là cố gắng giảm bớt sự phức tạp. Mặc dù các giải pháp clean code có vẻ thanh lịch và hiệu quả, nhưng chúng không phải lúc nào cũng dễ dàng và thường là kết quả trực tiếp của việc chống lại sự phức tạp!

Xem video Clean Code in Practices từ anh Tú Phạm (Head of Engineering) tại buổi Technical Event #12 do Gamba tổ chức.

Tham khảo: Garywoodfine

Tags clean code

Dev's Corner

Chuẩn bị gì trước phỏng vấn: 16 Câu hỏi tư duy phản biện (critical thinking) bằng tiếng Anh

Post author By Gambaru
Post date 17 September, 2022
No Comments on Chuẩn bị gì trước phỏng vấn: 16 Câu hỏi tư duy phản biện (critical thinking) bằng tiếng Anh

Câu hỏi phản biện (Critical thinking question) khi phỏng vấn

Câu hỏi phản biện (critical thinking) luôn là dạng câu hỏi yêu thích của nhà tuyển dụng, mặc dù đối với ứng viên, đối mặt với một câu hỏi phản biện quả thực không dễ chịu gì.

Làm thế nào để thấy đúng ý định của nhà tuyển dụng thông qua câu hỏi? Làm thế nào trả lời câu hỏi đó một cách rõ ràng và nhanh chóng?

Tất cả đều đòi hỏi phải thực hành, phải biết khả năng bạn sẽ gặp phải những câu hỏi như thế nào và lựa chọn cách trả lời tốt nhất.

Dưới đây là 16 câu hỏi phản biện bạn có thể găp trong quá trình phỏng vấn. Hãy tập làm quen, tư duy về dạng câu hỏi này nhé.

Dừng lại chút nào, nếu bạn đang #open_to_work, thử nghía qua các công việc đang tuyển trên Gamba nhé. Vào LINK NÀY để xem các job cần đến kỹ năng về Critical Thinking hoặc scan QR Code ở bên dưới nhé.

*Xem và ứng tuyển các job Critical Thinking*

1. Tell me about a time when you had to convince your supervisor or team to use an alternative approach to solve a problem

Interviewers test your critical thinking skills by learning whether you can make decisions based on logic and then communicate your reasoning to persuade others to follow you. They want to see influential behaviors, such as using data to establish trust in your decision rather than supporting an idea based on opinions or feelings. When answering, provide an example of when you successfully convinced someone using evidence to back up your proposal.

Example:

“At my previous job, I regularly had to search for information within a company database and create a spreadsheet with the results. Traditionally, this was a manual process, but I discovered a way to automate it. I raised this new approach with my supervisor by explaining the program we would need to use and showing them how the process worked. I detailed how this automated method would save us time, enabling us to move onto more important tasks.

Because I had data to back up my suggestion, they implemented this solution. This change resulted in a more efficient and streamlined workflow for our team.”

2. Tell me about a time when you needed to make a decision quickly

Interviewers want to see how you approach decision-making when under pressure. A sign of strong critical thinking is the ability to maintain your use of logic and reasoning to make the right choice, even within time constraints. Answer this question with a situation where a quick decision resulted in a positive outcome.

Example #1

“One time, my manager had to leave the office an hour before a scheduled presentation. We did not want to cancel the meeting with our clients, which meant we had little time to determine who would take over presentation duties. Because I spent so much preparing with my manager and had the best idea of the points they wanted to make, we decided I was the best choice.

We also asked another manager who was more familiar with these negotiations to support me and help answer client questions. The clients were impressed with our presentation and ended up approving our proposal. My manager was so pleased with our quick thinking and results that they began trusting me to handle more client presentations in the future.”

Example #2

While I like to gather as much information as possible before making a decision, I recognize that deadlines will often make this unrealistic. Sometimes, it’s of vital importance to act quickly to stay ahead of a competitor or fast-track a project.

The first step is to assess the immediacy of the deadline; if it’s urgent, I know I have to make a decision ASAP. In this situation, I’ll quickly weigh up the pros and cons of each option and select the course of action that best aligns with the business goals.

While working in customer service, I routinely had to make on-the-spot decisions to select the best solution in different contexts. I always made sure to get a full picture of the customer’s needs, and then chose the most suitable action from the options available.

Having a strong background understanding of the area and a clear selection process allowed me to make the right call 99% of the time.

3. How would you handle a situation where you noticed your supervisor made an error in a report or presentation?

Interviewers want to see how you would handle a difficult and possibly uncomfortable situation with an authority figure. When responding to this question, explain what action you would take and the thought process behind your decision. Your answer should show the potential employer that you can take a professional approach.

Example:

“If I noticed a mistake in my supervisor’s work, I would wait until I could speak with them privately. I would then show them the mistake and offer to help them fix it. I believe having the conversation in private shows my supervisor that I respect them and their authority. My previous supervisors appreciated this honesty, and my last manager even had me perform the final review of all their drafted documents.”

4. Describe one of the most difficult decisions you have had to make at work

Interviewers ask this question to learn whether you have experience making decisions in challenging situations. Your answer should display your thought process behind a difficult choice, including how you used critical-thinking skills to determine your options and find the right solution.

Example #1

“At my last job, I helped set up a new learning platform for a specific department. We met with five vendors to provide online training, but I had to make the final decision on which one to hire. I compared the five vendors against requirements related to our budget and the needs of our learners. I also asked our stakeholders, who participated in the meetings with vendors and tested their content, which they liked best.

I chose the vendor who best met all of our requirements and was most popular with the stakeholders. As a result, we saw significant productivity improvement from our learners and received positive feedback on their training experiences.”

As a manager, layoffs were among the toughest decisions I had to make in my previous role. In those situations, I had to put personal loyalties aside and make tough choices based on the needs of the business.

This involved a regimented process of ranking staff across several different criteria including merit, skills, and tenure. Ultimately, we favored staff with long-term potential, such as those with in-demand skills and a growth mindset.

The decisions were far from easy, but recognizing that someone had to make the call, I never shied away from them either. I think the best approach for any difficult work decision is to be objective, consult data, and consider the long-term impact.

5. How would you handle a situation where a colleague presented you with a new or unusual idea?

One of the key elements of critical thinking is open-mindedness. Potential employers want to see your ability to consider new ideas to improve processes or solve difficult problems, so give a specific example from your past. Your answer should also include how this open-mindedness benefited you and your work.

Example

“I once collaborated with a coworker on a project, and they suggested taking a completely different approach than I usually took. I asked them to walk me through their approach and explain how it has worked for them in the past. The steps they suggested taking seemed easier than mine, so we decided to use their method. As a result, we got the work done much faster than I usually do—and I found a new favorite approach for doing similar projects.”

6. How would you solve a disagreement among team members on how to approach a project?

You can develop your critical thinking abilities by evaluating opposing viewpoints and using them to form viable solutions. Looking at different sides of a situation can broaden your perspective, which can often lead to better solutions. Show the interviewers that you can make decisions that work best for your team.

Example #1

“In a team situation where there are opposing viewpoints, I ask everyone to present their idea and the reasoning behind it. Rather than just going by what is popular, I have the team look at the evidence or logic to determine which choice is the best for our needs. For example, I was on a team where there was disagreement on how often we should hold meetings on project progress updates.

At first, the majority wanted weekly meetings, but a few people were adamant about short, daily check-ins. After listening to the reasoning behind these ideas, our group determined that a daily 15-minute meeting would be more beneficial in keeping us on task. We found that this plan did not take away time from our responsibilities and helped us finish the project sooner because the frequent check-ins held us accountable for our assignments.”

Example #2

I think it’s great to hear different perspectives in the workplace, provided that they come from a well-meaning place. Listening to opposing viewpoints helps to refine my own opinion and can often bring the team to a middle ground from which more balanced decisions can be made.

A few months ago, a co-worker and I disagreed on how best to deliver a digital marketing campaign for a client. In short, he wanted to run paid search engine advertisements while I preferred to create content for the client’s company website.

After listening to his argument, I presented my case to show that content marketing was likely to yield a higher return on investment by showing case studies from previous clients in a similar field.

Eventually, we agreed to the content strategy, and allocated only a small slice of the budget to paid ads. Within a few weeks, the client had doubled the traffic on their website and was extremely satisfied with our project delivery.

Example #3

In this situation, I would first remind team members of the urgency of the task at hand and the need to move quickly. Next, I would write up a simple, straightforward list of the pros and cons of each available strategy, drawing attention to any potential risks that may be encountered.

I would then give team members a few minutes to consider each option and voice any additional queries they may have. If a clear consensus still cannot be reached at this point, I would take a vote to decide the strategy to move forward with.

I recognize that it’s not always possible to reach a clear agreement. But by stripping the situation back to the simple facts, at least everyone can make an informed and objective decision in a time-sensitive manner.

7. Have you ever anticipated potential problems and developed steps to avoid them?

Potential employers are interested in seeing whether you can look at a situation and anticipate potential challenges. This ability incorporates strong observational and problem-solving skills, which are essential to critical thinking. Your answer should show that you can identify issues and logically determine ways of resolving them before they even happen.

Example #1

“In my previous job, I was responsible for scheduling staff members. I knew that scheduling was more complicated during the holiday season. To combat this, I established procedures for requesting time off during that period that enabled me to set schedules further in advance. I also implemented a program that trained staff on how to complete the responsibilities of different jobs, which provided flexibility in the event of last-minute absences. As a result of these changes, I had a plan of action in place when scheduling difficulties arose. Our team felt prepared and avoided productivity disruptions.”

Example #2

Working as a retail store manager at the start of the COVID-19 pandemic, it immediately became obvious that our store would need to change certain procedures as infections picked up.

I decided to act quickly, investing in protective equipment for staff, implementing plastic screens at the checkouts, and rearranging the store layout early on in the pandemic to make the site more Covid-friendly for our customers and staff.

Our proactive approach resonated with customers, who appreciated the new measures while other stores in the local area remained slow to adapt. Our trading volume actually rose by around 25% compared to pre-pandemic levels. Staff also reported feeling safer in our monthly surveys.

It’s important to try and pre-empt risks in any business. To do this, I always consider the worst-case scenario that could affect the business and learn from competitors’ failures.

8. How do you handle making a decision when you don’t have all of the information?

Interviewers often want to see how you conduct your thinking process within certain limitations. Your answer should display how you were able to use logic and resourcefulness to come to a rational decision. When including an example in your response, focus on the thought process rather than the results.

Example #1

“I like to have as much information as possible when making decisions, though I realize this is not always realistic. In this situation, I would try to find as much information as I could and use context to fill in any missing areas.

I once had a question about a proposal for a client. My supervisor was not available, so I reviewed the client’s creative brief for insights. The brief provided enough information that I found a possible solution to my problem. When I made my presentation, I felt comfortable with what I had prepared and only received a few changes from the client.”

Example #2

I prefer to make decisions after taking in all of the facts, but I recognize that the need to act quickly will sometimes take priority. In these situations, I pore over all of the information available and use my intuition to fill in any gaps. This could be by drawing parallels to a similar task from the past or predicting future outcomes to map the best decision in the present.

I experienced this situation in my last job while writing a funding application with a very quick turnaround. The final section to complete before submission was the summary, where it was crucial to really sell our organization’s solution in a compelling and straightforward way.

My manager was unreachable at the time, so I decided to contact the head office to retrieve the summaries of our previous successful funding applications. Using these examples, I was able to craft a persuasive summary. A few weeks later, we were awarded the funding.

9. When solving a problem or completing a task, how do you determine when you need help from others?

Potential employers may ask about your ability to seek support from colleagues, as this can display that you can act sensibly to create optimal outcomes. Provide an example of a situation where you needed help, how you came to that decision and how it benefited you.

Example #1

“In the past, I have realized that some situations require support from others. I will make this decision when I recognize a task is too large to handle on my own or when I need additional viewpoints on an issue to find a solution.

Last year, I agreed to create a report for an internal client with a short deadline. As I worked on this report, I realized I would not be able to finish it in the given time and reached out to a coworker. With their help, we completed the report within the deadline, and the resulting product was much better than if I had rushed to complete it by myself.”

Example #2

When I’ve been given a task to complete independently, I try to avoid asking my co-workers for help as I know everyone is busy with their own work. Sometimes, though, it can be really useful to get a fresh pair of eyes to look over things when I’ve hit a wall in a project. Help is a two-way street, so I always try to make time to assist co-workers when I am asked.

About a year ago in my sales position, I was tasked with integrating invoices into a spreadsheet containing order history for different clients. Software isn’t my strong point, so I sought help from a member of the development team—someone with whom I had built a good rapport previously.

I knew this was something that would probably only take him 15 minutes, so I didn’t feel like too much of a burden when I asked for help. He duly completed the task, and the project could move forward. I had previously helped him before, and I also offered my support for anything he needed in the future.

10. How would you handle a situation where a colleague is having trouble understanding your process or solution?

For this specific example, you should discuss how you would take different learning styles into account to best communicate with the other person.

Example:

“When I notice that a colleague is having trouble understanding my explanation, I pause and ask how they are feeling so far. By doing this, I can learn where they began to get confused. Now I have a new starting point to build their knowledge upon and can adjust my explanation to suit their needs. This may require me to use visual aids or examples to relay the information or use language that is less technical depending on the type of learner.

I recognize that not everyone receives information or instruction in the same way, so I usually try to prepare a few methods of explanation beforehand. That way, if they need a visual aid, for example, then I can already have one ready to use.”

11. What work-related advice would you give to former employers?

This question gauges a candidate’s propensity to voice criticism, and whether they choose to express it in a constructive or negative way. There’s no real right or wrong answer here; candidates simply need to explain their suggestions thoughtfully and thoroughly.

Example

I’ve always tried to provide feedback to my bosses when it was appropriate to do so. Voicing criticism can be a tricky task, so I make an effort to frame the discussion in a constructive and non-malicious way.

One of my former bosses was particularly strong-willed, which sometimes made it difficult for the team to share new ideas. If we were able to show evidence of the potential of a new idea—using data, for example—he would be less dismissive than if we were to suggest it off the cuff. Over time, the boss grew more receptive to outside ideas rather than immediately shrugging them off.

In another company, some of my co-workers were dissatisfied as they felt undervalued by the boss. Rather than take this up with the boss directly, I raised the issue in the quarterly employee survey, suggesting that the senior leadership give more praise and recognition to high-performing staff in order to improve motivation and employee satisfaction.

12. How should friction between team members be dealt with?

Conflict resolution is a skill that can be hard to come by for hiring managers. In work environments with people of different opinions and values, it’s important to have someone who can defuse conflict situations with a proactive, patient, and impartial approach.

Example

When managed properly, I think that workplace disagreements can be healthy and help to promote a diversity of opinion. However, when they become personal, they serve no purpose and must be resolved immediately with fairness and good judgment.

In one of my previous roles as a team leader, conflict flared up between two coworkers after disagreeing on how to allocate the quarterly budget. At the first opportunity, I arranged a one-on-one chat with each colleague to understand their reasoning and try to reconcile both positions.

After the situation had been de-escalated, I brought the two together to talk it out in a calm and non-threatening space. With active listening and turn-taking techniques, they were able to settle their differences. I followed up regularly in the weeks after, and we were able to put the conflict behind us.

13. What is the most innovative work-related idea you have come up with? How did it benefit the organization?

This question asks candidates to consider a time when they have thought outside the box to deliver a new solution in a previous job. Having proactive problem-solvers in your organization will help it stay ahead of the curve.

Example

In one of my previous roles, I was placed in charge of a small workgroup tasked with finding a way to improve productivity and efficiency. Each member of the group seemed to have their own opinion of the best solution, but most entailed large expenses we could not afford.

Since management needed a low investment solution, I proposed adding two additional fifteen-minute breaks to the working day for employees to read a book, catch up on the news, or go for a walk around the block. This was because I knew many employees felt burnt out by the end of the day, and their work suffered as a result.

The team supported the idea, but management was hesitant at first. After presenting my argument, they agreed to trial the breaks for two weeks. By the second week, the results were clear: employees were working more effectively and they were more satisfied at work. Soon after, the new break system was implemented on a scale across the company.

14. How would you deal with a situation where a weak link in the team is affecting the quality of performance?

This question assesses the candidate’s ability not only to identify workplace problems but also their willingness to tackle them proactively. Strong candidates won’t shy away from having uncomfortable conversations, but will also be respectful and keep things confidential.

Example

If I noticed that a particular team member was disrupting the delivery of a project, I would look to offer solutions rather than point fingers. The first step would be to identify the cause of the team member’s poor performance.

If it was down to a lack of skills, I would suggest to the team leader in private that they receive appropriate training to help get them up to speed on the project. Alternatively, they could be reassigned to another area that they have greater expertise in.

If their performance was due to poor motivation, I would suggest that the employee be given personalized performance goals, assistance, and feedback. Encouragement, rather than criticism, should help the employee feel more motivated.

15. If you are given ten projects but only have time to complete three, how do you decide which three to work on?

Workers will often need to prioritize tasks based on their urgency and importance. In this situation, critical evaluation is necessary to distinguish the important from the less-important tasks using specific measures like time, effort, and value.

Example

If I had to manage multiple time-sensitive tasks, I’d first list them all together in a single document and order them based on the urgency of the deadlines. Second, I would flag any tasks which could feasibly be delegated to co-workers for completion.

From the remaining tasks, I would identify those which are both urgent and important. The next step would be to order these based on their value by considering which tasks have the most serious consequences for failing to complete them, and also which tasks have the highest ROI.

For example, missing a deadline for a brand-new client could be more damaging than missing one for a loyal client of many years, and whose project is less urgent. Using this process, I’d select the three tasks which:

Only I can complete
Are urgent
Bring a lot of value to the business

16. You discover a new approach that could improve performance while saving resources, but it’s unpopular among your co-workers. How would you present your case to your manager?

Innovative thinkers can be great assets to your organization, but they’re of little value if they fail to defend their ideas when faced with disapproval. While other team members’ views should be respected, the strong candidate will be able to argue their case persuasively.

Example

Before putting the idea forward to the manager, I would find out more about the reasoning behind the team’s resistance. It could be that they don’t want to go through a new learning curve or are unconvinced by its benefits.

These insights would allow me to tweak my proposal so that it addresses my co-workers’ doubts. At this point, I would present the idea to my manager and explain that I am willing to support the team in adopting the new approach with presentations and training.

The support sessions would aim to overcome the team’s hesitation by showing how the new approach would benefit them in the long run. I’d also encourage anonymous feedback so that the new approach can be improved. Ultimately, I’d try to reach a place of mutual understanding with positive outcomes for everyone involved.

Gambaru tổng hợp.

Tags câu hỏi phản biện, critical thinking, Phỏng vấn

Dev's Corner

Chuẩn bị gì trước phỏng vấn: 65 Câu hỏi logic bằng tiếng Anh

Post author By Gambaru
Post date 16 September, 2022
No Comments on Chuẩn bị gì trước phỏng vấn: 65 Câu hỏi logic bằng tiếng Anh

65 Câu hỏi logic để chuẩn bị cho quá trình phỏng vấn

Phỏng vấn để ứng tuyển một vị trí nào đó luôn là quá trình không dễ dàng đối với gần như mọi ứng viên, vì vậy điều chúng ta có thể làm đó là chuẩn bị thật tốt về nhiều mặt trước khi đến gặp nhà tuyển dụng.

Một trong những chuẩn bị quan trọng nhất chính là việc trả lời các câu hỏi đánh giá ban đầu như câu hỏi IQ, câu hỏi Logic hoặc câu hỏi trong buổi phỏng vấn chuyên môn như câu hỏi phản biện (critical thinking question).

Không phải nhà tuyển dụng nào cũng sẽ hỏi, nhưng dù thế nào, bạn vẫn cần phải lận lưng chút vốn liến để khi cần kíp thì có thể ra tay.

Dưới đây sẽ tổng hợp 65 câu hỏi logic (logical question) bằng tiếng Anh giúp cho bạn vừa tham khảo vừa làm quen với nhiều thể loại câu hỏi logic khi bắt đầu quá trình tìm kiếm công việc mới.

Dừng lại chút nào, nếu bạn đang #open_to_work, thử nghía qua các công việc đang tuyển trên Gamba nhé. Vào LINK NÀY để xem các job cần đến kỹ năng về Logical Thinking hoặc scan QR Code ở bên dưới nhé.

*Xem và ứng tuyển các job Logical thinking*

Number Series

1. Look at this series: 12, 11, 13, 12, 14, 13, … What number should come next?

A. 10
B. 16
C. 13
D. 15

Answer: D. This is an alternating number of subtraction series. First, 1 is subtracted, then 2 is added.

2. Look at this series: 36, 34, 30, 28, 24, … What number should come next?

A. 22
B. 26
C. 23
D. 20

Answer: A. This is an alternating number of subtraction series. First, 2 is subtracted, then 4, then 2, and so on.

3. Look at this series: 7, 10, 8, 11, 9, 12, … What number should come next?

A. 7
B. 12
C. 10
D. 13

Answer: C. It’s an alternating addition and subtraction series. 3 is added in the first pattern, and then 2 is subtracted.

4. Look at this series: 2, 1, (1/2), (1/4), … What number should come next?

A. (1/3)
B. (1/8)
C. (2/8)
D. (1/16)

Answer: B. It’s a division series. Every number is half of the previous number. The number is divided by 2 successively to get the next result. 4/2 = 2. 2/2 = 1. 1/2 = ½. (1/2)/2 = ¼. (1/4)/2 = 1/8 and so on.

5. Look at this series: 80, 10, 70, 15, 60, … What number should come next?

A. 20
B. 25
C. 30
D. 50

Answer: A. This is an alternating addition and subtraction series. In the first pattern, 10 is subtracted from each number to arrive at the next. In the second, 5 is added to each number to arrive at the next.

Verbal Classification

6. Which word does NOT belong with the others?

A. index
B. glossary
C. chapter
D. book

Answer: D. Rest is all parts of a book. Choice a does not belong because the book is the whole, not a part.

7. Which word is the odd man out?

A. trivial
B. unimportant
C. important
D. insignificant

Answer: C. Remaining are synonyms of each other.

8. Which word does NOT belong with the others?

A. wing
B. fin
C. beak
D. rudder

Answer: C. The wing, fin, and rudder are all parts of an airplane.

9. Which word is the odd man out?

A. hate
B. fondness
C. liking
D. attachment

Answer: A. Rest are positive emotions.

10. Pick the odd man out?

A. just
B. fair
C. equitable
D. biased

Answer: D. Fair, just, and equitable are all synonyms meaning impartial. Favorable means expressing approval.

Analogies

11. CUP : LIP :: BIRD : ?

A. GRASS
B. FOREST
C. BEAK
D. BUSH

Answer: C. BEAK. You drink out of a cup with your lips. Similarly, birds bite grass with their beaks.

12. Paw : Cat :: Hoof : ?

A. Lamb
B. Horse
C. Elephant
D. Tiger

Answer: B. Horse. Cat’s feet are called paws and horse’s are called hoofs.

13.

A. 1
B. 2
C. 3
D. 4

Answer: B. A T-shirt is to a pair of shoes as a chest of drawers is to a couch. The relationship shows to which group something belongs. The T-shirt and shoes are both articles of clothing; the chest and couch are both pieces of furniture.

14.

A. 1
B. 2
C. 3
D. 4

Answer: C. Scissors is to knife as a pitcher is to watering can. This relationship is about function. The scissors and knife are both used for cutting. The pitcher and watering can are both used for watering.

15. EXPLORE : DISCOVER

A. read : skim
B. research : learn
C. write : print
D. think : relate
E. sleep : wake

Answer: B. One explores to discover; one researches to learn.

Matching Definitions

16. An Informal Gathering occurs when a group of people get together in a casual, relaxed manner. Which situation below is the best example of an Informal Gathering?

A. A debating club meets on the first Sunday morning of every month.
B. After finding out about his salary raise, Jeremy and a few colleagues go out for a quick dinner after work.
C. Meena sends out 10 invitations for a bachelorette party she is giving for her elder sister.
D. Whenever she eats at a Chinese restaurant, Roop seems to run into Dibya.

Answer: B. After getting some good news, Jeremy and a few friends casually get together for a drink after work, thereby having an informal gathering. Choices a and c describe more formal types of gatherings. Choice d describes a chance or coincidental kind of meeting.

17. A Tiebreaker is an additional contest carried out to establish a winner among tied contestants. Choose one situation from the options below that best represents a Tiebreaker.

A. At halftime, the score is tied at 28.
B. Mary and Megan have each scored three goals in the game.
C. The referee tosses a coin to decide which team will have possession of the ball first.
D. The Sharks and the Bears each finished with 14 points, and they are now battling it out in a five-minute overtime.

Answer: D. This is the only choice that indicates that an additional period of play is taking place to determine the winner of a game that ended in a tie.

18. Reentry occurs when a person leaves his or her social system for a period of time and then returns. Which situation below best describes Reentry ?

A. When he is offered a better paying position, Jacob leaves the restaurant he manages to manage a new restaurant on the other side of town.
B. Catherine is spending her junior year of college studying abroad in France.
C. Malcolm is readjusting to civilian life after two years of overseas military service.
D. After several miserable months, Sharon decides that she can no longer share an apartment with her roommate Hilary.

Answer: C. Malcolm is the only person returning to a social system that he has been away from for an extended period of time.

19. Embellishing the Truth occurs when a person adds fictitious details or exaggerates facts or true stories. Which situation below is the best example of Embellishing the Truth?

A. Isabel goes to the theater, and the next day, she tells her coworkers she thought the play was excellent
B. The realtor describes the house, which is eleven blocks away from the ocean, as prime waterfront property.
C. During the job interview, Fred, who has been teaching elementary school for ten years, describes himself as a very experienced teacher
D. The basketball coach says it is likely that only the most talented players will get a college scholarship

Answer: B. The realtor is using a clear exaggeration when she states that a house which is eleven blocks away from the ocean is prime waterfront property.

20. Posthumous Publication occurs when a book is published after the author’s death. Which situation below is the best example of Posthumous Publication

A. Richard’s illness took his life before he was able to enjoy the amazing early reviews of his novel
B. Melissa’s publisher cancels her book contract after she fails to deliver the manuscript on time.
C. Clarence never thought he’d live to see the third book in his trilogy published..
D. Elizabeth is honored with a prestigious literary award for her writing career and her daughter accepts the award on behalf of her deceased mother.

Answer: A. Although choice d also mentions a writer who has died, it does not state that one of the writer’s books was published after her death, only that she received an award. Choice a states that Richard wasn’t around to see the early reviews of his novel, therefore implying that Richard died before the book was published. The other two options depict living writers

Verbal Reasoning

21. Vincent has a paper route. Each morning, he delivers 37 newspapers to customers in his neighborhood. It takes Vincent 50 minutes to deliver all the papers. If Vincent is sick or has other plans, his friend Thomas, who lives on the same street, will sometimes deliver the papers for him.

A. Vincent and Thomas live in the same neighborhood.
B. It takes Thomas more than 50 minutes to deliver the papers.
C. It is dark outside when Vincent begins his deliveries.
D. Thomas would like to have his own paper route.

Answer: A. The fact that Vincent and Thomas live on the same street indicates that they live in the same neighborhood. There is no support for any of the other choices.

22. Erin is twelve years old. For three years, she has been asking her parents for a dog. Her parents have told her that they believe a dog would not be happy in an apartment, but they have given her permission to have a bird. Erin has not yet decided what kind of bird she would like to have.

A. Erin’s parents like birds better than they like dogs
B. Erin does not like birds.
C. Erin and her parents live in an apartment.
D. Erin and her parents would like to move.

Answer: C. Since Erin’s parents think a dog would not be happy in an apartment, we can reasonably conclude that the family lives in an apartment. We do not know if Erin’s parents dislike dogs (choice a) or if Erin dislikes birds (choice b).There is no support for choice d.

23. When they heard news of the hurricane, Maya and Julian decided to change their vacation plans. Instead of traveling to the island beach resort, they booked a room at a fancy new spa in the mountains. Their plans were a bit more expensive, but they’d heard wonderful things about the spa and they were relieved to find availability on such short notice.

A. Maya and Julian take beach vacations every year.
B. The spa is overpriced.
C. The spa is overpriced.
D. Maya and Julian decided to change their vacation plans because of the hurricane

Answer: D. The first sentence makes this statement true. There is no support for choice a. The passage tells us that the spa vacation is more expensive than the island beach resort vacation, but that doesn’t necessarily mean that the spa is overpriced; therefore, choice b cannot be supported. And even though the paragraph says that the couple was relieved to find a room on short notice, there is no information to support choice c, which says that it is usually necessary to book at the spa at least six months in advance.

24. Georgia is older than her cousin Marsha. Marsha’s brother Bart is older than Georgia. When Marsha and Bart are visiting with Georgia, all three like to play a game of Monopoly. Marsha wins more often than Georgia does.

A. When he plays Monopoly with Marsha and Georgia, Bart often loses.
B. Of the three, Georgia is the oldest.
C. Georgia hates to lose at Monopoly.
D. Of the three, Marsha is the youngest.

Answer: D. If Georgia is older than Marsha and Bart is older than Georgia, then Marsha has to be the youngest of the three. Choice b is clearly wrong because Bart is the oldest. There is no information in the paragraph to support either choice a or choice c.

25. On weekends, Mr. Sanchez spends many hours working in his vegetable and flower gardens. Mrs. Sanchez spends her free time reading and listening to classical music. Both Mr. Sanchez and Mrs. Sanchez like to cook.

A. Mr. Sanchez enjoys planting and growing vegetables.
B. Mr. Sanchez does not like classical music.
C. Mrs. Sanchez cooks the vegetables that Mr. Sanchez grows.
D. Mrs. Sanchez enjoys reading nineteenth century novels.

Answer: A. Because Mr. Sanchez spends many hours during the weekend working in his vegetable garden, it is reasonable to suggest that he enjoys this work. There is no information to suggest that he does not like classical music. Although Mrs. Sanchez likes to cook, there is nothing that indicates she cooks vegetables (choice c). Mrs. Sanchez likes to read, but there is no information regarding the types of books she reads (choice d).

Logical Games

The government of an island nation is in the process of deciding how to spend its limited income. It has $7 million left in its budget and eight programs to choose among. There is no provision in the constitution to have a surplus, and each program has requested the minimum amount they need; in other words, no program may be partially funded. The programs and their funding requests are:

Hurricane preparedness: $2.5 million
Harbor improvements: $1 million
School music program: $0.5 million
Senate office building remodeling: $1.5 million
Agricultural subsidy program: $2 million
National radio: $0.5 million
Small business loan program: $3 million
International airport: $4 million

26. If a legislature decides to fund agricultural subsidy programs, national radio, and a small business loan program, what 2 other programs can they fund?

A. harbor improvements and school music program
B. harbor improvements and international airport
C. hurricane preparedness and international airport
D. hurricane preparedness and school music program
E. harbor improvements and hurricane preparedness

Answer: Option B. The only two programs that total 1.5 million dollars are the harbor improvements and school music program.

27. Senators from urban areas are very concerned about assuring that there will be funding for a new international airport. Senators from rural areas refuse to fund anything until money for agricultural subsidies is appropriated. If the legislature funds these two programs, on which of the following could they spend the rest of the money?

A. the school music program and national radio
B. hurricane preparedness
C. harbor improvements and the school music program
D. small business loan program
E. national radio and senate office building remodeling

Answer: A. The total cost of the school music program and national radio is $1 million, the amount left after the international airport and agricultural subsidies are funded.

International airport + Agricultural subsidy program
$4 million + $2 million = $6 million
school music program and national radio is $1 million.
Hence, Total $7 million.

Questions 3-5 are based on the following information:

At a small company, parking spaces are reserved for the top executives: CEO, president, vice president, secretary, and treasurer with the spaces lined up in that order. The parking lot guard can tell at a glance if the cars are parked correctly by looking at the color of the cars. The cars are yellow, green, purple, red, and blue, and the executives names are Alice, Bert, Cheryl, David, and Enid.

The car in the first space is red.
A blue car is parked between the red car and the green car.
The car in the last space is purple.
The secretary drives a yellow car.
Alice’s car is parked next to David’s.
Enid drives a green car.
Bert’s car is parked between Cheryl’s and Enid’s.
David’s car is parked in the last space.

28. Who is the secretary?

A. Enid
B. David
C. Cheryl
D. Bert
E. Alice

Answer: E. Cheryl cannot be the secretary, since she’s the CEO, nor can Enid, because she drives a green car, and the secretary drives a yellow car. David’s, the purple car, is in the last space. Alice is the secretary, because her car is parked next to David’s, which is where the secretary’s car is parked.

29. Who is the CEO ?

A. Alice
B. Bert
C. Cheryl.
D. David.
E. Enid.

Answer: C. The CEO drives a red car and parks in the first space. Enid drives a green car; Bert’s car is not in the first space; David’s is not in the first space, but the last. Alice’s car is parked next to David’s, so Cheryl is the CEO.

30. What color is the vice president’s car?

A. green
B. yellow
C. blue
D. purple
E. red

Answer: A. The vice president’s car cannot be red, because that is the CEO’s car, which is in the first space. Nor can it be purple, because that is the treasurer’s car, which is in the last space, or yellow, because that is the secretary’s. The president’s car must be blue, because it is parked between a red car (in the first space) and a green car, which must be the vice president’s.

Statement and Assumption

In each question below is given a statement followed by two assumptions numbered I and II. You have to consider the statement and the following assumptions and decide which of the assumptions is implicit in the statement.

Give answer:

(A) If only assumption I is implicit
(B) If only assumption II is implicit
(C) If either I or II is implicit
(D) If neither I nor II is implicit
(E) If both I and II are implicit.

31. Statement: Films have become indispensable for the entertainment of people.

Assumptions:

I. Films have become indispensable for the entertainment of people.

II. People enjoy films.

Options:

A. Only assumption I is implicit.
B. Only assumption II is implicit.
C. Either I or II is implicit.
D. Neither I or II is implicit.
E. Both I and II are implicit.

Answer: B. ‘Films are indispensable’ does not mean that they are the only means of entertainment. So, I is not implicit. Clearly, II follows from the statement. So, it is implicit.

32. Statement: “To keep myself up-to-date, I always listen to 9.00 p.m. news on radio.”- A candidate tells the interview board.

Assumptions:

I. The candidate does not read newspaper.

II. Recent news is broadcast only on radio.

Options:

A. Only assumption I is implicit.
B. Only assumption II is implicit.
C. Either I or II is implicit.
D. Neither I or II is implicit.
E. Both I and II are implicit.

Answer: D. The candidate listens to news on the radio does not mean that he does not read newspaper or that radio is the only source of recent news. So, neither I nor II is implicit.

33. Statement: A Notice Board at a ticket window: Please come in queue.’

Assumptions:

I. Unless instructed people will not form queue.

II. People any way want to purchase tickets.

Options:

A. Only assumption I is implicit.
B. Only assumption II is implicit.
C. Either I or II is implicit.
D. Neither I or II is implicit.
E. Both I and II are implicit.

Answer: E. The instructions have been given so that people willing to buy tickets may not form a crowd. So, I is implicit. Also, it is clear that people would purchase the tickets even after following the given instructions. So, II is also implicit.

34. Statement: Do not copy our software without our permission – A notice.

Assumptions:

I. It is possible to copy the software.

II. Such warning will have some effect

Options:

A. Only assumption I is implicit.
B. Only assumption II is implicit.
C. Either I or II is implicit.
D. Neither I or II is implicit.
E. Both I and II are implicit.

Answer: E. Since the notice warns one against copying software without permission, it is evident that software can be copied. So, I is implicit. Also, the warning is given with the motive that no one dares to copy the software. So, II is also implicit.

35. Statement: If he is intelligent, he will pass the examination.

Assumptions:

I. To pass, he must be intelligent.

II. He will pass the examination.

Options:

A. Only assumption I is implicit.
B. Only assumption II is implicit.
C. Either I or II is implicit.
D. Neither I or II is implicit.
E. Both I and II are implicit.

Answer: A. The statement mentions that he will pass if he is intelligent. So, I is implicit. Further, this means that it is not necessary that he will pass. So, II is not implicit.

Statement and Conclusion

In each question below is given a statement followed by two conclusions numbered I and II. You have to assume everything in the statement to be true, then consider the two conclusions together and decide which of them logically follows beyond a reasonable doubt from the information given in the statement.

Give answer:

(A) If only conclusion I follows
(B) If only conclusion II follows
(C) If either I or II follows
(D) If neither I nor II follows and
(E) If both I and II follow.

36. Statements: The old order changed yielding place to new.

Conclusions:

I. Change is the law of nature.

II. Discard old ideas because they are old.

Options:

A. Only conclusion I follows
B. Only conclusion II follows
C. Either I or II follows
D. Neither I nor II follows
E. Both I and II follow

Answer: A. Look carefully at the number of dots in each domino. The first segment goes from five to three to one. The second segment goes from one to three to five. The third segment repeats the first segment.

37. Statements: Government has spoiled many top-ranking financial institutions by appointing bureaucrats as Directors of these institutions.

Conclusions:

I. Government should appoint Directors of the financial institutes taking into consideration the expertise of the person in the area of finance.

II. The Director of the financial institute should have expertise commensurate with the financial work carried out by the institute.

Options:

A. Only conclusion I follows
B. Only conclusion II follows
C. Either I or II follows
D. Neither I nor II follows
E. Both I and II follow

Answer: E. According to the statement, Government has spoiled financial institutions by appointing bureaucrats as Directors. This means that only those persons should be appointed as Directors who are experts in finance and are acquainted with the financial work of the institute. So, both I and II follow.

38. Statements: Prime age school-going children in urban India have now become avid as well as more regular viewers of television, even in households without a TV. As a result, there has been an alarming decline in the extent of readership of newspapers.

Conclusions:

I. Method of increasing the readership of newspapers should be devised.

II. A team of experts should be sent to other countries to study the impact of TV. on the readership of newspapers.

Options:

A. Only conclusion I follows
B. Only conclusion II follows
C. Either I or II follows
D. Neither I nor II follows
E. Both I and II follow

Answer: D. The statement concentrates on the increasing viewership of TV. and does not stress either on increasing the readership of newspapers or making studies regarding the same. So, neither I nor II follows.

39. Statements: Wind is an inexhaustible source of energy and an aerogenerator can convert it into electricity. Though not much has been done in this field, the survey shows that there is vast potential for developing wind as alternative source of energy.

Conclusions:

I. Energy by wind is comparatively newly emerging field.

II. The energy crisis can be dealt by exploring more in the field of aero-generation.

Options:

A. Only conclusion I follows
B. Only conclusion II follows
C. Either I or II follows
D. Neither I nor II follows
E. Both I and II follow

Answer: E. The phrase ‘not much has been done in this field’ indicates that wind energy is a comparatively newly emerging field. So, I follows. The expression ‘there is vast potential for developing wind as alternative source of energy’ proves II to be true.

40. Statements: The best way to escape from a problem is to solve it.

Conclusions:

I. Your life will be dull if you don’t face a problem.

II. Your life will be dull if you don’t face a problem.

Options:

A. Only conclusion II follows
B. Only conclusion II follows
C. Either I or II follows
D. Neither I nor II follows
E. Both I and II follow

Answer: D. Clearly, both I and II do not follow from the given statement.

Cause and Effect

In each of the following questions, two statements numbered I and II are given. There may be cause and effect relationship between the two statements. These two statements may be the effect of the same cause or independent causes. These statements may be independent causes without having any relationship. Read both the statements in each question and mark your answer as

(A) If statement I is the cause and statement II is its effect;
(B) If statement II is the cause and statement I is its effect;
(C) If both the statements I and II are independent causes;
(D) If both the statements I and II are effects of independent causes; and
(E) If both the statements I and II are effects of some common cause.

41. Statements:

I. All the schools in the area had to be kept closed for most part of the week.

II. Many parents have withdrawn their children from the local schools.

Options:

A. Statement I is the cause and statement II is its effect.
B. Statement II is the cause and statement I is its effect.
C. Both the statements I and II are independent causes.
D. Both the statements I and II are effects of independent causes.
E. Both the statements I and II are effects of some common cause.

Answer: D. Closing the schools for a week and the parents withdrawing their wards from the local schools are independent issues, which must have been triggered by different individual causes.

42. Statements:

I. There is unprecedented increase in the number of young unemployed in comparison to the previous year.

II. A large number of candidates submitted applications against an advertisement for the post of manager issued by a bank

Options:

A. Statement I is the cause and statement II is its effect.
B. Statement II is the cause and statement I is its effect.
C. Both the statements I and II are independent causes.
D. Both the statements I and II are effects of independent causes.
E. Both the statements I and II are effects of some common cause.

Answer: A. An increase in the number of unemployed youth is bound to draw in huge crowds for a single vacancy.

43. Statements:

I. Majority of the students in the college expressed their opinion against the college authority’s decision to break away from the university and become autonomous

II. The university authorities have expressed their inability to provide grants to its constituent colleges.

Options:

A. Statement I is the cause and statement II is its effect.
B. Statement II is the cause and statement I is its effect.
C. Both the statements I and II are independent causes.
D. Both the statements I and II are effects of independent causes.
E. Both the statements I and II are effects of some common cause.

Answer: B. Clearly, the university’s decision to refuse grant to the colleges must have triggered the college authority to become autonomous.

44. Statements:

I. The Government has imported large quantities of sugar as per trade agreement with other countries.

II. The prices of sugar in the domestic market have fallen sharply in the recent months

Options:

A. Statement I is the cause and statement II is its effect.
B. Statement II is the cause and statement I is its effect.
C. Both the statements I and II are independent causes.
D. Both the statements I and II are effects of independent causes.
E. Both the statements I and II are effects of some common cause.

Answer: A. The increase in supply always triggers a reduction in the prices.

45. Statements:

I. It is the aim of the city’s civic authority to get the air pollution reduced by 20% in the next two months.

II. The number of asthma cases in the city is constantly increasing

Options:

A. Statement I is the cause and statement II is its effect.
B. Statement II is the cause and statement I is its effect.
C. Both the statements I and II are independent causes.
D. Both the statements I and II are effects of independent causes.
E. Both the statements I and II are effects of some common cause.

Answer: B. The increase in number of asthma cases must have alerted the authorities to take action to control air pollution that triggers the disease.

Logical Deduction

In each question below are given two statements followed by two conclusions numbered I and II. You have to take the given two statements to be true even if they seem to be at variance from commonly known facts. Read the conclusion and then decide which of the given conclusions logically follows from the two given statements, disregarding commonly known facts.

Give answer:

(A) If only conclusion I follows
(B) If only conclusion II follows
(C) If either I or II follows
(D) If neither I nor II follows and
(E) If both I and II follow.

46. Statements: No women teacher can play. Some women teachers are athletes.

Conclusions:

I. Male athletes can play.

II. Some athletes can play.

Options:

A. Only conclusion I follows
B. Only conclusion II follows
C. Either I or II follows
D. Neither I nor II follows
E. Both I and II follow

Answer: D. Since one premise is negative, the conclusion must be negative. So, neither conclusion follows.

47. Statements: All mangoes are golden in color. No golden-colored things are cheap.

Conclusions:

I. All mangoes are cheap.

II. Golden-colored mangoes are not cheap.

Options:

A. Only conclusion I follows
B. Only conclusion II follows
C. Either I or II follows
D. Neither I nor II follows
E. Both I and II follow

Answer: B. Clearly, the conclusion must be universal negative and should not contain the middle term. So, it follows that ‘No mango is cheap’. Since all mangoes are golden in colour, we may substitute ‘mangoes’ with ‘golden-coloured mangoes’. Thus, II follows.

48. Statements: Some kings are queens. All queens are beautiful.

Conclusions:

I. All kings are beautiful.

II. All queens are kings.

Options:

A. Only conclusion I follows
B. Only conclusion II follows
C. Either I or II follows
D. Neither I nor II follows
E. Both I and II follow

Answer: D. Since one premise is particular, the conclusion must be particular. So, neither I nor II follows.

49. Statements: All cars are cats. All fans are cats.

Conclusions:

I. All cars are fans

II. All cars are fans

Options:

A. Only conclusion I follows
B. Only conclusion II follows
C. Either I or II follows
D. Neither I nor II follows
E. Both I and II follow

Answer: D. Since the middle term ‘cats’ is not distributed even once in the premises, no definite conclusion follows.

50. Statements: Some engineers are fools. Anand is an engineer.

Conclusions:

I. Some fools are engineers.

II. Anand is a fool.

Options:

A. Only conclusion I follows
B. Only conclusion II follows
C. Either I or II follows
D. Neither I nor II follows
E. Both I and II follow

Answer: A. Since the middle term ‘engineer’ is not distributed even once in the premises, no definite conclusion follows. However, I is the converse of the first premise and thus it holds.

Letter and Symbol Series

51. SCD, TEF, UGH, ____, WKL

A. CMN
B. UJI
C. VIJ
D. IJT

Answer: C. There are two alphabetical series here. The first series is with the first letters only: STUVW. The second series involves the remaining letters: CD, EF, GH, IJ, KL.

52. B₂CD, _____, BCD₄, B₅CD, BC₆D

A. B₂C₂D
B. BC₃D
C. B₂C₃D
D. BCD₇

Answer: B. Because the letters are the same, concentrate on the number series, which is a simple 2, 3, 4, 5, 6 series, and follows each letter in order.

53. QPO, NML, KJI, _____, EDC

A. HGF
B. CAB
C. JKL
D. GHI

Answer: A. This series consists of letters in a reverse alphabetical order.

54.

A. 1
B. 2
C. 3
D. 4

Answer: C. This is an alternating series. In the first segment, the letter “E” faces right, then down, then right. In the second segment, the letters all face down. To follow this pattern, in the fourth segment, the letters must all face up.

55.

A. 1
B. 2
C. 3
D.4

Essential Part

56. champion

A. running
B. swimming
C. winning
D. speaking

Answer: C. Without a first-place win, there is no champion, so winning is essential. There may be champions in running, swimming, or speaking, but there are also champions in many other areas.

57. saddle

A. horse
B. seat
C. stirrups
D. horn

Answer: B. A saddle is something one uses to sit on an animal, so it must have a seat (choice b). A saddle is often used on a horse (choice a), but it may be used on other animals. Stirrups (choice c) are often found on a saddle but may not be used. A horn (choice d) is found on Western saddles, but not English saddles, so it is not the essential element here.

58. directory

A. telephone
B. listing
C. computer
D. names

Answer: B. A directory is a listing of names or things, so (choice b) is the essential element. A telephone (choice a) often has a directory associated with it, but it is not essential. A computer (choice c) uses a directory format to list files, but it is not required.Names (choice d) are often listed in a directory, but many other things are listed in directories, so this is not the essential element.

59. contract

A. agreement
B. document
C. written
D. attorney

Answer: A. An agreement is necessary to have a contract. A contract may appear on a document (choice b), but it is not required. A contract may be oral as well as written, so choice c is not essential. A contract can be made without an attorney (choice d).

60. vibration

A. motion
B. electricity
C. science
D. sound

Answer: A. Something cannot vibrate without creating motion, so motion is essential to vibration.

Artificial Language

61. Here are some words translated from an artificial language.

gorblflur means fan belt

pixngorbl means ceiling fan

arthtusl means tile roof

Which word could mean “ceiling tile”?

A. gorbltusl
B. flurgorbl
C. arthflur
D. pixn arth

Answer: D. Gorbl means fan; flur means belt; pixn means ceiling; arth means tile; and tusl means roof. Therefore, pixnarth is the correct choice.

62. Here are some words translated from an artificial language.

hapllesh means cloudburst

srenchoch means pinball

resbosrench means ninepin

Which word could mean “cloud nine”?

A. leshsrench
B. ochhapl
C. haploch
D. haplresbo

Answer: D. Hapl means cloud; lesh means burst; srench means pin; och means ball; and resbo means nine. Leshsrench (choice a) doesn’t contain any of the words needed for cloud nine. We know that och means ball, so that rules out choices b and c. When you combine hapl (cloud) with resbo (nine), you get the correct answer

63. Here are some words translated from an artificial language.

morpirquat means birdhouse

beelmorpir means bluebird

beelclak means bluebell

Which word could mean “houseguest”?

A. morpirhunde
B. beelmoki
C. quathunde
D. clakquat

Answer: C. Morpir means bird; quat means house; beel means blue; clak means bell. Choice c, which begins with quat, is the only possible option.

64. Here are some words translated from an artificial language.

krekinblaf means workforce

dritakrekin means groundwork

krekinalti means workplace.

Which word could mean “someplace”?

A. moropalti
B. krekindrita
C. altiblaf
D. dritaalti

Answer: A. Krekin means work; blaf means force; drita means ground; and alti means place. Drita means ground, so that rules out choices b and d. Choice c isn’t correct because blaf means force. That leaves choice a as the only possible answer.

65. Here are some words translated from an artificial language.

dionot means oak tree

blyonot means oak leaf

blycrin means maple leaf

Which word could mean “maple syrup”?

A. blymuth
B. hupponot
C. patricrin
D. crinweel

Answer: C. In this language, the adjective follows the noun. From dionot and blyonot, you can determine that ‘onot’ means oak. From blyonot and blycrin, you can determine that bly means leaf. Therefore, crin means maple. Because the adjective maple comes after the noun, patricrin is the only possible choice.

Gambaru tổng hợp.

Tags câu hỏi logic, logical question, Phỏng vấn

Dev's Corner

ML Engineer là gì? Giải đáp bí ẩn xung quanh ML Engineer

Post author By Gambaru
Post date 26 August, 2022
No Comments on ML Engineer là gì? Giải đáp bí ẩn xung quanh ML Engineer

Phẩm chất của 1 ML Engineer thành công. Ảnh: FactoryPal

Bài viết này sẽ giúp bạn nắm vững những bước đầu tiên đi tới sự nghiệp đầy triển vọng trong lĩnh vực Machine Learning (Học máy). Hãy cùng tìm hiểu ML Engineer (Kỹ sư học máy) là gì, trách nhiệm công việc của họ và cách thành công trong vai trò này.

ML Engineer là những lập trình viên thành thạo về kỹ thuật, những người chuyên nghiên cứu, xây dựng và thiết kế phần mềm tự chạy để tự động hóa các mô hình dự đoán. Kỹ sư ML xây dựng các hệ thống trí tuệ nhân tạo (AI) tận dụng các tập dữ liệu khổng lồ để tạo và phát triển các thuật toán có khả năng học hỏi và cuối cùng là đưa ra dự đoán.

*Machine Learning Engineer. Ảnh: Sandiedo.edu*

Mỗi khi phần mềm thực hiện một thao tác, nó sẽ “học” từ những kết quả đó để thực hiện các thao tác trong tương lai chính xác hơn.

Thiết kế hệ thống học máy yêu cầu ML Engineer đánh giá, phân tích và tổ chức dữ liệu, thực hiện kiểm thử và tối ưu hóa quy trình học tập để giúp phát triển các mô hình học máy hiệu suất cao.

Dừng lại chút nào, nếu bạn đang #open_to_work, thử nghía qua các công việc đang tuyển trên Gamba nhé. Vào LINK NÀY để xem các job cần đến kỹ năng Machine Learning hoặc scan QR Code ở bên dưới nhé.

*Xem và ứng tuyển các job Machine Learning*

ML Engineer làm gì?

Kỹ sư học máy là những lập trình viên có kỹ năng cao, những người phát triển hệ thống trí tuệ nhân tạo (AI) sử dụng các tập dữ liệu lớn để nghiên cứu, phát triển và tạo ra các thuật toán có thể học và đưa ra dự đoán.

Nhìn chung, vai trò này chịu trách nhiệm thiết kế các hệ thống học máy, liên quan đến việc đánh giá và tổ chức dữ liệu, thực hiện các bài kiểm thử, nói chung là giám sát và tối ưu hóa các quy trình học máy để giúp phát triển các hệ thống học máy hoạt động mạnh mẽ.

Nhiều mô tả công việc yêu cầu kiến thức và kinh nghiệm về các ngôn ngữ lập trình như Python, Java và C / C ++.

Mô tả công việc của kỹ sư học máy

Mặc dù các nhiệm vụ cụ thể sẽ khác nhau tùy thuộc vào quy mô của một tổ chức và nhóm khoa học dữ liệu tổng thể, nhưng mô tả công việc của Kỹ sư học máy điển hình sẽ bao gồm tất cả hoặc hầu hết các trách nhiệm sau:

Thiết kế, phát triển và nghiên cứu các hệ thống, mô hình và chương trình Machine Learning
Nghiên cứu, biến đổi và chuyển đổi các nguyên mẫu khoa học dữ liệu
Tìm kiếm và chọn tập dữ liệu thích hợp trước khi thu thập dữ liệu và mô hình hóa dữ liệu
Thực hiện phân tích thống kê và sử dụng kết quả để cải thiện mô hình
Đào tạo và đào tạo lại các hệ thống và mô hình ML khi cần thiết
Xác định sự khác biệt trong phân phối dữ liệu có thể ảnh hưởng đến hiệu suất của mô hình trong các tình huống thực tế
Trực quan hóa dữ liệu để có thông tin chi tiết hơn
Phân tích các trường hợp sử dụng của thuật toán ML và xếp hạng chúng theo xác suất thành công
Hiểu khi nào những phát hiện của bạn có thể được áp dụng cho các quyết định kinh doanh
Làm phong phú thêm các frameworj và thư viện ML hiện có
Xác minh chất lượng dữ liệu và / hoặc đảm bảo nó thông qua làm sạch dữ liệu

Nền tảng của ML Engineer

Dù bạn sẽ thấy ML Engineer có thể bắt đầu ở bất kỳ ngành nào, nhưng hầu hết đều có kiến thức nền tảng về khoa học máy tính, kỹ thuật, toán học hoặc khoa học dữ liệu.

Một nghiên cứu từ Indeed đã nhấn mạnh sự khác biệt về nền móng của Kỹ ML Engineer và các vai trò liên quan khác, như (Data Scientist) nhà khoa học dữ liệu, Software Engineer (Kỹ sư phần mềm), Data Analyst (nhà phân tích dữ liệu) và Data Engineer (Kỹ sư dữ liệu).

Các con số của Indeed cho thấy vai trò Data Scientist có lĩnh vực nghiên cứu đa dạng nhất trong số các chức danh công việc liên quan được xem xét, trong khi vai trò Software Engineer thu hút những người có nền tảng giáo dục ít đa dạng nhất.

Trong trường hợp của ML Engineer, hơn 60% đến từ khoa học máy tính hoặc kỹ thuật và họ có khả năng xuất thân từ những nền tảng này gần như gấp đôi so với Data Scientist.

Theo nền tảng chuyên môn của họ, nghiên cứu cho thấy rằng chức danh công việc trước đây của ML Engineer có nhiều khả năng nhất là “Kỹ sư phần mềm”.

Nhiều ML Engineer khác hoạt động về mặt học thuật trước khi chuyển sang sự nghiệp machine learning.

Nhưng điều quan trọng cần nhớ là khoa học dữ liệu và học máy vẫn còn ở giai đoạn sơ khai vì các lĩnh vực nghiên cứu và nhiều công ty trong lĩnh vực công nghệ và hơn thế nữa đang tìm cách xây dựng các nhóm khoa học dữ liệu của họ, các con đường mới để trở thành Kỹ sư học máy đang trở nên khả thi.

Mặc dù bạn cần một nền tảng vững chắc về toán học và khoa học máy tính, nhưng nhiều người đang học các kỹ năng và lĩnh vực kiến thức khác cần thiết để trở thành Kỹ sư học máy – ví dụ: hiểu phương pháp học có giám sát và không giám sát, học sâu, hồi quy, phân loại, phương pháp phân nhóm, và mạng nơ-ron – bằng cách tham gia 1 khóa học cấp chứng chỉ, nhiều khóa học trong số đó có thể được hoàn thành trực tuyến.

Đặc điểm của một ML Engineer thành công

Mọi chuyên gia về Học máy xuất sắc dường như sẽ có một vài đặc điểm chung. Dưới đây là các đặc điểm của một Kỹ sư học máy thành công:

Họ là những lập trình viên vững tay nghề

Nếu bạn đang muốn theo đuổi sự nghiệp trong lĩnh vực AI và máy học, bạn sẽ cần học cách lập trình. Một lập trình viên nên hiểu các ngôn ngữ được sử dụng thường xuyên bao gồm C ++, Java và Python và nó không dừng lại ở đó.

Các ngôn ngữ như R, Lisp và Prolog cũng đã trở thành những ngôn ngữ quan trọng cho việc học máy. Tuy nhiên, không phải tất cả các kỹ sư học máy thành công đều cần phải là chuyên gia về HTML hoặc JavaScript.

Họ có nền tảng vững chắc về Toán và Thống kê

Bạn không thể thành thạo machine learning nếu không biết chút nào về toán học. Cho dù bạn có nền tảng chính thức về toán học và thống kê hay không, bạn sẽ cần phải có năng lực toán học ít nhất ở cấp trung học phổ thông để theo kịp.

Trọng tâm của nhiều thuật toán học máy là một đặc tính chính thức của xác suất và các kỹ thuật bắt nguồn từ nó. Liên quan chặt chẽ đến vấn đề này là lĩnh vực thống kê, cái cung cấp các thước đo, phân phối và phương pháp phân tích khác nhau cần thiết để xây dựng và xác nhận các mô hình từ dữ liệu quan sát.

Về cơ bản, nhiều thuật toán machine learning là phần mở rộng của các bước lập mô hình thống kê.

Họ là những người giải quyết vấn đề sáng tạo

Các kỹ sư ML giỏi nhất được thúc đẩy bởi sự tò mò. Họ không phản ứng bằng sự thất vọng khi một mô hình hoặc thử nghiệm không thành công, mà thay vào đó, họ tò mò muốn tìm hiểu lý do.

Nhưng họ cũng giải quyết vấn đề một cách hiệu quả.

Các chuyên gia học máy giỏi nhất phát triển các phương pháp tiếp cận tổng quát để sửa lỗi và phân nhóm sai lạc (misclassification) trong các mô hình học máy của họ vì việc sửa các lỗi riêng lẻ sẽ tốn thời gian đồng thời làm cho các mô hình của bạn khó làm việc hơn và phức tạp hơn.

Điều quan trọng nữa là phải cân bằng giữa quyết tâm giải quyết vấn đề với hiểu biết thực tế rằng rất nhiều mô hình và thử nghiệm của bạn sẽ thất bại. Các ML Engineer giỏi nhất phát triển khả năng hiểu được thời điểm cần rời bỏ.

Họ yêu thích quy trình lặp đi lặp lại

Học máy về bản chất là một quá trình lặp đi lặp lại. Để đạt được hiệu quả trong vai trò này, một người cần thực sự tận hưởng phong cách phát triển đó.

Xây dựng một hệ thống học máy có nghĩa là người ta xây dựng một mô hình rất đơn giản một cách nhanh chóng, để bắt đầu, sau đó lặp lại để cải thiện nó theo từng giai đoạn.

Tuy nhiên, một lần nữa, một ML Engineer giỏi không thể quá cứng đầu. Bạn cần hiểu rõ khi nào cần dừng lại.

Luôn có thể cải thiện độ chính xác của bất kỳ hệ thống học máy nào bằng cách tiếp tục lặp lại hệ thống đó, nhưng người ta cần học cách phát triển trực giác khi nó không còn xứng đáng với thời gian và công sức.

Họ có trực giác mạnh mẽ về dữ liệu

Không có machine learning nào mà không phân tích dữ liệu. Một ML Engineer hoặc Data Scientist giỏi cần có khả năng nhanh chóng sàng lọc các tập dữ liệu lớn, xác định các mẫu và biết cách sử dụng dữ liệu đó để đưa ra các kết luận có ý nghĩa và có thể hành động được.

Gần giống như họ có giác quan thứ sáu đối với dữ liệu. Kỹ năng quản lý dữ liệu là rất quan trọng.

Chúng cũng nên hữu ích trong việc xây dựng các đường ống dữ liệu lớn (data pipeline).

Và người ta cũng cần hiểu sức mạnh của trực quan hoá. Để đảm bảo những thông tin đắt giá bạn khai thác được người khác hiểu và đánh giá đúng, bạn phải có sẵn các công cụ trực quan hóa dữ liệu như Excel, Tableau, Power BI, Plotly và Dash.

Những công việc tương tự với ML Engineer

Trong lĩnh vực rộng lớn hơn của khoa học dữ liệu (data science), có nhiều chuyên gia dữ liệu thực hiện các vai trò tương tự như ML Engineer. Dưới đây là một số vị trí có thể là một phần trong con đường sự nghiệp của một chuyên gia ML.

Data Scientist (Nhà khoa học dữ liệu)

Vai trò của Nhà khoa học dữ liệu nằm ở mối liên hệ giữa công nghệ và kinh doanh. Nhà khoa học dữ liệu phải hiểu những thách thức mà các công ty đang phải đối mặt và sau đó sử dụng phân tích dữ liệu và xử lý dữ liệu để tìm ra các giải pháp và cơ hội.

Công việc của một Nhà khoa học dữ liệu là tìm ra những thông tin chi tiết hữu ích có thể hành động được ẩn trong dữ liệu phi cấu trúc và sử dụng dữ liệu đó để thực hiện các phân tích dự đoán.

Các xu hướng và kiểu mẫu mà nhà khoa học dữ liệu nhận thấy giúp các công ty đưa ra quyết định dựa trên dữ liệu và cuối cùng là tăng doanh thu. Nhà khoa học dữ liệu cũng được kỳ vọng trình bày những phát hiện của họ bằng những hình ảnh trực quan bắt mắt.

Data Analyst (Nhà phân tích dữ liệu)

Các nhà phân tích dữ liệu quan tâm đến việc trực quan hóa, tổng hợp và xử lý dữ liệu.

Một trong những trách nhiệm hoặc kỹ năng quan trọng nhất của Nhà phân tích dữ liệu là tối ưu hóa, là nơi họ tạo và sửa đổi các thuật toán có thể được sử dụng để thu thập thông tin mà không làm hỏng dữ liệu.

Data Engineer (Kỹ sư dữ liệu)

Kỹ sư dữ liệu xây dựng và thử nghiệm hệ sinh thái dữ liệu lớn có thể mở rộng để các Nhà khoa học dữ liệu có hệ thống dữ liệu ổn định và được tối ưu để chạy các thuật toán của họ.

Công việc của Kỹ sư dữ liệu cũng là cập nhật các hệ thống hiện có với các phiên bản nâng cấp của công nghệ hiện tại.

Kỹ thuật dữ liệu cũng thường liên quan đến việc xây dựng các thuật toán để giúp các công ty hoặc khách hàng truy cập dễ dàng hơn vào dữ liệu thô.

AI Engineer (Kỹ sư trí tuệ nhân tạo)

Kỹ sư AI làm việc với các kỹ thuật máy học truyền thống như xử lý ngôn ngữ tự nhiên (NLP) và mạng nơ-ron để xây dựng các mô hình có tác dụng hỗ trợ cho các ứng dụng AI.

Computer Scientist (Nhà khoa học máy tính)

Các nhà Khoa học Máy tính chủ yếu giải quyết phần mềm và hệ thống phần mềm, bao gồm lý thuyết, thiết kế, phát triển và ứng dụng của chúng.

Software Engineer / Software Developer (Kỹ sư phần mềm)

Kỹ thuật phần mềm là sử dụng phân tích toán học và các nguyên tắc khoa học máy tính để thiết kế và phát triển phần mềm máy tính.

Kỹ sư phần mềm phát triển tất cả các loại phần mềm, bao gồm hệ điều hành, trò chơi máy tính, ứng dụng và hệ thống điều khiển mạng.

Hàng ngày, tùy thuộc vào giai đoạn phát triển phần mềm, Nhà phát triển phần mềm sẽ đảm bảo các chương trình đang hoạt động chạy trơn tru, cập nhật, sửa lỗi và tạo chương trình mới.

Kỹ thuật phần mềm trải dài trên nhiều loại công nghệ, từ thiết bị nhà thông minh đến trợ lý ảo.

ML Engineer làm việc với ai?

Tùy vào quy mô của một tổ chức, ML Engineer rất có thể sẽ làm việc như một thành viên của nhóm khoa học dữ liệu lớn hơn.

Nhóm đó có thể bao gồm Data Scientist, Data Analyst, Data Engineer, Data Architect (Kiến trúc sư dữ liệu) và Quản trị viên cơ sở dữ liệu (Database Administrator).

Ngoài nhóm dữ liệu của riêng họ, ML Engineer có thể hợp tác với nhiều bên liên quan khác nhau với các kỹ năng khác nhau trong toàn bộ tổ chức, bao gồm tất cả mọi người từ lãnh đạo doanh nghiệp cấp cao đến nhóm tiếp thị, bán hàng, CNTT, phát triển phần mềm hoặc phát triển web, tùy thuộc vào mức độ thâm niên.

Những lý do để trở thành kỹ sư học máy

Nếu bạn tò mò về sự nghiệp trong lĩnh vực dữ liệu hoặc AI, thì đây là một số lý do hàng đầu để trở thành Kỹ sư học máy.

Có tiềm năng thu nhập cao

Indeed đã xếp hạng ML Engineer là công việc số 1 của năm 2019 vì lý do chính đáng: họ kiếm được mức lương trung bình là 148.485 USD.

Các con số của Indeed cũng cho thấy rằng một ML Engineer có thể kiếm được tới 200.000 USD tại một trong những thị trường lớn hơn của Mỹ.

Các ML Engineer ở San Francisco đã báo cáo mức lương trung bình chỉ ở phía nam là 200.000 USD trong khi ở New York, họ chỉ mang về nhà dưới 170.000 USD.

Nhu cầu về kỹ năng ML Engineering đang cao

Rất nhiều công ty đang quan tâm nhiều đến dữ liệu lớn và do đó, nhu cầu về các chuyên gia dữ liệu trên thị trường việc làm cao hơn bao giờ hết.

Thậm chí, đã có những báo cáo về cuộc đấu thầu tranh giành tài năng AI khi những gã khổng lồ trong lĩnh vực công nghệ gấp rút giành lấy những bộ óc hàng đầu trong ngành.

Một báo cáo gần đây của Robert Half về tương lai của công việc (the future of work) tiết lộ rằng 30% các nhà quản lý ở Mỹ được khảo sát cho biết công ty của họ hiện đang sử dụng AI và ML, và 53% dự kiến sẽ áp dụng những công cụ đó trong vòng 3-5 năm tới.

Nói cách khác, không có dấu hiệu nào cho thấy thị trường việc làm màu mỡ này sẽ sớm biến mất.

Cơ hội học hỏi liên tục

Machine Learning là một lĩnh vực tương đối mới. Vẫn còn rất nhiều giải pháp, công cụ, thuật toán và ứng dụng đang chờ được tạo ra và khám phá.

Tương tự như Software Engineer, Kỹ sư ML về bản chất phải coi trọng việc học. Và việc sử dụng các khóa học, blog, hướng dẫn và podcast để luôn dẫn đầu trong một lĩnh vực non trẻ và đang thay đổi nhanh chóng là điều cần thiết.

Trên thực tế, Khảo sát Digital Skills năm 2020 của BrainStation cho thấy 61% chuyên gia dữ liệu tham gia các khóa học trực tiếp và 60% khác tập trung vào các hội thảo. Rõ ràng, giáo dục thường xuyên rõ ràng là một bộ phận cố định của lĩnh vực này.

Họ sống trên đỉnh cao công nghệ

Bạn có phải là một trong những người chỉ đơn giản là bị mê hoặc bởi công nghệ, cực kỳ phấn khích khi đọc về về những tiến bộ mới nhất trong AI hoặc các ứng dụng máy tính?

Ở vị trí này, bạn sẽ có cơ hội tạo ra sự thay đổi thực sự bằng cách làm việc trên các công nghệ mới nhất và sáng tạo nhất. Nếu bạn thích logic và lập trình, bạn sẽ thích học các ngôn ngữ lập trình mới cho các ứng dụng tiên tiến.

Đây cũng là một sự nghiệp tuyệt vời cho những ai thích tìm kiếm các ứng dụng thực tế cho toán học. Là một Kỹ sư Máy học, bạn có khả năng sử dụng đại số tuyến tính, giải tích, xác suất thống kê trong công việc hàng ngày của mình.

Machine Learning mang lại sự đa dạng

Nếu bạn thuộc tuýp người cảm thấy nhàm chán, thì sự nghiệp Machine learning sẽ có rất nhiều sự đa dạng.

Hầu như bất kỳ ngành nào bạn có thể nghĩ đến sẽ được hưởng lợi từ việc đầu tư nhiều tiền hơn, thời gian và tài nguyên vào việc khai thác thông tin chi tiết từ dữ liệu, vì vậy bạn có thể chọn làm việc trong bất kỳ ngành nào mà bạn quan tâm.

Bạn cũng có cơ hội để thực sự tạo ra sự khác biệt. Bạn có thể tham gia một đội ngũ tạo ra bước đột phá lớn tiếp theo trong lĩnh vực chăm sóc sức khỏe, an ninh mạng, tiếp thị hoặc ô tô tự hành. Đó là một triển vọng thú vị đối với nhiều người.

Các kỹ năng trong Machine Learning

Để thành công với tư cách ML Engineer, bạn phải kết hợp kiến thức và bộ kỹ năng của Kỹ sư phần mềm và Nhà khoa học dữ liệu. Điều đó có nghĩa là hiểu tất cả các khái niệm cơ bản của khoa học máy tính và phân tích dữ liệu, đồng thời sở hữu một số kỹ năng mềm cần thiết cho cả hai ngành.

Kỹ năng dữ liệu

Một Kỹ sư học máy được kỳ vọng sẽ có nhiều năng lực giống như Nhà khoa học dữ liệu, bao gồm mô hình hóa dữ liệu, trình độ kỹ thuật với các ngôn ngữ lập trình như Python và Java và hiểu cách đánh giá các thuật toán và mô hình dự đoán. Hiểu biết về xác suất và thống kê cũng sẽ rất hữu ích.

Kỹ năng kỹ thuật phần mềm

Một số khái niệm khoa học máy tính quan trọng đối với Kỹ sư ML là thuật toán (và biết cách viết thuật toán có thể sắp xếp, tối ưu hóa và tìm kiếm), hiểu cấu trúc dữ liệu và có kiến thức về kiến trúc máy tính.

Vì đầu ra điển hình của Kỹ sư ML là phần mềm, họ cũng phải hiểu cách tuân theo các phương pháp tốt nhất về kỹ thuật phần mềm, đặc biệt là các phương pháp liên quan đến thiết kế hệ thống, kiểm soát phiên bản, kiểm thử và phân tích yêu cầu.

Kỹ năng học máy

Mặc dù một Kỹ sư học máy thường được cho là ngồi ở điểm giao giữa khoa học dữ liệu và kỹ thuật phần mềm, nhưng vẫn có một số năng lực đặc biệt quan trọng đối với các công việc ML.

Nhiều Kỹ sư học máy hiện đang được đào tạo về học sâu (deep learning), kiến trúc mạng nơ-ron, xử lý ngôn ngữ tự nhiên (NLP) và lập trình động.

Kỹ năng mềm cho ML Engineer

Mặc dù machine learning là một chức danh kỹ thuật nhưng các kỹ năng mềm cũng rất quan trọng. Ngay cả khi bạn sở hữu kiến thức hàng đầu về máy học, bạn cũng sẽ yêu cầu các kỹ năng trau chuốt trong giao tiếp, quản lý thời gian và làm việc nhóm.

Điều quan trọng nữa là Kỹ sư học máy phải cam kết học tập suốt đời. Do các lĩnh vực trí tuệ nhân tạo, học sâu, học máy và khoa học dữ liệu đang thay đổi nhanh chóng như thế nào, giáo dục thường xuyên là cần thiết cho bất kỳ chuyên gia nào muốn đi đầu.

Công cụ trong Machine learning

ML Engineer không chỉ phải có kiến thức về cách viết mã và phát triển bằng các ngôn ngữ lập trình như Python, Java và C ++, nhiều kỹ sư học máy cũng thấy hữu ích khi sử dụng thành thạo các công cụ và tài nguyên sau:

TensorFlow
Spark và Hadoop
R Programming
Apache Kafka
MATLAB
Google Cloud ML Engine
Amazon Machine Learning

Tham khảo: BrainStation

Tags machine learning, ml engineer, ml engineering

Dev's Corner

Các phương pháp phát triển kỹ sư: Cố vấn, huấn luyện, và tài trợ!

Post author By Gambaru
Post date 11 July, 2022
No Comments on Các phương pháp phát triển kỹ sư: Cố vấn, huấn luyện, và tài trợ!

Bạn có biết sự khác nhau giữa cố vấn (mentoring), huấn luyện (coaching) và tài trợ (sponsoring) không?

Là những lãnh đạo kỹ thuật, chúng tôi thường xuyên thấy mình ở trong tình huống phát triển các đồng nghiệp.

Đó có thể là chính thức, ví dụ: với tư cách là người quản lý hoặc thông qua chương trình cố vấn hoặc không chính thức, ví dụ: làm việc với một người mà chúng tôi thấy có tiềm năng to lớn và muốn tham gia vào cuộc hành trình của họ.

Tôi nói hành trình vì đích đến có thể thú vị, nhưng với cách tiếp cận đúng, quá trình đến đó thậm chí còn thú vị hơn.

*Khác nhau giữa Coaching, Mentoring và Sponsoring*

Để tận dụng tối đa việc phát triển các đồng nghiệp của mình, bạn nên áp dụng nhiều cách tiếp cận khác nhau để giúp họ phát triển. Bạn muốn họ đạt được những giải pháp và mục tiêu mà bản thân bạn có thể không đạt được.

Có những phương pháp phát triển kỹ sư nào?

Tìm tới bất kỳ cuốn sách, khóa học hoặc ấn phẩm nào và bạn sẽ thấy nhiều cách tiếp cận được chỉ ra, nhưng bạn có thể sẽ thấy lặp đi lặp lại các chủ đề giống nhau.

Từ cố vấn, huấn luyện và tài trợ, đến một số cách tiếp cận trong cố vấn như giảng dạy và hướng dẫn.

Tất cả các phương pháp này thường được sử dụng thay thế cho nhau và trong cùng một buổi, rất khó để phân biệt giữa các phương pháp này. Vì vậy, hãy nói ngắn gọn về chúng.

Cố vấn (mentoring): chia sẻ kinh nghiệm của bạn để kỹ sư có thể tận dụng nó.
Huấn luyện (coaching): đặt những câu hỏi phù hợp để giúp kỹ sư đạt được giải pháp phù hợp với họ.
Tài trợ (sponsoring): cung cấp các dự án hoặc cơ hội vượt khỏi khả năng hiện tại để giúp một kỹ sư phát triển.

Với tư cách là một người quản lý, tôi khá tự tin rằng mình đã sử dụng sự trợ giúp đắc lực của cả ba, nhưng tôi rất ngây thơ và nhiều người cũng vậy.

Tạp chí Harvard Business Review đã đăng một nghiên cứu về vấn đề này 2 năm trước và nó cho biết các nhà quản lý hay nghĩ rằng họ đang huấn luyện, nhưng trên thực tế, họ đang ‘micromanaging-as-coaching’ (quản lý vi mô dưới dạng huấn luyện) mà thôi.

Đây là cạm bẫy chính xác mà tôi đã rơi vào. Lần đầu tiên tôi nhận ra rằng mình không biết sự khác biệt này là trong một hội thảo do Lara Hogan dẫn dắt về cố vấn, huấn luyện và tài trợ.

Hội thảo đó đã thắp lên một vùng hoàn toàn mới trong não tôi!

Sau đó, tôi ngồi xuống để viết ra những điều mình sẽ nói nếu tôi phải cố vấn vs. tài trợ vs. huấn luyện trong một bảng (xem phần tiếp theo) và tôi bắt đầu nhận ra sự khác biệt giữa chúng.

Các phương pháp phát triển khác nhau ra sao trong các tình huống?

Khi tôi bắt đầu hiểu sự khác biệt giữa cố vấn, huấn luyện và tài trợ, tôi tự đánh lừa mình rằng chỉ có 1 cách tiếp cận lý tưởng cho mỗi tình huống.

Hãy để tôi giúp bạn tiết kiệm thời gian, vì tôi không bao giờ lấy lại được số giờ đã mất trước khi tôi nhận ra điều này: bạn có thể sử dụng bất kỳ cách tiếp cận nào cho một tình huống.

Trên thực tế, việc lựa chọn cách tiếp cận nào để áp dụng thậm chí không nên phụ thuộc vào tình huống. Mà nó sẽ phụ thuộc vào các yếu tố của tình huống: thời gian, mối liên hệ, mối quan hệ và trạng thái tâm trí của người mà bạn đang làm việc cùng.

Để chứng minh điều đó, dưới đây bảng so sánh đã giúp tôi thấy sự khác biệt giữa ba cách tiếp cận. Đây là những gì bạn có thể nói với tư cách người cố vấn, huấn luyện viên hoặc nhà tài trợ trong một số tình huống phổ biến.

*Khác biệt giữa cố vấn, huấn luyện và tài trợ trong việc phát triển kỹ sư*

Bây giờ bạn có thể tự mình thấy sự khác biệt, thách thức là tìm ra phương pháp nào bạn cảm thấy thoải mái nhất và ít cảm thấy thoải mái nhất và sau đó làm quen với việc lựa chọn phương pháp tiếp cận dựa trên tình huống.

Cách tiếp cận tự nhiên của bạn là gì?

Bạn có thấy rõ ngay phương pháp phát triển nào mà bạn cảm thấy thoải mái nhất và ít cảm thấy thoải mái nhất không? Nếu không, đây là một câu đố dành cho bạn.

Hãy nghĩ về lần cuối cùng ai đó xin bạn lời khuyên (hoặc cụ thể hơn, hãy nghĩ về lần cuối cùng ai đó nói chuyện cụ thể với bạn về việc giải quyết xung đột với người khác.)

Nếu câu trả lời của bạn kiểu như:

Tôi đã khuyến khích họ / Tôi đã nói với họ / Tôi đã chia sẻ… Bạn có thể cảm thấy thoải mái nhất với tư cách là một người cố vấn.
Đầu tiên tôi hỏi họ… Bạn có thể cảm thấy thoải mái nhất với tư cách là một huấn luyện viên.
Tôi đã giúp đỡ đằng sau hậu trường… Bạn có thể cảm thấy thoải mái nhất với tư cách là một nhà tài trợ.

Rất có thể bạn đã sử dụng kết hợp các phương pháp tiếp cận để phát triển các đồng nghiệp của mình và điều quan trọng ở đây là có được cảm nhận về những người bạn hứng thú nhất và những người bạn ít hứng thú nhất.

Đối với cá nhân tôi, tôi thích cố vấn nhiều nhất và huấn luyện ít nhất. Bây giờ, sau rất nhiều nỗ lực có ý thức để huấn luyện, tôi đã ổn định về tổng thể, nhưng tôi có xu hướng chọn cách tiếp cận tương tự cho các tình huống cụ thể. Tôi đang cố cải thiện điều này.

Đối với những người hâm mộ chiêm tinh học, tôi có thể nói rằng tôi là mặt trời cố vấn (cách tiếp cận mà tôi mặc định), mặt trăng bảo trợ (điều thúc đẩy phương pháp của tôi) và bình minh huấn luyện (cách tôi áp dụng phương pháp của mình). Thế còn bạn?

Bạn sẽ chọn phương pháp phát triển kỹ sư nào?

Bây giờ bạn đã hiểu rõ hơn về các phương pháp tiếp cận khác nhau là gì và xu hướng tự nhiên của bạn ở đâu, đã đến lúc thực hành và thử thách bản thân bằng cách thay đổi phương pháp tiếp cận và thử kết hợp chúng vào một mẻ.

Trước khi bạn bắt đầu, đây là một số mẹo mà tôi nhận được từ những người khác hoặc tự khám phá.

Thông báo cho mọi người nếu bạn đang thử một cái gì đó mới

Khi tôi cố gắng đưa thêm phần huấn luyện vào các phiên 1:1 của mình, một số người đầu tiên tôi gặp ngay lập tức muốn biết tại sao tôi đặt câu hỏi và liệu họ có làm sai điều gì không. Điều đó thật đáng ngờ đối với họ.

Tôi đã phải nhanh chóng giảm thiểu thiệt hại bằng cách giải thích rằng tôi đang cố gắng phát triển với tư cách là một nhà quản lý và thử một cách tiếp cận phát triển mới; ngăn chặn khủng hoảng.

Sau đó, tôi thực hiện một cách tiếp cận tế nhị hơn và chỉ xoay quanh một hoặc hai câu hỏi cho đến khi cả hai chúng tôi đều cảm thấy thoải mái hơn. Tôi thích nhất là câu đơn giản, ‘Bạn nghĩ gì?’ Thông báo ý định của tôi và từ từ có hiệu quả. Như bạn có thể mong đợi, đối với những nhân viên mới chưa gặp tôi trước đây, họ nhanh chóng chấp nhận sự pha trộn trong cách tiếp cận của tôi hơn nhiều, bởi vì tôi đã chọn nó trước khi bắt đầu.

Bạn luôn có thể tài trợ

Bởi vì cố vấn và huấn luyện là những cách tiếp cận theo thời gian thực hơn, điều đó có nghĩa là luôn có cơ hội tài trợ ai đó khi bạn có mối quan hệ, tầm ảnh hưởng và thời gian.

Điều này nghĩa là khi kết thúc cuộc họp hoặc trao đổi 1: 1, tôi tự hỏi mình, ‘Tôi có thể làm gì để hỗ trợ họ khi cuộc họp kết thúc?’

Và đảm bảo tôi dành thời gian sau đó để đánh giá cách tôi có thể thực hành phương pháp tài trợ của mình. Theo tôi, đây là cơ hội lớn nhất bị bỏ lỡ trong vai trò lãnh đạo.

Thích ứng dần

Tôi thường thấy rằng khi bắt đầu một cuộc trò chuyện lớn với người mà tôi cố vấn, tôi theo dõi 3 điều: thời gian còn lại, mối liên hệ giữa chúng tôi trong thời điểm hiện tại, năng lượng và sự quen thuộc của họ với tình huống.

Trong những trường hợp thuận lợi và có sự tin tưởng giữa chúng tôi, tôi hầu như luôn bắt đầu với việc huấn luyện.

Nếu bất kỳ người nào trong số họ rút lui hoặc nếu tôi chủ yếu giao tiếp không đồng bộ, tôi có thể lựa chọn cách tiếp cận cố vấn hoặc thay đổi các điều kiện để cho phép huấn luyện nhiều hơn, chẳng hạn như yêu cầu thêm thời gian.

Tôi làm điều này vì tôi thấy rằng thông qua huấn luyện, người đó thường tiết lộ một giải pháp tốt hơn bất cứ điều gì tôi từng nghĩ ra. Đó cũng là những khoảnh khắc mà họ tương tác nhiều nhất.

Đó là những khoảnh khắc huấn luyện mà tôi học được nhiều nhất về một người, từ một người và tìm ra giải pháp tốt hơn.

Các câu hỏi huấn luyện là bài tập tuyệt vời

Tôi nhận được cái này từ Lara Hogan. Tôi nổi tiếng với việc kết thúc các cuộc nói chuyện và 1:1 với bài tập về nhà cho người kia, nhưng Lara Hogan là người đầu tiên khiến tôi có khả năng đặt câu hỏi huấn luyện vào cuối cuộc họp!

Tôi khá thích nhận những câu hỏi kích thích tư duy, vì vậy tôi cố gắng để một câu ở cuối phần 1:1 hay làm bài tập về nhà.

Tôi cho người đó biết rằng câu hỏi dành cho họ nhiều hơn tôi, nhưng tôi vẫn muốn nghe câu trả lời của họ không đồng bộ hoặc trong cuộc họp tiếp theo. Tôi luôn hy vọng họ sẽ theo dõi phản hồi của họ.

Thành thật mà nói, tôi nghĩ rằng tôi đã thất bại trong việc thực hành cái này, vì vậy viết bài này là một lời nhắc nhở tốt để tôi rút lại vấn đề này!

Mentees: Hướng dẫn người cố vấn của bạn

Hầu hết mọi người cố vấn cũng là một người được cố vấn, vì vậy chúng ta hãy lật ngược bảng trong một phút.

Trong cuộc họp cuối cùng bạn có với người cố vấn của mình, bạn nhận được cách tiếp cận nào và cách tiếp cận bạn thích là gì?

Bây giờ bạn đã biết sự khác biệt và có rất nhiều ví dụ để nói qua, bạn có thể nói với người cố vấn của mình những gì bạn có thể muốn nhiều hơn hoặc ít hơn.

Cá nhân tôi nhận thấy rằng yêu cầu những gì tôi muốn theo truyền thống là rất khó đối với tôi và tôi đã đạt được nhiều tiến bộ nhất khi ủng hộ nhu cầu của mình bằng cách chỉ vào khuôn khổ hoặc tập hợp thông tin của ‘bên thứ ba’ để tạo điều kiện cho cuộc trò chuyện.

Nếu bạn liên quan đến tình cảm này, chúng tôi hoan nghênh bạn sử dụng bảng này!

Đề xuất của tôi là thêm vào bảng một vài tình huống trong quá khứ với người cố vấn của bạn, viết ra trích dẫn từ cách tiếp cận bạn đã nhận được và tiếp tục điền vào phần còn lại của bảng.

Bằng cách đó, rất dễ chỉ ra những gì bạn đã nhận được so với những gì bạn đang tìm kiếm với sự kết hợp của các ví dụ chung và phù hợp.

Thử thách của tôi dành cho bạn

Theo lời khuyên của riêng tôi, bài đăng này sẽ không hoàn chỉnh nếu không có câu hỏi huấn luyện và thử thách dành cho bạn.

Câu hỏi:

Bạn có thể làm gì để tăng 10% tần suất sử dụng phương pháp tiếp cận kém thoải mái nhất trong 1:1 của mình?

Thách thức:

Thực hành cách tiếp cận kém thoải mái nhất của bạn với một người bạn mà bạn tin tưởng và sau đó đưa nó vào một trong các cuộc họp của bạn vào tuần tới (trước tiên hãy cho họ biết). Ghi lại những gì đã thay đổi và chia sẻ, nếu bạn sẵn sàng!

Nếu bạn giống tôi, thì bạn sẽ thấy rằng thử thách này không hề dễ dàng chút nào, nhưng ít nhất nó cũng có một chút thú vị.

Đó là bởi vì điều này đưa bạn ra khỏi vùng an toàn của mình để đổi lấy sự phát triển cá nhân. Tiềm năng giúp ai đó phát triển sẽ tăng lên khi bạn đầu tư vào bản thân và thúc đẩy bản thân phát triển.

Bạn sẽ ngạc nhiên về mức độ bạn có thể thoát ra khỏi mối quan hệ cố vấn bằng cách chuyển đổi mối quan hệ đó và tận tâm trong cách tiếp cận với những người được cố vấn.

Tôi hy vọng bạn chấp nhận thử thách này để làm phong phú thêm các mối quan hệ của mình và tận hưởng cuộc hành trình nhiều hơn nữa. Chúc may mắn!

Nguồn: LeadDev

Tags coaching, developing engineer, mentoring, sponsoring