Đối với các doanh nghiệp có quy mô nhỏ thì việc giữ chân và khiến các nhân viên đồng hành cùng phát triển được xem là một thách thức lớn trong ngành Nhân sự . Từ thực tế trên, trong lĩnh vực nhân sự, việc tìm ra nguyên nhân và các giải pháp phù hợp để giảm thiểu sự rời đi của nhân viên là một điều quan trọng.
Dựa trên khảo sát hơn 300 người đã bỏ việc tại các doanh nghiệp nhỏ tại Mỹ trong vòng hai năm gần đây chúng tôi đã thống kê những nguyên nhân khiến các nhân viên quyết định rời bỏ các doanh nghiệp nhỏ. Bài viết sau đây sẽ phân tích một vài nguyên nhân đồng thời đưa ra những giải pháp phù hợp cho các doanh nghiệp.
1. Những lý do hàng đầu: Chính sách giải quyết phúc lợi kém, vấn đề ở người quản lý
Những sự bồi thường hoặc phúc lợi kém là lý do được 33% số người cho là nguyên nhân hàng đầu dẫn đến việc họ chấp nhận rời bỏ công việc hiện tại. Song, có 26% nhân viên lại cho lý do khiến họ từ bỏ đến người người quản lý của họ.
Tiền không thể mua được hạnh phúc nhưng nó có thể đóng một vai trò quan trọng trong việc liệu các nhân viên có ở lại đồng hành cùng quanh doanh của bạn hay không. Vấn đề lương bổng luôn trì trệ sẽ vô tình tạo cho các nhân viên cảm giác họ chưa nhận được quan tâm từ tổ chức của mình.
Giải quyết vấn đề trì trệ
Nếu doanh nghiệp bạn có doanh thu cao, hãy quan tâm đến việc kích hoạt tăng lương. Điều này không chỉ là cách để tạo động lực giúp thu hút và giữ chân nhân viên đồng thời còn giảm bớt sức cạnh tranh so với các công ty đối thủ trong một thị trường tiền lương đang trì trệ.
Để tránh những phát sinh ngoài ý muốn cũng như đảm bảo tính minh bạch trong vấn đề nhạy cảm này, bạn nên sử dụng các phần mềm quản lý lương thưởng để có kế hoạch phân chia chi phí phù hợp. Quan tâm nhiều hơn đến các vấn đề phúc lợi cho nhân viên như áp dụng các gói bảo hiểm với giá phải chăng và toàn diện hơn, hỗ trợ các dịch vụ ăn uống, đi lại để giảm thiểu sự chi tiêu không cần thiết.
Chú trọng đến việc phát triển và đào tạo người quản lý
Theo một nghiên cứu nhỏ từ Gallup , có đến 50% nhân viên đã bỏ việc để rời xa người quản lý nhân sự của họ tại một số thời điểm trong chặng đường phát triển sự nghiệp.
Theo đó, các nhà quản lý có thể vô tình tạo ra những áp lực cho nhân viên thông qua các công việc hằng ngày của họ như: Luôn đặt ra những mục tiêu cần đạt; thay đổi liên tục những mong muốn hoặc thậm chí là không cho nhân viên có cơ hội bày tỏ những nguyện vọng, ý kiến cá nhân. Nguyên nhân có thể đến từ chính người quản lý và cả quy trình đào tạo của cả tổ chức. Đây được xem là hệ quả của việc các doanh nghiệp nhỏ thiếu sự đầu tư đúng mực trong việc phát triển tiềm lực của các nhân viên có triển vọng trước khi họ trở thành các nhà quản lý tuyệt vời.
Nói một cách đơn giản, chất lượng của những người quản lý của doanh nghiệp bạn đang sở hữu có khả năng phát triển thêm hoặc làm phá vỡ đi cả một hệ thống và quá trình tạo lập doanh nghiệp. Vì thế, trước khi mong muốn giữ chân các nhân viên, hãy chắc chắn rằng những người quản lý nhân viên của tổ chức bạn phải có phẩm chất tốt; được phát triển hoàn thiện các kỹ năng quan trọng bên cạnh khả năng chuyên môn nghề nghiệp.
2. Hạn chế khả năng phát triển nghề nghiệp
Có đến 22% số lượng nhân viên cho rằng lý do họ rời công ty là do họ cảm thấy bị giới hạn trong việc phát triển nghề nghiệp. Doanh nghiệp với quy mô nhỏ chưa thật sự tạo cho họ niềm tin về mô hình đào tạo, định hướng lâu dài cho mỗi cá nhân mà chỉ đơn thuần là đang giới hạn họ trong một phạm vi đủ đáp ứng các nhu cầu công việc hiện tại.
Đặc biệt hơn đối với những nhân viên trẻ trong thế hệ thế hệ Z (1995 – 2012), họ đánh giá cao những môi trường có thể mang lại cho họ sự thăng tiến. Đó cũng chính là ưu tiên hàng đầu của họ khi đánh giá các nhà tuyển dụng tiềm năng.
Cũng theo một nghiên cứu của Robert Half, 20% lực lượng lao động Gen Z kỳ vọng sẽ trở thành một doanh nhân thành đạt và 32% mong muốn được trở thành nhà quản lý nguồn lực về nhân sự. Điều này cho thấy, họ đang thật sự tìm kiếm một sự phát triển lâu dài. Các nhà tuyển dụng có thể cho rằng họ trẻ với bản tính tham vọng hoặc thiếu sự kiên nhẫn, muốn “đốt cháy giai đoạn”. Tuy nhiên, một sự thật là nếu các doanh nghiệp nhỏ có thể đưa ra một lộ trình tiến bộ rõ rệt cho mỗi nhân viên thì họ đã không phải rời bỏ doanh nghiệp của mình.
Thiết lập lộ trình phát triển và đánh giá những nỗ lực
Để khắc phục tình trạng hiện tại, các doanh nghiệp cần xác định rõ lộ trình thăng tiến cho mỗi nhân viên dựa trên năng lực của họ. Cụ thể, các lãnh đạo nhân sự cần thiết lập những tiêu chí phù hợp cho mỗi vị trí nghề nghiệp trong tổ chức của mình.
Đồng thời, việc đánh giá liên lục những thay đổi của mỗi nhân viên rất quan trọng. Doanh nghiệp cũng có thể sử dụng những các công cụ hỗ trợ để thuận tiện hơn trong việc theo dõi, đưa ra những phản hồi, đánh giá cụ thể cho nhân viên về hiệu suất công việc của họ. Điều này cho thấy, tổ chức đang thật sự đề cao những nỗ lực, ghi nhận những thành quả của từng nhân viên nhằm hướng đến việc phát triển một tập thể vững mạnh toàn diện.
3. Văn hóa môi trường doanh nghiệp
Như khảo sát mà chúng tôi đưa ra từ đầu bài viết, có 22% nhân viên cho rằng nguyên nhân khiến họ quyết định từ bỏ công việc là văn hóa môi trường trong doanh nghiệp.
Điều này là điều dễ nhận thấy vì khi một cá nhân không thể hòa hợp trong một môi trường văn hóa chung thì khó có thể hợp tác cùng nhau phát triển. Có nhiều nguyên nhân cụ thể hơn cho thấy một cá nhân không thích ứng được văn hóa làm việc của tổ chức.
Chẳng hạn như một nhân viên cảm thấy cách vận hành những hoạt động của doanh nghiệp chưa thật sự đi đúng định hướng so với các giá trị cốt lõi mà nhà tuyển dụng hay chính tổ chức đó đề ra. Chính từ sự nhìn nhận này mà có thể những đề xuất, góp ý của nhân viên không được chấp nhận, bị bác bỏ và họ cảm thấy mình không được tôn trọng dẫn đến việc rời đi.
Bên cạnh đó, sự tương tác quá ít hoặc quá căng thẳng khi làm việc cũng được xem là một yếu tố chi phối văn hóa doanh nghiệp. Điều này không đáng trách bởi lẽ mỗi công ty sẽ có những hình thức văn hóa tổ chức – ứng xử riêng tùy thuộc vào từng lĩnh vực, đặc tính tôn giáo, tuổi tác và cá tính của tập thể nhân sự. Ví dụ, nếu đó là một môi trường đầy sự năng động, đôi khi quá đến mức phải có sự cạnh tranh hay thậm chí là những tin đồn về bè phái, các nhân viên sẽ cân nhắc về khả năng đồng hành của mình sau khi họ có thời gian trải nghiệm.
Sự nhìn nhận và thay đổi từ cả hai phía – Doanh nghiệp & Nhân viên
Đối với doanh nghiệp, các nhà lãnh đạo nên có những hướng tiếp cận mới hơn để tạo ra một môi trường làm việc thoải mái cho nhân viên của mình. Hãy là một “lãnh đạo tinh tế” bằng cách lược bỏ bớt những nội quy kỷ luật thừa thãi, tăng giao tiếp – tương tác hiệu quả giữa các nhân viên thông qua những buổi thuyết trình, đánh giá. Đó là cách tạo cơ hội cho nhân viên trình bày quan điểm, những ý kiến phản hồi để cải thiện một môi trường làm việc chung. Các doanh nghiệp có thể tạo ra động lực cho nhân viên để họ có thể tự phát triển thông qua những cố gắng. Một nguyên tắc cần nhớ đối với mọi doanh nghiệp: Hãy để nhân viên bảo chúng ta nên làm gì thay vì chúng ta bảo họ phải làm gì.
Đối với nhân viên, việc đầu tiên chính là xác định cá tính và mục tiêu làm việc dựa trên tiêu chí sự phù hợp để có thể đưa ra quyết định đúng đắn trước khi làm việc trong bất kỳ tổ chức/doanh nghiệp nào. Đồng thời, nhân viên cũng cần có khả năng thích ứng nhanh với môi trường và hoàn cảnh công việc. Bạn nên nhớ dù bạn có là một nhân viên giỏi nhưng bạn không có sự thích ứng, tính linh hoạt thì khó có thể thành công.
Có rất nhiều nguyên nhân dẫn đến việc một nhân viên có thể rời bỏ công ty và bài viết mà TopDev trình bày chỉ tập trung phân tích những nguyên nhân phổ biến nhất. Song, dù cho lý do có là gì thì việc xác định và tìm ra các giải pháp nhằm khắc phục tình trạng đó là điều cần thiết. Hi vọng các nhà tuyển dụng nhân sự và cả nhân viên sẽ có cách nhìn mở cùng lối suy nghĩ sâu sắc hơn về vấn đề này.
Bạn là một lập trình viên sành sỏi, code bạn viết chưa bao giờ làm các sếp thất vọng, vậy đâu là bước tiếp theo cho bạn – lead một team. Bài viết này sẽ tóm gọn những đặc điểm, kỹ năng, kinh nghiệm cần có để thành công trở thành tech lead.
Thế nào là một Tech Lead (TL)
TL là cánh tay phải đắc lực của Project manager (PM)
Sự thành/bại của một TL được đong đo bằng sự thành công của team anh ấy dẫn dắt
Là người có thể đưa ra một tầm nhìn công nghệ, đưa ra lựa chọn, quyết định sử dụng cái nào và không sử dụng cái nào
Là người đưa đường dẫn lối cả team làm việc được cùng nhau
TL có thể nâng cao và giải quyết các vấn đề của team thông qua giao tiếp, kỹ năng lãnh đạo, và tầm ảnh hưởng.
Có thể bạn chưa biết, Quiz 03 của Kambria Code Challenge sẽ tập trung vào chủ đề Recurrent Neural Networks. Cuộc thi sẽ diễn ra vào cuối tuần sau ngày 02/05/2020.
Recurrent Neural Network (RNNs – Mạng nơ-ron hồi quy) là một trong những mô hình Deep Learning trong công nghệ trí tuệ nhân tạo. RNN ra đời với ý tưởng chính là sử dụng một bộ nhớ để lưu lại thông tin từ từ những bước tính toán xử lý trước để dựa vào nó có thể đưa ra dự đoán chính xác nhất cho bước dự đoán hiện tại. Cơ bản thì nó là một mạng neural hồi quy là một mạng neural chứa một vòng lặp bên trong nó.
Trong bài viết này, TopDev sẽ tổng hợp những nội dung về Recurrent Neural Network để giúp bạn nhanh chóng ôn tập kiến thức trước khi tham gia Quiz 03.
Bài viết này sẽ giúp làm sáng tỏ một số quan niệm sai lầm về Machine Learning. Quan trọng hơn là làm rõ một số quy trình của deep learning cũng như nguyên nhân tại sao nó hoạt động tốt trong các lĩnh vực như xử lý ngôn ngữ tự nhiên (NLP), nhận diện hình ảnh, và dịch ngôn ngữ trong khi lại không thành công ở những mảng khác.
Bài toán dịch ngôn ngữ là 1 bài toán khá hay. Hôm nay, bài này sẽ hướng dẫn bạn chi tiết về cách code lại thuật toán Attention trong Deep learning cho dạng bài toán Sequence to sequence (Seq2Seq). Trong bài hướng dẫn này mình sẽ code một Machine Translation có chức năng dịch ngôn ngữ Anh -> Việt.
Với mục đích hiểu sâu hơn về thuật toán, sản phẩm được code trên Tensorflow 2.0 thay vì Keras (code với Keras đơn giản hơn rất nhiều nhưng khó hiểu sâu).
Bài viết này sẽ hướng dẫn các bạn làm quen với Keras – 1 framework DL rất dễ sử dụng, thân thiện với người dùng nhưng cũng rất mạnh mẽ. Cụ thể, trong bài này mình sẽ nói về 4 modules chính trong Keras: Keras models, Keras layers, Keras losses và Keras optimizers.
Bài viết này chủ yếu dành cho những bạn đã có kiến thức cơ bản về ML, DL và đang muốn tìm 1 framework để xây dựng các mô hình ML, DL 1 cách nhanh nhất. Nếu bạn chưa có nên tảng về ML, DL hay còn lạ lẫm với các khái niệm filter, kernel size, strides trong CNN hoặc vẫn còn chưa quen với mạng recurrent network thì các bạn có thể tham khảo tại đây để có thể hiểu được những kiến thức cơ bản về mặt lý thuyết trước khi sử dụng Keras.
Đây là bài toán đặc trưng để sử dụng mô hình RNN. Trong nhiều mạng neural truyền thống khác, dữ liệu đầu vào và đầu ra hoàn toàn độc lập với nhau, tức là chúng không có liên kết thành chuỗi. Do đó khi áp dụng vào bài toán dự báo sẽ rất khó để đưa ra kết quả dự đoán.
Mô hình của thuật toán RNN tỏ ra lợi thế hơn trong việc áp dụng vào bài toán dự báo bởi lẽ chúng thực hiện cùng một tác vụ cho tất cả các phần tử của một chuỗi với đầu ra phụ thuộc vào cả các phép tính trước đó.
Bạn có thể tìm thấy một số bài toán thuộc thể loại này, như phân tích tài chính, tỉ số chứng khoán, hay áp dụng nó để phân tích tỉ giá Bitcoin để đầu tư đúng chỗ, đúng thời điểm.
Chúc bạn chuẩn bị tốt trước khi dự thi Quiz 03 – Kambria Code Challenge!
—–
Thông Tin Quiz 03
⏰Thời gian: 14h00 – 14h45 (giờ Việt Nam) ngày 02/05/2020
Chúng ta cùng bắt đầu học sử dụng React Hook, nó giải quyết vấn đề gì, sử dụng nó ra sao.
Mấy tháng trước thiên hạ rần rần với React hook khi nó còn đang ở bản proposal (show hàng cho các anh lập trình viên, nếu thích thì họ phát triển tiếp), bây giờ khi React chính thức công bố trên trang chủ rồi, chúng ta cùng làm quen với React hook cũng ko có gì muộn.
State trong React
Khi khai báo một component trong React bằng class (stateful component), không dùng function để khai báo (stateless component), thì trong component đó chúng ta có state
Vấn đề của hàm setState là nó chỉ có khi chúng ta khai báo component bằng class, nó là hàm async – nghĩa là nếu chúng ta gọi setState nhiều lần, component được render lại với số lần gọi setState.
Nguyên nhân chính đẻ ra cái hook chính là việc ko thể setState trong function component (ủa vậy tại sao đẻ ra khái niệm function component chi, stateless component chi?)
Sử dụng React Hook
Trước tiên muốn dùng React Hook, phải đảm bảo version React đang dùng thấp nhất là 16.8.0
Hàm quan trọng cần nhớ là useState
import React, {useState} from 'react';
Hàm useState nhận tham số initial state, sau đó sẽ trả về một mảng 2 phần tử, phần tử đầu tiên là state hiện tại, thứ 2 là hàm để update state (setState đó mà)
Một câu bạn sẽ được hỏi trong lúc phỏng vấn, một cơ hội để bạn tìm hiểu về công ty, vậy nên hỏi những câu nào?
Quy trình, nơi làm việc, team
Một task dài nhất là bao lâu? Fix một lỗi tốn nhiều nhất là bao lâu? Theo anh đánh giá, mất bao lâu để hiểu hết toàn bộ source code hiện tại?
Một task càng ngắn, chứng tỏ quy trình tốt và kiến trúc dự án tốt, task được phân chia một cách rõ ràng, lỗi được cô lập và kiểm soát tốt.
Với level junior hoặc mid thì tốn một tháng để thành thạo là bình thường, người quản lý có vấn đề gì với thời gian để thích nghi như thế không, đặc biệt nếu bạn chỉ ở mức junior
Rất nhiều team sẽ không có 1 người có thể hiểu hết toàn bộ source code, có thể giải thích cho bạn bất cứ chổ nào. Nhưng hy vọng bạn lead có thể nắm sơ và biết ai đang phụ trách phần nào.
Mình được cấp máy tính gì, công ty có cấp cho mình thiết bị mà mình cần để phục vụ công việc
Với mấy ngành khác thì không biết sao, chứ là dân dev, cái máy tính rất quan trọng, một ngày làm việc 8 tiếng, một tuần cày đủ 7 ngày, việc một cái máy tính chạy ngon lành không chết nửa chừng, không dính virus, ko tự tắt máy bất thình lình là vô cùng cần thiết.
Các công ty lớn thường việc mua thêm thiết bị cũng rất lằng nhằn về quy trình mua sắm thiết bị mới.
Làm sao công ty đánh giá được là em việc tốt, hiệu quả cao?
Câu này quan trọng nhất nhé, mỗi người quản lý, mỗi công ty sẽ có cách trả lời khác nhau.
Nó cũng tùy thuộc vị trí bạn đang apply, junior có thể bạn học được nhanh từ những người khác, senior thì bạn giúp đồng nghiệp của mình nâng cao chất lượng công việc.
Thường thì 2 dev có cùng làm 1 task không? (hoặc nhiều hơn)
Pair program hoặc mob program có được áp dụng trong công ty không?
Cách nhìn nhận của người làm chung về vấn đề hỗ trợ giữa các bộ phận, đã áp dụng chưa?
Có bao nhiêu dev trong công ty chỉ mới làm việc trong khoảng 6 tháng?
Có 2 nguyên nhân cho vấn đề này: (1) phát triển nhanh cần thêm người, (2) các bạn dev rủ nhau ra đi quá đông.
Công ty phát triển nhanh không có nghĩa là không có vấn đề, họ sẽ áp dụng những quy trình mới, tập hợp những người chưa từng làm việc chung với nhau thành một team.
Dev rủ nhau ra đi quá đông là tình huống không ai muốn nghe. Có thể công ty đang gặp khó khăn để cứu vớt dự án sắp chết, chính sách công ty không tốt, hay là lead nghỉ kéo người theo, dù là nguyên nhân gì cũng nên biết chính xác.
Team size đang là bao nhiêu người, số lượng mong muốn là bao nhiêu cũng là một cách để biết.
Có bao nhiêu dev làm ở đây 2, 4 năm rồi?
Một minh chứng cho việc các dev cảm thấy hài lòng với công ty. 1 dev có thể chịu đựng công ty trong tối đa một năm, nhưng sẽ hiếm thấy việc nhiều dev có thể cùng chịu đựng được trong nhiều năm.
Với những công ty startup (thời gian thành lập bé hơn 2 năm) thì chỉ cần biết người đầu tiên gia nhập công ty còn làm không.
Các vấn đề liên quan đến kỹ thuật
Môi trường làm việc là sản phẩm các dev đang tạo và văn hóa quản lý tạo bởi lead, môi trường làm việc tốt là công việc không luôn trong tình trạng chạy đua với deadline.
Tốn bao lâu để hoàn tất deploy?
Nếu tốn nhiều thời gian deploy, nghĩa là nó đang được làm thủ công, dễ phát sinh lỗi.
Thế nào được xem là một pull request lớn, số dòng code, số file
Nếu task được chia nhỏ sẽ dễ quản lý, ít bị conflict. Pull request nhỏ chứng tỏ merge code thường xuyên, công ty đang theo quy trình quản lý hiện đại. Branche lớn, kéo dài, cho thấy người senior thiếu kinh nghiệm chia công việc. Pull request lớn chỉ khi source code được phân tách rất rõ ràng, độc lập, pull request nhỏ cũng chứng tỏ code được tổ chức rất tốt.
Với cá nhân mình, một pull request được cho là lớn khi có khoảng 2000 dòng code, 20 file khác nhau.
Một câu trả lời mình cũng mong muốn nhận được là các team sẽ làm việc trên từng feature branch. Tổ chức gít theo từng feature giúp code dễ maintain hơn, mặc dù cái này không phải lúc nào cũng đúng, đôi khi feature branch cũng rối lắm.
Phải đụng đến bao nhiêu repository để update một tính năng nào đó?
Có những project chỉ bao gồm một repository, cả ngàn commit một ngày. Có dự án được tổ chức bởi cả chục cái repository quan hệ chằng chịt với nhau. Câu hỏi này giúp hiểu rõ hơn cấu trúc project và cách phân chia code.
Với những công ty trẻ, chỉ có một sản phẩm, có quá nhiều repository cũng không tốt. Công ty nhỏ nên tập trung và tiết kiệm thời gian tối đa, xây dựng sản phẩm đưa đến user, việc có nhiều repository khiến tiêu tốn thời gian để quản lý và deploy khá nhiều.
Mình cũng thường hỏi cách quản lý khi code bị duplicate và các thư viện của riêng công ty.
Việc phải thay đổi trên nhiều repository có thường xuyên không?
Nếu các module không được tách biệt tốt, việc thay đổi như thế rất hay xảy ra. Phải deploy cùng lúc nhiều service sẽ khó đoán được lỗi do đâu nếu có xảy ra. Cùng đồng nghĩa với việc service chưa được cấu trúc tốt.
Xử lý các tình huống khẩn cấp
Có hay xảy ra tình huống phải fix lỗi khẩn cấp? Thế nào được xem là tình huống khẩn cấp?
Thí dụ như user không thể truy cập vào website, thực hiện thanh toán không được sau khi nâng cấp tính năng mới.
Nếu những tình huống như vậy xảy ra thường xuyên, chứng tỏ việc thay đổi một phần dù chỉ nhỏ trong code cũng rất khó. Trong source code phụ thuộc lẫn nhau không biết trước được.
Quá trình xử lý lỗi phát sinh là như thế nào?
Với các công ty startup, thiếu các quy trình này là điều tốt, code chạy tốt quá đâu cần quy trình :D. Chưa có nhiều lỗi đến mức người ta phải nghĩ ra quy trình cho vấn đề này.
Với những công ty đã được thành lập lâu thì ngược lại, chắc chắn họ đã gặp nhiều lần vấn đề này, cần có quy trình rõ ràng để giải quyết để tránh lặp lại những lỗi như vậy
Giữa đêm em có bị nhận cuộc gọi lên để fix bug không?
Trong trường hợp nào bạn sẽ bị gọi lên sữa lỗi, yêu cầu OT, trong trường hợp OT thì có thêm tiền không
Thường trường hợp như vậy trong công ty có xảy ra nhiều không, có được request thêm ngày nghỉ phép không trừ lương trong trường hợp đó.
Thật lòng mà nói mình cũng không thích làm việc trong các công ty yêu cầu nhân viên làm việc ngoài giờ quá nhiều như vậy.
Con đường phát triển cho từng nhân viên
Nếu đã hoàn thành công việc được giao, thời gian rảnh thì mình có thể tự nghiên cứu, học tập không?
Là một Developer, sống trong môi trường công nghệ luôn phát triển không ngừng, chúng ta không ngừng học hỏi cho kịp với lớp trẻ. Các công ty luôn yêu cầu hoàn thành công việc sớm chừng nào tốt chừng ấy, và vẫn đảm bảo chất lượng, để đáp ứng được chuyện đó, developer phải có rất nhiều kiến thức, học hỏi không ngừng từ cộng đồng, áp dụng vào công việc đang làm, cho các dự án mới. Để trở thành dev chất không có cách nào khác là bạn phải dành thời gian nghiên cứu đều đặn.
Với câu hỏi này, người trả lời tốt nhất chính là các bạn dev đang làm trong công ty, chứ không phải cấp quản lý, vì những người quản lý sẽ luôn nói điều tốt về chính sách. Không phải công ty nào cũng có đồng quan điểm về việc học từ đâu, học như thế nào, học thời gian nào, sẽ có những công ty không cho phép nhân viên truy cập youtube, vốn là nguồn resource học lớn đối với mình, bên cạnh medium. Nếu nói thời gian nghiên cứu của nhân viên là việc nhân viên phải làm ở nhà, công ty chỉ trả tiền 8 tiếng cho bạn để làm việc trong công ty không phải để ngồi nghiên cứu là mình thấy không đồng ý.
Cách đánh giá một developer chất lượng, có sự phát triển trong công việc?
Một số công ty đánh giá developer chất bằng việc anh ta hoàn thành toàn bộ deadline, không gây nhiều issue. Một vài công ty có chương trình đào tạo cho nhân viên mới, giúp bạn đạt vị trí cao hơn, hoặc được nghía các dự án khác để học hỏi công nghệ. Nhưng cơ bản phải biết mình muốn gì trong tương lai, và làm ở công ty đó thì bạn có đạt được mục tiêu của mình ngày qua ngày không.
Công ty có những hoạt động chia sẻ kiến thức như là semi tổ chức rầm rộ không?
Chia sẻ kiến thức giữa các developer là một phần rất quan trọng. Nếu có các buổi workshop hàng tháng, hàng quý để đồng nghiệp senior chia sẻ và cùng nhau bàn luận thì tuyệt vời, nếu được trả lời “có, nhưng thật sự chưa đủ” thì quá đỉnh rồi.
Có được tham gia các hội thảo có tính phí không?
Các hội thảo chuyên môn, đặc biệt có tính phí tham gia rất tốt cho sự phát triển cá nhân, nếu công ty có chi trả cho nhân viên tham gia những hội thảo như vậy thì quá tuyệt. Nếu được tài trợ tham gia các hội thảo như vậy, bạn cũng nên share lại kiến thức có được với đồng nghiệp trong các buổi meeting nội bộ. Mỗi năm một lần là đủ với mình.
Phương pháp quản lý dự án và xét độ ưu tiên
Cách anh điều phối giữa việc đưa thêm tính năng mới và bảo trì những tính năng cũ
Theo nhiều kinh nghiệm được chia sẻ từ các nhà quản lý, 1/3 thời gian để bảo trì, ví dụ như refactor code, xóa code thừa, bổ sung unit test, tăng tốc độ, là mức hợp lý để cân bằng giữa bổ sung tính năng mới và bảo trì.
Hoặc hỏi thêm kinh nghiệm những gì cần làm trong để maintain
Quy trình phát triển một sản phẩm, tính năng mới, từ lúc lên ý tưởng đến lúc deploy là thế nào?
Câu hỏi này sẽ phải trả lời rất nhiều, từ lúc lập kế hoạch, trao đổi giữa các bộ phận, đến lúc implement, feedback, deploy. Nó đã gom đủ một vòng.
Task được kiểm tra như thế nào? Ai là người tạo ra mấy task này?
Mỗi công ty mỗi khác, tùy người quản lý.
Làm thế nào để xác định nên build một version?
Dựa trên tính năng đặt ra, khách hàng yêu cầu, thời gian cố định
Khi nào task được xem là complete?
Đúng yêu cầu của PR, QA bảo đóng sau khi test, bên kinh doanh đã thấy được sản phẩm deploy và không nhận thêm bất cứ phàn nàn nào?
Phần mềm đang sử dụng để quản lý task?
Nhiều phần mềm dạng này lắm: Pivotal, Asana, Wrike, JIRA, Trello, post-it + tấm bảng, thẻ được in ra, Visual Studio Online, Marvel.
Cá nhân tác giả bài viết cũng như mình đồng quan điểm: JIRA là thằng gớm nhất
Đã hết giờ hỏi!
Không có con người hoàn hảo, không có công ty hoàn hảo, bạn chấp nhận được những gì, những gì bạn sắp ưu tiên nó thấp hơn. Chúc các bạn tìm được công việc tốt. Mình đã có việc rồi, không muốn đi phỏng vấn nữa đâu các bạn.
Khi thế giới nhân sự có tính đổi mới, nhiều sự gián đoạn đã xảy ra trong quy trình phát triển nguồn nhân sự. Theo một khảo sátvề tương lai nhân sự toàn cầu của KPMG International, gần 3 trong số 5 (chiếm 57%) giám đốc nhân sự tin rằng nếu chức năng nhân sự không thể hiện rõ tính hiện đại hóa cách tiếp cận để hiểu và lập kế hoạch cho nhu cầu trọng yếu (tức sự phát triển) của lực lượng lao động trong tương lai, nó sẽ nhanh chóng trở nên lạc lối, xa rời định hướng chiến lược trong tổ chức hiện đại. Vì thế, việc tiếp cận, dự đoán những khả năng có thể xảy ra và lập kế hoạch giải quyết những gián đoạn là điều quan trọng.
Các tổ chức nhân sự thế giới đang nỗ lực tìm kiếm và xây dựng khung năng lực trên ba khả năng riêng biệt.
Theo quan điểm của chúng tôi, thông qua các khả năng này, HR có thể lập biểu đồ cho một khóa học đào tạo trong tương lai một cách bài bản nhằm giúp định hướng tốt hơn nguồn lực lao động trong tương lai trước những phát bất ngờ trong thời đại kỹ thuật số.
Trong nghiên cứu của mình, có tổng cộng ba khả năng bao gồm:
Định hình lực lượng lao động trong tương lai và xây dựng một nền văn hóa có mục đích
Ưu tiên phát triển chiến lược dựa trên trải nghiệm của nhân viên
Mã hóa dữ liệu thông qua hiểu biết về lực lượng lao động
1. Định hình lực lượng lao động và xây dựng một nền văn hóa DN có mục đích
Các tổ chức nhận ra rằng các cấu trúc lực lượng lao động hiện tại đang bị phá vỡ bởi các mô hình kinh doanh và công nghệ mới. Họ đang cố nắm bắt cơ hội để định hình lại lực lượng lao động và mong muốn đạt được những lợi ích tối đa khi trí thông minh của con người và khả năng hoạt động của máy móc được cộng hưởng.
Một khi ngành Nhân sự đang được vận hành và biến đổi theo xu hướng phát triển của kỹ thuật số, nhiều mô tả tương lai gần cho một định hướng phát triển nguồn nhân lực được tạo ra. Và thực tế cho thấy, định hướng đó bị chi phối bởi quá nhiều đặc tính của thời buổi công nghệ số như: hợp thức hóa quy trình hoạt động nhân sự, tiếp cận quá nhiều nguồn dữ liệu phức tạp,… Điều đó dễ khiến việc định hướng trở nên khó khăn vì chưa tập trung vào một mục tiêu nhất định.
Nghiên cứu cho thấy ¾ các tổ chức nhân sự Pathfinding đồng ý rằng HR cần chủ động tạo ra các thách thức cho thành phần lực lượng lao động để đáp ứng nhu cầu phát triển của tổ chức trong tương lai. Đồng thời, họ cũng đang dành sự ưu tiên cho việc nâng cao lực lượng lao động để quản trị những ảnh hưởng của AI – trí tuệ nhân tạo với đối tượng này.
Ngoài việc định hình lực lượng lao động trong tương lai, các tổ chức nhân sự của Pathfinding hiểu rằng HR đóng một vai trò quan trọng trong việc định hình và duy trì văn hóa phù hợp với chiến lược kinh doanh của họ. Cụ thể, những số liệu thực từ nghiên cứu cho thấy, những người hoàn toàn đồng ý việc một chiến lược phù hợp có ý nghĩa trong vấn đề duy trì văn hóa cho tổ chức của họ thì cao gấp 6 lần so với số lượng người không đồng ý.
2. Ưu tiên phát triển chiến lược dựa trên trải nghiệm của nhân viên
Đã có một cuộc khảo sát diễn ra với những nguồn dữ liệu được thu thập và phân tích dựa trên mối quan hệ giữa các tổ chức nhân sự và nhân viên.
Có đến 95% nhân sự viên chia sẻ rằng họ đang ưu tiên cho những trải nghiệm cá nhân của mình như một lĩnh vực trong tâm bên cạnh chuyên môn về nhân sự. Nhiều tổ chức nhân sự của Pathfinding cũng đồng quan điểm rằng kinh nghiệm của các nhân viên trong tổ chức là sự lựa chọn hàng đầu để họ tập trung phát triển chiến lược.
Quan tâm đến những trải nghiệm của nhân viên là một kỹ năng cần thiết hàng đầu mà nhà quản trị nhân sự cần có. Đây là một biểu hiện của cách tiếp cận mới, nói lên rằng những lãnh đạo cấp cao đã thật sự chú trọng đến sự phát triển chung của tổ chức trong tương lai. Đi từ sự thấu hiểu nhân viên cũng chính là cách tìm ra sự gián đoạn làm cản trở quá trình hoàn thiện định hướng chiến lược nhân sự lâu dài.
3. Thấu hiểu dữ liệu về lực lượng lao động
Các tổ chức nhân sự Pathfinding tin rằng sức mạnh của khoa học dữ liệu có thể tạo những hiểu biết và biểu diễn thành những hành động cụ thể. Tất nhiên những hành động ấy đều mang lại giá trị cho toàn bộ tổ chức. Vì thế, khi các nhà quản trị nhân sự đã hiểu biết rõ về lực lượng lao động có thể dễ dàng mã hóa nguồn dữ liệu để đề ra các giải pháp nhân sự hiệu quả.
Ví dụ đơn giản, khi đủ sự hiểu biết về nhân sự của mình, các nhà lãnh đạo có thể yên tâm áp dụng những cách thức tiếp cận mới. Đầu tư vào công nghệ số, trí tuệ nhân tạo,… những sản phẩm khoa học sáng tạo sẽ giúp nhà lãnh đạo phân tích, mã hóa các dữ liệu, cho ra những số liệu chuẩn và từ đó, đưa ra những quyết định chính xác hơn. Sự đầu tư nào cũng cần dựa trên một nền tảng vững chắc và ở đây sự hiểu biết về lực lượng lao động (sự thấu hiểu về những nhân viên) chính là nền tảng đó.
Lời kết:
Nếu xem xét trong một cách khoa học, chúng ta sẽ thấy một logic liên kết và củng cố lẫn nhau để xây dựng khả năng trong cả 3 khả năng riêng biệt. Năm 2020 được xem thời điểm mà ngành nhân sự đang có những bước tiến đột phá, đổi mới toàn diện vì thế đòi hỏi HR phải có lối tư duy hiện đại đồng thời hiểu rõ chức năng của nhân sự.
Hãy nhớ rằng, điều tạo ra sức mạnh của thế hệ nhân sự tiếp theo không phải là theo đuổi các khả năng rời rạc, mà là tạo ra một cách tiếp cận toàn diện, đổi mới và củng cố lẫn nhau để thiết lập một hệ thống hoàn chỉnh; xây dựng và phát triển nguồn lực lao động cho tổ chức trong tương lai.
Năm 2016 Google giới thiệu Firebase. Khi bắt đầu phát triển ứng dụng điện thoại, bạn sẽ cần đến server và một developer để làm việc với server
Firebase cung cấp những tính năng chúng ta cần ở server, thêm vào đó là realtime database, storage, hosting, authentications, analytics, notifications, crash report,…
Firebase Analytics
Firebase Analytics cho phép bạn analyse các thao tác của user trên app, miễn phí cho 500 sự kiện khác nhau.
Với kết quả analyse này chúng ta có thể biết được người dùng cần gì, sử dụng app ra sau, chúng ta nên nâng cấp những tính năng nào
Realtime Database
Firebase cung cấp NoSQL realtime cloud database. Lưu trữ dữ liệu ở dạng JSON và cho phép đồng bộ với client
Khi kết nối Realtime Database với Android, iOS, Javascript SDK, một realtime database sẽ được tạo ra và dùng chung cho tất cả user. Tất cả client sẽ nhận được update khi có sự thay đổi của dữ liệu
Authentication
Sử dụng Firebase Authentication user sẽ xác thực tài khoản bằng nhiều cách, email, Facebook, Twitter, Google hay Github.
Firebase Authentication cho phép tạo một user mới lưu xác thực của user xuống Firebase Database, không còn cực khổ đi config ở phía server
Thậm chí chúng ta còn có thể gởi confirm email sau khi đăng ký và forget password.
Crash Reporting
Một tính năng hữu ích cho mội developer, với Firebase Crash Reporting chúng ta sẽ có tất tần tật log từ thông tin OS đến chi tiết lỗi nếu xảy ra
Cloud Messaging
Với Firebase Cloud Messaging(FCM) chúng ta có thể tương tác với user theo một khoảng thời gian chỉ định, notify user những thay đổi đã xảy ra.
Sử dụng FCM để chạy quảng cáo, khuyến mãi, miễn là nó dưới 4KB
Remote Config
Remote config theo các developer là tính năng xịn nhất của Firebase, cho phép thực hiện những thay đổi mà không cần chạy lại build. User sẽ có được những thay đổi đổi mới nhất mà không cần update lại app.
App Indexing
Nếu google tìm thấy bất kỳ từ khóa tìm kiếm nào khớp với app của chúng ta và nếu app được cài rồi, user sẽ ngay lập tức thấy kết quả có app của chúng ta.
Invites
Nếu app có nội dung tốt, được nhiều người thích thú, user có thể share nó với người khác sử dụng Firebase Invites.
AdMob
Sau tất cả cố gắng để build app, chúng ta cần đến AdMob để kiếm chút đỉnh từ quảng cáo.
Khi bắt đầu có định hướng và bước chân vào con đường hoạt động nhân sự, chắc hẳn bạn sẽ gặp phải nhiều khái niệm/ thuật ngữ mới và học làm quen với chúng. Đôi khi bạn lại tự hỏi “Case study” hay “OT” là gì? Đừng lo lắng vì với bài viết sau đây, TopDev sẽ giúp bạn nắm trong tay 20 thuật ngữ chuyên sâu về ngành Nhân sự.
1. Administrator carde/High rank cadre – Cán bộ quản trị cấp cao:
Người tham gia hoạch định chiến lược nhằm phát triển đào tạo và lãnh đạo nhân viên. Đồng thời, trực tiếp tham gia vào quá trình đánh giá và chịu trách nhiệm cuối cùng trước kết quả của một tổ chức/doanh nghiệp. Cán bộ quản trị cấp cao là một trong những nhân sự nòng cốt trong hệ thống quản trị cấp cao.
2. Assessment of employee potential – Đánh giá tiềm năng nhân viên:
Thuật ngữ mô tả việc nhìn nhận và đánh giá năng lực tiềm ẩn của nhân viên từ những đóng góp ban đầu và khả năng phát triển lâu dài của họ. Việc đánh giá được theo dõi và quan sát bởi chính những người có mắt nhìn chuyên môn. Đánh giá tiềm năng giúp các lãnh đạo nhân sự/nhà quản lý có thể nắm bắt được năng lực và đó là cơ sở để thiết lập lộ trình phù hợp cho từng nhân viên.
3. Board interview/Panel interview – Phỏng vấn hội đồng:
Được hiểu là một hình thức tuyển dụng giúp các doanh nghiệp khai thác nhiều khía cạnh của một ứng viên. Việc phỏng vấn hội đồng cho thấy mức độ quan trọng của vị trí mà ứng viên mong muốn ứng tuyển. Phỏng vấn hội đồng không quá tập trung hay lặp lại những câu hỏi có logic nhằm nắm bắt thông tin cơ bản mà chủ yếu xoáy sâu vào những câu hỏi liên hệ thực tế thông qua những việc đề xuất các sáng kiến, giải pháp, cách thức vận hành công việc,…
4. Career planning and development – Kế hoạch và phát triển nghề nghiệp (Thăng tiến nghề nghiệp):
Đây là thuật ngữ mô tả kết quả diễn tiến của quá trình đánh giá tiềm năng. Kế hoạch thăng tiến nghề nghiệp được xây dựng dựa trên các chỉ tiêu về năng lực, khả năng thích ứng, tiềm năng phát triển,… Đó là một lộ trình phù hợp có ý nghĩa trong việc định hướng nhân viên trên con đường phát triển sự nghiệp. Và tất nhiên, kế hoạch thăng tiến được phân chia theo từng giai đoạn khác nhau và được theo dõi, xem xét cũng như thay đổi nếu có những phát sinh.
5. Case study – Nghiên cứu tình huống:
Nghiên cứu tình huống là nhiệm vụ mà mỗi nhân viên cần phân tích nhằm tìm ra nguồn thông tin, dữ liệu. Đồng thời, qua việc nghiên cứu tình huống, nhân viên có thể đánh giá được khả năng phát triển của một dự án và xác định được những điểm tích cực cũng như hạn chế cần phải khắc phục.
6. Contractual employee – Nhân viên hợp đồng:
Người làm việc theo hợp đồng lao động. Hợp đồng được xây dựng dựa trên các căn cứ giấy tờ có giá trị pháp lý được thể hiện dưới hình thức là một bản mẫu. Nhà tuyển dụng thường có quyền quy định cách thức tổ chức, thực hiện công việc và những mô tả cụ thể về hợp đồng lao động gắn với các căn cứ thực tế và căn cứ có thẩm quyền (thuộc căn cứ pháp lý).
7. Disciplinary action – Thi hành kỷ luật:
Thuật ngữ mô tả quá trình các nhân viên tuân thủ, chấp hành đúng các quy định chung của nội bộ tổ chức/doanh nghiệp đề ra. Nếu có sự sai phạm về các hành vi liên quan đến vấn đề kỷ luật, các hình thức xử lý sẽ được áp dụng tùy vào mức độ sai phạm của từng nhân viên. Có thể là nhắc nhở, viết báo cáo kiểm điểm, đánh giá tác phong, khiển trách, đình chỉ hoặc sa thải.
8. Entrepreneurial – Năng động, sáng tạo:
Đây là thuật ngữ dùng để chỉ tính cách của người làm trong lĩnh vực Nhân sự. Thuật ngữ chỉ cá nhân hoặc một tập thể luôn cố gắng tìm tòi, học hỏi những cái mới, luôn cập nhật và thích ứng nhanh với sự thay đổi chung trong mô hình phát triển nhân sự; có những ý tưởng, đóng góp hay cho tổ chức/doanh nghiệp.
9. Going rate/wage/Prevailing rate – Mức lương hiện hành trong xã hội:
Hiểu đơn giản là mức lương cơ bản phù hợp với các chỉ số tiền tệ ứng với tình hình phát triển chung trong xã hội tại một thời điểm nào đó. Tất nhiên, mức lương hiện hành sẽ thay đổi và các công ty cần có sự cập nhật và phân bổ hợp lý. Song, vẫn phải đảm bảo được tính ổn định về cơ chế vận hành lương bổng theo từng quy mô hoạt động của tổ chức.
Phần lương bổng không chỉ ghi nhận những thành quả, nỗ lực của nhân viên mà còn tạo ra giá trị nhằm gia tăng động lực, khích lệ và thúc đẩy tinh thần làm việc của nhân viên. Đây cũng được xem là một trong những cách thức hiệu quả để tăng năng suất lao động cho tổ chức/doanh nghiệp.
11. Insurance plans – Kế hoạch bảo hiểm:
Kế hoạch được thiết lập để tạo ra những chế độ đãi ngộ về sức khỏe cho nhân viên trong tổ chức/doanh nghiệp. Một kế hoạch bảo hiểm được đảm bảo là một kế hoạch với những công việc chi tiết.
12. Job specification – Bảng mô tả tiêu chuẩn chi tiết công việc:
Một bảng liệt kê các tiêu chuẩn cụ thể, được phân chia và sắp xếp theo trình tự khoa học nhằm mục đích mô tả các nhiệm vụ, công việc cần thực hiện.
13. Manpower replacement chart – Sơ đồ sắp xếp lại nhu cầu nhân lực:
Sơ đồ được thống kê theo hệ thống nhằm mục đích sắp xếp và phân bổ nguồn lực nhân sự sao cho hợp lý. Căn cứ vào sơ đồ sắp xếp, người quản lý cho thể dễ dàng cập nhật những thay đổi nếu có những phát sinh bất ngờ,
14. Overtime (OT) – Giờ phụ trội (làm thêm giờ):
Thuật ngữ mô tả việc một nhân viên làm quá giờ, ngoài giờ làm việc chính thức (hay có thể gọi là tăng ca). Ngoài ra, thuật ngữ OT còn được sử dụng để chỉ người làm được trả lương cho việc làm ngoài thời gian hợp đồng chính thức.
15. Performance appraisal – Đánh giá thành tích công tác/ khả năng hoàn thành công việc:
Thuật ngữ được sử dụng để mô ta việc nhân viên tự đánh giá lại các thành tích cá nhân và diễn giải nó thông qua các báo cáo, thuyết trình về các dữ liệu minh chứng hoặc việc nhà quản lý trực tiếp đánh giá các nhân viên thông qua kết quả, những đóng góp họ mang lại cho tổ chức.
16. Performance management – Quản lý hiệu quả công việc:
Đây là quy trình được thiết kế nhằm mục đích đánh giá, quản lý và cải thiện năng lực của nhân viên. Quá trình “quản lý hiệu quả công việc” hay cách gọi khác là “quản lý năng lực” là cho phép đưa ra những đánh giá chi tiết. Đó có thể là những cảnh báo về việc một nhân viên kém năng lực hay phân tích và khen thưởng nhằm tạo động lực cho những cá nhân nổi bật. Quản lý hiệu quả công việc cần có sự giám sát, theo dõi chặt chẽ và lâu dài của cấp quản lý nhân sự.
17. Probation – Thời gian thử việc:
Khoảng thời gian được thiết lập thành một lộ trình ngắn hạn (1 đến 3 tháng hoặc 3 đến 6 tháng tùy vào mô hình hoạt động của chủ tổ chức/doanh nghiệp). Thời gian thử việc được thiết kế với các mục tiêu cụ thể nhằm tạo cơ hội cho ứng viên bộc lộ được những kỹ năng, năng lực của nhân viên. Và dựa theo các tiêu chí đánh giá đi kèm, người lao động sẽ được xem xét về mức độ phù hợp với công việc, có đáp ứng nhu cầu của tổ chức hay không.
18. Principle “Equal pay, equal work” – Nguyên tắc công bằng lương bổng (theo năng lực):
Nhiều tổ chức/doanh nghiệp có chế độ lương khác nhau cho từng nhân viên tùy thuộc vào vị trí, năng lực và sự thể hiện lâu dài của họ theo quá trình. Vì thế, nguyên tắc này giúp đảm bảo tính công bằng và minh bạch trong vấn đề lương bổng (theo năng lực).
19. Retrenchment – Giảm biên chế:
Là sự chấm dứt hợp đồng lao động do sự dư thừa trong cơ chế quản lý, hoạt động của tổ chức/doanh nghiệp. Mức độ giảm biên chế có sự thay đổi khác nhau tùy thuộc vào quy mô hoạt động và các yếu tố xã hội tác động đến.
20. Salary advances – Lương tạm ứng:
Lương tạm ứng là lương được thụ hưởng theo hợp đồng lao động của tháng trước liền kề trước khi người lao động tạm thời nghỉ việc. Cơ chế quy đổi của lương tạm ứng được tính tương ứng với các hình thức trả lương theo tháng, theo tuần, theo ngày hoặc theo giờ.
Trên đây là 20 thuật ngữ chuyên sâu cho Nhân sự nội bộ mà các bạn có thể gặp khi tiếp xúc với ngành quản lý nhân sự. Hy vọng sẽ giúp các bạn có nhiều thông tin bổ ích hơn trong quá trình tìm hiểu về định hướng nghề nghiệp của mình.
Kambria Code Challenge là chuỗi cuộc thi và hackathon trực tuyến về lĩnh vực Trí tuệ nhân tạo được thiết kế để thu hút sự tham gia của các lập trình viên khắp nơi trên thế giới, kết nối họ trở thành một phần của cộng đồng các lập trình viên tại Kambria. Đây cũng là cơ hội để các bạn kiểm tra kiến thức về thuật toán AI, chứng minh các kỹ năng về lập trình của bạn, đồng thời nhận phần thưởng và phát triển cơ hội nghề nghiệp với các công ty công nghệ là đối tác của Kambria.
Kambria Code Challenge có tổng cộng 4 Quiz, trong đó Quiz 04 có giải thưởng lớn nhất. Mỗi Quiz sẽ xoay quanh từng chủ đề về AI, bao gồm:
🔹 Quiz 1: Multilayer Neural Network
🔹 Quiz 2: Convolutional Neural Network
🔹 Quiz 3: Recurrent Neural Network
🔹 Quiz 4: AI Projects
Riêng với Quiz 04, bạn phải tham dự ít nhất 2 Quiz bất kỳ trước đó để đủ điều kiện tham gia. Kambria Code Challenge hiện tại đang diễn ra Quiz 03. Bạn click vào link sau để tìm hiểu thêm thông tin! Hoặc đăng ký tham dự Quiz 03 theo hướng dẫn sau:
3️⃣ Sau khi click, bạn sẽ thấy 1 form đăng ký. Chỉ cần điền đầy đủ các thông tin cá nhân để tham gia cuộc thi.
4️⃣ Kambria sẽ gửi email tới các bạn để xác nhận việc đăng ký!
5️⃣ Quiz 03 sẽ diễn ra vào lúc 14h00 – 14h45 thứ 7, ngày 02/05/2020. Bạn có 30 phút để hoàn thành bài Quiz và nộp bài muộn nhất vào lúc 14h45.
Thử giải đề thi cũ, chuẩn bị cho Quiz 03!
Để có sự chuẩn bị tốt nhất cho Quiz 03, các bạn có thể luyện tập giải các đề thi về AI đã diễn ra trong các Quiz cũ của Kambria. Các vòng thi Quiz có những dạng đề bài tương tự nhau, nên việc luyện tập các vòng thi trước sẽ giúp bạn làm quen và nâng cao điểm số khi tham gia dự thi.
Bạn có thể luyện tập Quiz 01 và Quiz 02 ngay khi click vào các đường link dưới đây. Ngoài ra, bạn cũng có thể xem lại bài giải của các Quiz sau khi hoàn thành xong.
Git và GitHub — hai công cụ mà dân dev ai cũng nghe tên, thậm chí còn sử dụng hàng ngày. Thế nhưng, bạn có biết thế nào là một GitHub đủ “đẹp” để đưa vào CV? Hay làm thế nào để tối đa hoá hiệu suất công việc trên hai công cụ này?
Như đã hứa ở blog LinkedIn — vũ khí bí mật khi tìm việc online, hãy cùng đọc bài viết nóng hổi từ một chàng kỹ sư lập trình nhà Got It— người chuyên review GitHub cho các bạn ứng viên nhé!
1. Git
Khi viết code, sẽ có rất nhiều lúc bạn muốn, hoặc cần phải quay lại đoạn code mình đã viết tại một thời điểm trước đây. Một cách đơn giản, ta hoàn toàn có thể dùng tính năng undo/redo của trình biên soạn (editor) mình đang dùng. Tuy nhiên, editor có thể sẽ không lưu lại lịch sử sau khi đóng, và bạn cũng có thể nhấn nhầm sang một phím khác thay vì nhấn redo, và thế là lịch sử trạng thái được editor lưu lại đã bị ghi đè khiến bạn không thể redo được nữa.
Ngoài ra, khi nhiều người cùng làm việc trong một dự án, các thành viên cần tìm ra cách chia sẻ các thay đổi của mình để đảm bảo rằng tất cả mọi người đang làm việc trên cùng một phiên bản của dự án. Trước đây, lập trình viên thường chia sẻ các thay đổi code bằng cách xuất ra file patch và gửi cho nhau qua email. Khi nhận được một bản patch, các thành viên sẽ áp dụng nó vào trong phiên bản code hiện tại của mình trên máy cá nhân.
From 06f2790b5ca3fea45515e33c9660ad6265120a5a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=C5=81ukasz=20Langa?= <lukasz@langa.pl>
Date: Wed, 4 Mar 2020 23:16:55 +0100
Subject: [PATCH] Rename FileMode into just Mode The mode was never just about files to begin with.There are no other modes in
Black, this can be the default one.
--- black.py | 40 +++++++++++++++++++---------------------
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/black.py b/black.py
index 52096819..31859d1a 100644
--- a/black.py
+++ b/black.py
@@ -186,7 +186,7 @@ class Feature(Enum):
@dataclass-class
FileMode:
+class Mode:
target_versions: Set[TargetVersion] = field(default_factory=set)
line_length: int = DEFAULT_LINE_LENGTH
string_normalization: bool = True
@@ -209,6 +209,10 @@ def get_cache_key(self) -> str:
return ".".join(parts)
+# Legacy name, left for integrations.
+FileMode = Mode
+
+
def supports_feature(target_versions: Set[TargetVersion], feature: Feature) -> bool:
return all(feature in VERSION_TO_FEATURES[version] for version in target_versions)
Mỗi file patch chỉ biết đến hai trạng thái của dự án, là trước và sau khi được trích xuất ra. Như vậy, khi có nhiều file patch, ta cần phải biết thứ tự của chúng để có thể xây dựng lại chính xác một phiên bản của dự án tại bất kì thời điểm nào. Ngoài ra, vì file patch cũng chỉ là file thông thường được lưu trong ổ cứng, nên ta cần một cách để sao lưu lại chúng. Khi có nhiều người cùng làm việc trên một file, ta cần thêm một cơ chế đồng bộ các file patch với nhau, vì rất có thể sẽ có những thay đổi chồng chéo lên nhau.
Để giải quyết các vấn đề nêu trên, ta cần đến một hệ thống quản lý phiên bản. Phần một của bài viết này sẽ giới thiệu đến các bạn Git, một trong những hệ thống quản lý phiên bản phổ biến nhất hiện nay.
1.1.Git là gì?
Nguồn: https://xkcd.com/1597/
Git (https://git-scm.com/) là một hệ thống quản lý phiên bản phân tán (distributed version control system), được viết bởi Linus Torvalds (người tạo ra và phát triển chính của Linux kernel) vào năm 2005. Mục đích ban đầu của Git là để hỗ trợ việc phát triển Linux kernel. Ngoài Git còn có các hệ thống khác như Subversion và Mercurial. Các bạn có thể tham khảo bài viết sau về mức độ phổ biến của các hệ thống quản lý phiên bản vào năm 2016: https://rhodecode.com/insights/version-control-systems-2016; hoặc dữ liệu từ Google Trends: https://trends.google.com/trends/explore?date=all&q=git,svn,mercurial.
Để hiểu rõ hơn về Git, ta sẽ tìm hiểu về từng khía cạnh trong tên gọi hệ thống quản lý phiên bản phân tán.
Hệ thống quản lý phiên bản (version control system, VCS)
Nguồn: reddit
Trong cuốn sách kinh điển The Pragmatic Programmer [1], hai tác giả David Thomas và Andrew Hunt đã dành hẳn một phần (Topic 19) để nói về việc quản lý phiên bản. Còn trong một quyển sách khác nổi tiếng không kém [2], tác giả Robert C. Martin cũng đề cập đến việc sử dụng một hệ thống quản lý phiên bản ở ngay đầu phần phụ lục Tooling, và ông khuyên dùng Git để quản lý code.
Git hỗ trợ các lập trình viên bằng cách lưu lại toàn bộ các thay đổi với dự án, được chia nhỏ thành các commit. Mỗi commit là một đơn vị thay đổi, tương tự như một file patch. Tại mỗi commit, ta có một phiên bản của dự án. Bằng việc lưu lại toàn bộ thay đổi trong một hệ thống riêng biệt, ta hoàn toàn có thể quay lại bất cứ phiên bản nào tại thời điểm mà commit được tạo ra. Ngoài ra, Git cũng hỗ trợ làm việc nhóm thông qua tính phân tán.
Tính phân tán (distributed)
Khi làm việc với một dự án, ta sẽ tạo ra một Git repository (kho chứa), thường được gọi tắt là repo. Đây là nơi chứa toàn bộ các thông tin cần thiết để quản lý dự án, ví dụ như các thay đổi đã được nhắc đến ở trên.
Khi làm việc với một dự án được quản lý bởi Git, mỗi lập trình viên sẽ có một bản sao của Git repo trên máy cá nhân, và được đồng bộ với nhau thông qua một repo được lưu trữ trên máy chủ riêng biệt (remote repository). Thay vì chia sẻ các bản patch, lập trình viên sẽ tạo ra các commit, và gửi các commit này lên remote repository. Các lập trình viên khác có thể đồng bộ repo trên máy cá nhân với remote repo để thấy được các commit này, và thêm vào phiên bản của dự án hiện tại trên máy của mình nếu muốn.
1.2. Sử dụng Git như thế nào?
Khi bắt đầu sử dụng Git cho một dự án, ta cần khởi tạo một Git repository trên máy cá nhân, bắt đầu với câu lệnh git init. Sau khi được khởi tạo, mọi thay đổi sẽ được Git theo dõi và quản lý. Trong trường hợp bắt đầu làm việc với một dự án đã và đang sử dụng Git, và đã có một remote repository, ta có thể tạo ra một bản sao trên máy cá nhân bằng câu lệnh git clone.
Sau khi thiết lập môi trường làm việc, ta có thể bắt đầu thao tác với Git như sơ đồ bên dưới. Local repository chính là bản sao của Git repo trên máy cá nhân, được đồng bộ với những local repo khác thông qua remote repo. Cũng trên máy cá nhân, ta còn có hai môi trường nữa là thư mục làm việc (working directory) và khu vực chờ (staging area).
Nguồn: https://www.edureka.co/blog/git-tutorial/
Tất cả các thao tác thêm/sửa/xoá để thay đổi code sẽ được thực hiện trên thư mục làm việc. Khi muốn lưu lại những thay đổi này, ta sẽ dùng câu lệnh git add để thêm chúng từ thư mục làm việc sang khu vực chờ. Sau đó sử dụng câu lệnh git commit để lưu từ khu vực chờ vào local repository.
Khu vực chờ là nơi để chuẩn bị cho những thay đổi trước khi chúng được commit. Ví dụ như ta thay đổi ba file: a.py, b.py, và c.py. Tuy nhiên thay đổi ở file c.py tương đối độc lập với hai file còn lại nên ta muốn tách ra một commit riêng. Để làm được việc đó, đầu tiên ta thêm file a và b vào khu vực chờ và commit trước:
> git add a.py
> git add b.py
> git commit -m "Thay doi file a va b"
Sau đó mới thêm file c vào khu vực chờ và commit:
> git add c.py
> git commit -m "Thay doi file c"
Thao tác với Git sử dụng Fork: duyệt lại thay đổi ở khu vực chờ trước khi commit
Tuy nhiên lúc này, những thay đổi mới chỉ đang ở local repository, tức là những lập trình viên khác không biết đến sự tồn tại của chúng. Để đưa những thay đổi này lên remote repository, ta dùng lệnh git push. Và ngược lại, dùng lệnh git pull để cập nhật những thay đổi mới nhất của người khác từ remote repository về máy cá nhân.
Một tính năng rất quan trọng khi làm việc nhóm với Git là tách nhánh (branching). Tất cả Git repository đều có một nhánh mặc định là master, nơi các commit sẽ được lưu lại ở thời điểm ban đầu. Khả năng tách nhánh của Git giúp cho các thành viên của dự án có thể làm việc độc lập vì nếu mỗi người có một nhánh riêng, các thay đổi khi được push lên remote repository sẽ không gây ra xung đột. Ta có thể kiểm tra xem nhánh hiện tại đang làm việc là gì với câu lệnh git branch, và tạo một nhánh mới với câu lệnh git checkout.
Thao tác với Git sử dụng Fork: lịch sử commit và các nhánh
Sau khi đã tạo ra một nhánh mới, ta có thể bắt đầu commit những thay đổi lên nhánh này. Khi hoàn thành phần việc của mình trên nhánh cá nhân, ta cần tích hợp các thành phần lại với nhau thông qua việc hợp nhất các nhánh với câu lệnh git merge. Các thay đổi sau khi đã được hợp nhất lại sẽ được các thành viên pull về local repository của mình. Trong hình minh hoạ bên trên, ta có thể thấy các merge commit như Merge branch ‘release/v1.1.0’ into develop, hoặc Merge branch ‘release/v1.1.0‘.
1.3. Các nguyên tắc khi làm việc với Git
Có một số nguyên tắc nhất định giúp cải thiện hiệu suất và nâng cao khả năng làm việc nhóm khi sử dụng Git để quản lý phiên bản cho dự án.
Tách nhánh mới để làm việc. Như đã nói ở trên, việc tách nhánh mới giúp các thành viên có thể làm việc độc lập với nhau. Ngoài ra, bằng cách làm việc trên một nhánh riêng biệt, ta có thể đảm bảo rằng code trên nhánh mặc định (master) luôn là code ổn định và có thể được đưa lên môi trường production.
Viết commit message rõ ràng, dễ hiểu. Mỗi commit đều có một message, là nơi để lập trình viên tóm tắt những thay đổi được lưu lại trong commit này. Commit message rõ ràng và tường minh giúp cho các thành viên khác có thể dễ hình dung về những thay đổi hơn khi nhìn vào git log hoặc git tree. Conventional Commits là một quy ước viết commit message thường được dùng.
Nguồn: https://xkcd.com/1296/
Mỗi commit chỉ nên có một trách nhiệm duy nhất. Nguyên tắc Single Responsibility (S trong SOLID) là một nguyên tắc cơ bản trong thiết kế phần mềm. Tạo Git commit là một trong nhiều tính huống khác ta có thể áp dụng nguyên tắc này. Mỗi commit chỉ nên lưu lại những thay đổi nhỏ, có liên quan trực tiếp đến nhau. Thay vì tạo ra một commit với rất nhiều thay đổi (hàng trăm dòng code và hàng chục file được thay đổi), ta nên chia ra thành nhiều commit nhỏ. Điều này giúp dễ quan sát các thay đổi, và việc quay lại một trạng thái trước đây cũng dễ dàng hơn vì lịch sử đã được chia nhỏ.
Tránh commit những thay đổi không cần thiết, hoặc không nên được lưu lại. Giả sử rằng trong dự án của bạn cần lưu lại những cấu hình cho việc kết nối vào cơ sở dữ liệu, hoặc là khoá bí mật dùng trong việc mã hoá thông tin… Những thông tin này tuyệt đối không được lưu lại với Git, vì một khi bạn đưa những thông tin này lên một remote repository công khai, bất cứ ai cũng có thể xem được và truy cập vào cơ sở dữ liệu của bạn… Ngoài ra, còn những thông tin khác như các thành phần phụ thuộc của dự án cũng không nên được lưu lại, ví dụ như npm_modules khi làm việc với JavaScript, hoặc venv khi làm việc với Python.
1.4. Các tính năng khác của Git
hooks. Hooks là một tính năng rất mạnh mẽ của Git. Với tính năng này, ta có thể thêm các hành động tuỳ chỉnh vào từng giai đoạn làm việc với Git, ví dụ như trước và sau khi commit/push… Thường dùng nhất là pre-commit hook, được chạy trước mỗi commit. Thậm chí còn có một framework chuyên để quản lý chúng. Pre-commit hooks thường được sử dụng để format code theo một chuẩn chung (black/prettier), chạy các chương trình phân tích tĩnh (static analysis) như mypy, eslint… để giảm thiểu lỗi.
annotate/blame. Khi sử dụng câu lệnh này, với mỗi dòng trong một file, ta có thể biết được người gần nhất sửa dòng này là ai, và sửa vào lúc nào. Các kỹ sư ở Got It rất hay dùng để blame nhau, đúng như tên gọi của câu lệnh, ví dụ như: Chỗ này chú J, chú K viết khó đọc thế, chỗ này ai viết mà tinh tế thế, hoá ra là anh M.
Nguồn: reddit
cherry pick. Khi dùng câu lệnh git merge để hợp nhất hai nhánh lại làm một, ta sẽ mang tất cả commit của nhánh tính năng vào nhánh chính. Tuy nhiên, không phải lúc nào ta cũng muốn làm vậy, chẳng hạn như khi cần deploy và test trước một số thay đổi chọn lọc từ nhánh tính năng. Đây là lúc ta sử dụng đến câu lệnh cherry-pick để copy thay đổi từ những commit cần thiết sang một nhánh khác. Đơn vị nhỏ nhất có thể cherry pick là một commit, nên nếu commit quá lớn thì ta sẽ không thể chọn ra những thay đổi cần thiết.
Ngoài các tính năng kể trên, bạn đọc có thể tham khảo thêm các tính năng khác như submodule, stash, rebase, status, diff…
1.5. Tìm hiểu thêm vềGit
Trên đây chỉ là những hướng dẫn rất cơ bản về Git. Bạn đọc muốn tìm hiểu sâu hơn có thể tham khảo tại những liên kết sau:
Dựa vào tên gọi thì các bạn cũng có thể đoán được rằng Git và GitHub có liên quan đến nhau. Trong phần giới thiệu về Git bên trên, ta biết rằng các thành viên của một dự án đồng bộ code với nhau thông qua một remote repository được lưu trữ trên máy chủ riêng biệt. GitHub là một công ty cung cấp dịch vụ lưu trữ các dự án được kiểm soát phiên bản bởi Git, có trang chủ tại địa chỉ https://github.com/. Tất cả các dự án của Got It được kiểm soát phiên bản bởi Git và lưu trữ trên GitHub.
Ngoài mục đích chính là nơi để lưu trữ các dự án sử dụng Git, GitHub là một nơi có thể giúp các lập trình viên cải thiện kĩ năng của bản thân. Hiện nay, GitHub là một trong những dịch vụ phổ biến nhất để lưu trữ các dự án mã nguồn mở. Các lập trình viên khác có thể tham gia đóng góp vào các dự án này thông qua việc sử dụng Git và GitHub. Nếu như bạn chưa đủ khả năng để đóng góp vào dự án mà bạn muốn tham gia, thì bạn cũng có thể học hỏi kinh nghiệm từ các lập trình viên khác bằng cách theo dõi các đóng góp của họ. Ngoài việc theo dõi các dự án mà bạn đã biết, bạn cũng có thể khám phá các dự án mới đang được nhiều người chú ý đến thông qua các tính năng Explore và Trending. GitHub cũng rất thân thiện với người dùng mới bằng việc có những hướng dẫn rất rõ ràng và trực quan tại https://guides.github.com/.
2.2. GitHub và tuyển dụng
Không chỉ dừng lại ở việc cải thiện kĩ năng cá nhân, sử dụng GitHub hợp lý cũng là một cách để các lập trình viên có thể gây ấn tượng với nhà tuyển dụng. Sau khi tạo tài khoản GitHub, bạn có thể lưu trữ các dự án cá nhân của mình. Thông qua đó, nhà tuyển dụng sẽ có một hình dung rõ ràng hơn về khả năng của bạn, thay vì chỉ dựa vào những gì được viết trong CV.
Lịch sử hoạt động trên GitHub thể hiện nhiều điều về lập trình viên đó, ví dụ như các công nghệ đã sử dụng, khả năng cộng tác với các lập trình viên khác, khả năng quản lý dự án… Tại Got It, các ứng viên có tài khoản GitHub (hoặc các dịch vụ tương tự) “đẹp” sẽ được đánh giá cao trong bước CV Review (các bạn có thể tìm hiểu kĩ hơn về quy trình tuyển dụng của Got It tại đây. Có thể nói, Github của một lập trình viên cũng giống như portfolio của một designer.
Câu hỏi được đặt ra là: Làm thế nào để có một tài khoản GitHub “đẹp”? Vì GitHub là nơi để lưu trữ các dự án sử dụng Git, nên sử dụng Git đúng cách là một tiêu chí để đánh giá ứng viên. Các sai lầm thường gặp khi sử dụng Git có thể nhắc tới việc dồn quá nhiều thay đổi vào một commit, hoặc viết commit message không rõ ràng, thiếu nghiêm túc…
Dồn quá nhiều thay đổi vào một commit
hay…
Viết commit message thiếu nghiêm túc
Ngoài việc sử dụng Git hợp lý, những điều nên làm để có thể gây ấn tượng thông qua GitHub có thể kể tới:
Code rõ ràng và dễ đọc, theo quy chuẩn. Với các dự án mã nguồn mở, bất kì ai cũng có thể xem toàn bộ mã nguồn, qua đó có thể đánh giá chất lượng của dự án. Có thể nói rằng chất lượng code là tiêu chí quan trọng nhất khi đánh giá ứng viên thông qua các dự án cá nhân. Việc viết code dễ đọc có thể bắt đầu bằng cách làm theo các quy ước thông dụng như PEP8 với Python và ESLint với JavaScript. Cài đặt các pre-commit hooks để đảm bảo rằng các quy ước được tuân thủ cũng là một điểm cộng.
Sử dụng các công cụ hỗ trợ. Ngoài cách đảm bảo chất lượng code thông qua việc làm theo các quy ước, viết test giúp ta chắc chắn rằng code đã được viết đúng logic. Viết test đúng và đủ cũng là một phần không thể thiếu trong các dự án được đầu tư nghiêm túc. Ta có thể cài đặt sao cho test được tự động chạy mỗi khi push code lên GitHub với các công cụ như Travis CI, CircleCI, Azure Pipelines; cùng với đó là theo dõi tỉ lệ code đã được kiểm tra bởi test với các công cụ như Coveralls, Codecov… Thông qua khả năng sử dụng các công cụ một cách thích hợp, ta có thể đánh giá được xem tác giả có quan tâm và đảm bảo chất lượng của dự án hay không, cùng với đó là khả năng tìm hiểu và áp dụng các công nghệ, kĩ thuật phổ biến.
Một ví dụ về việc sử dụng các công cụ hỗ trợ như CI, coverage…
Cung cấp mô tả rõ ràng về các dự án. Các dự án cá nhân cần có một tiêu đề và mô tả ngắn gọn nhưng vẫn đầy đủ. Ngoài ra, mỗi dự án nên có một file README chứa những thông tin cơ bản về dự án. File README này sẽ được hiển thị tại trang chủ của dự án, ví dụ như https://github.com/psf/black, nó sẽ là ấn tượng đầu tiên khi truy cập vào dự án của bạn trên GitHub. Vì vậy, có một file README rõ ràng, dễ đọc, mô tả chi tiết về dự án là một điểm cộng rất lớn trong quá trình review GitHub. Các bạn có thể tham khảo các bài viết sau để tìm hiểu thêm về cách viết README: https://www.makeareadme.com/, https://github.com/kylelobo/The-Documentation-Compendium.
Quản lý dự án. GitHub cung cấp khả năng quản lý dự án với tính năng Issues. Với Issues, bạn có thể theo dõi bug và các yêu cầu tính năng mới cho mỗi dự án. Tận dụng hợp lý tính năng này là một cách để thể hiện kĩ năng quản lý dự án và làm việc nhóm.
Giấy phép (License). Có thể bạn chưa để ý đến license, nhưng đây là một điều rất quan trọng với các dự án mã nguồn mở. Chúng cho phép lập trình viên khác sử dụng, cũng như đóng góp các thay đổi, nâng cấp cho dự án của bạn. Một số loại giấy phép phổ biến phải kể đến MIT, Apache License 2.0… Bạn có thể tìm hiểu thêm tại https://choosealicense.com/, hoặc tham khảo một ví dụ về giấy phép MIT tại https://github.com/psf/black/blob/master/LICENSE.
Tạo trang cá nhân với GitHub. Có một trang web cá nhân là một trong những điều gây ấn tượng mạnh với nhà tuyển dụng. GitHub cho phép bạn tạo trang web cá nhân và trang web cho các dự án của bạn. Hướng dẫn chi tiết có tại https://pages.github.com/.
Bài viết bởi M.P – Kỹ sư của Got It Vietnam. Take out with full credit!
Tài liệu tham khảo
[1] D. Thomas and A. Hunt, The Pragmatic Programmer, 20th Anniversary Edition: your journey to mastery. Addison-Wesley Professional, 2019.
[2] R. C. Martin, The Clean Coder: A Code Of Conduct for Professional Programmers. Prentice Hall, 2011.
Trình duyệt web – Lần này chủ đề ít hardcore hơn một chút, nhưng bảo đảm sẽ giúp bạn cứu tiếp nhiều giây của cuộc đời, tích tiểu thành đại. Mỗi năm cũng tiết kiệm được cả vài tuần chứ không ít nhé các bạn.
Hôm nay chúng ta nói về trình duyệt Chrome, trình duyệt mà hầu hết các bạn dùng duyệt web hàng ngày, vậy các bạn có bao giờ nghĩ đến việc Chrome có thể trở nên tuyệt vời hơn như thế nào chưa?
Đây nhé …
1. Bạn hay xem Youtube phải không?
Thấy phiền vì quảng cáo, hãy cài ngay plugin Youtube AdBlocker, tiết kiệm bao nhiêu giây các bạn? (mỗi quảng cáo tối thiểu 5 giây, công sức canh me bấm nút “Bỏ qua quảng cáo”, rồi thỉnh thoảng bác Google tặng cho chúng ta cái video 30s coi chơi)
2. Bạn đã bao giờ lâm vào cảnh loạn xà ngầu vì mở quá nhiều Tab chưa?
$#^&@^#@&$#@*($)
Dĩ nhiên rồi.
Nó sẽ như thế này:
◎ Điếng người khi ráng đi tìm tab chứa nội dung mình cần
Đây là bí kíp mình học được từ giáo sư đáng kính thời còn làm việc ở Seoul – Hàn Quốc.
Mỗi khi cần tìm hiểu về vấn đề gì đó, giáo sư sẽ mở một cửa sổ mới hoàn toàn với một tab duy nhất. Sau đó nếu cần tìm hiểu thêm các vấn đề liên quan đến chủ đề đó thì cứ mở thêm trong cửa sổ đó.
Nếu có vấn đề khác nữa cần tìm hiểu, chúng ta lại mở cửa sổ mới và tương tự như thế. Bằng cách này, lúc chuyển cửa sổ, chúng ta có thể nhìn vào nội dung của Tab bất kì để đoán toàn bộ nội dung của cửa sổ đó, cũng như số lượng Tab / cửa sổ lúc này sẽ đủ ít để có thể nhìn thấy rõ tiêu đề từng Tab.
Nó sẽ trông như thế này cho từng cửa sổ (trong thực tế mỗi cửa sổ lúc dùng vẫn phóng to ra như thường)
Nhìn ví dụ, khi dùng cửa sổ bên trái, ta dễ biết là chúng ta đang làm việc trên blog, còn chuyển qua cửa sổ bên phải, dễ dàng biết ngay là đang nghiên cứu về deep learning / convolutional neuron network.
Cái này người ta gọi là giảm tải cho nhận thức, không bị overload nhận thức (cognitive overload). Thử làm theo xem sao, bạn sẽ thấy tư duy bạn trở nên trong suốt tỉnh táo hơn rất nhiều, đồng thời độ tập trung khi làm việc trên từng vấn đề được tăng lên đáng kể đấy! Làm xong nhớ báo cáo kết quả áp dụng với sếp!
3. Lưu trữ nội dung hay để đọc lại
Bạn có thể dùng bookmark của Chrome để lưu các link thường truy cập hoặc extension Pocket (lưu lại để đọc sau).
Điều quan trọng để tinh thần luôn sáng suốt là bạn luôn để ý sắp xếp Bookmark của Chrome được tổ chức theo cấu trúc rõ ràng, có thể phân chia theo concept, đặc điểm công việc … để lúc cần có thể tìm thấy nhanh chóng.
4. Cũng là chuyện Tab
Với bí kíp quản lý các link thường truy cập ở trên vào Bookmark, dần dần bạn sẽ thấy thật vẫn chưa tiện lắm khi cần mở link nào đó trong Bookmark.
Xin giới thiệu extension Quick Tabs. Bạn còn nhớ trong bài 1 mình nói về hotkeys chứ? Nào, chỉ với phím tắt Ctrl+Q, sẽ mở ra ngay giao diện tìm kiếm gần như google, và bạn có thể nhập vào một đoạn ngắn trong tiêu đề / đường dẫn để có thể nhanh chóng truy xuất, lưu ý là có nhiều link đã lưu ở lịch sử trình duyệt bạn cũng không cần phải lưu ở Bookmark mới có thể tìm kiếm!
5. Vâng, chắc Chrome chỉ có mỗi Tab là đáng nhớ 😀
Ví dụ hôm nay bạn đang nghiên cứu về chủ đề big data, bạn đang nghiên cứu dở chừng và mở chừng 5 tabs, mà tới giờ ngủ rồi phải tắt máy thôi. Ấy thế ngày mai mở máy lên lại không lẽ lại đi mò lại từng link, hay giờ phải lưu lại từng link vào bookmark?
Nó cho phép chúng ta dễ dàng lưu lại một nhóm các Tab đang mở lại và mở lại nguyên cả nhóm chỉ với một click chuột.
6. Lướt web kiểu dân công nghệ
Ý là dùng chuột có vẻ không ra dáng dân công nghệ lắm, nên cứ phải dùng bàn phím thôi các bạn ạ. Nói chơi thôi, các bạn có thể thử trải nghiệm cảm giác lạ khi lướt web có thể truy xuất các bài viết trên trang chỉ trong vòng vài nốt nhạc, nhanh hơn dùng chuột nhiều.
Hình minh họa bên dưới là đọc bào vnexpress.net, để bắt đầu, bạn bấm f, lúc này mỗi link trên web sẽ hiển thị một hoặc vài ký tự. Bạn muốn vào link nào chỉ cần bấm đúng các ký tự đó thì trình duyệt tự mở link. Rất smart.
Và như một thói quen của sự tối ưu hóa mọi thứ, chúng ta hãy cũng nhau đi tìm phím tắt của chương trình toàn phím tắt này nhé
7. Các plugins tuyệt vời khác
Khi lập trình web, sẽ có rất nhiều plugin hỗ trợ kèm theo Chrome, tiêu biểu là các plugin React / Redux khi các bạn code ReactJS, hay plugin hỗ trợ xem thông tin SEO metadata, SEO performance metrics, hay chỉnh sửa Cookie cho custom cookie trước khi gởi lên server, hay xem thông tin màu sắc, font chữ của các element trên web, … nói chung là vô vàng các thể loại plugin dành cho lập trình nhé các bạn. Phần này là bài tập cho các bạn tự đi tìm, như thường lệ, chỉ cần có câu hỏi, sẽ có câu trả lời!
Nếu bạn đọc có extension nào dành cho Chrome hay, đừng ngận ngại chia sẻ nhé.
Phù hợp cho các bạn thiết kế nào ko muốn làm code dạo, design dạo nữa, bạn muốn cái gì đó cao hơn ở tầng khái niệm
Nếu lập trình chúng ta có các nguyên tắc chung khi viết code như KISS, DRY, thì trong thiết kế cũng có những nguyên tắc chính khi làm việc. Những nguyên tắc này sẽ là kim chỉ nam, nếu có tranh cãi giữa các member trong team, thì cứ đè nguyên tắc này ra mà giải quyết (nghe hơi có mùi cứng nhắc, mình thì thích tùy cơ ứng biến hơn)
Nhất quán, nhưng không hòa tan (phải có chất riêng với thằng khác)
Cởi mở, mọi thứ tốt hơn
Bao trừu tượng luôn các bạn, trang Gov.uk này cũng có câu tổng quát rất hay
Thiết kế tốt là thiết kế có thể sử dụng. Phục vụ cho nhiều đối tượng sử dụng, dễ đọc nhất nhất có thể. Nếu phải từ bỏ đẹp tinh tế – thì cứ bỏ luôn. Chúng ta tạo sản phẩm cho nhu cầu sử dụng, không phải cho người hâm mộ. Chúng ta thiết kế để cả nước sử dụng, không phải những người đã từng sử dụng web. Những người cần dịch vụ của chúng ta nhất là những người đang cảm thấy khó sử dụng dịch vụ nhất. Luôn nhớ về họ ngay từ đầu.
Những nguyên tắc thiết kế trong sản phẩm sẽ giúp cá nhân người thiết kế, cả thành viên trong team, PM, product owner ra định hướng được những quyết định cần thiết trong những tình huống phải lựa chọn.
Nếu sản phẩm của bạn có mặt trên nhiều nền tảng khác nhau, chúng ta nên cân nhắc có 1 design system và 1 vài nguyên tắc chung cho nó. Chúng ta phải có sự khác biệt với những sản phẩm khác nhưng đồng nhất trên các hệ thống khác nhau, giữa các màn hình.
Một vài team đặt những nguyên tắc chung như thế này: rõ ràng, đơn giản, hữu dụng, không thể tạo được những sản phẩm tốt nếu chỉ có những nguyên tắc quá căn bản, chung chung như vậy. Cho nên, chúng ta cùng tham khảo những nguyên tắc của những ông lớn xem họ định nghĩa thế nào.
Airbnb
Đồng nhất
Mỗi một thành phần là một phần của hệ thống lớn hơn, đóng góp tích cực cho khi hệ thống lớn lên. Không có những tính năng đứng riêng một mình và nằm ngoài các phần còn lại.
Triệu người sử dụng
Airbnb được sử dụng bởi cộng đồng thế giới. Sản phẩm phải thể hiện sự hiếu khách và dễ dàng truy cập.
Biểu tượng
Trong cả thiết kế và tính năng đây là điều chúng ta muốn tập trung, sản phẩm phải mang tính biểu tượng, chuẩn mực cho dòng sản phẩm như vậy, phải được thể hiện rõ ràng nhất, mạnh mẽ nhất.
Ngôn ngữ tự nhiên, cởi mở
Mang hơi thở cuộc sống vào trong các sản phẩm, cho phép chúng ta trao đổi tốt hơn với user để cả 2 có thể hiểu nhau.
Là người bạn thân thiết
Không có cảm giác của thiếu tin tưởng, sản phẩm cho phép mọi người có thể hiểu về nhau hơn, như một người bạn, chúng ta sẽ có mặt ở đó khi họ cần
Thiết kế để có ấn tượng đầu tiên tốt đẹp
Mặc dù Airbnb yêu cầu một số thông tin của user, nhưng không cung cấp thông tin này cho bên thứ 3. Nên chúng ta hỏi khách thông tin của họ nhưng không bắt buộc.
Tin tưởng cần thời gian
Giống như cuộc sống này, bạn sẽ nhận càng nhiều từ Airbnb nếu bạn càng tin tưởng chúng tôi. Tin tưởng cần xuất phát từ cả 2 bên. Nếu khách càng tin tưởng vào chủ nhà, thì chủ nhà cũng sẽ sẵn sàng chia sẻ với khách nhiều hơn
Facebook
Triệu người sử dụng
Mục tiêu của chúng ta là làm cho thế giới cởi mở hơn, đi đến từng cá nhân ở mọi ngóc ngách trên thế giới. Design phải mà ai cũng có thể xài, dù ở văn hoá nào, ngôn ngữ gì, thiết bị nào, ở tầng lớp nào trong xã hội. Sản phẩm phục vụ cho 90% người sử dụng, bỏ qua những tính năng mà chỉ có một vài thiểu số người yêu cầu
Cho con người
User quay lại Facebook vì có bạn bè và những người họ quen biết. Đó là thứ chúng ta cung cấp như đã hứa, những người mà bạn quan tâm ở một nơi duy nhất. Lý do mà tiếng nói và những gì chúng ta muốn trình bài được ẩn đi phía sau, tiếng nói của những người user quan tâm, khuôn mặt, cảm xúc, suy nghĩ của họ được ưu tiên hàng đầu.
Sạch sẽ
Phần hiển thị phải thật sạch sẽ, tinh gọn. Sạch sẽ không phải là cách tiếp cận dễ dàng, tiết chế các khoảng trống, kích thước khác nhau, màu sắc, số lượng các định dạng điều phải giảm bớt đi.
Đồng nhất
Chúng ta không muốn lãng phí thời gian, tăng cường sử dụng pattern, những phần giống nhau khi được thể hiện một cách giống nhau sẽ mang tới sự gần gũi và dễ sử dụng. Mọi tương tác với user điều có một mục đích: tạo sự tin tưởng. Bỏ bớt, tái sử dụng, đừng thiết kế lại.
Hữu dụng
Sản phẩm của chúng ta là công cụ hữu dụng không phải công cụ giải trí, được sử dụng hằng ngày cung cấp giá trị hữu ích. Không có những khoảng trắng dư thừa, tương tác dưa thừa, mọi thứ thể hiện liền mạch, nhanh nhất.
Nhanh
Không chỉ tôn trọng thời giản của bản thân, chúng ta phải biết tôn trọng thời gian người khác. Chạy phải nhanh, hiệu quả, không tốn thời gian.
Minh bạch
User tin tưởng trao cho chúng nhận dạng, ảnh, suy nghĩ, hội thoại của họ. Chúng ta phải trung thực và rõ ràng về mọi thứ, tại sao và những gì đang diễn ra. (Sau vụ lùm xùm làm mất thông tin user mình hoan mang Hồ Quỳnh Hương với nguyên tắc này quá)
Apple (Cái này dành cho các bạn nhà iPhone)
Thẩm mỹ
Thẩm mỹ trên cả bộ mặt ứng dụng và tính năng, cách hoạt động.
Ví dụ ứng dụng giúp người sử dụng thực hiện các tính năng quan trọng, không sử dụng hình ảnh ko liên quan, nội dung rõ ràng, dùng control mặc định, hoạt động có thể lường trước kết quả. Ngược lại các ứng dụng như game phục vụ giải trí có thể cung cấp các giao diện vui nhộn.
Thống nhất
Ứng dụng đi theo chuẩn mực chung, các element được cung cấp bởi hệ thống, icon ai cũng hiểu, kiểu chữ chuẩn mực, các tính năng của ứng dụng vận hành theo cách mà user mong đợi.
Tương tác trực tiếp
Luôn nhớ thiết kế để user sử dụng trực tiếp thông qua màn hình, những gì thấy trên màn hình, user có thể xoay điện thoại, họ sẽ thấy được kết quả của việc đó ngay lập tức trên màn hình.
Phản hồi
User thực hiện 1 action nào đó, phản hồi lại kết quả action đó, để họ biết. Các element có thể tương tác được highlight rõ ràng khi user tab, các animation hiển thị ý nghĩa rõ ràng.
Ẩn dụ
Khi sử dụng các đối tượng mang tính ẩn dụ (như icon) cho tương tác, cần đảm bảo nó phải được nhiều người biết đến
User là người quyết định
Ứng dụng không phải là đứa quyết định, người sử dụng sẽ quyết định làm cái gì, ứng dụng cho biết hành động đó dẫn đến kết quả gì.
Google Material Design
Nổi bật, hình ảnh, mục đích rõ ràng
Cách thành phần chính trong thiết kế in ấn: typography, grid, space, scale, color, image không chỉ phục vụ cho mục đích nịn mắt, nó tạo ra trật tự, ý nghĩa, tập trung.
Chuyển động cung cấp một ý nghĩa
Mọi chuyển động cần có ý nghĩa và phù hợp, phục vụ mục đích tập trung sự chú ý và duy trì các thao tác đang thực hiện
Microsoft
Giữ mọi thứ đơn giản
Kim chỉ nam cho mọi thiết kế của Microsoft bây giờ. Nhằm mang đến cảm giác trung thực và không bị ảnh hưởng bởi thời gian.
Mang tính cá nhân
Tạo một cảm xúc kết nối với từng người sử dụng. Làm sao để user khi sử dụng có được cảm giác như sản phẩm được thiết kế cho mỗi mình mình.
Nghĩ toàn diện
Chúng ta không đơn thuần tạo ra sản phẩm, chúng ta đang xây dựng thế giới nơi chúng ta sống, một thế giới tốt hơn.
Tạo cảm giác hào hứng
Tạo ra những trải nghiệm cho user mà họ biết là người đằng sau thiết kế đó là một con người thực.
Cảm nhận cái này dễ thấy nhất là lúc chúng ta cài window, giờ chúng ta cảm giác như đang có người nói chuyện với mình í, không phải các thông báo đơn thuần, như có một AI đằng sau
Khi bạn dự thi Quiz 03, nếu bạn đạt bất kỳ hạng mục giải thưởng nào, Kambria đều sẽ quyên góp giá trị tương đương để hỗ trợ cộng đồng cùng đẩy lùi đại dịch COVID-19. Tất cả các khoản đóng góp sẽ được thanh toán bằng VND, và sẽ đóng góp vào quỹ phòng chống dịch Covid-19 của Bộ Thông tin và Truyền thông Việt Nam, Bộ Y tế Việt Nam, Ủy ban Trung ương Mặt trận Tổ quốc Việt Nam.
Quiz 03 của Kambria Code Challenge được tổ chức với chủ đề: Mạng hồi quy RNN (Recurrent Neural Network). Bounty sẽ bắt đầu vào thứ 7 ngày 2/5/2020. Các bạn tìm hiểu chi tiết ở link bên dưới, click vào “Join this Challenge” để tham gia!
Thưởng càng lớn cho các bạn tham gia nhiều cuộc thi. Quiz cuối cùng (Câu đố 04) sẽ có giải thưởng lớn nhất, nhưng sẽ yêu cầu các thí sinh đã thực hiện 2 quiz trước đó để có thể tham gia.
Môi trường Nhân sự luôn có những thách mới đòi hỏi bạn cần có một tác phong làm việc chuyên nghiệp, biết tận dụng những khả năng vào đúng thời điểm và quan trọng nhất là cách linh hoạt trong ứng xử, không ngừng học hỏi, cố gắng để vươn đến thành công.
Dù cho bạn là một nhân viên mới hay một người gắn bó lâu năm thì hãy ghi nhớ 10 kim chỉ nam sau đây vì nếu có trót quên, bạn có thể đã tự “thổi bay” sự nghiệp của mình trong phút chốc đấy!
Việc không biết thì hỏi là điều tốt. Thế nhưng, nếu hỏi mà thiếu thông suốt thì đó là lỗi của bạn. Một ứng viên tiềm năng nên suy nghĩ trước điều mình hỏi có thực tế hay không. Đây là sự cẩn trọng trong cách suy nghĩ và được thể hiện qua xu hướng hành vi. Không một ai thích thích một người đồng nghiệp hay một nhân viên chỉ loanh quanh mãi những câu hỏi mơ hồ, xáo rỗng cả. Vì vậy, một điều quan trọng cần nhớ, hãy hỏi trực tiếp các thắc mắc nếu trước đó bạn đã suy nghĩ thật kỹ lưỡng.
Hoặc cũng có những thường hợp, bạn đã suy nghĩ rất nhiều về vấn đề cần hỏi. Tuy nhiên, bạn cần tham khảo những ý kiến và đáp án thuyết phục hơn ,vì thế bạn lựa chọn cách hỏi người khác. Bạn nên nhớ rằng, một điểm chung mà hầu hết mà người tiếp nhận thông tin câu hỏi phản hồi bạn chính là họ chỉ gợi mở, quanh co mà khó tập trung vào việc đưa ra những cảm quan cá nhân mình. Đây là thủ thuật an toàn và thông minh trong giao tiếp.
Nếu bạn thật sự mong muốn những lời góp ý chân thành từ họ, hãy thu hẹp khoảng cách bằng việc loại bỏ đi tâm thái “đùn việc”, cho họ thấy bạn thật sự trân trọng những gì mà họ chia sẻ.
Dù thế nào, thắc mắc vẫn là của bạn và đơn giản, bạn đang muốn thảo luận thêm với nhiều người để mở rộng cách xử lý vấn đề mà thôi. Đừng bao giờ đẩy trách nhiệm giải quyết cho người khác nhé!
2. Kéo dài “deadline”
Việc tạo ra deadline (tức là đặt ra mức giới hạn cho sự hoàn thành một công việc nào đó) cũng thể hiện sự thông minh của người quản lý nhân sự hoặc tính liên kết, sự thấu hiểu giữa các nhân viên cùng một team. Vì thế điều quan trọng là nên đặt deadline một cách hợp lý (đã phòng trường hợp thời gian co dãn vì những phát sinh không mong muốn).
Dù cho lượng công việc ít hay nhiều, nhà quản lý nhân sự cần phân chia phù hợp với quỹ thời gian, phân tích kỹ càng những tiêu chí như năng lực, kỹ năng mềm và phẩm chất nhân viên để đặt ra những deadline phù hợp. Tuy vậy, nhiều nhân viên vẫn không đảm bảo được deadline và luôn đổ lỗi cho hoàn cảnh, viện cớ rất nhiều lý di như: quên – một lý do thiếu chuyên nghiệp, vì những sự cố khác, do quá nhiều đầu việc hoặc thậm chí là do cần thực hiện những việc khác quan trọng hơn.
Hoàn thành công việc đúng thời hạn là nguyên tắc cơ bản của một người đi làm. Và nếu có mong muốn có thể phát triển xa hơn trong nghề nghiệp, thì việc cam kết đúng deadline còn là trách nhiệm với đồng nghiệp, công ty và chính bản thân mình. Đừng để bị thổi bay chỉ vì việc kéo dài deadline mãi.
3. Thiếu chủ động để bắt nhịp với tiến độ phát triển chung
Chủ động và linh hoạt là những yếu tố quyết sự bạn sẽ phát triển nhanh hay sẽ dậm chân tại chỗ. Ngành Nhân sự chú trọng việc khai thác và phát triển tài năng của con người. Vì vậy, nếu đã có quá trình rèn luyện, song bản thân bạn chưa bứt phá ra khỏi vùng an toàn thì nhiều nguy cơ bạn buộc phải dừng lại. Nhà quản lý luôn mong muốn thấy được sự nỗ lực của bạn, dù ít hay nhiều, miễn là bạn trưởng thành hơn từng ngày. Đừng phải để ai phải nhắc, bạn phải tự mình tìm ra được sự kết nối trong công việc và giải quyết chúng. Đó là cách bạn đang dần khai thác sự sáng tạo và điều này cũng giúp bạn bắt nhịp với tiến độ công việc một cách tốt hơn.
Làm việc xong, quên viết báo cáo hay kiểm tra tiến độ nhưng lại quên thống kê số liệu. Điều đó không những thể hiện sự thiếu cẩn trọng mà còn cho thấy mức độ nhìn nhận một vấn đề tổng thể của bạn chưa tốt. Nếu cứ giữ mãi cái nhìn thiếu bao quát, bạn khó có thể đưa ra những góp ý chuyên môn thiết thực cho tổ chức của mình. Đồng thời, bạn như định vị mình trong một khuôn khổ riêng, khó lòng hợp tác và đồng nhất với sự phát triển chung của doanh nghiệp. Dần dần, chính bạn sẽ cảm thấy lạc lõng và không còn hứng thú với công việc nữa.
4. Làm việc qua loa, không vận dụng kĩ năng chuyên nghiệp
Tình trạng này dễ nhận thấy ở những nhân viên mới bắt đầu làm việc. Có thể do họ thiếu kinh nghiệm hoặc thậm chí là cố tình do cảm thấy không thật sự hài lòng với công ty.
Việc bạn thực hiện nhiệm vụ một cách qua loa. không vận dụng những kỹ năng cần thiết để xử lý thể hiện bạn là người thiếu cẩn trọng, chưa thật sự nhiệt huyết với công việc; kỹ năng giao tiếp, đơn xin nghỉ việc,… Một báo cáo sơ sài với những lỗ hổng chưa hợp lý, một bài thuyết trình với mô típ lặp đi lặp lại với các thông mình được copy & paste trên mạng thật khiến người tiếp nhận nó phải khó chịu.
Kiến thức chuyên môn bạn có, tại sao không vận dụng? Kỹ năng mềm bạn không thiếu, tại sao bạn không dùng nó để phân tích thông tin. Hãy gạt bỏ đi suy nghĩ tận dụng những thói quen cũ thuộc về bản năng để giải quyết công việc cho có. Như vậy, kết quả sẽ rất thất vọng và bạn có thể sẽ bị sa thải vì sự thiếu trách nhiệm và không chỉn chu trong công việc. Nhớ rằng, làm việc thì cần nghiêm túc, mọi sự đầu tư đều cho ra những thành quả và giá trị xứng đáng.
5. Lý do xin nghỉ “trường kỳ”
Một lý do về vấn đề sức khỏe luôn được chấp thuận, tuy nhiên đừng vì thế mà lạm dụng nó quá mức. Đôi khi bạn quá nhạy cảm đến mức chỉ một vài biểu hiện nhỏ của cơ thể bạn cũng cho rằng mình không khỏe và xin nghỉ. Điều này không công bằng vì những nhân viên khác cũng đang cố gắng làm việc, thậm chí là làm thay phần việc của bạn trong khi bạn lại nghỉ ngơi dù tình trạng không quá căng thẳng.
Những lý do không chính đáng thể hiện bạn là người thiếu sự kiên trì và dễ dàng từ bỏ một việc gì đó khi. Đã là nhân viên, bạn cần phải biết mình có có trách nhiệm giải quyết công việc được giao phó, chứ không đơn giản là lúc đầu thì hứng thú, làm được lưng chừng lại tùy hứng bỏ đi và viện cớ rằng mình quá mệt mỏi. Điều này cho thấy bạn thiếu chuyên nghiệp trong tác phong và phẩm chất chuyên môn nghề nghiệp, với cách hành xử như vậy, việc bạn bị “đánh bay” ra khỏi công ty chỉ còn là vấn đề thời gian.
Ngành Nhân sự và môi trường làm việc nhân sự chưa bao giờ là một môi trường để bạn dễ tồn tại, thế nhưng thật ra nó cũng chẳng khó chịu và mệt mỏi như bạn nghĩ. Chỉ cần có ý thức làm tốt việc của mình, thêm một chút khéo léo trong ứng xử thì sẽ chẳng khó khăn nào có thể hạ gục được bạn đâu.
Trong mục “Chuyên gia nói” lần này, chúng ta sẽ trò chuyện cùng anh Hiếu Phạm – Software Engineer tại Rockset. Từng là nhân viên của 3 công ty công nghệ lớn như Google, Microsoft và Facebook, hãy cùng tìm hiểu vì sao anh Hiếu chọn Rockset là nơi phát triển sự nghiệp.
Về khách mời Hiếu Phạm
Hiện đang là Senior Software Engineer ở công ty Rockset, công ty làm về realtime database được 4 năm
Công việc đầu tiên là ở tập đoàn Facebook.
Và trước khi ra trường, anh thực tập ở 3 công ty, tập đoàn lớn là Google, Microsoft và Facebook.
Rockset là 1 công ty khởi nghiệp software access và service về mảng realtime database. Rockset được thành lập bởi những kỹ sư ngày trước cũng từ facebook và google. Là những kỹ sư ban đầu thiết kế các hệ thống rất là lớn như là RocksDB, HDFS hay Gmail.
Rockset giải quyết vấn đề gì?
Rockset thực ra là 1 realtime database giúp khách hàng có thể chạy những sql query trên datahost mà trước giờ họ không support cái SQL query ấy, thí dụ như là DynamoDB, Kafka, hay S3 của Amazon hoặc là google course query của Google. 1 điểm hay của Rockset đó chính là realtime, có nghĩa là khi mà data đến mình query được luôn, chứ mình không phải đợi 1 đến 2 ngày. Và cái hay nữa là khi khách hàng dùng Rockset không cần phải tune query, không phải tạo index để làm gì hết, khỏi cần phải data rockset và rockset sẽ tự động làm cho tới cái query họ nó nhanh hơn. Mình chỉ mới làm ở đây được mấy tháng và dự án mà mình thích nhất hiện giờ là giúp cho hệ thống Rocket chứa được hình nhiều thông tin hơn, và với 1 giá tiền rẻ hơn, vì mình càng chứa nhiều thông tin hơn AWSB của mình sẽ rất là lag, nên công việc của mình bây giờ là làm cho nó càng rẻ càng tốt.
Anh hãy giới thiệu hoặc giải thích đơn giản về architecture của Rockset? Vai trò của một người làm về Search Engine là xử lý ở quá trình nào trong mô hình này?
Hệ thống của Rockset chia làm 3 phần, gọi là Tailer – Leaf – Aggregator. Tailer nói nôm na là nơi xử lý những dữ liệu thô, và đưa cái dữ liệu đã được xử lý đó vào leaf, và leaf là nơi chứa dữ liệu đó để cho aggregator đó query cái dữ liệu đó 1 cách hiệu quả. Sau khi aggregator query những dữ liệu đó xong sẽ làm các phép tính sequel đó rồi trả lại dữ liệu cho người dùng, đó là cái nhìn chung về architecture của rockset, thật ra cái architecture này được dùng ở rất nhiều nơi.
Ngày xưa khi mà mình làm ở bên search họ cũng dùng những cái architect như thế này và 1 trong những người đầu tiên khi mà xây dựng hệ thống search của Facebook hiện giờ cũng đang làm ở Rockset, cho nên đó là lý do vì sao mà 2 hệ thống trông rất là giống nhau.
Data-driven app là gì? Có ý nghĩa như thế nào đối với các doanh nghiệp?
Các doanh nghiệp hiện giờ khi phải quyết định chuyện gì, họ phải phân tích nhiều về data mới biết được vấn đề hiện giờ là gì và giải pháp nên là thế nào. Khi mà họ có nhiều data họ xem có đúng không và có cần phải thay đổi giải pháp đó không. Điểm mạnh ở Rockset là đưa data cho khách hàng 1 cách realtime, tức là hiện giờ để xây dựng 1 cái hệ thống để đọc được data từ phản hồi nhiều khi rất là khó là 1, cái thứ 2 là mình phải đợi 1-2 ngày để data có thể đến được, và 1-2 ngày cũng không còn là tức thời nữa, nên điểm mạnh của Rockset là khi mà data đến được luôn, data như thế nào, cái quyết định của mình có đúng hay không, mình có thể thay đổi quyết định 1 cách tức thời.
Hệ thống của anh sử dụng cloud nào và nó có khác gì với tailer vật lý hay không?
Hiện giờ ROckset sử dụng AWS và Kubernetes chạy trên AWS, và lý do mình dùng Kubernetes là tại vì sau này mình muốn gửi sang google cloud mình có thể chuyển sang 1 cách dễ dàng. Lý do mình sử dụng cloud vật lý là vì economics của cloud giờ nó đã rất là khác rồi, giả sử bây giờ mà mình cần chạy 1 computation mất 100 tiếng chẳng hạn thì mình có thể thuê 1 trăm máy và mình chạy mất 1 tiếng thay vì ngược lại, và khi mình thuê xong và trả lại cho AWS mình chỉ trả cho 1 tiếng đó thôi nó sẽ rẻ hơn rất là nhiều. Đó là lý do mà Rockset build for the cloud, tức là khi khách hàng cần bao nhiêu, mình thuê bấy nhiêu đó máy hỗ trợ khách hàng, sau đó mình sẽ tắt đi để tiết kiệm chi phí, như thế rất là tiết kiệm cho khách hàng cũng như Rockset.
Anh hay dùng ngôn ngữ nào và anh có thể tiết lộ về Database?
Ở Rockest có 2 phần, 1 phần người ta gọi là injection đưa data từ khách hàng vào Rockset, phần đó mình dùng Java, còn phần Leaf và Aggregator mà mình nói thì database mình dùng C++, query khi dùng C++, nó sẽ nhanh hơn và rockset được build on top of RocksDB và vì có anh engineer, ngày xưa là 1 trong những người viết ra RocksDB cũng như về HDFS. Hiện giờ anh đang làm CTO của Rockset, nên cũng là lý do RS dùng RocksDB.
Đâu là đặc điểm khác nhau giữa data stream, data lake và data warehouse?
Thực ra nó chỉ là nơi mà mình chứa dữ liệu thô, tức là dữ liệu từ khách hàng, dữ liệu từ những cái mà mình thu thập, nó nằm hết vào data lake. Còn data warehouse họ lấy data từ data lake sau đó họ chế biến để họ xử lý sao cho query 1 cách hiệu quả nhất. Tức là lấy dữ liệu thô sao đó làm sau cho nó có thể query được. Còn stream là 1 khái niệm mới khác hẳn, mình có thể tưởng tượng nó như 1 luồng thông tin luôn luôn đi vào chẳng hạn, cái data lúc nào cũng vào người ta thường đưa data stream vào data lake, sau đó rồi datawarehouse sẽ mỗi ngày lấy data từ data lake đấy họ xử lý lại và data sẽ được query và data ngày hôm sau sẽ được query từ ngày hôm trước.
Anh có thể giải thích vai trò của data source là gì? Vì sao Rockset lại lựa chọn các data source như Amazon S3, Amazon Kinesis, Amazon DynamoDB, Apache Kafka, Google Cloud Storage, Amazon Redshift? Ưu điểm của mỗi loại này là như thế nào?
Data source mình chỉ hiểu đơn giản nó là nơi người ta để data thôi, nó cũng có ưu và khuyết điểm nhất định, nhưng nhìn chung lý do Rockset support những cái datasource này là rất nhiều data scientist họ thích dùng SQL, nhưng những data source này lại không support SQL thế nên rockset muốn họ khả năng query sql trên những data source này cho công việc họ đơn giản hơn, bởi vì data scientist xem sql như ngôn ngữ mẹ đẻ của họ vậy.
Query Lambdas của Rockset là gì?
Cơ bản nó chỉ là 1 cái hàm nằm trên Rockset thôi, và nó có nhiều tham số, bình thường 1 lập trình viên khi họ lập trình phần mềm của họ mà phải cần query sql, họ phải viết cái sql vào code page của họ nên là thành ra nó có khá nhiều bug, khiến nó cũng khó làm hơn bây giờ lập trình viên họ chỉ cần để sẵn cái sql query nằm trên rockset và họ cho Rockset cái tên cũng như tham số và rockset sẽ tự động biết chạy những cái sql nào và gửi trả lại đúng cái kết quả đó chứ không cần phải viết sql trong phần mềm của họ nữa.
Một số công nghệ hữu ích trên thế giới mà ở Việt Nam ít người sử dụng là gì? (chẳng hạn như Kafka)
Nó cũng mới phát triển gần đây thôi, mình có thể hiểu sơ rằng Kafka là 1 luồng thông tin nó rất đáng tin cậy, tức là thông tin khi mình đã viết vào Kafka rồi chắc chắn thông tin nó ở đó, nên khi mà mình đọc Kafka mình sẽ thấy cái lượng thông tin đó. Công dụng của Kafka là gì, thí dụ mình có 2 data center 1 cái ở TPHCM và 1 cái ở Hà Nội, và mình muốn 2 cái data center này có data giống hệt nhau tại vì khi mà mình hỗ trợ khách hàng ở TPHCM hay ở Hà Nội mình muốn là 2 data giống nhau, Kafka là cái để cho khách hàng có thể copy 1 data từ nơi này sang nơi khác 1 cách rất thuận tiện, và giả sử khi mà mình copy giữa chừng mà máy mình hỏng hay sao đó và khi mình restart có thể bắt đầu tiếp ngay từ chỗ đó chứ không cần phải bắt đầu lại từ đầu. Đó là công dụng của Kafka.
Và có 1 công dụng nữa mà mình thấy là gần đây có rất nhiều doanh nghiệp hiện giờ họ dùng 1 cái gọi là hybrid cloud, nó có nghĩa là 1 phần hệ thống nằm trong server vật lý ở công ty họ, và 1 phần nằm trên cloud, nhiều khi di chuyển dữ liệu giữa 2 phần này họ hay dùng Kafka vì nó rất đáng tin cậy.
Anh có nhận xét thế nào về khác biệt trong tư duy, cách tổ chức và xây dựng hệ thống của Việt Nam và các công ty hàng đầu trên thế giới?
Mình chưa có cơ duyên làm việc ở các công ty công nghệ ở Việt Nam, nên mình chỉ có kinh nghiệm ở một vài công ty công nghệ ở Mỹ. Đương nhiên mỗi công ty công nghệ đều có văn hoá xây dựng hệ thống khác nhau, nhưng nhìn chung đều rất data-driven, dựa trên data để tìm ra điểm khắc phục hệ thống.
Công ty chia ra nhiều nhóm nhỏ, mỗi nhóm làm 1 phần đặc trách, và coi các nhóm khác như khách hàng của mình. Mỗi lần hệ thống có vấn đề đều được phân tích kỹ lưỡng, tìm ra nguyên nhân cũng như làm sao để điều đó không xảy ra lần sau.
Cái mình học được lớn nhất là, khi hệ thống lớn như thế, cái gì có thể hỏng chắc chắn sẽ hỏng. Kỹ sư phải xây dựng hệ thống làm sao mà nếu 1 vài máy hệ thống bị hỏng bất cứ lúc nào, hệ thống vẫn phải chạy một cách trơn tru.
Từng là Intern tại Google, Microsoft và Facebook nhưng đâu là lý do khiến anh dừng chân?
Mỗi công ty đều có cái hay riêng, và bản thân mình cũng học được nhiều điều khác nhau ở từng công ty. Cá nhân mình thích trải nghiệm ở Facebook nhất, cũng như cảm thấy ở Facebook mình sẽ được trải nghiệm ở nhiều vị trí và nhóm khác nhau nên sẽ học được nhiều hơn.
Một văn hóa mình thích ở Facebook là move fast – tức là nếu cần làm gì thì làm luôn, chứ không cần phải đợi cấp trên ra chỉ thị. Quyết định rất nhanh. Đương nhiên cũng có cái hay và cái dở, nhưng mà mình nghĩ điều này giúp mình làm việc hiệu quả hơn rất nhiều.
Facebook cũng có cái scale mà mình muốn được thử sức nữa, vì lượng người dùng và data rất lớn.
Theo em biết, Software Engineer không chỉ đơn thuần là coder hay programmer, mà còn cần biết thu thập dữ liệu, cân bằng, khắc phục rủi ro, cũng như là về tư duy, tối ưu hóa trình duyệt. Thì theo anh vị trí Software Engineer ở từng công ty khác nhau như thế nào?
Công việc software engineer của mình nhìn chung có 2 phần: 1 là quản trị hệ thống của nhóm mình và 2 là code cho dự án mà mình đang làm.
Phần 1 thường mình có setup alert cũng như dashboard. Khi có chuyện sẽ được thông báo qua điện thoại, rồi mình lên dashboard cũng như đọc log của cái hệ thống để xem chuyện gì đang xảy ra, cũng như cách khắc phục. Nếu không khắc phục được mình sẽ gọi ai đó trong cái nhóm khác có liên quan để giúp.
Phần 2 chiếm chủ yếu thời gian của mình.
Các dự án được lập ra tùy vào mục tiêu của nhóm. Thông thường khi bắt đầu 1 quý, nhóm sẽ họp lại để nghĩ xem mục tiêu là gì và cần làm gì cho mục tiêu đó.
Sau đó chia ra làm nhóm nhỏ hơn, và chia việc nhau ra làm. Code xong đưa lên để review, và sau khi review xong sẽ submit, và 1 tuần 2 lần sẽ launch code mới ra production. Công ty mình launch như vậy để lỡ có bug catch nhanh và revert nhanh, cũng như mỗi lần push không có quá nhiều patch để push.
Anh hãy chia sẻ quá trình tôi luyện như thế nào để có thể có vị trí như ngày hôm nay?
Hè năm 2, mình rất may mắn (gần như là trúng xổ số) được thực tập tại nhóm quản lý MySQL ở Google. Ở đó mình được làm việc với những kỹ sư hàng đầu về database. Từ dịp đó, mình cảm thấy rất thích mảng hệ thống cơ sở dữ liệu. Năm 3 mình thực tập ở nhóm xây dựng Windows 10 ở Microsoft, và nhóm cơ sở dữ liệu thời gian ở Facebook. Mỗi lần thực tập mình đều học được 1 mảng khác nhau, nhưng đều về hệ thống máy tính. 3 lần đó giúp mình có kiến thức về C++, cũng như làm sao để xây dựng hệ thống một cách hiệu quả khi phải nhận lượng data khổng lồ.
Sau khi tốt nghiệp, mình làm 3 năm rưỡi ở Facebook, ở khoảng 3, 4 nhóm khác nhau tại Facebook. Mỗi nhóm đều có đặc thù khác nhau, cho dù đều làm về cơ sở dữ liệu. Ví dụ nhóm Search, đặc thù dữ liệu gồm các post trên Facebook, lại khác nhóm TimeSeries, khi đặc thù dữ liệu chỉ là 1 chuỗi gồm thời gian và giá trị.
Hơn nữa, mỗi nhóm lại có vấn đề riêng, có những tiêu chuẩn riêng. Ví dụ nhóm Search không cho phép thiếu bất cứ dữ liệu nào, nhưng nhóm TimeSeries ok với việc đó, nhưng phải chứa dữ liệu càng hiệu quả càng tốt.
Điều này giúp mình học được nhiều dạng hệ thống khác nhau, cũng như cái hay và cái dỡ ở mỗi hệ thống.
Search là một công cụ không thể thiếu và mỗi user khi search thì lại có một kết quả riêng. Vì vậy người làm về search phải có sự tinh tế, nhạy cảm riêng. Anh có thể chia sẻ thêm hệ thống unicorn của Facebook khi anh còn đảm nhiệm vị trí search Infrastructure được không?
Unicorn cũng khá là tương tự và giống với hệ thống của Rockset hiện giờ, tức là cũng có 3 phần: Tailer-Leaf-Aggregator architecture. Cốt lõi của unicorn gọi là inverted index, nghĩa là khi tìm một từ khóa, unicorn sẽ trả lại cho họ toàn bộ post liên quan đến từ khóa đó. Giả sử mình tìm kiếm Covid nó sẽ trả về hàng trăm, hàng ngàn post liên quan đến Covid. Ngoài phần đấy, unicorn còn có phần đặc biệt, đó là ranker. Giả sử khi mình tìm kiếm, mình không muốn kết quả trả về là một trăm, một nghìn post, mình chỉ cần 10 kết quả về covid thôi, và unicorn phải biết mình quan tâm đến cái gì, đối với riêng cá nhân mình chỉ quan tâm các bài post Covid liên quan đến bạn bè mình các tổ chức y tế đáng tin cậy, và unicorn phải biết được chuyện đó và đưa lại kết quả những bài post mà mình quan tâm, đó là điểm đặc biệt của unicorn, họ phải rank được các bài post đây mà tìm được cái nào relevant nhất đối với người tìm, đó là cái hay của unicorn.
Anh có vẻ ưu tiên về C++, có phải anh luôn tin tưởng và nhìn nhận tiềm năng của nó trong tương lai hay không? Và anh có thể chia sẻ khán giả về một dự án thành công nhờ vào C++ được không?
Bao nhiêu dự án những năm nay mình cũng chỉ dùng C++, ở 3 công ty mình làm họ đều sử dụng C++ cho cơ sở dữ liệu của họ. Lý do mình cảm thấy mình thích C++ là vì nó rất là nhanh, chạy không cần run time hay gì hết, đó là điểm mạnh của C++. Và C++ giúp cho người ta rất là nhiều option để optimize ngôn ngữ của mình, code của mình. Nhưng mà vì họ có quá nhiều option thế nên dễ dẫn đến người dùng dùng sai cách. Khi dùng C++ sai sách dễ dẫn đến phần mềm của mình bị crash và dễ bị nhiều bug; đó là điểm mạnh và điểm yếu của C++, điểm mạnh rất là nhanh nhưng điểm yếu lại rất khó dùng. Mình thấy nhiều hệ thống hiện giờ dùng C++ rất nhiều nên mình nghĩ tương lai rất là sáng sủa.
Làm thế nào để làm một big data, data thế nào thì được gọi là big, có phải những công ty lớn trên thế giới như Google, Facebook, hay chính phủ Trung Quốc mới có thể sở hữu big data.
Theo mình đây chỉ là tương đối. Đứng về quan điểm của quản trị viên của hệ thống, người ta quan tâm về “big” có một vài lý do sau:
Lượng data lớn dẫn đến số máy trong hệ thống phải lớn. Điều này có nghĩa là việc 1 trong những máy đó có vấn đề đi từ “có thể” lên “chắc chắn”. Hệ thống càng lớn thì vấn đề càng đến thường xuyên. Thế thì câu hỏi đặt ra là làm sao để xây dựng 1 hệ thống mà một vài thành phần trong hệ thống có vấn đề, nhưng cả hệ thống vẫn hoạt động bình thường.
Nhưng một góc nhìn khác là số lượng dữ liệu phải so với tài nguyên hệ thống là bao nhiêu. Lượng dữ liệu lớn đương nhiên dẫn đến lượng tài nguyên hệ thống khổng lồ. Nhưng như thế thì không ổn cho các doanh nghiệp, tại vì tài nguyên hệ thống là không hề rẻ. Thế nên câu hỏi đặt ra cho các quản trị viên hệ thống là, làm sao để quản lý lượng dữ liệu đó mà không dùng quá nhiều máy. Ví dụ như, ngày trước mình ở Facebook, hệ thống mình quản lý cực kỳ to, nhưng Facebook là một công ty khổng lồ, và mình xin bao nhiêu máy họ cũng cho (đương nhiên trong mức vừa phải). Bây giờ mình sang công y nhỏ hơn, lượng dữ liệu nhỏ hơn nhiều, nhưng lượng tài nguyên hệ thống còn nhỏ hơn gấp nhiều lần, cái khó khăn là làm sao để quản lý lượng dữ liệu đó với cái mình đang khó.
Thế nên, mình nghĩ cái mình nên quan tâm không phải là lượng dữ liệu lớn bao nhiêu, mà là làm sao để hệ thống của mình hoạt động hiệu quả, không phung phí tài nguyên, và có thể chịu được vấn đề khi mà một vài thành phần trong hệ thống đó có vấn đề.
Vậy anh có thể trình bày những kỹ thuật đặc trưng để duy trì hệ thống scale lớn như vậy được không?
Ở đây mình có thể hơi đi sâu về chuyên môn. Thông thường bài toán scaling có 2 mặt: 1 là scale từng máy một, tức là làm cho mỗi cá nhân từng thành phần hiệu quả hơn, và 2 là làm cho hệ thống hiệu quả hơn. Tương tự như trục tung và trục hoành trong toán học.
Trục tung tức là từng máy hiệu quả hơn, thường nhiều khi người ta có thể dùng chip mạnh hơn, ít điện năng hơn, chọn máy có nhiều RAM/SSD hơn. Nhưng trục này có 1 điểm bất lợi là mình chỉ có thể nâng cấp máy tính của mình đến một mức nào đó, vì những con chip mạnh thường đắt hơn rất nhiều so với hiệu năng nó mang lại.
Trục hoành là tăng số lượng máy. Nhưng điều này không phải cứ cho thêm máy là được. Ở một vài hệ thống mình đang làm, cho thêm máy chẳng khác nào đổ dầu vào lửa, vì cho thêm máy có nghĩa là số lượng data chạy qua network nhiều hơn, khả năng 1 máy hỏng cao hơn, dẫn đến vấn đề của cả hệ thống. Muốn đạt được điều này (hay từ chuyên môn là horizontal scalability), hệ thống cần phải được thiết kế đúng.
Một phương pháp mình hay dùng đó là khi service đang chạy, mình sẽ xem cái CPU profile, để xem phần nào của service đang chậm, hoặc tốn nhiều tài nguyên hơn mức cần thiết, và sau đó hiểu phần đó làm gì, và tìm ra phương pháp để làm phần đó nhanh hơn.
Lời khuyên khi chinh phục lĩnh vực Solution Architect
Theo anh, những bạn có tuýp người như thế nào thì sẽ phù hợp với lĩnh vực này?
Thực ra không có một tuýp người nhất định trong lĩnh vực này, lĩnh vực này khá là open và rất nhiều tuýp người có thể làm trong lĩnh vực này. Khi mình nhìn lại công việc của mình mình thấy nó cũng không khác gì nhiều công việc của những người khác, tức là mình có những vấn đề thế này, và mình có một vài solution thế này, và thế là làm sao để mình chọn ra solution, mỗi solution có điểm hay điểm dở, nó giúp giải quyết vấn đề này nhưng cũng giúp tạo ra vấn đề khác, và mình chọn solution nào cho đúng thôi. Mình nghĩ ai thích giải quyết vấn đề technical đều có thể làm trong lĩnh vực này.
Để có được vị trí trong các tập đoàn công nghệ lớn như Google, Facebook hay Microsoft, mình có điểm nào nổi trội để thu hút và hấp dẫn các nhà tuyển dụng?
Cái đầu tiên mình nghĩ là giá trị mình đem lại cho công ty là gì. Mình đặt mình vào vị trí một nhà tuyển dụng, họ tìm người để làm gì, thứ nhất họ tìm người giải quyết vấn đề giỏi, bình thường họ không tìm những người kiểu technology này, technology kia; họ không làm như thế vì mỗi công ty họ có technology riêng của họ.
Cái thứ hai là họ muốn biết kinh nghiệm của mình có liên quan đến vấn đề họ gặp phải không. Giả sử họ tìm thấy một ứng viên đã giải quyết những vấn đề tương tự vấn đề họ đang gặp, đó là một ứng viên tuyệt vời. Gần đây mình có nhận được một vài resume của nhiều bạn, cái mình cảm thấy được là các bạn đang cố cover rất nhiều technology đấy, mình sử dụng technology này cho dự án này, sử dụng technology kia cho dự án kia, các bạn muốn chứng minh có kinh nghiệm rất nhiều technology, nhưng cái nhà tuyển dụng quan tâm muốn biết bạn có phải là người giải quyết vấn đề tốt hay không, mình nghĩ các bạn nên tập trung vào bạn làm dự án gì, vấn đề các bạn giải quyết trong dự án đó là gì và kết quả dự án ấy như thế nào. Khi nhà tuyển dụng thấy được bạn là kỹ sư giỏi, có khả năng giải quyết vấn đề rất là khó, và nhiều khi vấn đề đó chính là vấn đề mà họ đang gặp phải, bạn chính là candidate tuyệt vời cho nhà tuyển dụng, mình nghĩ đó là cái mình góp ý đến các bạn khi nộp resume đó là đổi resume để tập trung hơn vào dự án bạn đang làm và show được kết quả các bạn đã làm như thế nào.
Anh có thể chia sẻ những tips nho nhỏ hoặc mẹo vặt giúp chinh phục công ty công nghệ ở Mỹ không?
Cá nhân mình nghĩ các bạn lập trình viên Việt Nam hoàn toàn đủ khả năng làm cho các công ty công nghệ ở Mỹ. Các bạn lập trình viên Việt Nam thực ra rất là giỏi, cái mình cảm thấy rào cản lớn nhất không liên quan đến năng lực mà đó là pháp lý, chi phí. Giả sử để có được visa đi làm ở Mỹ khá là khó, hoặc để phỏng vấn ở các công ty Mỹ họ sẽ đưa ứng viên đến tận headquarter để phỏng vấn trực tiếp. Vì chi phí đó khá lớn nên nhiều công ty không muốn đánh cược vào 1 thí sinh họ chưa chắc đã nhận. Nên thường nếu các bạn có referral từ những người đã làm bên này sẽ giúp cơ hội được phỏng vấn và nhận cao hơn nhiều.
Xin được cảm ơn những chia sẻ rất tâm huyết từ anh Hiếu, hy vọng qua bài viết này các bạn lập trình viên càng hiểu hơn về vai trò của một software engineer, hay “bỏ túi” những bí kíp giúp ứng tuyển các công ty công nghệ tại Mỹ. Hẹn gặp lại các bạn kỳ sau và đừng quên đón đọc “Chuyên gia nói” cùng TopDev nhé.
Hình ảnh máy gặt đập liên hợp ở dưới là một ví dụ rất rõ minh chứng cho điều này.
◎ Với chiếc máy gặt đập liên hợp này không còn cảnh một dàn các bác nông dân cầm liềm để gặt lúa, rồi vác từng bao về nhà để xay nữa.
Hôm nay với tư cách là một người dùng Windows lâu năm, đã từng cảm giác không thể thiếu Windows nhưng sau khoảng một tháng dùng Ubuntu 18.04 với một số kỹ thuật tweak lại một cách thích hợp nhất cho developer giờ đây tôi lại cảm giác không thể thiếu Ubuntu. Đoạn dưới đây sẽ hướng dẫn các bạn cách setup Ubuntu làm sao để có thể tận dụng tối đa hiệu suất lập trình, vd cài đặt phím tắt, cài terminal số một zsh kèm các plugins thiết yếu.
1. Cài ibus-unikey để hỗ trợ đánh tiếng Việt
Lưu ý: trình đánh tiếng Việt này sẽ không tương thích với các ứng dụng cài bằng snap, do đó để đánh được tiếng Việt trong ứng dụng luôn cài đặt ứng dụng từ đuôi .deb (Debian). Ví dụ bạn có thể vào website chính hãng skype / chrome / slack để tải .deb về cài đặt, sẽ có thể đánh tiếng Việt phà phà.
2. Tuyệt chiêu 10x nằm phần lớn ở đây với các bạn hay dùng câu lệnh
Bạn có muốn khi làm việc với các dòng lệnh bash, vd cài đặt npm, cài đặt chương trình, test api bằng curl, watch, chạy docker, … hiệu suất sẽ tăng lên đáng kể không?
Vậy hãy theo các bước hướng dẫn bên dưới, thì bạn sẽ có thể biến terminal của bạn thành như sau:
Chuyển đổi qua theme agnoster để hiển thị tốt hơn (https://github.com/agnoster/agnoster-zsh-theme), lưu ý có thể custom cách hiển thị cho theme agnoster để command prompt hiển thị ngắn gọn và súc tích hơn, bạn có thể tham khảo thêm trong link.
Cài font powerline-fonts https://github.com/Lokaltog/powerline-fonts
Thêm dòng sau DEFAULT_USER=$USER vào file ~/.zshrc
Và có thể enable rất nhiều plugins tuyệt vời cho oh-my-zsh. Ví dụ một số plugins tiêu biểu
plugin git sẽ bổ sung tên git branch khi ở trong 1 folder có dùng git.
plugin command-not-found sẽ hỗ trợ suggest package để cài đặt nếu chưa có
plugin history-substring-search sẽ hỗ trợ nhập 1 đoạn text trong câu, bấm nút lên (Up) và terminal sẽ show câu lệnh gần nhất có chứa đoạn text đó. Đặc biệt tiện trong trường hợp chạy các câu lệnh dài như docker, trong hình là tác giả chỉ nhớ là có chạy docker neo4j nhưng không nhớ chính xác câu lệnh.
◎ Plugins và ý nghĩa
plugin autosuggestions là khi đánh câu lênh, termnial sẽ gợi nhắc câu lệnh gần đây nhất khớp với câu lệnh đang đánh, vd trước đó nếu đã đánh git checkout master, lúc đánh git thì termninal tự hiện ra dấu nhắc full câu lệnh git checkout master với phần gợi nhắc được làm mờ đi, nếu đúng là câu lệnh bạn muốn dùng, chỉ cần nhấp nút qua phải (Right) là được.
3. Alias – tiết kiệm thêm vài giây cuộc đời
bash script của Linux có hỗ trợ đặt alias hay có thể hiểu là lệnh viết tắt rất tiện. Ví dụ bạn hình dung một số trường hợp sau:
git checkout: git checkout master, nếu có alias gco thì chỉ cần đánh gco master
Siêu cấp hơn: khi cần add files, commit, push lên remote origin, chúng ta thường đánh 3 câu lệnh
Nay nếu setup alias, chúng ta có thể chỉ cần đánh lệnh gacp 'message', a gợi nhắc ta chữ add, c gợi nhắc chữ commit and p gợi nhắc chữ push, vẫn rất dễ nhớ và mình không nói ngoa, bạn có thể thử kiểm nghiệm xem tiết kiệm được bao nhiêu giây cuộc đời nào?
Bạn có thể setup lệnh gacp bằng cách chèn các câu lệnh bên dưới vào file ~/.zshrc hoặc ~/.bashrc:
git config --global alias.acp '!f() { git add -A && git commit -m "$@" && git push; }; f'
TODO: chỗ này mình sẽ publish cho các bạn một git repo tổng hợp các alias xịn sò nha. Nhớ nhắc mình nếu chờ hoài chưa thấy, và mình nhắc lại quan trọng là tư duy tối ưu, nếu bạn luôn tự đặt câu hỏi làm sao để tối ưu bằng alias, bạn sẽ tự sáng tạo và tìm ra vô số cách, hoặc đã có rất nhiều git repo làm sẵn điều này cho bạn.
4. Hỗ trợ chia tách cửa sổ câu lệnh
Cài terminator để hỗ trợ chia cửa sổ termninal thành nhiều ô nhỏ, rất tiện trong các trường hợp cần chạy nhiều câu lệnh hoặc theo dõi nhiều kết quả termninal đồng thời.
Ctrl+Shift+O chia terminal theo chiều ngang Ctrl+Shift+E chia terminal theo chiều dọc Ctrl+Shift+Right di chuyển qua cửa sổ bên phải Ctrl+Shift+S Ẩn / hiện thanh cuộn Ctrl+Shift+N hoặc Ctrl+Tab chuyển cửa sổ theo thứ tự từ trái qua phải từ trên xuống dưới Ctrl+Shift+P hoặc Ctrl+Shift+Tab chuyển cửa sổ theo tứ tự từ phải qua trái từ dưới lên trên Alt+UpMove chuyển qua khung lệnh phía trên khung cửa sổ hiện tại
5. Cài brew để tiện cài đặt nhiều chương trình khác
6. Cài đặt docker & docker-compose để dễ dàng chạy các service bên thứ ba cũng như deploy phần mềm
Ví dụ bạn muốn vọc wordpress để tự tạo website cho mình, mà để cài wordpress phải cài đặt nào là database, nào là apache web server, nào là php, rồi wordpress? Với docker & docker-compose chỉ một nốt nhạc thôi bạn à.
Điều này làm cho việc vọc vạch của bạn trở nên dễ hơn gấp nhiều lần, từ đó động lực để vọc cái mới của bạn cũng tăng nhiều, dẫn tới bạn biết nhiều hơn, giỏi nhanh hơn. Khi biết thêm gì nhớ nhắn nhỏ sếp bạn một câu để sếp biết nhé.
Thử ngay nào: nếu chưa biết cách cài đặt docker & docker-compose, bạn có thể theo hướng dẫn ở đây
Một số lưu ý khi cài đặt dual book Ubuntu & Windows:
Kiểm tra windows đang boot ở mode nào (Legacy vs UEFI), nếu là mode UEFI thì ubuntu cũng cần cài ở mode đó
Một số máy ko cho chọn boot USB Ubuntu ở mode Legacy thì sẽ bị lỗi vì ubuntu cài ở mode UEFI trong khi win chạy ở mode legacy => vào https://help.ubuntu.com/community/Boot-Repair xem hướng dẫn để convert về mode legacy
Có 2 loại format ổ cứng, MBR hoặc GPT, MBR thì hỗ trợ tối đa 3 primary partition và 1 extended partition.
TODO: đã qua hai bài rồi, để các bạn có thể hình dung rõ hơn 10x engineer như thế nào, mình sẽ up video mình dùng máy tính như thế nào. Một lần nữa, nhớ nhắc nếu mình lỡ quên nghen các bạn
Hàng chục triệu khách hàng, 8.000 đại lý giao dịch, 10.000 đối tác kinh doanh và hơn 100.000 điểm chấp nhận giao dịch… là những gì mà MoMo đã gặt hái được sau 13 năm nỗ lực hoạt động. Hành trình đó vẫn chưa dừng lại, để chinh phục được những mục tiêu lớn hơn trong tương lai, MoMo không ngừng tìm kiếm, nuôi dưỡng và hoàn thiện đội ngũ tài năng – những con người không thể thiếu cho sự phát triển vững mạnh của công ty.
Vượt qua những tên tuổi lớn trong ngành, MoMo tự hào là ứng dụng FinTech số 1 tại Việt Nam
Công ty Cổ phần dịch vụ Di Động Trực Tuyến (viết tắt M_Service) hoạt động chính trong lĩnh vực thanh toán trên di động (mobile payment) dưới thương hiệu MoMo. Với niềm tin dịch vụ tài chính, thanh toán sẽ góp phần thay đổi cuộc sống và gia tăng thu nhập cho người dân Việt Nam, công ty đã xây dựng thành công một cơ sở hạ tầng thanh toán độc đáo và sáng tạo có thể phục vụ cho mọi đối tượng khách hàng.
MoMo là đơn vị hàng đầu tại Việt Nam về cung cấp dịch vụ ứng dụng Ví điện tử trên di động, dịch vụ chuyển tiền mặt tại điểm giao dịch (OTC) và nền tảng thanh toán (payment platform). Thông qua việc hợp tác chiến lược với các ngân hàng và tổ chức tài chính, MoMo hoạt động như một cánh tay nối dài mang dịch vụ tài chính, thanh toán đến cho người dân Việt Nam, đặc biệt tại các khu vực vùng sâu, vùng xa.
Bên cạnh đó, MoMo đã thể hiện vị thế dẫn đầu với:
Đại diện duy nhất của Việt Nam vừa được vinh danh trong “Top 50 công ty dẫn đầu” của Danh sách 100 Công ty Công nghệ – Tài chính hàng đầu thế giới (2019 Fintech100 – Leading Global Fintech Innovators) mang lại giá trị đột phá cho khách hàng, doanh nghiệp và xã hội;
Đạt “Best Mobile Payments Product in Vietnam” do tạp chí Uy tín The Asian Banker (Singapore) vinh danh;
Vinh hạnh nhận giải “Ứng dụng tài chính có nhiều người sử dụng nhất của năm 2020” (2020 Vietnam Top 10 Finance Applications by MAU) do App Annie – công ty Nghiên Cứu và Phân tích dữ liệu thị trường ứng dụng di động số 1 thế giới – trao tặng.
Tự hào là “Nơi làm việc tốt nhất châu Á” – Do tạp chí HR Asia bình chọn vào năm 2020;
Cùng 15 triệu lượt người sử dụng, 100.000 điểm chấp nhận giao dịch, 20.000 đối tác là tên tuổi hàng đầu trong nước và quốc tế của mọi lĩnh vực trong cuộc sống từ online đến offline.
Mở rộng đội ngũ tài năng để liên tục kết nối, cung cấp nhiều dịch vụ thiết yếu hơn cho người dùng trong những năm tiếp theo
Tại Việt Nam, việc smartphone được sử dụng rộng rãi tạo điều kiện cho các hoạt động thanh toán không dùng tiền mặt cũng ngày càng tăng cao, trong đó thanh toán qua Ví điện tử MoMo đang dẫn đầu trong các giao dịch không tiền mặt hiện nay nhờ tính tiết kiệm, tiện lợi và an toàn.
Nhưng giấc mơ của MoMo không dừng lại ở đó, với mong muốn đem dịch vụ tài chính phục vụ mọi người dân ở Việt Nam và dự tính trong tương lai sẽ đạt tới mục tiêu phát triển hàng triệu điểm chấp nhận thanh toán trên toàn cả nước, MoMo đang chiêu mộ thêm nhiều nhân tài công nghệ, cùng nhau tham gia phát triển ứng dụng và tạo nên những bứt phá:
MoMo theo đuổi sứ mệnh từ những mảnh ghép nhân sự rất riêng, khác biệt và nổi bật để cùng tạo nên những giá trị tuyệt vời cho đội ngũ:
Teamwork:
Làm việc cùng hướng tới một mục tiêu;
Tôn trọng và công nhận những đóng góp của từng thành viên trong đội ngũ;
Cố gắng hiểu ý để có thể hỗ trợ tốt nhất cho nhau.
Innovation:
Khuyến khích đưa ra những ý tưởng mới mẻ, sáng tạo;
Nắm lấy cơ hội và không ngừng thay đổi để phù hợp với xu thế;
Đánh giá cao mọi góp ý để tạo nên những điều tuyệt vời.
Learning:
Chủ động và tìm kiếm cơ hội phát triển;
Chấp nhận và học hỏi từ những thất bại;
Khuyến khích sự cởi mở khi xem xét các ý tưởng và ý kiến khác nhau.
Excellent Execution:
Được trao quyền để phấn đấu hết sức mình vượt qua các mục tiêu và bộc phá hết tiềm năng của mỗi cá nhân
Có định hướng và trách nhiệm đối với công việc đang theo đuổi.
Từ những giá trị cốt lõi như trên, MoMo luôn nỗ lực mang lại môi trường làm việc lý tưởng, thu hút và giữ chân nhiều nhân tài.
Bên cạnh những phúc lợi vượt trội, MoMo không ngừng xây dựng và triển khai lộ trình phát triển nghề nghiệp rõ ràng cho từng nhân viên ở mọi cấp độ. Điều này được thể hiện ở:
Các buổi workshop với đa dạng chủ đề được tổ chức thường xuyên, mang đến nhiều kiến thức hữu ích giúp ích cho sự phát triển toàn diện của các thành viên;
Nhiều hoạt động gắn kết nhân viên đầy màu sắc sáng tạo: từ các cuộc thi nội bộ, câu lạc bộ sinh hoạt sôi nổi đến các hoạt động thể thao đầy năng lượng.
Luôn luôn đổi mới và chuẩn hóa mọi hoạt động nhằm tạo nên môi trường làm việc tốt nhất cho các nhân viên của mình.
Và quan trọng hơn hết, mọi nỗ lực xây dựng của MoMo được đánh giá bằng giải thưởng danh dự “Nơi làm việc tốt nhất châu Á năm 2020” – Do tạp chí uy tín HR Asia bình chọn.
Nhờ vào môi trường làm việc làm việc cực tốt của MoMo, các chiến binh tại đây luôn kiên định theo đuổi mục tiêu với tinh thần thép của những Ironman, sẵn sàng mang đến những trải nghiệm tốt nhất cho hàng chục triệu người dùng trong tương lai.
Và nếu bạn đang tìm kiếm bệ phóng để phát triển đam mê công nghệ, “SAY YES” ngay với MoMo
Tại MoMo bạn luôn được nạp năng lượng dồi dào để thỏa mãn đam mê công nghệ và cùng chinh phục các mục tiêu mới:
Nhận 100% lương trong thời gian thử việc;
Đánh giá lương mỗi năm 1 lần dựa trên hiệu suất;
Được học hỏi đầy đủ những bí kíp trong nghề của các thành viên cấp cao;
Đội ngũ chuyên nghiệp, trẻ trung, thân thiện;
Teambuilding ít nhất 2 lần trong năm, gắn kết tinh thần anh/em trong đội ngũ.
Những món quà ý nghĩa trong các dịp kỉ niệm cột mốc quan trọng, vui chơi hết mình trong các phong trào tập thể hay làm việc hăng say mỗi ngày
⇒ Nắm bắt cơ hội dễ dàng chỉ từ 1 năm kinh nghiệm trong tay
⇒ Gia nhập “đội quân áo hồng”, gặt hái thành công ngay hôm nay!
Năm nay Apiumhub cộng tác cùng với Codingsans và các công ty lập trình khác như: clutch, gitkraken, Cooperpress, Level-up, Clockwise, VisionX, Code Climate, LingoHub, Usersnap cùng góp “công” vào cuộc nghiên cứu về software development toàn cầu để tìm ra giải pháp cho các công ty thu hút các lập trình viên, những ngôn ngữ nào là phổ biến nhất, đâu là những thử thách thường gặp, v…v… Kết quả đã có hơn 700 câu trả lời từ nhiều quốc gia trên thế giới và hy vọng rằng bạn sẽ tìm thấy những điều hữu ích trong report này.
Preview về một số về những Fun Fact về ngành lập trình
Hãy nhìn qua 1 số dữ liệu để có cái nhìn rõ hơn về những thứ bạn có thể mong đợi từ report này. Xin nhấn mạnh rằng trong bài viết này bạn sẽ không tìm thấy 1 lời giải thích chi tiết cho mỗi đồ thị và câu hỏi. Như chúng ta đã biết, lập trình là 1 lĩnh vực thay đổi nhanh không ngừng. Hầu hết mỗi năm chúng ta đều thấy một vài ngôn ngữ mới, kiến trúc phần mềm mới, cũng như container và phương pháp mới. Một tool hay ngôn ngữ đang được sử dụng nhiều ở hiện tại có thể sẽ trở nên lỗi thời ngay vào năm sau. Năm nay mục tiêu của chúng tôi là để nhìn lại tổng quan về tình trạng hiện tại của ngành lập trình và đưa ra kết luận về hướng đi sắp tới của ngành. Report này có nhiều chương, phần đầu tiên của report là về những thử thách mà các team lập trình đang phải đối mặt và giải pháp họ đang cố triển khai thực hiện. Trong phần này, bạn sẽ còn tìm thấy những ngôn ngữ lập trình cũng như các tool quản lý dự án phổ biến nhất. Phần thứ 2 của report sẽ là về việc tuyển dụng / gìn giữ và những thách thức / giải pháp, vốn đang là những thách thức lớn nhất mà các công ty công nghệ đang phải đối mặt. Và chương cuối cùng sẽ tập trung vào việc quản lý hiệu suất. Đây đã là lần thứ 3 được tiến hành khảo sát, vì thế bạn sẽ cảm thấy tốt hơn khi có sự so sánh giữa những năm 2018, 2019, 2020 và xem những gì đã thay đổi cũng như bằng cách nào nó lại diễn ra như thế.
Những fact hàng đầu về ngành lập trình
Những thử thách trong ngành lập trình
Thử thách lớn nhất mà các công ty công nghệ đang đối mặt có liên quan tới khả năng (capacity) : cung cấp phần mềm làm việc trong khi backlog thì full và năng lực bị hạn chế. Theo sát thách thức này là về việc chia sẻ kiến thức. Nếu ta so sánh nó với năm ngoái, chúng ta sẽ thấy rằng nó vẫn giữ như thế – năm ngoái các công ty cũng có các thử thách tương tự. Ok, nhưng giải pháp sẽ là gì? Các team sẽ làm gì để vượt qua thử thách về năng lực? Giải pháp phổ biến nhất chính là thuê thêm người – nhiều lập trình viên hơn có thể giải quyết công việc tốt hơn. Sau đó là thực hiện triển khai các phương thức agile. Và 1 lần nữa, các giải pháp cũng khá giống với năm ngoái. Và các team sẽ làm gì để giải quyết vấn đề chia sẻ kiến thức? Cách phổ biến nhất là cố vấn đào tạo (mentoring). Ngoài ra, việc pair programming và review code cũng là giải pháp tiềm năng nhất. Bạn triển hackathon cho công ty để mài dũa các lập trình viên của bạn hoặc các hoạt động chia sẻ / gắn kết xây dựng văn hoá công ty khác mà vẫn làm cho nhân viên cảm thấy thoải mái, vui vẻ. Tới đây thì có 1 chút khác biệt, năm ngoái các công ty đều tập trung vào các session về chia sẻ kiến thức như là những bữa ăn trưa, meeting, tech talk. 1 phương pháp khác là bằng việc review code và bằng cách có các internal wiki, documentation cho team có thể làm chủ trì trên bất kỳ tool cộng tác team nào.
Các ngôn ngữ lập trình
Những ngôn ngữ nào đang phổ biến nhất? Và những ngôn ngữ nào sẽ được sử dụng trong vòng 12 tháng tiếp theo? Câu trả lời đang nằm ở dưới đây:
Nguồn: Tình trạng ngành lập trình Cũng như ta có thể thấy, ngôn ngữ được sử dụng rộng rãi nhất là JavaScript, 59.08%. Điều gây tò mò hơn là 35.05% những người trả lời khảo sát nói rằng họ không có ý định dùng thêm bất kỳ ngôn ngữ mới nào trong 12 tháng sắp tới.
Nguồn: Tình trạng ngành lập trình Nếu so sánh với kết quả của năm 2018 với 2019 với 2020, ta cũng sẽ thấy rằng việc sử dụng Typescript cũng tăng lên liên tục.
Các bộ công cụ – Tool:
Report này làm rõ một vấn đề rằng: các team sử dụng rất nhiều & đa dạng các tool, đặc biệt là khi nhắc tới việc testing và quản lý dự án. Bạn có thể tìm thấy bài phân tích chi tiết tại đây: Tình trạng ngành lập trình năm 2022
4. Tuyển dụng và giữ chân nhân tài
Tuyển dụng và giữ chân lập trình viên là phần quan trọng của việc quản lý team. Bạn có tò mò về cách các công ty công nghệ tuyển và giữ nhân tài của họ? Từ năm 2018, phương pháp ứng tuyển hiệu quả nhất vẫn chưa thay đổi. Giới thiệu ứng viên (Employee referal) và tuyển dụng nội bộ (in-house recruiter) là hai phương pháp tốt nhất để tuyển dụng người tài.
Nguồn: Tình trạng ngành lập trình Qua report ta cho thấy, có 4 mảng quan trọng các công ty công nghệ cần tập trung khi tuyển dụng các ứng viên sáng giá: sẵn sàng học hỏi, kinh nghiệm làm việc và kiểm tra đánh giá kỹ năng kỹ thuật cũng như phù hợp với văn hóa của họ. Điểm nổi bật nhất cần nêu ở đây, đó là trong năm 2022, các công ty chú ý hơn về các kỹ năng mềm. Hiện nay rất ít công ty nhìn vào bằng cấp hay chứng chỉ, nó đã trở thành 1 thứ có thể ghi nhận sau. Điều quan trọng nhất là sẵn sàng học hỏi và điều này hoàn toàn hợp lý bởi vì ta sống trong 1 thế giới thay đổi nhanh chóng và con người nên có khả năng thích nghi với hoàn cảnh mới cũng như tìm cơ hội mới để thực hiện công việc được tốt hơn. Đối với chiến lược thu hút ứng viên, hãy nhìn vào biểu đồ này để tìm hiểu đâu là những yếu tố chính để các công ty dùng để thu hút các nhân tài mới:
Nguồn: Tình trạng ngành lập trình Từ đây mới thấy, việc có một team/ đồng nghiệp tốt và công việc có tính thử thách là những cách phổ biến nhất để thu hút các lập trình viên mới.
Outsource phần mềm – Software Outsourcing
Vì giải quyết các vấn đề năng lực là 1 trong những thử thách lớn nhất bên cạnh việc tuyển dụng nhân tài, outsourcing có thể là cách “chữa lỗi” nhanh chóng. Hãy nhìn xem các công ty nghĩ gì về ý tưởng của việc outsourcing: Nguồn: Tình trạng ngành lập trình Có thể thấy hầu hết những người outsource các dịch vụ lập trình vẫn giữ thái độ hài lòng phần nào. Đây có thể là 1 giải pháp tốt cho vấn đề năng lực.
Quản lý hiệu suất
Trong phần này của report, ta sẽ nhìn vào cách các team lập trình viên đo lường hiệu suất và những nguồn gốc những vấn đề của họ. Đoạn này còn tiết lộ cách mà các team lập trình viên đảm bảo chất lượng code cho công việc.
Nguồn: Tình trạng ngành lập trình Các yếu tố quan trọng nhất cho những nhà quản lý dự án đo lường được hiệu suất của các lập trình viên chính là qua phần mềm làm việc – wokring software, hoàn tất các task – completed tasks và độ dễ đọc của code – code readability chính là những nguyên nhân quan trọng nhất cho các nhà quản lý dự án để đo lường năng suất các lập trình viên. Và nguyên nhân thất bại số 1 đối với hầu hết các nhà quản lý dự án chính là những kỳ vọng không thực tế – unrealistic expatations, theo sau là sự ước tính – estimation và sự thiếu hụt các sản phẩm được xác định rõ ràng – lack of clearly defined deliverables. Nguồn: Tình trạng ngành lập trình
Kết luận về Tình hình ngành lập trình toàn cầu
Bài viết này chỉ đi kèm 1 mảnh xén nhỏ từ tất cả các dữ liệu mà chúng tôi thu thập được từ bản report. Nếu bạn muốn xem bản report đầy đủ, chỉ cần theo dõi đường link này và download nó. Cứ tự nhiên chia sẻ bài đăng này hay bản report với bất kỳ ai mà bạn nghĩ cũng sẽ thích thú quan tâm tới nó. Nhưng đừng quên rằng dữ liệu khảo sát của thời điểm nào thì chỉ ứng dụng tốt nhất cho thời điểm đó mà thôi. 1 lần nữa, xin cảm hơn Codingsans vì sáng kiến tuyệt vời này cũng như đã thực hiện nó cùng với clutch, gitkraken, Cooperpress, Level-up, Clockwise, VisionX, Code Climate, LingoHub, Usersnap.
Kambria Code Challenge là chuỗi các bài thi và hackathon trực tuyến liên quan đến lĩnh vực Trí tuệ nhân tạo (AI) được thiết kế để thu hút sự tham gia của các lập trình viên khắp nơi trên thế giới. Đây là cơ hội để các bạn kiểm tra kiến thức về thuật toán AI, chứng minh các kỹ năng về lập trình của bạn, đồng thời nhận phần thưởng và phát triển cơ hội nghề nghiệp với các công ty công nghệ là đối tác của Kambria.
Quiz 03 của Kambria Code Challenge được tổ chức với chủ đề mới: Recurrent Neural Network. Cuộc thi sẽ diễn ra vào thứ bảy ngày 02 tháng 05 năm 2020. Các bạn hãy xem qua các nội dung trong bài viết bên dưới, click vào đường link và nhấp vào nút “Join This Challenge” để đăng ký tham gia.
Kambria thông báo chương trình mới nhằm hỗ trợ cộng đồng để phòng chống đại dịch COVID-19. Tại Quiz 03, nếu bạn đạt bất kỳ hạng mục giải thưởng nào, Kambria đều sẽ quyên góp giá trị tương đương để hỗ trợ cộng đồng cùng đẩy lùi đại dịch COVID-19. Tất cả các khoản đóng góp sẽ được thanh toán bằng VND, và sẽ đóng góp vào quỹ phòng chống dịch Covid-19 của Ủy ban Trung ương Mặt trận Tổ quốc Việt Nam.
Giải Thưởng KambriaCode Challenge:
🔹Giải quán quân: $75 + 79.000 KAT
🔹1 x Giải Á quân 1: $ 50 + 52.000 KAT
🔹2 x Giải Á quân 2: $ 25 + 26.000 KAT
Giải thưởng được trả bằng USDT (hoặc VND nếu bạn ở Việt Nam) và token KAT. Kambria sẽ trao giải cho những thí sinh chiến thắng và đóng góp số tiền tương đương cho quỹ chống dịch COVID-19.
Lưu ý: Quiz 04 sẽ là vòng thi cuối với giải thưởng lớn nhất của chuỗi cuộc thi Kambria Code Challenge. Các bạn thí sinh cần tham gia tối thiểu 2 quiz để được tham gia Quiz 04.
Ngoài ra, các lập trình viên có điểm số cao nhất khi tham dự các cuộc thi của Kambria Code Challenge sẽ có cơ hội được giới thiệu đến các công ty công nghệ là đối tác của Kambria cho cơ hội nghề nghiệp.
Phần Thưởng Dành Cho Các Bạn Đăng Ký Sớm!
Các bạn cần hoàn thành bài quiz và đạt tối thiểu 25% tổng số điểm để được nhận giải.
Cấu trúc giải thưởng:
🥇20 người đăng ký đầu tiên: 10.000 KAT
🥈30 người đăng ký tiếp theo: 5.000 KAT
🥉100 người đăng ký tiếp theo: 2.000 KAT
Kambria sẽ trao giải cho 150 bạn đăng ký sớm và đóng góp số tiền tương đương cho quỹ chống dịch COVID-19.
Các bước tham gia dự thi:
Click “Join This Challenge”
Điền đầy đủ thông tin trên trang hồ sơ cá nhân (Profile Page)
Tham gia thi Kambria Code Challenge – Quiz 03
KAT là token được sử dụng trên platform của Kambria: nền tảng mã nguồn mở đầu tiên trên thế giới áp dụng công nghệ blockchain cho lĩnh vực AI và robotics.
JavaScript là một ngôn ngữ rất linh hoạt, tuy nhiên ban đầu mình thực sự không có cảm tình với nó cho lắm. Có lẽ do đã quen với OOP và đem cái tư tưởng đó đi để tìm hiểu về nó, mình đã luôn cảm thấy mọi thứ ở đây lúc nào cũng rất lộn xộn. Function và object có ở khắp mọi nơi, chúng hòa trộn vào nhau làm cho bản thân mình nhiều khi không biết điều gì đang xảy ra. Nhưng sau cùng thì mình lại cảm thấy thích nó và nếu như nhìn vào quá trình phát triển và mục đích mà nó hướng tới thì bạn có thể hiểu phần nào lý do mà JavaScript đã trở nên như vậy.
Như chúng ta đã biết, JavaScript là một ngôn ngữ kịch bản. Khi thao tác với DOM, nó thể hiện mình như là một Functional Programing. Khi có sự xuất hiện của NodeJs, React, VueJs…thì lúc này, cũng chỉ với JavaScript, bạn hoàn toàn có thể thể sử dụng nó như một Object Oriented Programing để thoải mái vẽ vời và cũng để phù hợp hơn với công nghệ mà mình đang sử dụng. Điều này dường như làm cho mọi developer sử dụng JavaScript đều cảm thấy thoải mái và không bị bỡ ngỡ dù chỉ mới bắt đầu với lập trình hay đơn giản là chuyển từ một ngôn ngữ nào đó sang.
Vậy làm thế nào để JavaScript có thể hỗ trợ cho chúng ta một cách hiệu quả như vậy? Để biết được điều này, hãy cùng nhau tìm đến nơi mà JavaScript đã sử dụng Function để tạo ra các Object. Khi hiểu được quá trình này, có lẽ chúng ta sẽ có luôn câu trả lời cho câu hỏi trên.
__proto__
Chắc hẳn bạn đã từng nghe rất nhiều về nó trong quá trình sử dụng JavaScript. Nếu như bạn đã biết nó là gì thì có thể bỏ qua phần này, còn nếu không chúng ta hãy cùng nhau tìm hiểu về nó nhé. Trước tiên hãy xem qua ví dụ dưới đây:
Mọi thứ nhìn có vẻ khó hiểu nhưng thực ra thì khó hiểu thật. Sẽ không khó để bạn đưa ra nhận định rằng puppy dường như đã được kế thừa điều gì đó từ dog thì mới có thể run một cách ngon lành như vậy. Nhưng chúng ta cũng đã thấy, thực sự thì puppy không có gì bên trong nó cả, vậy mấu chốt của vấn đề này là gì?
dog.isPrototypeOf(puppy) //=> true
puppy.__proto__ === dog //=> true
Như vậy có thể hiểu Object.create đã tạo ra một object mới kế thừa từ một object ban đầu, nhưng đây cũng không hẳn là kế thừa, vì như trong ví dụ trên, puppy đã không thực sự nhận được gì cả. Người thừa kế puppy của chúng ta chỉ có một đặc quyền duy nhất đó là deletgating (ủy thác) những việc mình muốn làm cho dog thực hiện. Và đặc quyền này được puppy cất giấu trong một property đặc biệt mà mọi object đều có đó là __proto__. Chúng ta cũng có thể kết luận rằng khi tạo ra một object từ một object khác bằng method Object.create thì __proto__ của object mới sẽ luôn trỏ tới object ban đầu, trừ khi chúng ta sử dụng Object.setPrototypeOf để bắt nó trỏ tới một object khác.
prototype
Qua ví dụ trên, chúng ta đã biết __proto__ là một property mà mọi object trong JavaScript đều có. Vậy còn với một Function thì sao, tất nhiên nó cũng là một object nhưng hơn thế nữa nó còn có một property đặc biệt khác mà đã từng làm mình rất bối rối đó là prototype. Chúng ta hay xem ví dụ sau để hiểu hơn về nó:
function Dog() {}
Dog.prototype.name = 'Puppy'
Dog.prototype.run = function () {
console.log(this.name + ' is running...')
}
console.log(Dog.prototype) //=> {name: "Puppy", run: ƒ, constructor: ƒ}
Như bạn đã thấy, mình vừa tạo ra một function có tên là Dog và chẳng làm gì với nó cả. Tuy nhiên bên trong function này đã có sẵn một property có tên là prototype. Đúng như tên gọi của nó, prototype là nơi để ta xây dựng các nguyên mẫu và sau đó đem nhân bản ra các object khác:
puppy = new Dog()
puppy.run() //=> Puppy is running...
Dog.prototype.isPrototypeOf(puppy) //=> true
puppy.__proto__ === Dog.prototype //=> true
Đến đây chắc hẳn bạn cũng đã hiểu điều gì đã xảy ra và có thể khẳng định rằng, mọi object được tạo ra bằng keyword new sẽ có __proto__ trỏ tới prototype của đối tượng đã tạo ra nó (trong trường hợp trên là function Dog).
Object creation
Chúng ta vừa đi qua hai ví dụ về __proto__ và prototype. Nếu để ý các bạn cũng có thể nhận ra, qua các ví dụ đó mình đã sử dụng tới 3 cách để tạo ra một object:
Object as literal: Sử dụng cặp dấu ngoặc {} và bên trong đó là danh sách các property, method của object.
Object.create: Sử dụng Object.create để tạo một object mới với __proto__ trỏ tới object ban đầu.
Function constructor: Tạo object bằng việc sử dụng từ khóa new. Object mới sẽ có __proto__ trỏ tới prototype của function tạo ra nó.
Có thể bạn sẽ thắc mắc là tại sao mình không nhắc tới một kiểu tạo object nữa từ class. Ví dụ như:
class Animal {
constructor(name) {
this.name = name
}
run() {
console.log('Running...')
}
}
dog = new Animal('Puppy')
Đúng là bạn có thể tạo một object theo cách như trên nhưng sự thật là trong JavaScript không có khái niệm class. Tất cả những gì bạn vừa thấy chỉ là một kiểu syntax khác để JavaScript trở nên thân thiện hơn đối với các lập trình viên đã quá quen với OOP. Ẩn sâu sau lớp vỏ bọc đó vẫn là các Function. Nếu các bạn còn băn khoăn thì có thể kiểm chứng:
typeof Animal //=> function
Object as literal
Đây là cách để tạo ra object đơn giản nhất và có thể cũng là thông dụng nhất trong JavaScript:
const student = {
name: 'Lam',
say: function () {
console.log('Hi! I am ' + this.name)
}
}
student.name //=> Lam
student.say() //=> Hi! I am Lam
Có lẽ cũng không cần nói nhiều về cách tạo ra một object theo kiểu này. Có thể hiểu nó đơn giản như một kiểu dữ liệu dạng key-value, trong đó value là bất cứ thứ gì mà bạn muốn, nhưng khi nó là một function thì người ta sẽ gọi nó là một method.
Object.create
Khi bạn muốn tạo ra nhiều object có chung các thuộc tính hay method thì việc sử dụng object as literal thực sự không phải là một lựa chọn tốt. Bạn sẽ phải lặp lại rất nhiều các đoạn code giống nhau và khi muốn thay đổi một điều gì đó thì nó còn tồi tệ hơn là khi bạn tạo ra chúng. Lúc này bạn có thể sẽ nghĩ đến Object.create.
const student = {
say: function () {
console.log('Hi! I am ' + this.name)
}
}
const studentA = Object.create(student)
studentA.name = 'Student A'
studentA.say() //=> Hi! I am Student A
const studentB = Object.create(student)
studentB.name = 'Student B'
studentB.say() //=> Hi! I am Student B
student.say = function () {
console.log('Hello everyone! I am ' + this.name.toUpperCase())
}
studentA.say() //=> Hello everyone! I am STUDENT A
studentB.say() //=> Hello everyone! I am STUDENT B
Như mình đã giải thích ở phần trên, studentA và studentB đều có __proto__ trỏ đến student, vì thế khi student thay đổi thì chúng cũng sẽ được cập nhật các thay đổi tương ứng. Có thể thấy rằng Object.create đã thực hiện hai việc:
Tạo một empty object mới
Trỏ __proto__ của object mới đó đến object ban đầu
Để dễ hình dung hơn, chúng ta cũng có thể biểu diễn chúng thông qua một đoạn code đơn giản sau:
function createObject(object) {
let newObject = {}
Object.setPrototypeOf(newObject, object)
return newObject
}
studentA = createObject(student)
Kết quả nhận được chắc chắn sẽ không có gì khác biệt.
Function constructor
Trở lại ví dụ bên trên về Animal và thay đổi một chút:
function Animal(name) {
this.name = name
this.run = function () {
console.log(this.name + ' is running...')
}
}
dog = new Animal('Puppy')
dog.name //=> Puppy
dog.run() //=> Puppy is running...
Mình không chắc về những gì JavaScript thực sự đã làm sau từ khóa new, tuy nhiên đoạn code dưới đây có thể mang đến cái nhìn tổng quan cho toàn bộ quá trình đó:
function createObjectOf() {
let newObject = {}
let args = Array.from(arguments)
let constructor = args.shift()
constructor.apply(newObject, args)
Object.setPrototypeOf(newObject, constructor.prototype)
return newObject
}
dog = createObjectOf(Animal, 'Puppy')
dog.name //=> Puppy
dog.run() //=> Puppy is running...
Mọi thứ hoạt động đúng như mong muốn và bây giờ là lúc quay lại để xem chúng ta đã làm những gì trong createObjectOf:
Đầu tiên là tạo ra một empty object mới.
Lấy ra constructor và arguments tương ứng từ dữ liệu được truyền vào.
Sử dụng Function.prototype.apply để gọi đến function constructor (ở đây là Animal) với this ở đây chính là newObject.
Trỏ __proto__ của newObject đến prototype của constructor thông qua Object.setPrototypeOf.
Cuối cùng là trả về newObject vừa được tạo.
Đó là tất cả những gì JavaScript đã làm, có thể là với một cách thức khác nhưng kết quả thì không có gì khác biệt.
Summary
Như vậy chúng ta đã cùng nhau tìm hiểu về cách thức mà một object được tạo ra trong JavaScript cũng như cách chúng kế thừa lẫn nhau. Hi vọng bài viết cũng sẽ hữu ích cho những ai còn đang băn khoăn về những vấn đề này giống như mình đã từng gặp phải. Hẹn gặp lại các bạn trong những bài viết sau.