Ngoài hơn 900 kỹ sư công nghệ thông tin đang tham gia trên các mặt trận, nhóm thông tin phản ứng nhanh chống dịch covid-19 của ban chỉ đạo quốc gia cần khẩn cấp theo thứ tự các vị trí tech quan trọng, các bạn làm trong lĩnh vực công nghệ – lập trình có thể tham khảo phía dưới các danh sách mà các đơn vị chống dịch đang cần gấp và cân nhắc tham gia nhé, Việt nam đang cần chúng ta.
1. Ban Chỉ đạo Quốc gia chống dịch
2️⃣ Open Street Map Engineers (3+ năm kinh nghiệm)
2️⃣ Big Data Engineer có kinh nghiệm về Public Health Data
2️⃣ Hadoop Engineers (3+ năm kinh nghiệm)
1️⃣ Project Managers ((5+ năm kinh nghiệm)
2️⃣ Java Engineer (3+ năm kinh nghiệm)
2️⃣ Documentor ((3+ năm kinh nghiệm)
👉 Làm việc tại Hà nội
👉 Đầu mối liên hệ anh Trung Nguyen
2. Bộ Y tế 👩💻👨💻Chuyên gia Dịch tễ & Thống kê để tham gia nhóm xây dựng và Vận hành mô hình dự báo dịch 👉 Có thể tham gia từ xa 👉 Đầu mối liên hệ anh Duc Anh Ha.
Mọi người có thể chia sẻ và giới thiệu bạn bè để cùng chung tay đẩy lùi dịch bệnh nhé!
Trong bài này, chúng ta sẽ tìm hiểu những kiến thức cơ bản về biến số (Variable) và Hằng số (constants) trong Swift. Và cùng xem xét các hằng số(constants) tại sao chúng được khuyến khích dùng nhiều. Chúng ta bắt đầu tạo mới một playgrounds cho bài viết này, sử dụng nó chính là một cách tuyệt vời để học cú pháp và hiểu các khái niệm cơ bản của Swift. Chạy Xcode 9, tạo mới một playground bằng cách chọn: New-> Playground… từ menu File của Xcode, sau đó nhập tên cho playground và chọn nền tảng iOS, chọn Next, Xong chúng ta bắt đầu code nào.
Biến số(Variables)
Khai báo biến số
Trong Swift, chúng ta sử dụng từ khóa var để khai báo một biến số. Nó cũng tương tự như việc khai báo một biến trong các ngôn ngữ khác vậy, nhưng tôi khuyên bạn không nên nghĩ tới cách khai báo của ngôn ngữ lập trình khác khi sử dụng từ khóa var trong Swift. Vì có một vài sự khác biệt quan trọng ở đây. Từ khóa var là cách duy nhất để khai báo một biến số trong Swift.Từ khóa var được sử dụng phổ biến trong việc khai bào biến và gán giá trị cho biến.
var blogName= “Tự học Swift 5 cùng với cafedevn”
Và chúng ta hãy nhớ một điều là không nên sử dụng dấu ; (semicolon) sau khi kết thúc một dòng code, mặc dù có thể dùng dấu; (semicolon), nhưng trường hợp nào bắt buộc dùng thì chúng ta mới dùng. Bạn có thể để ý biến blogName không có mô tả kiểu dữ liệu khi khai báo biến đó, đó chính là một tính năng của Swift khi khai báo biến, gọi là tính tự suy luận (Inference) kiểu dữ liệu.
Kiểu tự suy luận(Type inference)
Trong ví dụ trên ta thấy biến blogName được gán với trị “Tự học Swift 5 cùng với cafedevn”, Ở đây nếu bạn là một người mới học hoặc đã từ dùng JavaScript hoặc PHP, khi đó bạn sẽ nghĩ Swift là ngôn ngữ không bình thường và lỏng lẻo nhưng sự thât không phải vậy. Hãy để tôi nhắc lại cho bạn rằng Swift là ngôn ngữ để lập trình mạnh và an toàn.
Chúng ta mới bắt đầu và Swift đã cho thấy một vài điều kỳ diệu ở đây. Mặc dùng ví dụ trên không chỉ rõ kiểu dữ liệu nào nhưng biến blogName được hiểu với kiểu là String, đó là kiểu tự suy luận(Type Inference) trong Swift.Giá trị gán cho biến blogName là kiểu String và Swift đủ thông minh để biết được, sau đó chỉ định ngầm biến đó kiểu String.
Ngoài ra chúng ta có thể khai báo một biến tương tự ví dụ trên nhưng theo kiểu tường mình hơn như sau:
var blogName= “Tự học Swift 5 cùng với cafedevn”
Swift yêu cầu bạn phải rõ ràng hoặc ngầm chỉ định kiểu dữ liệu cho biến(Varliable) hay hằng số(constants), nếu không Xcode sẽ thông báo lỗi “Bạn thiếu kiểu dữ liệu cho biến” nếu bạn khai báo như sau:
var number
Để fix lỗi trên thì chúng ta có 2 cách, một là khai báo biến với kiểu tường mình, hai là khai báo và gán cho biến một giá trị cụ thể nào đó.
var number: String
var number = “10”
Thay đổi kiểu dữ liệu
Bạn có thể xem ví dụ bên dưới việc gán mới một trị mới và rất bình thường, chẳng có gì khác biệt.
var blogName : String = “Tự học Swift 5”
var number: String
blogName = “Tự học Swift 5.0000”
number = “10”
Nếu chúng ta gán kiểu số vào biến number, Xcode sẽ thông báo lỗi, rằng chúng ta không thể gán kiểu Int cho biến kiểu String, Đây là một vấn đề lớn của ngôn ngữ lỏng lẻo, nhưng đây là Swift. Swift là ngôn ngữ khá mạnh và an toàn, nên mỗi biến sẽ có một kiểu dữ liệu riêng và chúng ta không thể thay đổi kiểu được.
Vậy để thoát khỏi lỗi đó, thì chúng ta cần phải mô tả lại kiểu cho biến number thành Int như sau:
var blogName : String = “Tự học Swift 5”
var number: Int
blogName = “Cùng học Swift 5.0000”
number = 10
Điều quan trọng, chúng ta phải biết khi khai báo biến trong Swift, chúng ta không cần mô tả tường mình kiểu dữ liệu cho biến hoặc hằng số và mỗi biến hoặc hằng chỉ có một kiểu dữ liệu nhất định, không thể thay đổi kiểu dữ liệu đó.
Hằng số(Constans)
Hằng số(constants) cũng giống như biến số, nhưng nó chỉ có một sự khác biệt duy nhất là không thể thay đổi được giá trị. Giá trị là một hằng số và không thay đổi.
Khai báo hằng số
Để khai báo một hằng số, bạn sẽ dùng từ khóa let. Hãy nhìn vào ví dụ bên dưới, chúng ta sẽ khai báo biến street thay vì dùng var thì chúng ta dùng let.
let blogName : String = “Tự học Swift 5”
var number: Int
blogName = “Cùng tự học Swift 5.0000”
number = 10
Nếu chúng ta chỉ cập nhật dòng đầu tiên var thành let thì Xcode sẽ thông báo lỗi là hằng số thì không thể đổi giá trị. Chúng ta sẽ fix như sau:
let blogName : String = “Tự học Swift 5”
var number: Int
blogName = “Cùng tự học Swift 5.0000”
number = 10
Sử dụng
Tôi hy vọng bạn sẽ đồng ý rằng việc khai báo một hằng số trong Swift thật đơn giản, ở đây không cần các từ khóa rắc rối và phức tạp, cũng như dễ dàng khai báo một biến số vậy.
Việc sử dụng hằng số trong Swift được khuyến khích. Nếu một giá trị không thay đổi hoặc bạn không thay đổi trị khi xử lý, khi đó chúng ta nên dùng hằng số. Đây là một điểm lợi, một điểm lợi trong hiệu suất, nhưng quan trọng hơn là lợi về sự an toàn. Bằng cách dùng biến hằng số ở bất cứ đâu có thể dùng, chỉ cần nó là hằng số thì biến đó sẽ được an toàn, vì trị không bao giờ thay đổi.
In (Print)
Vậy để xem kết quả, hiển thị kết quả ra màn hình console thì chúng ta nên dùng lệnh nào?, Trong Swift, có hỗ trợ hàm print(..) nó cũng tương tự như hàm NSLog() trong Objective-C.
Ví dụ:
var string = “this is a string”
let constant = 3.14
print(string)
print(constant)
print(10 * 50)
print(“Tự học Swift 5.0”)
Hoặc dùng cú pháp \() trong hàm print để hỗ trợ in trị của biến ra console:
Ví dụ:
let blogName = “Tự học Swift 5.0”
let number = 10
print(“Hãy cũng học và chia sẽ tại Blog: \(blogName ) \(number).”)
Biến và hằng là một trong nhưng kiến thức cơ bản mà bạn cần phải nắm thật kỹ khi học và sử dụng ngôn ngữ Swift cũng như các ngôn ngữ lập trình khác, Mặc dù phải mất một ít thời gian để nắm rõ về hằng và biến, một khi bạn đã thực hành tốt nó rồi thì chắc chắn một điều là code của bạn sẽ an toàn và đơn giản để dễ hiểu hơn nhiều. Trong các bài viết tiếp theo chúng ta sẽ tìm hiểu cùng với nhau về hàm(Function) trong Swift.
Nhớ thời đại học quá nên ôn lại kiến thức vỡ lòng mấy bạn ơi
Nếu bạn là người theo chủ nghĩa viết code sao cho chạy được là đủ, bạn không nên đọc bài này. Còn mục tiêu là viết code và đặt cái tâm vào những gì mình viết ra thì bạn nên biết các nguyên tắc nền tảng này.
KISS
Nguyên tắc Keep it simple, stupid được áp dụng cho rất nhiều thứ trong cuộc sống, rất cần thiết cho các dự án từ vừa tới lớn.
Từ lúc bắt đầu code những dòng đầu tiên, chúng ta phải khắc cốt ghi tâm câu đơn giản nhất có thể, code càng phức tạp càng khó viết và đọc lại, càng có khả năng phát sinh bug, càng khó chỉnh sửa sau này. Cụ Antoine de Saint-Exupery có phán câu này:
Hoàn hảo không phải là khi không còn gì để thêm vào nữa, mà là không còn gì có thể bỏ bớt
DRY
Nguyên tắc vàng mà chúng ta nghe mãi nghe mãi. Don’t repeat yourself, không bao giờ để chuyện code chổ này giống hệt chổ kia, copy-paste một đoạn code ở nhiều chổ trong source. Nếu thấy một đoạn code mà cứ viết đi viết lại ở nhiều nơi trong source, người ta sẽ đánh giá trình bạn còn non và xanh lắm
Up up mở mở (Open/Closed)
Biết có thể viết thêm các tính năng bổ sung thoải mái, nhưng không được chỉnh sửa core chính. Cái này có thể lấy ví dụ bạn lấy những package trên npm, nó nằm trong node_modules, sẽ không được chỉnh sửa gì ở đó hết, nếu lỡ sau này người ta update lên, là bạn phải tự cập nhập thủ công nhé.
Hợp thể sẽ mạnh hơn được buff (Composition > Inheritance)
Nếu bạn có xem 5 anh em siêu nhân bạn sẽ hiểu, nếu 5 anh em siêu nhân mà hợp thể lại sẽ tạo ra một con robot với sức mạnh vượt bật, đánh bại mọi cả thể yêu quái, dù nó được buff rất nhiều đồ chơi để tăng dame.
Cái này có ví dụ cho anh em nào viết OOP, mà mình thì không rành OOP lắm, nên anh em tự tìm ví dụ nhé.
Ai làm việc nấy (Single Responsibility)
Mỗi function chỉ thực hiện một nhiệm vụ duy nhất, không ôm đồm nhiều thứ cùng lúc.
Nếu xác định ra đường là đi ăn cơm, thì ăn cơm rồi về, không có sẵn tiền mua thêm bịch chè, ly trà sữa hay vài trứng vịt lộn.
Bớt quan tâm con gái nhà hàng xóm (Separation of Concerns)
Cũng tương tự với ai làm việc nấy, nguyên tắc này có phần trừu tượng, khái quát hơn một chút.
Lấy ví dụ quan hệ trai-gái, để có thể quen một lúc 3 cô, bạn cần lập 3 tài khoản Zalo khác nhau, trên 3 cái điện thoại khác nhau, để khi đi chơi với cô nào thì không bị phát hiện mấy cô kia, đừng dùng 1 tài khoản trên 1 điện thoại mà chat với cả 3 cô cùng lúc.
Lấy ví dụ trong nghề lập trình nó là mô hình thiết kế MVC, còn trong nghề React nó là khái niệm Container và Presentation component. Nhưng anh em cứ nhớ ví dụ 3 cô gái cho dễ.
Bạn là lập trình viên không phải thầy bói (YAGNI – you aren’t gonna need it)
Nguyên tắc này nó nói là, bạn đừng viết ra những hàm mà bạn nghĩ, “ờ, có lẽ trong tương lai chúng ta sớm muộn cũng xài tới nó”. Cái gì cần thì viết, có sao lại viết trước?
Ví dụ, bạn viết sẵn một số lớp abstract và generic để tránh trùng lặp code, mà quá nhiều lớp abstract dẫn đến hậu quả không thể nào mà bảo trì nổi. Nói chung để đảm bảo nguyên tắc DRY, bạn cứ viết trước đi, nếu thấy bị trùng, thầy refactor lại, như ông bà có câu cứ có trâu rồi hả mua chuồng
Tối ưu hóa quá sớm (Avoid Premature Optimization)
Nếu bạn có xu hướng tối ưu các giải thuật được viết ra ngay từ đầu, vấn đề ở chỗ là bạn không thể biết được chương trình sẽ bị nghẽn cổ chai ở đâu cho đến khi có dữ liệu thực tế. Bạn có thể phỏng đoán, tất nhiên là được mà đôi khi hên hên lại đúng. Chỉ có một điều dễ thấy là bạn sẽ bỏ ra không ít thời gian để tăng tốc cho hàm đó, mà thiệt ra nó không chậm tới mức như bạn nghĩ, hoặc mức độ user sử dụng hàm đó sẽ không nhiều.
Hoàn thành những vấn đề mấu chốt trước, sau đó dò lại để biết đang bị thắt cổ chai ở đâu
Refactor, rồi lại Refactor, rồi lại Refactor
Sự thật ai cũng biết là khi bạn mới bắt đầu viết, thời gian sau nhìn lại, khi đã có cái nhìn cụ thể và rõ ràng hơn những gì mình đang làm trong dự án, bạn sẽ code trước đây mình viết thật sự chưa “ngon”. Công việc refactor là rất bình thường. Nếu bạn đang có việc cần thay đổi hoặc kiểm tra code cũ, nếu được thì cứ dọn dẹp một tí trước khi đi.
Thà anh code sạch, chứ anh không cần code cho cao siêu (Clean Code > Clever Code)
Nói về clean code, là phải bỏ đi cái tôi to bự sang một bên, đừng bao giờ nghĩ code thế cho ngầu, code mà để bạn khoe với thiên hạ rằng cách code của tôi mới thông minh hơn.
Ví dụ dễ thấy, một số thanh niên mình từng làm việc chung rất thích dùng câu điều kiện trên một dòng, anh ấy cứ && || && || && các kiểu trên một dòng, ai mà vô đọc thì chỉ có kiếm ảnh để nhờ giải thích là đang muốn làm cái gì.
Tổng kết
9 người thì 10 ý, nếu đi hỏi 9 người với câu hỏi “Thế nào được gọi là một lập trình viên tốt”, thì chắc nhận được không ít sự khác nhau về quan điểm, mà đôi khi còn trái chiều với nhau nữa.
Bạn thấy ý kiến này thế nào, một lập trình viên giỏi là người biết mình đang phục vụ người dùng cuối, người có thể làm việc hiệu quả với đồng đội, người có thể hoàn thành công việc được giao đúng yêu cầu, đúng tiến độ.
Rất ít bộ phận giải quyết nhiều nhiệm vụ hoặc quản lý nhiều thông tin như ngành nhân sự. Công nghệ hỗ trợ thực hiện các nhiệm vụ về tuyển dụng, tính lương và đánh giá hiệu suất, đồng thời cho phép các nhân viên nhân sự làm việc tốt hơn với nhân viên của công ty mình.
Dưới đây là sáu công cụ công nghệ về nhân sự mà bất kỳ doanh nghiệp thuộc mọi quy mô có thể có thực hiện nhằm xây dựng nguồn nhân sự dồi dào và phát triển tổ chức tốt hơn.
1. HRMS (Hệ thống quản lý nguồn nhân lực) hoặc HRIS (Hệ thống thông tin nguồn nhân lực)
Bộ phận nhân sự có rất nhiều thông tin để nhập, lưu trữ và theo dõi. Phương pháp phổ biến nhất để tổ chức thông tin này là thiết lập một hệ thống quản lý nguồn nhân lực toàn diện (HRMS).
Dù cho đó là giải pháp phần mềm hay phần mềm dưới dạng dịch vụ, HRMS có thể là người bạn tốt nhất về mặt nhân sự. Nó lưu trữ và tổ chức dữ liệu, ví dụ như hồ sơ nhân viên, lịch trình, hồ sơ tham dự và nhiều hơn nữa.
Các hệ thống thông tin nguồn nhân lực (HRIS) thường là các giải pháp dựa trên nguồn dữ liệu, cho phép bạn tạo ra các báo cáo chuyên sâu nhằm mục đích kiểm toán.
Phần lớn các dịch vụ HRMS, như Paychex và Workday, chúng hoạt động như nền tảng trung tâm của HR và thường dưới hình thức các mô-đun hoặc tích hợp cho phép người dùng truy cập các dịch vụ trả lương, quản lý lợi ích và đánh giá hiệu suất.
2. Giải pháp về hiệu suất
Các đánh giá và theo dõi về hiệu suất không chỉ là cuộc họp thường niên giữa người giám sát và nhân viên, mà còn được thể hiện thông qua việc các mục tiêu được thảo luận trong cuộc họp đó cần được xem xét lại trong suốt quá trình bởi HR. Để đánh giá hiệu suất và xây dựng mục tiêu tốt hơn cho từng nhân viên, HR có thể cung cấp cho người quản lý các công cụ giúp theo dõi hiệu suất của nhân viên trong suốt cả năm, lưu các ghi chú và phản hồi để chuẩn bị đánh giá cho cả người quản lý và nhân viên. Nhiều giải pháp HRMS và bảng lương, chẳng hạn nhưADP, đi kèm với một mô-đun đánh giá hiệu suất tùy chỉnh.
3. Phần mềm tuyển dụng
Đúng như tên gọi, phần mềm tuyển dụng giúp hợp thức hóa quy trình tuyển dụng. Bạn có thể đăng quảng cáo việc làm, sắp xếp và thực hiện các ứng dụng, quản lý ứng viên và nhiều hơn thế, giúp tiết kiệm cho bạn những rắc rối phát sinh khi tự mình giải quyết mọi thứ.
Đối với các doanh nghiệp nhỏ (có tính riêng biệt), bạn nên kiểm tra giá cả và tính năng cho từng giải pháp đang được xem xét: Nhiều chương trình tuyển dụng nhằm hướng tới các công ty lớn hơn với số lượng đơn ứng tuyển lớn. Tùy thuộc vào quy mô, định hướng mà các doanh nghiệp nhỏ hơn cũng có thể đáp ứng những nhu cầu tuyển dụng khác nhau. Bạn có thể kiểm tra những tin tức kinh doanh và tham khảo những phần mềm tuyển dụng tốt nhất tại đây.
Xử lý biên chế là một nhiệm vụ khó khăn. Hãy làm cho nó dễ dàng với chính bạn (và nhân viên kế toán của bạn) bằng cách đầu tư vào một dịch vụ trả lương trực tuyến. Giải pháp này giúp tính toán và theo dõi tiền lương một cách tự động, các khoản khấu trừ, thời gian nghỉ, v.v. Một số thậm chí cho phép bạn nộp thuế lương và báo cáo tuyển dụng mới cho IRS. tiêu đề tuyển dụng
Chúng tôi đã tổng hợp danh sách các dịch vụ trả lương tốt nhất, bạn có thể tham khảo tại đây
5. Nền tảng quản lý lợi ích
Mặc dù một số dịch vụ trả lương cho phép bạn quản lý những lợi ích nhất định, ví dụ như thời gian nghỉ hè, thì một giải pháp tối ưu có thể giúp bạn quản lý tất cả các lợi ích của nhân viên bao gồm thời gian nghỉ, kế hoạch nghỉ hưu, bảo hiểm y tế, bồi thường cho công nhân và các đặc quyền khác.
Chen Amit, Giám đốc điều hành của công ty về những giải pháp thanh toán Tipalti cho biết một trong những quyết định tốt nhất mà ông ta đưa ra đối với công ty là thuê ngoài quản lý lợi ích.
“Nó mang lại cho doanh nghiệp của chúng tôi một cơ sở nền tảng cho các quy trình nhân sự được đảm bảo về tiêu chuẩn, một cái gì đó ít nhất đưa bạn ngang hàng với các tổ chức lớn hơn,” Amit nói. “Và sau đó, chúng tôi có thể tập trung thêm vào các lợi ích và đặc quyền vượt xa tiêu chuẩn nha khoa, sức khỏe, thị lực. Nó cũng làm đơn giản hóa dấu chân hoạt động của chúng tôi.”
Tuy nhiên, một dịch vụ quản lý lợi ích không nhất thiết giống như một tổ chức sử dụng lao động chuyên nghiệp (PEO), hoạt động theo thỏa thuận đồng tuyển dụng. PEO hoạt động như một chủ nhân hợp pháp về lực lượng lao động của bạn, đảm bảo sự tuân thủ trong việc phát hành tiền lương của nhân viên và quản lý lợi ích.
“PEO có thể cung cấp cho bạn quyền truy cập vào các đặc quyền bổ sung, các tùy chọn chăm sóc sức khỏe và chuyên môn thay vì tự mình quản lý mọi thứ”, Jacqueline Breslin, giám đốc dịch vụ vốn nhân lực tại TriNet cho biết. “Những lợi ích này cũng giúp cho việc tuyển dụng vì chúng làm cho bạn trở nên thu hút hơn.”
Để tìm hiểu thêm về PEO và xác định xem đó có phải là lựa chọn phù hợp cho công ty của bạn hay không, hãy đọcPEO nhé!
6. Công cụ tham gia của nhân viên
Sự cam kết đồng hành của nhân viên là ưu tiên cao đối với nhiều công ty. Với các công cụ công nghệ ngày nay, bạn có thể theo dõi văn hóa của tổ chức, đồng thời có cái nhìn sâu sắc hơn về những mong muốn của nhân viên mình.
“Tôi đã thấy các ứng dụng khuyến khích những phản hồi tích cực trong tổ chức đồng thời giúp hình thành văn hóa công ty”, Pablo Brenner, CEO của Collokia, một công cụ cộng tác doanh nghiệp cho biết.
Ví dụ cụ thể, các chương trình như YouEarnedIt cho phép mọi người nhìn nhận sự nỗ lực và biểu dương các đồng nghiệp khi họ không chỉ hoàn thành tốt công việc mà còn giúp phát triển những giá trị cốt lõi của công ty. Các công cụ khác, như TINYpulse, có ý nghĩa trong việc cải thiện văn hóa và hoạt động công ty thông qua việc thu thập những phản hồi ẩn danh.
Khi bạn đang cố gắng cảm nhận những suy nghĩ, ý kiến và mục tiêu cụ thể của nhân viên, chẳng hạn như loại thực phẩm nào sẽ được cung cấp trong cuộc họp tiếp theo hoặc thu thập ý kiến của nhân viên về chính sách mới của toàn công ty, đôi khi tốt nhất là sử dụng các chương trình miễn phí như Google Forms hoặc Survey Monkey. Những công cụ này cho phép bạn tập hợp những phản hồi trung thực một cách ẩn danh.
Những sự lựa chọn khác về công nghệ mang tính chất tương tác bao gồm các nền tảng mạng nội bộ của công ty như Igloo, Podio và OneWindow Workplace; các ứng dụng mạng xã hội của công ty như Yammer, WeVue và Workplace (của ứng dụng Facebook); và nhiều công cụ cộng tác khác.
Ron Yekutiel, CEO và chủ tịch của nền tảng video Kaltura, đã đưa ra lưu ý rằng những công cụ video có thể được các bộ phận nhân sự quan tâm để cải thiện quy trình tuyển dụng và đào tạo của họ.
“Việc thực hiện các cuộc phỏng vấn hiệu quả hơn thông qua video, hội nghị video mang các nhóm phân tán lại gần nhau hơn, xem xét và đào tạo … nhân viên mới và hiện tại … lực lượng lao động ngày nay thích video hơn như một phương tiện cho giao tiếp và hợp tác,” ông nói.
Lựa chọn giải pháp
Sự hấp dẫn của việc lựa chọn những giải pháp được đánh giá cao nhất hoặc ít tốn kém nhất là không hề bàn cãi. Nhưng điều quan trọng là bạn phải nghiên cứu và tìm ra công cụ phù hợp với nhu cầu kinh doanh. Đừng đầu tư vào một số giải pháp nhất định chỉ vì lợi ích của riêng của họ – đơn giản là vì nó không xứng đáng đối với công ty vào thời gian này, Breslin nói.
“Nó thì quan trọng để tìm ra giải pháp giúp tự động hóa các nhiệm vụ và có thể sẽ chiếm hết lượng thời gian quý giá trong ngày của bạn”, cô nói. “Tuy nhiên, một số nhiệm vụ không bao giờ được tự động hóa, chẳng hạn như xử lý các khiếu nại hoặc xung đột nhân viên.”
Brenner lưu ý rằng các công cụ bạn sử dụng phải thân thiện với người dùng và không gây rắc rối hoặc thất vọng cho nhân viên của bạn.
“Bạn sẽ không mong đợi việc đọc hướng dẫn về cách sử dụng ứng dụng mới trong một thiên niên kỷ, vậy tại sao bạn nên mong đợi nhân viên đọc hướng dẫn vận hành cho chương trình phần mềm nội bộ?” anh nói.
Cho dù bạn đang xem xét loại công cụ công nghệ nào, hãy cân nhắc và tìm kiếm các giải pháp phù hợp có thể đưa tổ chức của bạn tiến xa hơn trong tương lai.
“Các đồng đội nhân sự đang tìm kiếm sự tiên phong trong những đường hướng phát triển nên kết hợp các công nghệ mới, chẳng hạn như … các hệ thống hợp tác kinh doanh trong khi để mắt đến các công nghệ như AR và VR khi chúng phát triển,” Yekutiel nói. “Đây là một chặng đường dài trong việc thu hút lực lượng lao động ở hiện tại và cả tương lai, cho phép các nhóm trong toàn tổ chức làm việc hiệu quả và gia tăng năng suất.”
Hệ 08 trường Ivy League là một trong số các trường cao đẳng uy tín hàng đầu trên thế giới. Hệ thống bao gồm các trường ĐH Brown, ĐH Harvard, ĐH Cornell, ĐH Princeton, ĐH Dartmouth, ĐH Yale, ĐH Columbia, và ĐH Pennsylvania.
Tất cả 8 trường đều nằm trong Top 15 của Truyền thông Mỹ và Báo cáo toàn cầu (U.S. News and World Report).
Các trường Ivy League cũng nổi tiếng về việc chọn lọc rất cao và cực kỳ khó để đậu vào. Nhưng tin tốt là tất cả các trường đại học này hiện đã cung cấp các khóa học trực tuyến miễn phí trên nhiều nền tảng trực tuyến. Các khóa học này có tên là Massive Open Online Courses hoặc được gọi tắt là MOOCs.
Đến nay, họ đã cho ra 500 khóa học, trong đó khoảng 450 vẫn còn hoạt động. Class Central đã thực hiện một bộ tổng hợp tất cả những khoá này, bạn có thể khám phá dưới đây. Tôi đã chia các khóa học này thành các loại sau:
Computer Science
Data Science (Khoa học Dữ liệu)
Programming (Lập trình)
Humanities (Nhân văn)
Business (Kinh doanh)
Art & Design
Science (Khoa học)
Social Sciences (Khoa học Xã hội)
Health & Medicine (Y học)
Engineering
Mathematics (Toán học)
Education & Teaching (Giáo dục)
và Personal Development (Phát triển bản thân)
Tôi cũng đã sắp xếp các khóa học này trên trang tổng hợp của Class Central cho Ivy League MOOCs. Bộ này sẽ được cập nhật tự động mỗi khi các khóa học mới được thêm vào. Bạn có thể đăng ký để nhận được cập nhật mới bằng cách nhấp vào “FOLLOW” màu xanh nút.
Responsive với CSS chúng ta tùy biến code bằng @media, vậy với JS, ta thêm các điều kiện theo tốc độ mạng bằng cách nào?
Chúng ta sẽ sử dụng API của trình duyệt navigator.connection.effectiveType để tối ưu theo tốc độ kết nối mạng của user
Các thông tin về mạng của user có thể lấy qua navigator.connection, trong đó có giá trị effectiveType là một trong các giá trị ‘slow-2g’, ‘2g’, ‘3g’, ‘4g’
Chrome 62 trở về trước, chúng ta chỉ có giá trị navigator.connection.type, giá trị này không phải tốc độ mạng. Mặc dù type là wifi, nhưng lại là một wifi cùi mía, tốc độ ngang ngửa 2g, Chrome sau này có phát minh thêm giá trị effectiveType, tính theo tốc độ đi-về của cục dữ liệu cho chính xác.
Còn trường hợp, trong nhà có thanh niên nào đó mở link down film Nhật, tốc độ mạng đang “như tia chớp”, thì chuyển sang “cùi mía”, biết được sự thay đổi này cần add thêm cái listener cho đối tượng navigator.connection
Xem xét một trong những câu lệnh được sử dụng nhiều nhất trong lập trình: câu điều kiện
Một trong những món ăn mà anh em lập trình chúng ta phải nhai đi nhai lại trong suốt cuộc đời, dù là bạn đang viết ngôn ngữ gì là CÂU ĐIỀU KIỆN. Nếu không khéo trong lúc nấu code, thì món ngon đó đôi khi trở thành món dỡ ẹt, người sau vào ăn không thấy ngon, chúng ta tự ăn cũng không thấy ngon.
Bài này được viết trong một chiều chủ nhật đang đói bụng
❌ Không ngon
const printAnimalDetails = animal => {
let result;
if (animal) {
if (animal.type) {
if (animal.name) {
if (animal.gender) {
result = `${animal.name} is a ${animal.gender} ${animal.type};`;
} else {
result = "No animal gender";
}
} else {
result = "No animal name";
}
} else {
result = "No animal type";
}
} else {
result = "No animal";
}
return result;
};
Liệu rằng các chuyên gia về quản trị nhân sự có nên sở hữu trí tuệ cảm xúc?
Đó là một câu hỏi nhiều thách thức trong môi trường làm việc ngày nay, đặc biệt là khi các nhân viên tiềm năng cho phép và sử dụng trí tuệ của cảm xúc như một phần không thể thiếu trong quá trình đưa ra quyết định của họ.
Thực chất EI là gì?
Theo Mike Poskey, chủ tịch của ZERORISK HR, EI (Emotional Intelligence) hay còn gọi là trí tuệ cảm xúc là một tập hợp các năng lực cho phép con người thể hiện và tự nhận ra được những hành vi, tâm trạng, sự dao động của bản thân và biết cách kiểm soát chúng trong từng tình huống cụ thể.
Trí thông minh của cảm xúc còn được hiểu theo nghĩa đơn giản hơn tức là cách một cá nhân nào đó biết nhận ra những cảm xúc mình đang tồn tại bên trong mình, từ đó họ có thể điều khiển được tích cách, suy nghĩ và hành động của mình một cách hiệu quả. Và khi ngành Nhân sự phát triển, trí tuệ cảm xúc đã trở thành một chiến lược quan trọng trong việc quyết định liệu một ứng viên tiềm năng có đủ sự phù hợp với vai trò mà họ đang ứng tuyển hay không.
Tuy nhiên, giữa việc quyết tâm xây dựng văn hóa công ty và thực sự bắttay vào việc để cải thiện chưa thực sự kết nối với nhau chặt chẽ. “Các công ty dường như rất thích bàn luận về tầm quan trọng của con người cũng như đặt họ làm trọng tâm, tuy nhiên lại thất bại trong việc đẩy mạnh EI giữa các lãnh đạo và tổ chức” giám đốc của HBR-AS cho biết. Nhiều tổ chức gặp khó khăn trong việc xem trọng EI để đạt được các lợi ích cho tổ chức – như nhân viên có tâm trạng tốt hơn, có động lực để làm việc có năng suất cao hơn.
Lợi ích của EI đối với ngành Nhân sự
Trí thông minh cảm xúc có thể đóng một vai trò quan trọng trong công việc của các chuyên gia nhân sự, vì nó cung cấp cho họ cái nhìn sâu sắc về quá trình đào tạo và phát triển nhân sự. Ngoài ra, sự hiểu biết từ EI có thể giúp các nhà quản lý nhân sự xác định xu hướng hành vi của tổ chức/doanh nghiệp. Chính lợi ích thiết thực này giúp họ thuận lợi hơn trọng việc phát triển các chương trình thúc đẩy giao tiếp lành mạnh tại nơi làm việc.
EI tạo ra cho chính bạn cơ hội để khám phá cảm xúc và những tác động đa chiều mà bạn đang gặp phải. Đồng thời, EI còn giúp hình thành nên một môi trường làm việc thân thiện, vui vẻ cho nhân viên và người quản lý nhân sự, từ đó thúc đẩy việc gia tăng hiệu suất công việc của toàn tổ chức.
Để có thể thấy rõ những lợi ích mà EI mang lại, hãy đảm bảo rằng bạn hiểu rõ 4 thuộc tính của EI:
Tự nhận thức và năng lực đồng cảm
Tự kiểm soát và thích ứng
Năng lực nhận thức xã hội
Quản lý các mối quan hệ
Tự nhận thức và năng lực đồng cảm
Poskey đánh giá việc sự tự nhận thức là một năng lực đặc biệt vì nó giúp thúc đẩy khả năng tự phán đoán và xác định cảm xúc ảnh hưởng đến hành vi và suy nghĩ, tự đánh giá chính xác mong muốn của cá nhân. Biểu hiện của năng lực này chính là việc tự thích ứng và sáng tạo đổi mới trong môi trường nhân sự khắc nghiệt.
Năng lực đồng cảm khiến bạn có sự thấu hiểu, kết nối hơn tốt hơn với những cảm xúc của đồng nghiệp. Đó cũng là nền tảng giúp phát triển con người và thúc đẩy sự đa dạng trong lối tư duy về cảm xúc. tiêu đề tuyển dụng
Tự kiểm soát và thích ứng
Kiểm soát các xung động và cảm xúc của bạn là yếu tố rất quan trọng để đạt được thành công. Hiệu quả công việc của bạn sẽ được gia tăng nếu bạn biết cách quản lý cảm xúc của bản thân trong một khoảng thời gian.
Khả năng thích ứng cũng có thể tạo ra sự khác biệt cho các bạn trong việc quản trị nguồn nhân lực. Ví dụ nếu bạn là người quản lý nhân sự, hãy khuyến khích các nhân viên của mình dành đủ thời gian cần thiết để quản lý cảm xúc của bản thân. Cụ thể như khuyến khích họ nghỉ ngơi 15 phút để có thể nhận biết, kiểm soát và đánh giá lại những cảm xúc cá nhân một cách tốt hơn. Đó là cơ hội để họ hiểu bản thân hơn đồng thời tạo ra sự thích ứng, tính cân bằng cảm xúc trước những áp lực từ môi trường làm việc nhân sự.
Năng lực nhận thức xã hội
EI giúp bạn có thể dễ dàng tiếp nhận các tín hiệu xã hội của người khác, cảm thấy thoải mái trong một tập thể năng động. Từ đó, EI sẽ kích thích sự tương tác qua lại giữa bạn và đồng nghiệp, giúp bạn tự tin hơn trong giao tiếp. Điều quan trọng là phải biết vai trò của bạn trong các môi trường làm việc khác nhau, hiểu cảm xúc của bạn và điều tiết nó để có thể hòa nhập một cách tốt nhất.
Ví dụ, một chuyên gia nhân sự thành lập các hội thảo về các giải pháp thực tế có thể giúp người lao động phát triển nhận thức xã hội. Các nhân viên tham gia và hiểu được các tình huống hiện thực phổ biến có thể xảy ra, nắm bắt được cảm xúc của người lao động để có thể thoải mái giao tiếp, kết nối họ tốt hơn.
Quản lý các mối quan hệ
Hầu hết các mối quan hệ đều có những mâu thuẫn và các nhà quản lý nguồn nhân lực có thể giúp nhân viên của mình khắc phục được điều này. Tổ chức các chương trình giao tiếp mở là cách tốt nhất để quản lý các mối quan hệ. Chính EI tạo ra cho bạn khả năng này chứ không một năng lực nào khác.
Poskey cũng nhấn mạnh rằng trí thông minh cảm xúc là yếu tố giúp bạn chinh phục quá trình giao tiếp, thực hiện các công tác lãnh đạo, giải quyết xung đột và hợp tác lâu dài trong sự phát triển chung của ngành tuyển dụng nhân sự. Thông qua năng lực EI và lợi ích từ việc quản lý các mối quan hệ cũng giúp bạn xác định được những giá trị thật sự mà bạn đóng góp cho một tổ chức/doanh nghiệp.
Dù cho là năng lực xã hội hay năng lực cá nhân, thì đó đều là những năng lực xuất phát từ trí thông minh cảm xúc. Tùy vào kinh nghiệm hay tiềm năng sẵn có mà mỗi cá nhân sẽ có một giới hạn trí tuệ cảm xúc khác nhau. Song, mọi năng lực của EI đều có tính quyết định, chi phối và ảnh hưởng sâu sắc đến quá trình công tác nhân sự.
Nếu bạn đang tò mò liệu rằng mình có phải là người có trí tuệ cảm xúc cao, có khả năng duy trì tính ổn định về cảm xúc hay không, hãy làm một bài kiểm tra tính cách với công cụ trắc nghiệm tính cách của TopDev.
Lưu ý: Bài test dành cho Tất cả các lập trình viên/người làm trong lĩnh vực công nghệ thông tin.
Với những lợi ích thiết thực từ trí thông minh cảm xúc, bạn nên áp dụng EI trong công tác thực hiện, sắp xếp và phát triển chiến lược nhân sự. Vậy phải làm thế nào để áp dụng EI trong việc phát triển chiến lược nhân sự?
Hãy ghi nhớ 3 bước sau đây:
Xây dựng văn hóa gắn kết từ trong ra ngoài
Đơn giản bạn hãy hình dung nền văn hóa gắn kết giống như một mạng lưới các mối quan hệ được liên kết chặt chẽ giữa con người và môi trường làm việc của họ, và tất nhiên có sự tương tác như một tổng thể mạch lạc. Khi nắm bắt được tổng thể, tức là bạn đã bước đầu xác định được giá trị văn hóa và định hướng phát triển.
Tập trung vào các nhà lãnh đạo
Mức độ EI của các nhà lãnh đạo ảnh hưởng trực tiếp đến mức độ tham gia và hiệu suất công việc từ nhân viên của của họ. Vì thế để phát triển chiến lược toàn diện, chúng ta nên tập trung vào các nhà lãnh đạo, sử dụng EI của bản thân để tạo sự kết nối.
Lúc này, các năng lực EI cần được phát huy một cách tối đa như khả năng nắm bắt cảm xúc, hiểu được suy nghĩ và quản lý mối quan hệ xã hội. Đây là cơ hội tiếp cận, trao đổi để tạo ra cơ sở thông tin cần thiết giúp hoàn thiện chiến lược nhân sự tốt hơn.
Ưu tiên tạo ra sự kết nối cảm xúc
Kết hợp hai bước trên bạn sẽ xây dựng được một chiến lược nhân sự với giá trị văn hóa, định hướng và nguồn dữ liệu là thông tin từ các nhà lãnh đạo giàu kinh nghiệm.
Lưu ý rằng văn hóa gắn kết con người cần đặt lên hàng đầu vì nó là nền tảng quan trọng giúp phát triển chiến lược. Tạo ra sự kết nối rất quan trọng vì giúp thúc đẩy sự liên kết về cảm xúc của nhân viên và khách hàng, đồng thời ảnh hưởng đến mức độ tham gia và khả năng hình thành mối quan hệ mạnh mẽ giữa họ.
Điểm hạn chế của EI – Trí thông minh cảm xúc
Một nghiên cứu mới từ Đại học Manchester Metropolitan và Trường Kinh doanh EMLyon ở Pháp cho biết: “Các nhà quản lý sở hữu năng lực trí tuệ cảm xúc ở mức độ cao, nhiều khả năng không nhận được sự đánh giá tích cực và đạt hiệu quả trong công việc khi được so sánh với các nhân sự khác cùng cấp bậc.”
Cũng theo đó, Giáo sư Nikos Bozionelos của EMLyon, một trong những nhà nghiên cứu cũng chỉ ra trí tuệ cảm xúc hoạt động “năng suất” đến một thời điểm nhất định và sau đó rơi vào trạng thái không hiệu quả, có thể phát sinh những tác động tiêu cực không mong muốn.
Đơn giản có thể giải thích như sau: Gia tăng sự thông minh về cảm xúc vượt quá mức giới hạn (Beyond limits) sẽ tạo ra tác động ngược. Khi một người lãnh đạo, cấp trên phụ trách quản lý nhân sự có quá nhiều trí thông minh cảm xúc sẽ dẫn đến sự khó kiểm soát về năng lực EI.
Chẳng hạn, do có quá nhiều EI liên quan đến sự đồng cảm, điều này vô tình khiến người quản lý nhân sự trở nên ngần ngại áp dụng các chính sách, biện pháp giải quyết về chuyên môn. Họ sợ sẽ tạo ra gánh nặng cho cấp dưới. Đây cũng chính là hạn chế khi một cá nhân bị chi phối quá nhiều về năng lực cảm tính, họ trở nên do dự, không quyết đoán trước những quyết định quan trọng. Vì thế, họ dần mất đi sự nhìn nhận chính xác về năng lực của mình trong mắt nhân viên.
Lời kết
Quay trở lại phần đầu của bài viết này, chúng tôi đã đặt ra câu hỏi: Liệu rằng các chuyên gia về quản trị nhân sự có nên sở hữu trí tuệ cảm xúc?
Câu trả lời là có. Và tất nhiên cũng có nhiều lý do quan trọng để các chuyên gia nhân sự nên thành thạo về trí thông minh cảm xúc. Thực tế cho thấy, xu hướng chung hiện tại ở các công ty nhân sự là các quản lý cấp cao thường lựa chọn người thông minh từ những trải nghiệm, thay vì lựa chọn người thông minh từ sách vở. Cách lựa chọn như thế không có nghĩa là trí thông minh học thuật là không quan trọng. Điều đó chỉ có nghĩa là chúng ta cần phải hiểu rõ hơn về bản thân, nhận biết và kiểm soát tốt cảm xúc của chính mình. Có thế, bạn sẽ tìm thấy sự cân bằng giữa năng lực chuyên môn và năng lực trí tuệ cảm xúc, dung hòa nó để trở nên thành công hơn.
Bài viết đã được sự cho phép của tác giả Vũ Công Tấn Tài
Người ta thường dùng những danh hiệu như Fresher, Junior, Senior, … để chỉ cấp bậc hoặc kinh nghiệm làm việc của một lập trình viên, những thứ này có thể các bạn đã quá quen thuộc. Chúng ta dành rất nhiều thời gian để phân loại, hoặc nói về việc như thế nào là Fresher, như thế nào là Junior, … Mọi thứ dường như có vẻ phức tạp.
Mình không phản đối cách phân cấp này, tuy vậy mình muốn mang đến cho mọi người 1 góc nhìn mới, đơn giản và dễ hiểu hơn về cách phân cấp lập trình viên. Hình dung trong cuộc sống, dù chúng ta có nhiều tên gọi khác nhau cho các giai đoạn của cuộc đời (thiếu nhi, thiếu niên, thanh niên, trung niên, cao niên, …), chúng ta vẫn có thể nhìn 1 người nào đó dưới góc độ “sự trưởng thành”. Tương tự, chúng ta có thể đánh giá 1 lập trình viên dựa trên sự TRƯỞNG THÀNH của họ.
Trưởng thành là có trách nhiệm với việc mình làm
Đây có lẽ là yếu tố tiên quyết cho việc nhìn nhận một người thực sự trưởng thành hay chưa, và lập trình viên cũng vậy. Chúng ta cần có trách nhiệm với những gì được giao, chúng ta phải nỗ lực để đảm bảo các yêu cầu được hoàn thành đúng thời hạn. Hoàn thành không chỉ có nghĩa là tạo ra một kết quả đúng, mà còn phải hoàn thiện sao cho tốt nữa (code sạch, hiệu suất tốt, bảo mật, …).
Ở một vài khía cạnh nào đó, lập trình viên là người đầu tiên phải test sản phẩm, phải đảm bảo code của mình thực sự chạy đúng chứ không phải chỉ biết phó thác điều đó cho tester. Đôi khi một tester bắt được nhiều bug không phải là do người tester giỏi, mà đơn giản là người viết code đã không đủ tốt.
Trưởng thành là không dựa dẫm vào người khác
Khi mới đi làm, có thể bạn sẽ cần tới sự hướng dẫn và giúp đỡ của nhiều người. Điều này không có gì là xấu, tuy nhiên chúng ta cần phải có ý thức cải thiện khả năng của mình theo năm tháng. Đừng hỏi sự giúp đỡ 2 lần với cùng 1 vấn đề. Hãy tự biết rút ra kinh nghiệm cho bản thân.
Đừng chỉ biết thụ động đợi leader giao việc, thay vào đó hãy luôn cố gắng đóng góp ý kiến trong các buổi thảo luận, mạnh dạn đưa ra giải pháp và bảo vệ giải pháp của mình. Hãy biết cùng mọi người giúp đỡ lẫn nhau để hoàn thiện sản phẩm chứ đừng chỉ biết đổ lỗi cho người này đã viết code tệ hay người kia đã test không kĩ khi sản phẩm có lỗi.
Đừng xin lỗi, hãy trở nên tốt hơn. Dù xây dựng phần mềm là việc làm có tính teamwork nhiều người, nhưng hãy luôn sẵn sàng để có thể giải quyết được một mình.
Trưởng thành là biết thừa nhận khuyết điểm
Các cụ có câu: nhân vô thập toàn. Có nghĩa là không ai là không có khuyết điểm, ai cũng có điểm gì đó mà mình không thật sự giỏi. Đừng ngại thừa nhận điều mình không biết / làm sai, để học hỏi, để nhờ người khác giúp đỡ, và để tiến bộ hơn.
Nghe thì có vẻ hiển nhiên, nhưng thật sự là có rất nhiều người không bao giờ chịu thừa nhận mình sai dù cho đã được nhiều người góp ý. Họ luôn cho rằng giải pháp của họ là tốt nhất, công cụ này là nhất, công cụ khác là không tốt, … Mình đã từng gặp những người luôn cho rằng Web là nhất, Mobile chỉ là thứ nhỏ bé, React là nhất trong khi Angular là rác rưởi, ..v.v. Mình nghĩ rằng đây không phải là một thái độ tốt.
Khi quá tôn thờ một điều gì đó, bạn đánh mất cơ hội có được những điều khác tốt hơn.
Trưởng thành là luôn dám đương đầu với thách thức
Như đã nói, khi mới bắt đầu công việc, chúng ta có thể cần tới sự giúp đỡ và hướng dẫn của những người đi trước. Khi bạn còn ít kinh nghiệm, có thể là bạn chỉ được giao những nhiệm vụ nho nhỏ như fix một lỗi giao diện, làm một hàm ultility bổ trợ cho các lớp logic phía trên, …v.v.. Ít ai dám giao cho bạn công việc lớn như thiết kế nguyên một module phụ trách thanh toán, kiểm tra quyền truy cập …
Tuy vậy, theo thời gian, bạn cần phải chứng tỏ được khả năng có thể đảm đương được những công việc lớn hơn, có ảnh hưởng nhiều hơn. Nếu cấp không chủ động, thì hãy thử mở lời rằng bạn muốn làm thứ gì đó lớn hơn coi sao. Tất nhiên là bạn phải nỗ lực để hoàn thành công việc, để chứng minh rằng mình có thể làm được những việc phức tạp.
Không cần phải quá vội, nhưng hãy tiến bộ từng chút một. Đừng thấy việc khó mà thoái thác cho người khác, như vậy là bạn tự đánh mất cơ hội của chính mình đấy.
Trưởng thành là có thể giúp đỡ người khác
Điều này thì chắc là cũng dễ hiểu, lúc bắt đầu bạn được người khác giúp đỡ, sau đó thì tới lượt bạn dùng kinh nghiệm của mình giúp đỡ lại những người mới khác. Bạn cần phải giúp nhóm của mình nâng cao khả năng của từng thành viên, như vậy thì nhóm mới mạnh và làm được nhiều việc lớn hơn.
Ngoài ra, người ta còn cho rằng, khi hướng dẫn lại cho người khác, tức là bạn đang học tới 2 lần. Mình tin điều này là đúng. Trong lúc hướng dẫn người khác, có thể bạn sẽ phát hiện ra những góc nhìn mới rất thú vị. Bạn cũng có thể được lòng nhiều người khi đã giúp đỡ họ, điều này thật sự là cần thiết trong việc nâng cao uy tín cho bản thân.
Bởi vậy, đừng chỉ biết mỗi bản thân, hãy tỏ ra hữu ích và trách nhiệm bằng việc hỗ trợ những người khác.
Tổng kết
Mình từng gặp nhiều khó khăn khi cố vạch ra những giới hạn rõ ràng cho những khái niệm như Fresher, Junior, Senior, … Vì thế mà mình gặp phải khó khăn khi không biết làm thế nào để đạt được những mức độ tương ứng.
Khi nhìn nhận khả năng và vai trò của lập trình viên dưới góc nhìn của sự trưởng thành, mình cảm thấy nó dễ hiểu và dễ hình dung hơn, từ đó việc xây dựng kế hoạch rèn luyện và phát triển cũng dễ dàng hơn, và mình muốn chia sẻ điều đó với mọi người trong bài post này.
Cuối cùng, trưởng thành không chỉ gói gọn trong những điều trên, nó còn nhiều hàm ý rộng lớn hơn nữa, ví dụ như việc xây dựng tính kỉ luật, có được sự kiên trì, biết mình thật sự muốn gì và vạch ra con đường đi, sáng tạo, … Nhưng cũng giống như các giai đoạn của cuộc đời, bạn liên tục phải giải quyết nhiều vấn đề mới, vậy nên đừng ngại để luôn đối mặt và vượt qua nó.
Đừng để bạn chỉ lớn lên, mà không hề trưởng thành.
Là cái tên nổi bật trong làng Vlogger, kênh YouTube của Hana’s Lexis đã thu hút tới hơn 520.000 lượt đăng ký theo dõi, bên cạnh trang blog facebook cũng hot không kém với hơn 130.000 lượt Thích và Theo Dõi.
Không sở hữu gương mặt của các nàng hot girl, hay cuộc sống sang chảnh. Điều “mang” subscribers và followers đến Hana nằm ở những chia sẻ hết sức hài hước và thú vị về chủ đề học tiếng Anh, cùng những quan điểm rất chân thật của cô nàng. Tuy nhiên, ít ai biết ngoài trình tiếng Anh siêu đẳng với điểm IELTS tuyệt đối 9.0 của mình, Hana còn là 1 lập trình viên, và hiện chị đang sinh sống và làm việc tại Mỹ.
Chia sẻ về quá trình phỏng vấn những công ty công nghệ hàng đầu tại Mỹ, Hana cho biết chị không mang tư tưởng phải đậu hay với mục đích kiếm việc làm, mà chỉ để thử sức cũng như tích lũy kinh nghiệm, trau dồi vốn kiến thức, từ đó biết mình yếu chỗ nào để luyện tập và học hỏi thêm.
Hành trình “apply dạo” và trải nghiệm quy trình độc đáo
Lần này chị muốn chia sẻ 1 chút về chủ đề “Kinh nghiệm phỏng vấn ở các công ty Mỹ” và cụ thể hơn là tại 1 công ty startup tại San Francisco là Mapbox và đáng chú ý hơn hết chính là Amazon. Amazon thì đã quá nổi tiếng, và là 1 trong những trang thương mại điện tử hàng đầu thế giới, vậy còn Mapbox thì sao? Theo chia sẻ của Hana, họ là công ty tạo ra những ‘bản đồ’ mà bạn hay thấy trong những app khác, ví dụ như Google Maps chẳng hạn… hay là khi bạn mở các app không phải để chỉ đường ví dụ như Foody và có bản đồ những nơi ăn uống trong đó, thì Mapbox sẽ là nơi cung cấp các giải pháp bản đồ đó cho các công ty khác tùy theo nhu cầu của họ, quả là 1 startup thú vị phải không nào. Hana’s Lexis cũng không ngại chia sẻ 1 chút về trải nghiệm phỏng vấn ở 1 công ty Mỹ như Mapbox, dù chỉ là 1 công ty startup, nhưng Mapbox cũng thuộc dạng khá là lớn. Đồng thời Hana cũng không quên khoe sự hào hứng của mình với văn hóa startup của họ, trụ sở của Mapbox chiếm nguyên 1 tầng (khá giống văn phòng của TopDev), sau đó trang hoàng lại thành nhiều phòng, ngoài phòng họp và làm việc sẽ là những phòng nghỉ ngơi, đọc sách giải trí cho các nhân viên. Bằng cách ‘apply’ dạo trên mạng, Hana đã nhận được mail từ Mapbox có kèm link để làm bài test online, và ở đây họ còn không giới hạn thời gian làm bài như những nơi khác. Thay vì làm 1-2 bài như những nơi khác, trong vòng 60-90 phút cho 1-2 bài. Các ứng viên của Mapbox có thể làm 3 bài trong thời gian tận 6 tiếng. Điều này tạo cảm giác thoải mái cho các ứng viên, miễn sao “bạn tự giác, không copy, paste là được.” “Quan trọng lúc làm test online là mình phải tự trung thực, vì nếu không thì tới khi bạn lên onsite phỏng vấn trực tiếp bạn sẽ thành trò cười cho thiên hạ” Tại vòng phỏng vấn tiếp theo, vì một số lý do thời tiết và khách quan, Hana tới trễ 20 phút, và bị âm điểm về ‘behavioral’. Vòng behavioral bao gồm những câu hỏi về tiểu sử bản thân, tình huống xử lý qua lại, mình là người như thế nào, nhưng với khoảng 5 phút còn lại để trả lời nên Hana chưa thực sự hoàn thành tốt vòng này. Tiếp theo 2 câu sau sẽ là về phần ‘technical’ và chung với 1 người trong team của Mapbox. Hana chia sẻ thêm quan điểm cá nhân: “Ở Mỹ sẽ có 2 dạng phỏng vấn. Dạng thứ nhất là leetcode (1 trang web để thực hành giải thuật toán). Dạng thứ hai, khác với leetcode, nhà tuyển dụng sẽ ghép đôi (pairing) bạn với 1 người trong team, để cùng giải quyết các vấn đề thực tế để họ thấy được năng lực làm việc hàng ngày cùng team của bạn sẽ ra sao. Nhưng những nơi mà mình đi thì sẽ phỏng vấn theo kiểu giải toán, giải các bài tập coding như trên leetcode hay là HackerRank.”
HackerRank như là 1 dịch vụ, là 1 nơi mà bạn có thể lên làm bài tập, luyện về coding. Và nó còn có 1 dịch vụ là tạo ra những room để những người phỏng vấn và người được phỏng vấn đăng nhập vào 1 link để code. Theo Hana, cách này cũng khá là hay vì sẽ không cần phải viết code lên bảng, việc gõ trên HackerRank sẽ giúp bạn cảm thấy quen thuộc hơn. Và ở Mapbox mỗi lần phỏng vấn họ sẽ cho bạn 1 link để làm bài trên HR. “Lúc làm bài quan trọng là phải ‘communicate’ với người ta, cho họ biết là mình đang suy nghĩ gì, hướng giải quyết của mình là như thế nào, đồng thời giải thích tại sao mình lại chọn cách này không chọn cách kia và về độ không gian và thời gian nó có lợi như thế nào.” “Nói chung mục đích của việc phỏng vấn ở các công ty Mỹ, chủ yếu sẽ là ‘problem solving – giải quyết vấn đề’ và vừa phải ‘communication – giao tiếp’ nữa, phải ‘thinking out loud – nghĩ gì nói đó’, phải nói ra suy nghĩ của mình để họ hiểu được hướng giải quyết của mình, vì cho dù có giải đúng mà bạn không nói gì, thì họ cũng không tha thiết lắm mà còn có thể đánh giá bạn là người khó làm việc cùng”.
Hai bài technical làm tại Mapbox theo tác giả không khó lắm, một bài là về kiểu design: thiết kế một function để đáp ứng yêu cầu, bài còn lại tương tự như giải thuật toán. Theo Hana, về bài design chị nhận help & hint khá nhiều nên bản thân chị cũng không cảm thấy ổn lắm. Bài cuối thì khá dễ, chị cho rằng mức độ của câu này chỉ tầm ‘trên mức dễ và thấp hơn trung bình 1 chút’.
Sau đó Hana tham dự phỏng vấn tại Amazon.
“Mục đích của mình khi đi phỏng vấn Amazon, đậu là 1 phần, do mình biết năng lực bản thân cũng chưa đủ tầm, nên mục đích lớn nhất của mình là ‘KHÔNG LÀM TRÒ HỀ CHO THIÊN HẠ – make a fool of myself – in front of the interviewers.” Nếu các buổi phỏng vấn tại Mapbox là tự túc di chuyển, các công ty lớn như Amazon sẽ hỗ trợ vé máy bay, khách sạn để đón ứng viên. Nhà tuyển dụng sẽ mất thời gian nếu ứng viên thực sự không đạt yêu cầu trung bình, và Hana không muốn mình là một trong số đó. Tuy nhiên, Hana đã không để chuyện đó xảy ra, tuy không được offer nhưng cô cho hay là buổi phỏng vấn không khó như mình nghĩ. “Bắt đầu phỏng vấn từ lúc 9h và sẽ liên tục tới 9h50, nghỉ 10 phút rồi 10h tới 10h50, nghỉ 10 phút … thì tới 1h chiều là sẽ hoàn tất, bao gồm cả ăn trưa.” Hana chia sẻ chị khá thích kiểu phỏng vấn như thế vì sẽ tạo cảm giác thoải mái và tạo hiệu quả tốt hơn cho các ứng viên,. Chị còn chia sẻ 1 điểm khá thích thú về Amazon đó chính là họ còn cho phép mang cún cưng vào văn phòng, và lúc ngồi ở sảnh chờ phỏng vấn chị còn thấy rất nhiều chó cưng ở khắp nơi, đủ thể loại, ‘dễ thương kinh khủng’ – Hana chia sẻ 1 cách chân thật.
Trong bài phỏng vấn đầu tiên, người phỏng vấn chị là một người Ấn Độ, từng làm ở Amazon Nhật Bản. Và ở Amazon lúc nào cũng sẽ theo dạng câu hỏi behavioral trước rồi mới tới câu hỏi kỹ thuật trong khoảng 50 phút. Phần behavioral là 20 phút và technical sẽ là 30 phút. Nên bạn sẽ nhận được khá nhiều câu hỏi về behavioral với 20 phút x 4 là 80 phút chỉ để nói về tiểu sử, thời gian làm việc, kinh nghiệm làm việc. Hay là kể về 1 lần mà bạn cãi nhau với sếp, tại sao lại cãi, và cách mình bảo vệ chính kiến của mình ra sao, cách mà 1 lần mình giải quyết 1 vấn đề phức tạp bằng 1 cách đơn giản v..v.. Hana chia sẻ rằng bên Amazon hỏi nhiều tới mức mà khi xong buổi phỏng vấn thử 3 thì chị còn không biết mình còn gì để nói không vì họ đã hỏi hết cả rồi. Đặc biệt ở Amazon, họ còn có ‘14 guiding leadership principles‘, và họ rất tập trung trong việc phác họa những candidate – ứng viên như mình. Dựa vào kinh nghiệm quá khứ của mình để họ xem mình có phù hợp với các ‘guiding leader principles’ đó không, ví dụ:
‘ownership’ tức là làm chủ những gì đang làm,
phải có ‘backbone’ để bảo vệ chính kiến của mình,
‘customer obsession’ – cuồng khách hàng, là cố gắng làm vừa lòng khách hàng Đó là những principles của Amazon và mỗi nơi sẽ có 1 principle khác nhau, riêng Amazon thì các principle này khá quan trọng cho việc phỏng vấn, và đôi lúc sẽ là ‘make or break’ luôn, tức là cho dù bạn làm rất tốt về phần technical nhưng lại không phù hợp với các principles đó thì có thể họ cũng sẽ không ‘hire’ – thuê bạn.
Về phần phỏng vấn principles – behavioral này thì Hana cũng cảm thấy rất biết ơn về những người bạn gửi lời động viên, khuyên nhủ tới chị, dù chưa hề quen biết nhau như thông qua kênh Youtube của mình, chị đã được nhiều sự giúp đỡ từ những người đã từng làm hay có người quen ở Amazon để chia sẻ kinh nghiệm.
Quay lại vòng phỏng vấn đầu tiên, Hana cho rằng phần technical này chỉ thuộc mức dễ trên Leetcode thôi, và chỉ còn chia sẻ thêm Leetcode là nơi để làm bài tập giải đáp câu hỏi về phỏng vấn lập trình. Và chị cảm thấy khá ok với bài đầu của mình và anh Ấn Độ cũng là người đánh giá chị tốt nhất. Ở vòng 2, có hai người phỏng vấn: 1 manager và ‘shadow interviewer’, tức chỉ học hỏi kinh nghiệm. Câu hỏi lần này là về design 1 function. nhưng do không hiểu câu hỏi lắm nên Hana khá là struggle và không hiểu lắm về ‘clarify’, những cái yêu cầu của đề bài, và họ cố tình đặt câu hỏi không rõ ràng như vậy để xem bạn có hỏi những câu hỏi đắt giá hay không, có tìm ra được những cái mấy chốt vấn đề để mà giải quyết hay không.
Do chưa chuẩn bị kĩ nên Hana cũng không đưa ra được các câu hỏi đắt giá hay vào những chỗ cần phải tập trung nên chị cho rằng đây là phần phỏng vấn tệ nhất của ngày hôm đó. Đối với Hana, lần phỏng vấn onsite thứ 2, sau lần đầu tại Mapbox, hoàn toàn khác hẳn. Mapbox casual, thoải mái hơn nên so với công ty lớn như Amazon chị cũng có hơi khớp 1 chút.
Vòng thứ 3, người manager chỉ hỏi toàn bộ về behavioral, và Hana chia sẻ là ‘nói hết vốn luôn’. Chị cũng cảm thấy lạ 1 chút vì nó không có câu hỏi ‘technical’. Nên trong 4 vòng thì chỉ có 3 vòng là có câu hỏi ‘technical’ thôi. Vòng thứ 4, phần cuối cùng, thì phần technical này Hana cho là phần giống các câu hỏi Leetcode nhất, giải các thuật toán, cấu trúc dữ liệu,…. Nhưng Hana không quen với ‘whiteboard coding’ cho lắm, nên lần này vẫn phải nhận hint từ người phỏng vấn, dù nhận hint xong vẫn giải được nhưng hint nhiều quá cũng không tốt, vì mình sẽ không tự lập được và để người ta chỉ hướng. Sau tất cả, Hana nhận được sự đánh giá là ‘borderline candidate’, tức là 1 ứng viên ‘mém’ được offer, nhưng do phần technical còn yếu nên đành hụt mất cơ hội này. Còn phần behavioral thì Hana khá là tự tin, và chị còn cảm thấy rất biết ơn Amazon vì nhờ học và trả lời rất nhiều về phần ‘behavioral’ nên chị sẽ không phải học thêm về nó nữa. Chị còn khá nhẹ nhõm vì mình đã đạt được mục đích của mình là không tự làm bẽ mặt bản thân mà còn được nhận là ‘borderline candidate’. Chị còn chia sẻ thêm mình là candidate được các người phỏng vấn bàn tán nhiều nhất, nhưng vì là 1 công ty lớn nên họ sẽ không mạo hiểm, và nếu không chắc chắn họ sẽ không tuyển. Vì dù sao bạn vẫn có thể về luyện tập thêm, để 6 tháng – 1 năm sau có thể thử lại.
“Điều mình thích ở công ty lớn đó là bạn được nhận hay không là do bản thân bạn thôi!” bạn sẽ chỉ đấu tranh với bản thân mình thôi chứ không cần phải đấu tranh với ai khác, và phụ thuộc vào thực lực của bạn. Cũng như những công ty như Amazon, Facebook, Google, Microsoft, Netflix, Apple thì chỉ cần 1-2 ngày sau là họ đã có kết quả phỏng vấn, dựa vào ‘performance’ của mình để quyết định tuyển bạn hay không.
Đối với các công ty quy mô nhỏ, nhiều người cùng ứng tuyển cho 1 vị trí nên cũng có nhiều yếu tố hên xui trong đó, mặc dù bạn làm tốt nhưng có người khác làm tốt hơn, hay dù họ không làm tốt bằng bạn nhưng lại phù hợp với văn hóa của team hơn, được manager thích hơn thì bạn cũng có thể rớt dễ dàng.
Sau các buổi phỏng vấn này, Hana chia sẻ chị đã có nhiều kinh nghiệm phỏng vấn ở công ty lớn, và làm cho chị tự tin hơn hẳn. Và chỉ cần luyện tập thêm, chị hoàn toàn có thể làm việc được ở những công ty lớn. Và theo resolution của mình, thì đây cũng chỉ là bắt đầu năm 2020, nên Hana cũng không cảm thấy buồn. Ngoài ra chị còn hào hứng chia sẻ với chúng ta là sắp tới Hana sẽ có 1 buổi phỏng vấn với 1 ông lớn trong lĩnh vực tech đó chính là Google. Hãy cùng theo dõi kỳ tiếp theo khi Hana tham dự vòng tuyển dụng tại công ty công nghệ đáng mơ uớc nhất Google và cách chị chuẩn bị CV trước khi apply tại các công ty này nhé.
Trong Java việc tối ưu hoá hiệu năng là công việc rất quan trọng, nó không chỉ giúp code thông thoáng hơn, giúp tiêu tốn ít tài nguyên hệ thống hơn, mà các kĩ thuật được trình bày dưới đây sẽ giúp nâng cao hiệu suất (performance) làm việc của Java khi chạy chương trình!
Một lập trình viên Java có kinh nghiệm luôn coi việc tối ưu hoá hiệu năng như là 1 phần quan trọng của công việc lập trình, trang bị những kĩ thuật, thủ thuật tối ưu sẽ thể hiện một lập trình viên có trình độ và coi nó như 1 kĩ năng không thể thiếu khi làm việc với Java.
Các kĩ thuật dưới đây không phải là những giải thuật toán học cao siêu, cũng không phải triển khai 1 cách phức tạp, đôi khi chúng rất dễ để thực hiện nhưng rất nhiều lập trình viên không để ý hoặc chưa biết cách để triển khai nó.
b. Lưu ý khi viết cấu trúc điều khiển(if, else, while, …)
– Phải sắp xếp đúng thứ tự ưu tiên cho các biểu thức logic
– Xem xét vòng lặp lựa chọn có phù hợp hay không(for, while, do while)?
– Xem xét vòng lặp điều kiện có kết thúc hay không?
– Tối ưu điều kiện kiểm tra của vòng lặp for
– Xem xét việc tính toán có thể được đưa ra ngoài vòng lặp không?
– Khai báo biến tạm để tránh phải gọi hàm tính toán nhiều lần.
c. Lưu ý khi thao tác I/O với file hệ thống
– Tắt line buffering
– Sử dụng các class Reader/Writer để đọc và ghi file theo dòng
– Caching
d. Lưu ý khi thực hiện lập trình đa luồng
e. Sử dụng StringBuilder để nối xâu
f. Phải có thời gian timeout trong các giao tiếp với hệ thống ngoài
g. Tránh ghi log ra console
2. Chi tiết thực hiện
a. Sử dụng lại đối tượng
Có 2 kỹ thuật chính là: Dedicated object reuse và Object pool. Tùy theo trường hợp mà sử dụng một cách hợp lý
– Dedicated object reuse: Khi đối tượng xử lý thường xuyên một công việc lập đi lặp lại.
VD: Cần thực hiện một công việc lập đi lập lại chuyển một đối tượng kiểu Date sang kiểu String. Trong trường hợp này ta nghĩ đến việc sử dụng lại đối tượng Date Formating.
private final SimpleDateFormat dt = new SimpleDateFormat("yyyyy-mm-dd hh:mm:ss");
– Object pool:
+ Trường hợp chúng ta có một loại object(ví dụ object connection kết nối với database), và nhiều tiến trình khác nhau có thể sử dụng đoạn code mà sử dụng object này.
+ Để tránh xung đột giữa các thread trong việc dùng chung object, ta có thể sử dụng synchronized block với block object. Nhưng cách này sẽ chậm hơn việc tạo mới object trên từng thread.
+ Giải pháp trong trường hợp này là xây dụng object pool chứa tập các object có vai trò như nhau. Các thread khác nhau khi cần 1 object thì có thể lấy từ pool, sau khi dùng xong có thể trả lại object cho pool để các thread khác có thể sử dụng.
b. Lưu ý khi viết cấu trúc điều khiển(if, else, while, …)
– Phải sắp xếp đúng thứ tự ưu tiên cho các biêu thức logic
Với câu lệnh:
if(slowFunction() && (i>=0) && (j>i )){}
Phải chuyển thành
if((i>=0) && (j>i ) && slowFunction()){}
– Xem xét vòng lặp lựa chọn có phù hợp hay không(for, while, do while)?
Ví dụ:
while(!isOptimize()){
doOptimize();
}
Nếu trạng thái đầu là chưa optimaze thì nên chuyển thành.
do{
doOptimize();
while(!isOptimize());
– Xem xét vòng lặp điều kiện có kết thúc hay không?
public void sillyLoop(int i)
{
while(i!=0){
i--;
}
}
Nếu trường hợp i<0 vòng lặp sẽ vô hạn.
Nên chuyển thành
public void sillyLoop(int i)
{
while(i>0){
i--;
}
}
– Tối ưu điều kiện kiểm tra của vòng lặp for
for(int i=0; i<str.length();i++)
Nên chuyển thành
for(int i=0; len=str.length(); i<len;i++)
– Xem xét việc tính toán có thể được đưa ra ngoài vòng lặp không?
– Khai báo biến tạm để tránh phải gọi hàm tính toán nhiều lần.
Ví dụ:
if(max<calcScore()){
max=calcScore();
}
Phải chuyển thành
temp=calcScore();
if(max<temp){
max=temp;
}
c. Lưu ý khi thao tác I/O với file hệ thống
– Tắt line buffering: Khi sử dụng PrintStream để ghi dữ liệu ra file, thiết lập mặc định của PrintStream cho phép nó khi gặp ký tự xuống dòng(“\n”) thì sẽ thực hiện flush dữ liệu xuống file. Tuy nhiên trong trường hợp ta ghi nhiều dòng dữ liệu ngắn, việc tự động flush dữ liệu xuống file khi gặp “\n” làm giảm hiệu quả buffering.
VD: PrintStream ps=new PrintStream(bos, false);
– Sử dụng các class Reader/Writer để đọc và ghi file theo dòng: Sẽ nhanh hơn sử dụng class DataInputStream khoảng 20% và không có các vấn đề về convert byte thành character.
– Caching: Khi cần phải đọc các dòng dữ liệu trong file nhưng không theo một thức tự xác định trước, ta nên xem xét việc đọc tất cả các dòng của file trước, lưu(cache) vào vùng nhớ của chương trình trong một ArrayList hoặc Vector để tránh việc thao tác với file nhiều lần.
Kết
Như bạn đã thấy, đôi khi không cần quá nhiều công sức để cải thiện hiệu suất trong Java. Hầu hết những cách trong bài này chỉ cần thêm một sự cố gắng nhỏ là có thể áp dụng chúng vào code của bạn. Chúc anh em thành công nhé.
Ngày 11.3 vừa qua, Tổ chức Y tế thế giới (WHO) đã chính thức công bố căn bệnh viêm đường hô hấp cấp (Covid-19) do chủng mới của vi-rút corona gây ra là “đại dịch toàn cầu”. Tính đến thời điểm hiện tại, dịch bệnh đã lan nhanh tại hơn 160 quốc gia và vùng lãnh thổ với số người nhiễm bệnh lên đến hơn 180.000 ca.
Trong vài tuần trở lại đây, các công ty đã gặp phải những khó khăn lớn về việc kiểm soát và đề ra phương án bảo vệ nhân viên mình ở cả trong và ngoài nước. Vậy trong bối cảnh nguồn nhân lực đang bị ảnh hưởng như hiện tại, điều gì cần phải lưu ý? Bài viết sau đây sẽ giải đáp một số thông tin cần thiết cho nhà tuyển dụng nói riêng và giới nhân sự nói chung.
Vi rút corona là gì?
Những cái tên được giới chuyên môn về y tế kể ra như:
Chủng virus mới 2019
Covid-19
2019-nCoV
Đây là chủng mới của coronavirus được xác định ở Vũ Hán, tỉnh Hồ Bắc, Trung Quốc. Virus nCoV, hay còn gọi là coronavirus, một loại virus đường hô hấp mới, gây bệnh viêm đường hô hấp cấp ở người và cho thấy có sự lây lan từ người sang người. Đây là chủng virus mới chưa được xác định trước đó. Cùng với nCoV, đã có 6 chủng coronavirus khác được biết tới ngày nay có khả năng lây nhiễm ở người.
Theo Trung tâm kiểm soát dịch bệnh tại Hoa Kỳ, nguồn gốc của chủng đặc biệt này vẫn chưa được phát hiện và vẫn chưa có vắc-xin phòng ngừa virus này.
Ở người, vi rút lây từ người này sang người kia thông qua tiếp xúc với dịch cơ thể của người bệnh. Tùy thuộc vào mức độ lây lan của chủng vi rút, việc ho, hắt hơi hay bắt tay có thể khiến người xung quanh bị phơi nhiễm.
Người làm Nhân sự và những hành động cấp thiết
Cho đến khi tìm được vắc-xin hay những phác đồ điều trị, ức chế được sự phát triển của virus, các công ty nên có biện pháp trấn an tinh thần nhân viên. Tránh tạo ra những nguồn thông tin sai lệch làm ảnh hưởng tiêu cực đến nhân viên.
Một số điều cần làm để chúng ta có thể ngăn chặn coronavirus lây lan như: các nhân viên hạn chế việc chạm vào mắt, mũi và miệng của bạn bằng tay khi chưa vệ sinh sạch sẽ. Nếu có bất kỳ triệu chứng như ho, sốt, khó thở, đau nhức, cơ thể mệt mỏi, ngay lập thức phải báo cáo để làm công tác kiểm tra, giám định. tiêu đề tuyển dụng
Để đảm bảo cho sức khỏe của toàn thể nhân viên, công ty cần có những kế hoạch phòng chống cụ thể. Chẳng hạn như đề xuất việc làm việc tại nhà, làm việc từ xa thay vì phải lên công ty. Trường hợp nếu vẫn còn nhiều vấn đề công việc quan trọng và cần phải theo dõi tiến độ chặt chẽ, nên có giải pháp làm việc luân phiên nhau để kịp thời cập nhật tình hình công việc.
Các nhân viên nên hạn chế nói chuyện trừ những trường hợp khẩn cấp. Công ty cần hỗ trợ nhân viên những vật dụng cần thiết như nước rửa tay, khẩu trang,.. hoặc thông tin về những lưu ý cho nhân viên để công tác phòng dịch tốt hơn.
Trước tình hình dịch bệnh ngày một chuyển biến phức tạp, nhiều kế hoạch của các công ty vẫn phải thực hiện và việc gặp gỡ trao đổi các đối tác vẫn diễn ra.
Theo trang thông tin SHRM, vì đây là giai đoạn nhạy cảm nên có thể làm gia tăng sự phân biệt đối xử giữa nhân viên với các đối tác nước ngoài, thậm chí là giữa sếp với nhân viên của mình.
Các nhà quản lý, lãnh đạo nhân sự cần đối xử với những nhân viên của mình một cách công bằng và bình đẳng dù cho họ có dấu hiệu nhiễm bệnh hay là không. Đây là thời điểm mọi người cần ra sức chung tay bảo vệ cho bản thân và toàn tập thể thay vì có những thái độ dè bỉu, lo lắng và bất an với chính những đồng nghiệp xung quanh.
Chú trọng đến chính sách ốm đau cho nhân viên
Nhiều nhân viên tỏ ra sợ hãi và xem đó là cớ để thoát khỏi môi trường làm việc. Vì thế, nhà quản lý nhân sự cần nắm rõ xu hướng tâm lý, cảm xúc của nhân viên mình để có những động thái giải quyết phù hợp.
Trừ những trường hợp thật sự có những dấu hiệu về sức khỏe có liên quan đến dịch bệnh, thì mọi công tác nhân sự vẫn tiếp diễn như bình thường. Đây cũng được xem là thời điểm tốt để người quản lý nhắc nhở các nhân viên mình về các chính sách ốm đau và vắng mặt của công ty.
Thông báo về việc lưu trú
Một số nhà quản lý nguồn nhân lực và lãnh đạo cấp cao có quyền truy cập, giám sát và thông tin cho các nhân viên của mình về dịch bệnh.
Chẳng hạn, Tổ chức Y tế Thế giới, công bố các báo cáo hàng ngày về coronavirus đồng thời cung cấp một bản tóm tắt thông tin tình hình về các triệu chứng, giải pháp chăm sóc, phòng ngừa và điều trị.
Lúc này, HR có vai trò quan trọng trong việc tuyên truyền và triển khai thực hiện các kế hoạch đối phó với dịch bệnh đến với nhân viên; bảo vệ nhân viên và đảm bảo rằng họ luôn được theo dõi tốt về tình trạng sức khỏe, thông tin chính xác về diễn biến dịch bệnh. Đây là biểu hiện rõ nhất minh chứng vai trò của việc quản trị nhân sự trong các tình huống cấp thiết nhất.
Chúng ta không biết được những gì sẽ xảy đến tiếp theo. Tuy vậy, việc cần làm lúc này là các nhà quản trị nhân sự và các nhân viên cần đồng hành cùng nhau để ứng phó với những vấn đề như: bảo vệ sức khỏe, phòng chống dịch bệnh hay việc sẵn sàng giải quyết những khó khăn mà ngành Nhân sự đang phải đối mặt.
Thông thường chúng ta sẽ dùng một nhà kho để chứa dữ liệu state như Redux, một component container bọc ở nút đầu tiên trong app, các component con bên trong có thể truy xuất và cập nhập các dữ liệu một cách dễ dàng
Với các API mới được React bổ sung là useState, createContext, useContext chúng ta có thêm một lựa chọn để làm nhà kho mà ko cần dùng đến Redux
// useAuth.js
import { AuthProvider } from "AuthProvider";
export const useAuth = () => {
const { state, dispatch } = userContext(AuthContext);
const login = () => {
// làm gì đó ở đây
}
const logout = () => {
// làm gì đó ở đây
dispatch({ type: "logout" })
}
// ... còn một số thức khác
const isAuthenticated = () => {
return state.expiresAt && new Date().getTime() < state.expiresAt;
};
// ... còn một số thức khác
return {
isAuthenticated,
user: state.user,
userId: state.user ? state.user : null;
login,
logout,
handleAuthentication
}
}
Với cách làm này, bất kỳ component nào sử dụng useAuth đều sẽ truy xuất đến một kho dữ liệu chung
import useAuth from "useAuth";
const MyCom = () => {
const {
/* quá trời thứ linh tinh trả về */
} = useAuth();
//...
};
Chào các bạn, hôm nay chúng ta sẽ cùng nhau tìm hiểu rõ và chi tiết về các cách sử dụng các toán tử as, as?, as! trong Swift. Các toán tử này cũng là một trong những yếu tố tạo nên tính an toàn trong code Swift. Nếu bạn hiểu rõ nó thì code của bạn sẽ rất an toàn, nếu không thì có thể gây ra bug và crash ứng dụng triền miên.
Để bắt đầu cho bài hướng dẫn này, các bạn nên sử dụng Xcode Playground để thực hành code theo các ví dụ trong bài, nó giúp bạn sẽ dễ hiểu và nhớ lâu hơn. Trong bài này có một vài kiến thức về optional nếu bạn nào chưa hiểu về nó thì có thể tìm hiểu tại đây.
Trước tiên chúng ta sẽ tìm hiểu về 2 ký tự “?”, “!”: Trong khai báo biến, ký tự “?” có nghĩa là ta nói rằng biến đó có khả năng bị nil chứ không phải lúc nào cũng có giá trị. Trong câu lệnh thông thường, dấu “?” xuất hiện báo hiệu rằng biến đó có thể bị nil và khi sử dụng biến đó mà biến đó bị nil thì app sẽ không bị crash. Trong khai báo biến, khi dùng ký tự “!” có nghĩa là chúng cực kỳ chắc chắn rằng biến có “!” sẽ luôn luôn có giá trị. Nếu không có giá trị trong các biến đó thì khi sử dụng biến đó sẽ gây ra crash ứng dụng.
Lưu ý: Khi chúng ta khai báo biến mà không biết biến này có giá trị hay không thì nên dùng ký tự “?” và ngược lại nếu biết biến luôn luôn có giá trị thì chúng ta sẽ dùng ký tự “!”. Ví dụ:
var a:Int?
print(a) // Hiện thị giá trị nil. Không carsh
let b:Int!
print(b) // Sẽ bị báo lỗi ngay lập tức.(Bị crash)
//Chúng ta có thể sửa như sau:
let b:Int! = 1
print(b)
//hoặc
var b:Int!
b = 1
print(b)
As sử dụng trong trường hợp chúng ta muốn ép kiểu(upcasting) dữ liệu nào đó thành một kiểu dữ liệu ta mong muốn. Lưu ý: Khi dùng As bạn phải chắc chắn một điều là kiểu dữ liệu bạn muốn ép kiểu cũng chính là kiểu dữ liệu của biến bạn đang muốn ép, nếu không sẽ xảy ra bug. Ví du:
// Ép kiểu (Up casting)
let button = UIButton()
let view = button as UIView
// Khái báo biến và ép kiểu
let string = "3"
let nsString = string as NSString
let value = nsString.floatValue // 3
let rawString: AnyObject = "Tự học Swift"
let optionalString: AnyObject? = "Tự học Swift"
let nilString: AnyObject? = (nil as String?)
let rawInt: AnyObject = Int(3)
let optionalInt: AnyObject? = Int(3)
let nilInt: AnyObject? = (nil as Int?)
// Sử dụng as
let result1 = rawString as String // AnyObject is not convertible to String
let result2 = optionalString as String // AnyObject? is not convertible to String
let result3 = nilString as String // AnyObject? is not convertible to String
let result4 = rawInt as String // AnyObject is not convertible to String
let result5 = optionalInt as String // AnyObject? is not convertible to String
let result6 = nilInt as String // AnyObject? is not convertible to String
Tuy nhiên chúng ta có thể sử dụng cách ép kiểu an toàn bằng cách dùng toán tử sau: As? Được dùng giống như As nhưng khác biệt ở chỗ là nếu trường hợp chúng ta ép kiểu không thành công nó sẽ trả về trị nil. Để hiểu rõ hơn chúng ta xem ví dụ sau: Ví dụ:
let string = "3"
let nsString = string as NSString
let value = nsString.floatValue // 3
let rawString: AnyObject = "Tự học Swift"
let optionalString: AnyObject? = "Tự học Swift"
let nilString: AnyObject? = (nil as String?)
let rawInt: AnyObject = Int(3)
let optionalInt: AnyObject? = Int(3)
let nilInt: AnyObject? = (nil as Int?)
// as?
let result17 = rawString as? String // String? "Tự học Swift"
let result18 = optionalString as? String // String? "Tự học Swift"
let result19 = nilString as? String // String? nil
let result20 = rawInt as? String // String? nil
let result21 = optionalInt as? String // String? nil
let result22 = nilInt as? String // String? nil
let result23 = rawString as? String! // Không thể ép kiểu từ AnyObject sang kiểu optional String!
let result24 = rawString as? String? // Không thể ép kiểu từ AnyObject sang kiểu optional String?
let result25 = optionalString as? String! // String!? "Tự học Swift"
let result26 = optionalString as? String? // String?? "Tự học Swift
let result27 = optionalInt as? String? // String?? nil
As! Được dùng Giống như As vậy tuy nhiên nó sẽ bắt buộc biến của chúng ta muốn ép kiểu phải trở thành kiểu dữ liệu nào đó. Nếu trường hợp biến đó không thể ép về kiểu đó thì sẽ xảy ra crash ứng dụng ngay. Lưu ý: Sử dụng thèn này rất nguy hiểm, nếu không chắc chắn được rằng kiểu chúng ta muốn ép sẽ thành công thì sẽ gây ra crash ứng dụng. Nếu chúng ta cảm thấy không chắc chắn hay mơ hồ về việc ép kiểu dư liệu này thì chúng ta nên dùng as? Để bắt trường hợp không ép thành công và xử lý tiếp. Ví dụ:
if let cell = tableView.dequeueReusableCellWithIdentifier("Cell") as? UITableViewCell {
//Nếu chúng ta ép kiểu thành công thì sử dụng biến cell để làm gì đó
} else {
// Ép không thành công thì chúng ta xử lý gì đó
}
Ví dụ:
let string = "3"
let nsString = string as NSString
let value = nsString.floatValue // 3
let rawString: AnyObject = "Tự học Swift"
let optionalString: AnyObject? = "Tự học Swift"
let nilString: AnyObject? = (nil as String?)
let rawInt: AnyObject = Int(3)
let optionalInt: AnyObject? = Int(3)
let nilInt: AnyObject? = (nil as Int?)
// as!
let result7 = rawString as! String // String "Tự học Swift"
let result8 = optionalString as! String // String "Tự học Swift"
// let result9 = nilString as! String // unexpectedly found nil while unwrapping an Optional value
// let result10 = rawInt as! String // Could not cast value of type '__NSCFNumber' (0x107c98130) to 'NSString' (0x1082afb00).
// let result11 = optionalInt as! String // Could not cast value of type '__NSCFNumber' (0x101e95130) to 'NSString' (0x1024acb00).
// let result12 = nilInt as! String // unexpectedly found nil while unwrapping an Optional value
// let result13 = rawString as! String! // Không thể ép kiểu từ AnyObject thành kiểu optional String!
// let result14 = rawString as! String? //Không thể ép từ kiểu AnyObject thành kiểu optional String?
let result15 = optionalString as! String! // String! "Tự học Swift"
let result16 = optionalString as! String? // String? "Tự học Swift"
Lưu ý:As! Cũng không thể ép kiểu dữ liệu nào đó thành kiểu optional. As? Và As! Ngoài việc ép kiểu để tạo ra biến mới và sử dụng nó thì chúng còn có công dụng để kiểu tra xem biến đó có chính xác thuộc loại kiệu dữ liệu mà mình muốn kiểm tra hay không. Nếu bạn ép kiểu thành công với as? Thì nó sẽ cho bạn một biến mới kiểu optional, ngược lại với as!, khi bạn ép kiểu thành công nó sẽ cho ra một biến bình thường. Để hiểu hơn chúng ta sẽ tham khảo ví dụ bên dưới:
Ví dụ 1:
var optionalString = dict.objectForKey(“SomeKey”) as? String
optionalString Sẽ là một biến optional kiểu String?, Nếu trường hợp chúng ta không ép kiểu thành kiểu dữ liệu String, có nghĩa là sẽ có trường hợp nào đó mà giá trị của dict.objectForKey(“SomeKey”) là một kiểu dữ liệu nào đó khác String thì khi đó dùng as? String sẽ ép kiểu không thành công thì biến optionalString sẽ được gián nil.
Ví dụ 2:
var optionalString = dict.objectForKey(“SomeKey”) as! String?
Trường hợp này thì bạn nói với hệ thống là kiểu dữ liệu của dict.objectForKey(“SomeKey”) là kiểu String?, chắc chắc là kiểu String?. Nếu khẳng định trên của bạn là đúng thì chúng ta sẽ có một biến optionalString với kiểu String? Nhưng không may nếu khẳng định của bạn là sai, có nghĩa là dict.objectForKey(“SomeKey”) không phải là kiểu String?, thì sẽ xảy ra crash ngay lập tức. Vậy giải pháp ở đây là chúng ta sẽ sử dụng cú pháp if let hay guard let… để kiểm tra kiểu dữ liệu của biến đó, nếu ta không chắc chắn. Ví dụ:
if let string = dict.objectForKey("SomeKey") as? String {
//Sử dụng biến đó
println(string)
} else {
// Làm gì đó nếu biến đó không phải kiểu String
}
Guard let string = dict.objectForKey("SomeKey") as? String else {
// Làm gì đó nếu biến đó không phải kiểu String
return
}
//Sử dụng biến đó
println(string)
Kết thúc phần này tuy không mấy khó hiểu nhưng nếu các bạn thực sự không nắm chắc và hiểu rõ về các từ khóa as, as?, as! thì khi sử dụng có thể gây ra crash ứng dụng một cách vô lý. Nếu bạn nào chưa rõ nên thực hành các ví dụ bên trên với background để hiểu và nhớ lâu hơn các trường hợp nên dùng và không nên dùng các từ khóa trên. Hy vọng các bạn thích và học được nhiều kiến thức từ bài viết này. Mong các bạn chia sẽ nó để mọi người cùng học và cùng trao đổi. Mọi thắc mắc hay trao đổi về bài viết, các bạn có thể để lại bình luận bên dưới mình sẽ hỗ trợ sớm nhất.
Chân thành cảm ơn các bạn đã theo dõi.
Là CTO của công ty DOF Hunt, ít ai biết anh Việt từng kinh qua vị trí Software Architect tại trang thương mại điện tử Sendo. Trong mục “Chuyên gia nói” tuần này, hãy lắng nghe những kinh nghiệm được anh chia sẻ về con đường phát triển để trở thành Software Architect, cùng những góc nhìn độc đáo của một DevOps Manager khi quản lý dự án và hơn hết là kinh nghiệm triển khai hệ thống Microservices từ anh Việt nhé.
Những công việc của Software Architect
Chào anh Việt. Khi còn là Software Architect thì anh thường xử lý những công việc gì?
Chính xác thì vị trí của tôi là Technical Architect, hay còn gọi là Solution Architect nhiều hơn, và trang thương mại điện tử như mọi người biết đó là Sendo. Software Architect sẽ lo về mảng thiết kế và làm bên hệ thống là phần lớn, tuy nhiên thì Software Architect và Solution Architect có điểm khác nhau, nằm ở chủ yếu Solution Architect thì chúng ta phải thiết kế về hệ thống nhiều hơn còn Software Architect thì chúng ta thiết kế về phần mềm nhiều hơn.
Anh có thể chia sẻ cho độc giả biết thêm hành trình đến với vị trí Software Architect của anh như thế nào?
Hành trình đến Architect của bản thân tôi khá là nhiều bước và vất vả, thông thường để làm 1 Architect thì chúng ta phải đưa ra những quyết định về giải pháp, về kinh nghiệm để lựa chọn giải pháp đó, theo tôi thì chúng ta bắt buộc phải đi qua một số thứ như từ 1 vị trí lập trình, đôi khi là tester nữa, cho đến thiết kế hệ thống.
Anh có thể chia sẻ thêm về mối tương quan giữa Software Architect và thương mại điện tử được không ạ?
Về Architect, nó sẽ theo nghiệp vụ, như các bạn đã biết Sendo là 1 trang thương mại điện tử và thương mại điện tử nó sẽ yêu cầu lượt tải cao, tức traffic rất lớn, thường thì Architect bên tôi phải thiết kế hệ thống có những thành phần nào đó mà nó phải chịu tải lớn như Caching rồi về Online transaction nhiều hơn, đó là phần khác biệt theo mình là lớn nhất so với những vị trí Architect khác.
Thường một ngày làm việc của anh như thế nào?
Thật ra thì vị trí Architect của tôi là một vị trí vất vả nhưng cũng không vất vả lắm, ví dụ như các bạn thấy những bạn coder thì mấy bạn sẽ quan tâm tới code, tới debug, tới làm thế nào mà để có thể có được cái sản phẩm đấy, nhưng vị trí của mình thì liên quan tới thiết kế, các bạn thấy là bên mình sẽ thiết kế, vẽ và tính toán hệ thống nhiều hơn, đó cũng là một sự khác biệt lớn ở đây.
Một ngày tôi dành khoản 1 vài tiếng để lên tham khảo các công nghệ mới hiện tại cập nhật, như các trang Medium hoặc đọc TopDev cũng là 1 kênh mà tôi cũng thường xuyên vào.
Anh có thể kể tên một vài công nghệ và công cụ mà anh sử dụng hàng ngày được không?
Thật ra thì công nghệ và công cụ nó sẽ đi theo cái thiết kế là nhiều, và nó phải hợp lý với cái nghiệp vụ đó cần, nếu như mà tôi được phép lựa chọn ở đây thì chắc là tôi sẽ lấy 1 ví dụ cá nhân ra thôi: backend tôi thường sử dụng Golang, bên Database thì tôi sẽ xài MySQL, Mongodb và Elasticsearch để làm 1 search engine và những công cụ cache thì tôi có Redis Cache thì nó đã quá nổi tiếng rồi, rồi Message broker thì tôi sẽ dùng Kafka hoặc là NAS và những cái như mọi người biết về Docker Container thì sẽ xài qua Kubernetes, sơ sơ là như vậy còn thường thì cụ thể tôi mới biết là mình chọn cái gì, nó mới đúng hơn.
Những kinh nghiệm xương máu khi ở vị trí Software Architect
Sai lầm lớn nhất anh từng mắc phải trong công việc Software Architect là gì?
Sai lầm lớn nhất ở vị trí Software Architect của tôi, thật ra tôi đã làm Software Architect được 1 thời gian rồi, chỉ qua là tôi không biết là mình đang làm về nó, đó là một điều thú vị. Mãi sau này thì anh mới biết thôi, thì cái sai lầm đến nó nhiều lắm, có những cái đến như là đứng hình ở IP là cái thường thấy nhất và hệ thống đang chạy nhưng mà đến lúc vào thời điểm quan trọng thì nó chết, thường những sai lầm mà cho tới ngày hôm nay tôi cũng sẽ gặp nhưng mà ít ra thì tôi cũng đã có những kinh nghiệm mà biết cách giải quyết nó tốt hơn rồi.
3 lời khuyên anh muốn gửi đến các bạn mong muốn trở thành Software Architect là gì?
3 lời khuyên của anh thật ra dành cho tất cả các bạn theo ngành này chứ không chỉ là Software Architect. Thứ nhất các bạn phải đam mê thật sự với ngành. Thứ hai là các bạn phải tò mò và thứ ba là các bạn phải can đảm. Theo anh thì đó là những tố chất mà anh hay dùng để tuyển dụng.
Làm sao để trở thành một Software Architect
Từ vị trí Developer, cần phải trải qua những vị trí nào để trở thành Software Architect?
Theo như anh nói thì Software Architect phải biết rộng, cho nên các bạn sẽ phải thử càng nhiều càng tốt, cho nên mấy bạn bắt đầu với vị trí gì cũng được, không nhất thiết sẽ phải là từ vị trí lập trình. Thông thường thì chúng ta thấy 1 bạn từ background sysadmin thì sau này sẽ trở thành 1 bạn Solution Architect nhiều hơn là 1 bạn về lập trình, thậm chí 1 bạn chưa biết lập trình cũng được, các bạn chỉ cần đam mê công nghệ, các bạn có thể được trao cơ hội dấn thân vào nhiều hơn, anh nghĩ thì đó là 1 cái cơ hội tốt.
Theo quan điểm cá nhân của anh thì các bạn Developer tại Việt Nam nên có những hướng đi tiềm năng nào trong tương lai?
Theo quan điểm cá nhân của anh, hiện tại mấy bạn cũng biết, mobile app đang rất là phát triển và một thứ khác nữa là về mảng Data, cái đó các bạn có thể focus nhiều vào 2 mảng này, còn trong tương lai thì thật ra công nghệ thay đổi rất là nhanh, vấn đề ở đây anh thấy các bạn phải nên chọn 1 cái và lấy cái đó làm trọng tâm và thực sự hiểu biết nó, tức là theo anh cái về sau có thuật ngữ gọi là ‘domain knowledge’ rất là quan trọng, thành ra mình nên chuyên 1 cái gì đó trước, sau đó phát triển cái khác, còn nếu để lựa chọn về tương lai thì tôi vẫn tin Big Data sẽ là tương lai và xu thế.
AI – Trí tuệ nhân tạo hiện nay đang là vấn đề nóng, anh có thể chia sẻ quan điểm cá nhân của anh về tiềm năng của AI không?
Thật ra là tiềm năng và khả năng của AI thì anh cũng đã nhìn thấy được phần nhiều rồi, thật ra là chúng đang càng ngày càng len lỏi vào đời sống của mình nhiều hơn, thí dụ như ngày xưa, chúng ta chỉ nghe tới AI là những con robot trong phim thôi, thì bây giờ chúng ta thấy rất là nhiều thiết bị trong nhà mình, thậm chí cái bóng đèn chẳng hạn, cái quạt có bóng đèn, tủ lạnh cũng đã trang bị được AI rồi, theo anh đó là 1 hướng đi mà chắc chắn sẽ phải xảy ra và càng ngày càng bám liền với đời sống của mình nhiều hơn nữa.
Nếu có một điều mà anh biết trước khi bắt đầu làm, thì điều đó là gì?
Nếu mà có một điều tôi biết trước khi bắt đầu làm thì thực sự là anh chỉ muốn ngày xưa mình sẽ can đảm hơn, mình dám làm nhiều thứ hơn và nếu mà tìm được 1 ai đó để mình theo đuổi học hỏi, mình biết người đó có thể giúp mình thì mình nên làm.
Anh có thể chia sẻ những resource cho các bạn muốn trở thành Software Architect không?
Theo anh thì cái đó nó phụ thuộc vào lực học của mỗi người, nghĩa là có nhiều bạn tôi thấy hay xem youtube, có nhiều bạn thì hay xem facebook, có nhiều bạn thì tích lũy qua công việc của họ, nên ở đây mình sẽ không có 1 nguồn cụ thể nào nhưng mà nguồn anh hay đọc nhất là trang web Medium.
Thì em được biết là anh ngoài Solution Architect, anh còn là DevOps chuyên tư vấn giải pháp triển khai Microservices cho các công ty. Anh có thể định nghĩa DevOps là gì không?
DevOps thực ra là 1 từ ghép từ Develop và từ Operations, là chữ DevOps, điều đó có nghĩa là gì, có nghĩa là thứ nhất các bạn phải là Dev trước cái đã, điều thứ hai là các bạn phải ‘operation’ nó, tức là bạn phải quản lý được nó, điều hành nó. Nói một cách đơn giản hơn thì DevOps cụ thể nó như thế này, nó là chúng ta sẽ phải liên quan tới cái phần triển khai, quản lý và cài đặt các service của mình trên hệ thống.
Em có thắc mắc là DevOps Engineer là gì? Có phải là Sysadmin không ạ?
2 cái này thực sự nếu so sánh thì nó sẽ có 1 cái khoảng cách rất mỏng bởi vì đa số hiện nay Sysadmin là background của DevOps, có nghĩa rất là nhiều bạn đi lên từ Sysadmin, tuy nhiên sự khác biệt ở đây phân rõ ra luôn thì Sysadmin đa số hiện tại như anh biết họ sẽ làm nhiều về infrastructure, nghĩa là người sẽ thiết kế máy chủ và đảm bảo các máy chủ nó sẽ nói chuyện được tốt với nhau, liên quan tới như là Data Center rồi các thiết bị phần cứng để mà vận hành cái hệ thống máy chủ đó.
Còn về DevOps thì các bạn sẽ làm về phần mềm nhiều hơn, mặc dù nó không có liên quan tới phần lập trình nhiều, tuy nhiên nó lại liên quan tới phần làm thế nào để mà mình có thể giám sát được những hệ thống đó chạy và làm thế nào để mình triển khai được cái hệ thống đó khi mà lên Microservices.
Anh có thể giải thích rõ hơn “Tư tưởng mới, Công cụ mới, Kỹ năng mới” trong công việc của DevOps Engineer là gì không ạ?
Đó là lý do tại sao anh hay nói các bạn lập trình viên mới hay là những bạn theo ngành thì nên có tính tò mò cao, bởi vì tính tò mò sẽ cho chúng ta cái động lực để hiểu biết nhiều hơn, và công nghệ chúng ta đang ngày càng thay đổi thì mình phải cập nhật nhanh, đôi khi đối với cái chúng ta đang làm hiện tại đã có 1 ai đó 1 bên nào đó làm trước đó rồi hoặc là đang có giải pháp mới mà rất là phù hợp hơn rồi thì anh hay nói là mình phải làm đúng tức là tìm đúng công cụ cho đúng cái điều mình cần.
Theo anh, những kiểu Developer nào sẽ dễ trở thành DevOps nhất?
Theo như anh hiểu câu hỏi này thì những bạn Developer trong những lĩnh vực nào sẽ trở thành DevOps, thì ở đây theo anh, bạn Developer về Backend có khả năng dễ trở thành DevOps hơn, bởi vì DevOps hiện tại liên quan tới hệ thống, về server nhiều, ra là những bạn đang làm Backend thì có tốt chất dễ, tức là dễ đưa đến DevOps nhiều hơn. Tuy nhiên, cần 1 yếu tố nữa, đó là những bạn nào mà yêu thích thiết kế cơ, tức là mình sẽ được phép làm nhiều, là mình được lựa chọn công cụ mình được thiết kế nó chạy như thế nào, đó là những người mà tôi tin chắc là họ sẽ lên DevOps rất nhanh.
Theo anh thì đâu là lợi thế của các bạn DevOps so với các bạn Developer khác?
Lợi thế lớn nhất của các bạn DevOps so với các Developer khác thì đây là 1 vị trí rất là hot hiện tại, nó hot là vì chúng ta đang càng lúc càng cần những vị trí này nhiều hơn, vì các công ty đang muốn chuyển mình thành 1 công ty công nghệ và trở thành 1 công ty deploy được microservice, mà để lên microservice thì chúng ta cần những bạn DevOps để có thể làm được những chuyện đó, nên theo anh những bạn nào đang muốn trở thành DevOps, anh nghĩ đó là 1 quyết định rất sáng suốt vào lúc này.
Ở cương vị là một DevOps Manager, tiêu chí quan trọng nhất để anh tuyển dụng một DevOps Engineer là gì?
Những tiêu chuẩn và tiêu chí, theo bản thân anh thôi thì đó nên là 1 bạn có kiến thức về hệ điều hành Linux, và nên biết xài 1 số công cụ như chúng ta hay nghe thuật ngữ CI/CD, đó là những cái các bạn cần phải biết. Bên cạnh đó thì DevOps là 1 từ để chỉ vị trí công việc thôi, nếu mà nói cụ thể thì ví dụ 1 công ty về thương mại điện tử, họ sẽ cần các DevOps cho các công cụ có liên quan, lúc đó lại cần chia ra như là DevOps cho mảng BigData, DevOps cho các mảng về thương mại điện tử và DevOps cho các mảng về rất là nhiều, rất là nhiều loại, theo tôi là như vậy.
Anh có thể chia sẻ thêm một chút về lý do tại sao anh lại chọn chuyển hướng sang DevOps Engineer không ạ?
Lý do rất là đơn giản thôi, bởi vì nó đi từ nhu cầu của mình, lúc đó mình đang làm giải pháp khách hàng và họ đang gặp rất nhiều vấn đề bên phía hệ thống, trong quá trình đó thì mình vừa làm vừa nghiên cứu và mình vừa đi chung với họ và 1 cách vô tình anh trở thành DevOps, thật ra anh không phải là người làm DevOps chuyên.
Sai lầm lớn nhất mà anh từng mắc phải khi làm DevOps Engineer là gì?
Sai lầm DevOps theo anh nghĩ sai lầm này đến phần nhiều là do những cái mình đã biết, tôi hay dùng những cái như chính những cái mình đang biết nó là cái rào cản cho những cái mình đang học, nghĩa là mình đem DevOps chúng ta sẽ phải làm quen với những khái niệm mới và đôi khi cách triển khai và cài đặt nó sẽ rất khác so với cách truyền thống của chúng ta và rất là nhiều cái nó sẽ phải yêu cầu mình gần như không được sử dụng những cái cũ thì mình phải làm việc trên những cái mới và thường thì những người như anh lúc trước chưa quen thì mình dễ mắc phải những sai lầm đó hơn.
Đa số các bạn Developer thường hay thức khuya, anh có thể chia sẻ về cách phân bố thời gian của mình và lời khuyên nào dành cho các Developer hay không?
Theo anh thì đây là một câu hỏi hay, vì anh vẫn thường hay khuyên những bạn Developer làm chung là bản thân các bạn Developer thì ai cũng giống ai hết, thường hay thức khuya rồi dậy muộn, chứ thức khuya dậy sớm thì nó còn dễ, lúc trước tôi là như thế, nhưng mà sau này khi mà mình làm việc với những công ty lớn và yêu cầu sự chuyên nghiệp và chuẩn chỉnh hơn thì theo tôi sự phân bổ thời gian nó nên thế này: nên dành thời gian mà mình cảm thấy mình sáng tạo và tập trung nhất, có người có thể là sau buổi giờ chiều, có người thì sẽ là đầu giờ mỗi ngày 5 6 giờ sáng, như tôi thì tôi hay dậy vào 6 giờ sáng, đọc Medium hoặc là ngồi suy nghĩ phân tích hệ thống nhiều hơn, còn những thời gian khác thì dành cho những việc mình đã biết rõ rồi chỉ cần xử lý chân tay thôi.
Thí dụ bạn nào là Dev, theo tôi 1 ngày 8 tiếng để code, thì hãy code ít hơn, có 6 tiếng thôi; còn 2 tiếng mình tái đầu tư bản thân mình nhiều hơn, để mình học hỏi nhiều hơn. Theo tôi điều đó nó sẽ có lợi cho các bạn khá là nhiều.
Anh có thể chia sẻ về một kỉ niệm đáng nhớ cũng như kinh nghiệm xương máu khi chuyển đổi mô hình cho công ty khách hàng được không ạ?
Lúc trước anh có làm 1 đơn hàng như sau, cũng là chuyển đổi 1 cái hệ thống monolithic sang microservice, tuy nhiên phần lớn khách hàng ở Việt Nam mình, đặc biệt là những khách hàng bự thì họ hay có 1 hệ thống đã rất là lâu năm rồi và cái việc chuyển đổi đó nó không phải là 1 chuyện đơn giản 1 sớm 1 chiều và đôi khi cái phần nhiều là đến từ những bạn đang xài những cái license, thí dụ như những hệ thống EIP, họ mua về luôn rồi thì anh lại không được phép can thiệp vào hệ thống của họ để anh làm, thì đó cũng là 1 khó khăn rất lớn, nhưng lần đó mình đưa ra 1 chiến lược là mình xây mới, tức là anh dời qua từ từ, cũng giống như câu chuyện ở Sendo thôi. Từ từ từ từ anh tìm cách chứng minh là nó tốt hơn, sau đó họ mới chấp nhận. Đó là 1 kỷ niệm hồi anh cũng chưa có chuyên nghiệp lắm về mảng này, thì anh đã có trải qua về nó.
Động lực nào có thể giúp các bạn lập trình viên có thể hoàn thành tốt công việc?
Anh có lời khuyên nào dành cho các bạn Developer, để tạo động lực cho các bạn để chạy KPI, chạy Deadline, chạy Task được không ạ?
Đây cũng là 1 câu hỏi khá là thú vị với anh, thật ra cái chuyện mà anh chạy KPI, deadline này nọ đối với ai thì nó cũng có hết. Nhưng mà bên phía bọn anh thì có cái động lực nhiều hơn là 1 chuyện gì đó mà mình cảm thấy áp lực. Thì ở đây anh thường yêu cầu mấy bạn là để thành 1 Developer giỏi thì mình nên biết lười. Có nghĩa là những thứ mà chúng ta đang làm tay chân, những thứ mà mình cứ phải ngán ngẩm với nó thì mình nên có cách nào đó để mình cho nó tự động, mình nên dùng chất xám của mình vào những cái chỗ như vậy để mình khiến cho nó nhẹ nhàng hơn, càng về sau 1 phần là năng suất của các bạn nó sẽ tăng lên và 1 phần nữa là tự động những chuyện đó nó không còn là cái chuyện mà nó còn áp lực nữa. Mỗi lần như vậy thì chắc chắn là chúng ta sẽ có 1 giải pháp cho nó, vì anh là dân Technical – mình là dân Kỹ thuật, mình lập trình được thì anh tin là mình nên có cái cách nghĩ đó.
Anh hay dùng cách thức hay công nghệ gì để quản lý công việc của team, cũng như đo đạc hiệu quả làm việc của họ?
Nhân câu hỏi này anh cũng muốn chia sẻ 1 điều là bên anh theo triết lý quản trị tốt nhất là không có quản trị. Bên anh rất ít khi nào phải thường khắt khe KPI, hay phải hối thúc các bạn cả. Vì ngay từ đầu mình nên xây dựng cái văn hóa, đó là lý do mà anh cần những bạn có đam mê thật sự và tò mò cũng như yêu thích những thử thách, những người như vậy sẽ mang đến cho mình 1 cái trải nghiệm rất khác. Bên tôi chỉ xài Trello thôi, đó là 1 chương trình để mình quản lý các task của mấy bạn và về mặt quan trọng khác, anh nghĩ yêu cầu quan trọng nhất ở đây là sự giao tiếp của team. Chỉ cần team mình giao tiếp tốt và đầy đủ thì đã giải quyết rất là nhiều rồi. Ví dụ như là mỗi buổi họp chúng ta nên có văn hóa là note lại, viết docs, hoặc viết tất cả hoặc là chia sẻ thì nhiêu đó thôi đã đủ cho việc quản lý của mình.
Theo như anh chia sẻ thì cách của anh là quản trị như không quản trị, nhưng với những công ty, tập đoàn có hàng ngàn Developer. Anh có thể chia sẻ một chút trên góc nhìn của anh về vấn đề này được không?
Chia sẻ về việc này thì việc này nên làm từ đầu, nghĩa là khi bạn là 1 công ty nhỏ, 1 startup khoản chừng 5 tới 10 người thì mình nên làm trước, là mình đã quán triệt với nhau, sau đó những người mới vào họ sẽ theo cái văn hóa đó. Thật ra dùng từ ‘theo’ thì không đúng lắm, nó hơi bị gượng ép, đúng ra chúng ta sẽ tìm kiếm những người phù hợp, thì ngay từ đầu họ phù hợp rồi. Còn đối với những công ty đạt con số tính bằng hàng ngàn người như vậy thì hiện tại có những quy trình rất là nổi tiếng ở ngoài như mọi người biết đó là Scrum và Agile hoặc là họ xài đơn giản hơn là OKR, thì tôi thấy OKR nó khá là hiệu quả, ở Sendo cũng xài OKR, nghĩa là mình chỉ cần quan tâm tới cái Key action thôi và cái result nó là gì.
Nỗi sợ lớn nhất của anh trong công việc công nghệ là gì?
Nỗi sợ lớn nhất trong công việc lập trình thường nó đến từ chuyện không biết cái mình đang làm có thực sự tốt hay không, thì đó là phần lớn những cái tôi sẽ phải lo lắng nhiều hơn. Lý do là khi mình làm ở vị trí system là như mình đang giữ kho bạc của người ta vậy, chỉ cần 1 sai lầm rất nhỏ thôi cũng dẫn đến cái giá phải trả rất đắt, cho nên đó thường là những nỗi lo của người làm system, nhưng rất may mắn là hiện tại thì công nghệ nó đã giúp ích cho mình rất nhiều rồi, mình cũng không cần phải lo lắng nhiều như vậy nữa.
Đâu là những khó khăn trong việc tuyển dụng Lập Trình Viên
Hiện tại ngành công nghệ thông tin ở Việt Nam hiện nay rất HOT, “Cầu” vượt xa “cung”, dẫn đến hàng loạt doanh nghiệp gặp khó khăn trong vấn đề tuyển dụng, theo anh đâu là cốt lõi của vấn đề này?
Tôi cũng thường chia sẻ về vấn đề này, số lượng lập trình viên của Việt Nam mình nhiều, số lượng công ty cần cũng nhiều, nhưng 2 tập đối tượng này thường rất khó để tìm đến được với nhau. Lý do phần lớn theo tôi là do cái chất, ý anh là chất lượng lập trình viên của mình còn khá là thấp, tức là về mặt chung thì còn khá là thấp.
Thứ 2 là các bạn đang chạy theo xu hướng, tức là chạy theo yêu cầu tuyển dụng nhiều hơn. Ví dụ như: Cách đây 2 năm thì React Native mình mới phát triển thôi, lúc đó mọi người bắt đầu đổ qua học, sau đó mọi người thấy là sắp tới sẽ tuyển dụng React Native thì mình sẽ học React Native, rồi sau đó ai ai cũng học React Native thì nó lại như vậy, nghĩa là mình phải nhớ 1 điều là lương của mình nó sẽ tỉ lệ nghịch với độ hiếm kỹ năng hay là với mức độ tìm kiếm của người ta. Tức là nếu tuyển 1 bạn làm A mà ở đâu cũng có thì chắc chắn lương bạn sẽ thấp, nên chưa chắc là các bạn đi theo những xu hướng thị trường nó là tốt, nên như mình nói chắc chắn phải có 1 điều là phải đam mê thật sự với cái mình chọn.
Tham khảo thêm: Các vị trí tuyển lập trình React Native lương cao tại Topdev
Anh có thể chia sẻ cụ thể về lộ trình nghiên cứu hay học, của các công nghệ hiện có để đảm bảo tối thiểu có thể làm việc cùng với team của anh?
Theo tôi thì lộ trình của mỗi người nó sẽ phụ thuộc vào cái cách mà team và bản thân họ làm việc, cũng như cái trải nghiệm của mỗi người nó sẽ khác nhau. Nhưng tôi cảm giác ví dụ như 1 người mới hoàn toàn mà muốn bước chân vào lập trình thì điều đầu tiên nhất là phải nên làm luôn chứ đừng dùng tư duy là mình sẽ cần đến 1 nơi để học rồi mới làm được, đó là điều theo tôi không cần thiết.
Anh đưa ra ưu điểm nào của mình để thu hút được ứng viên?
Bên tôi tuyển dụng, nếu cho DOF Hunt thì tôi thấy nó đơn giản hơn, thông thường tôi sẽ đưa ra những thách thức, những vấn đề của bên DOF Hunt, để xem các bạn phản ứng với nó như thế nào hoặc các bạn có giải pháp gì cho nó không, thì đó là tiêu chí hàng đầu của tôi. Còn nếu 1 bạn fresher, tức là chưa biết gì thì đến DOF Hunt tôi chỉ yêu cầu 1 thứ thôi, đó là bạn có yêu thích sản phẩm hay không, có thực sự yêu thích nó hay không.
DOF Hunt như mọi người biết thì nó là 1 mạng xã hội dành cho nhiếp ảnh, nghĩa là liên kết mẫu ảnh và các bạn chụp ảnh, thành ra thường thì bên Developer mình sẽ không quan tâm nhiều lắm đến mảng này, nhưng nếu bạn có quan tâm thì tôi nghĩ mấy bạn sẽ là người phù hợp.
Những chia sẻ về DOF Hunt
Cơ duyên nào đưa anh đến với việc khởi nghiệp DOF Hunt?
Thật ra tôi là 1 người rất thích khởi nghiệp, tuy nhiên tôi là 1 người làm về kỹ thuật, và tôi tin là rất là nhiều bạn kỹ thuật làm về khởi nghiệp thường hay thất bại nhiều hơn, vì thật ra kỹ thuật thì các bạn biết nó chỉ là ⅓ tấm vé để tham gia cuộc chơi khởi nghiệp thôi và bởi vì chúng ta là người làm kỹ thuật thì cái cảm giác cái gì chúng ta cũng làm được hết, nhưng về mặt làm thế nào để kiếm tiền hoặc là bán nó thì đó là 1 điều có cảm giác rất là khó, vì đó là thứ yếu của dân kỹ thuật nói chung.
Còn về cơ duyên với DOF HUNT, thì 1 ngày đẹp trời thôi tôi được giới thiệu cái máy chụp hình, thật ra thì trước đó tôi có làm 1 giải pháp liên quan tới nén hình ảnh thì trong hình ảnh tôi phát hiện ra 1 thứ thú vị đó là cái EXIF. EXIF là thông tin hình ảnh đó, ảnh đó được chụp máy gì, lens gì, khẩu tốc bao nhiêu, tôi thấy nó khá là hay và tôi mới tìm hiểu thử 1 cái máy ảnh rồi từ từ tự nhiên mình trở thành 1 bạn giống như là đi học chụp hình luôn, rồi tôi đi tham gia 1 số các câu lạc bộ offline chụp hình.
Từ đó tôi mới thấy được chuyện là những bạn mới vô máy ảnh đa số ở Việt Nam mình thì chắc chắn là chụp người nhiều, và mấy bạn đi kiếm mẫu ảnh rất là nhiều và mẫu ảnh thì cũng đang có nhu cầu ngược lại và bên cạnh đó thì những bạn làm về kinh doanh như là chủ shop thời trang và các thương hiệu thời trang thì cũng có nhu cầu, thì tôi mới nghĩ là nếu vậy thì tại sao mình không dùng cái hiểu biết của mình trong mảng kỹ thuật để mình giải quyết nhu cầu đó, nên đó là lý do tôi thành lập DOF Hunt.
Xin cảm ơn anh Việt đã dành thời gian trao đổi cùng TopDev. Hy vọng bài phỏng vấn này cung cấp cho các bạn độc giả cái nhìn rõ nét về chức năng của một Architect trong ngành Lập trình, cũng như định hướng cho bản thân kiến thức chuyên sâu và tự đặt ra con đường phát triển sự nghiệp vững chắc. Đón chờ bài phỏng vấn tiếp theo trong mục Chuyên gia nói cùng TopDev nhé!
Bạn đã biết hoisted? Bạn cần biết thêm khái niệm Temporal Dead Zone là đủ một cặp
Khu vực tự trị, ngoài vòng pháp luật.
Đoạn code bên dưới sẽ cho kết quả thế nào, đố bạn
// có chạy được ko, chưa khai báo `Car`
new Car('red');
class Car {
constructor(color) {
this.color = color;
}
}
hoặc gọi một hàm trước khi nó được khai báo
// có chạy được ko, chưa khai báo greet
greet('VuiLapTrinh');
function greet(who) {
return `Hello, ${who}!`;
}
Đáp án là, với trường hợp sử dụng một class chưa được khai báo, kết quả là ReferenceError, còn sử dụng hàm chưa khai báo, chạy bình thường
Temporal Dead Zone (TDZ – khu vực tự trị) là nơi quản lý tính khả thi của let, const, class
Bắt đầu với khai báo const
white; // throws `ReferenceError`
const white = '#FFFFFF';
white;
Trước khi có sự xuất hiện của const white = '#FFFFFF', biến white sẽ nằm trong khu vực tự trị (TDZ)
Chúng ta không thể truy cập vào khu vực tự trị này, nên nó sẽ trả về lỗi ReferenceError: Cannot access 'white' before initialization
Khái niệm này giúp tránh sự lằng nhằng trong javascript trước đây, được phép sử dụng trước khi khai báo. Vì nó chỉ được thêm vào sau này, nên chỉ có hiệu lực trên các từ khóa sau này mới có là let, const, class
count; // throws `ReferenceError`
let count;
count = 10;
const myNissan = new Car('red'); // throws `ReferenceError`
class Car {
constructor(color) {
this.color = color;
}
}
Nó cũng giải thích luôn tại sao chúng ta phải gọi super trong class trước khi gọi this, vì this tạm thời nằm trong khu TDZ khi chưa gọi super
class MuscleCar extends Car {
constructor(color, power) {
this.power = power;
super(color);
}
}
const myCar = new MuscleCar('blue', '300HP'); // `ReferenceError`
Chúng ta phải dùng this. sau khi gọi super
Với những cách khai báo cũ là var, function nó không chịu chung số phận phải sống trong khu tự trị, nó sẽ chịu khái niệm Hoisting.
Hoisting là một cơ chế hoạt động gây khó dễ anh em chúng ta đã bao nhiêu thập kỷ nay.
Anh em ra đường gặp một em chưa hề quen biết, chúng ta nhẹ nhàng tới hỏi “Em nhà ở đâu thế?”, nhận được câu trả lời anh lên phường tra cứu, lên đến phường, “chẳng ai biết ẻm là ai”, phường chỉ lên quận tra cứu, quận lại bảo “có mà lên ủy ban thành phố chú ạ”, lỡ mà xui xui chúng ta phải lên đến trung ương để biết rằng em đã đăng ký hộ khẩu ở đâu.
// chạy như thường, nhưng đừng viết gì nhá value;// => undefined var value;
Để tìm được một mảnh ghép hoàn hảo, người tuyển dụng thường đặt ra nhiều câu hỏi có tính hệ thống để khai thác thông tin ở các ứng viên. Điều quan trọng là bạn có nhận ra bẫy câu hỏi để “đáp trả” một cách thông minh đồng thời bộc lộ đầy đủ khả năng của mình với nhà tuyển dụng. Và một trong những chiến thuật đặc biệt giúp bạn giải quyết được vấn đề này chính là phương pháp STAR.
Loại bỏ những cảm giác lo lắng, hồi hộp, căng thẳng trước buổi phỏng vấn, phương pháp hay kỹ thuật phỏng vấn STAR được xem là một bí quyết giúp bạn chinh phục mọi mục tiêu trong phỏng vấn.
Phương pháp STAR là gì?
STAR (Situation – Task – Action – Result) là mô hình cho phép bạn có thể trả lời trực tiếp các câu hỏi bằng cách tuân theo trình tự nhất định trong từng lời đáp; hay nói cách chuyên môn hơn, STAR giúp trả lời các câu hỏi mang tính hành vi. Cụ thể, kỹ thuật phỏng vấn STAR được áp dụng đối với các câu hỏi yêu cầu giải đáp những tình huống thực tế mà bạn đã từng thực hiện, xử lý và mang lại cho bạn nhiều trải nghiệm.
Đó cũng chính là điểm đặc biệt của STAR vì xuyên suốt cuộc phỏng vấn, nhà tuyển dụng và bạn sẽ trao đổi với nhau qua một chuỗi những câu chuyện, sự việc được thiết lập luân phiên nhau theo hệ thống câu hỏi tương ứng. Chính STAR cũng tạo điều kiện cho những chia sẻ của bạn được thể hiện rõ nhất, bạn là ai, bạn như thế nào, bạn có những gì,.. tất cả đều được truy xuất.
Các bước trong mô hình STAR
Tình huống (Situation): Mô tả một bức tranh tình huống và những chi tiết kèm theo. Tức là người phát ngôn kể lại tình huống, bối cảnh mà mình thực hiện. Với các thông tin như bạn là ai trong tình huống, sự việc đó – WHO; sự việc đó diễn ra khi nào – WHEN và diễn ra ở đâu – WHEN.
Nhiệm vụ (Task): Thuật lại nhiệm vụ chính của bạn trong tình huống này là gì. Tức là nói về việc vai trò, trách nhiệm, công việc nào mà bạn đảm nhận trong tình huống, sự việc đó. Với các thông tin cụ thể là bạn phải làm cái gì – WHAT và với lý do nào – WHY.
Hành động (Action): Diễn tả từng bước cụ thể cách thức bạn thực hiện, và giải quyết sự việc đó như thế nào – HOW.
Kết quả (Result): Chia sẻ kết quả đạt được từ những hành động của bạn.
Ứng dụng kỹ thuật STAR với 4 bước tiêu chuẩn
Bằng cách tuân theo 04 bước tiêu chuẩn này khi trả lời phỏng vấn, ứng viên có thể vạch ra một dàn ý cụ thể giúp câu chuyện của mình đi theo trình tự logic hợp lý nhất và ấn tượng nhất, cũng như giúp nhà tuyển dụng có thể theo được câu trả lời mà không phải lạc lối trong mớ “hỗn độn” đầy những chi tiết được đề cập đến một cách mơ hồ.
1. Tìm một ví dụ điển hình nhất phù hợp câu hỏi
Sự khởi đầu luôn quan trọng để bắt đầu áp dụng mô hình STAR. Bạn cần tìm ra một tình huống phù hợp nhất trong số những trải nghiệm mà bạn có được từ quá khứ. Thông thường, không có cách nào để bạn nắm bắt được suy nghĩ và những câu câu hỏi mà nhà tuyển dụng sẽ hỏi bạn. Vì vậy, để chiến thuật STAR được xây dựng một cách hoàn thiện ngay từ ban đầu, bạn nên chuẩn bị sẵn một số câu chuyện mà bản thân có thể tự linh hoạt thay đổi nhằm thích ứng với mọi câu hỏi mà nhà tuyển dụng có thể đưa ra thách thức bạn.
Nghĩ về những thành quả bạn gặt hái được trước đây và sắp xếp câu chuyện của chúng theo mô hình STAR. Đó là bước chuẩn bị cần thiết cho bạn. Nếu bạn gặp khó khăn trong việc kết nội nội dung câu chuyện, hãy thoải mái xin phép nhà tuyển dụng cho bạn một vài phút để tập trung suy nghĩ. Nhớ rằng một câu trả lời ấn tượng sau vài phút suy nghĩ sẽ có giá trị hơn một câu trả lời vội vàng nhưng trống rỗng. tiêu đề tuyển dụng
2. Sắp xếp lại các tình huống
Màn “chào sân” ấn tượng bằng việc tìm ra câu chuyện của chính mình là cơ sở quan trọng để thực hiện bước tiếp theo. Đã đến lúc bạn sắp xếp các tình huống trong câu chuyện một cách cụ thể và hợp lý nhất. Hãy thông minh trong việc tổ chức sắp xếp các tình tiết diễn ra trong câu chuyện của bạn, có thể thêm những chi tiết để tạo sự lôi cuốn nhưng vẫn phải cân nhắc.
Mục tiêu của bạn là vẽ ra một bức tranh cụ thể nhất và nhấn mạnh vào trọng tâm của nó để kết quả bạn thể hiện sau đó ấn tượng hơn nhiều. Một nguyên tắc giúp áp dụng thành công kỹ thuật STAR chính là sự đơn giản. Trả lời ngắn gọn, dễ hiểu, đúng vấn đề, đừng trả lời dài dòng và chỉ tập trung vào những gì thật sự liên quan đến câu hỏi.
Ví dụ, khi được nhà tuyển dụng hỏi về một lần bạn đạt được mục tiêu mà ban đầu bạn nghĩ ngoài tầm với, bạn có thể linh động sắp xếp một tình huống trong 1 – 2 câu như: “Trong vị trí IT mà tôi từng đảm nhận, công ty yêu cầu tôi phải chú trọng đến việc tạo ra nguồn thông tin chính xác thông qua việc cung cấp định hướng và hướng dẫn cho người dùng về phương thức hoạt động của các phần mềm mới .”
Ở bước này, bạn cần chia sẻ chi tiết với nhà tuyển dụng phần công việc mà bạn thực hiện.
Một lưu ý đồng thời sẽ là một điểm cộng đó là bạn nên mô tả chân thật những công việc bạn làm thì nhà tuyển dụng dễ đánh giá bạn hơn. Vì khi bạn tận tâm và có trách nhiệm với phần việc được giao, bạn mới có thể chia sẻ rõ ràng và chi tiết. Chẳng hạn với vị trí HR, bạn có thể chia sẻ: “Tôi phụ trách bộ phận tuyển dụng, trong quý đầu tiên, nhiệm vụ của tôi là phải gia tăng 50% các nguồn cung ứng nhân lực từ các trường Đại học, Cao đẳng, đơn vị đào tạo nghề… phù hợp với lĩnh vực kinh doanh của công ty.
Khi đã nêu ra công việc chi tiết, đã đến lúc bạn đi vào chi tiết giải thích việc bạn đã làm. Hãy kể ra và kèm những dẫn chứng về số liệu xác thực thay vì những lời nói mơ hồ như “tôi đã có những nghiên cứu về…” hay “tôi đã cố gắng hết mình để…”. Không phải ai cũng có cơ hội tiếp xúc với các nhà tuyển dụng vì thế đây là một cơ hội tốt cho bạn tạo ấn tượng và tỏa sáng. Bạn làm vị trí gì trong một nhóm, bạn có một bản kế hoạch chi tiết như thế nào? Bạn sử dụng những cách thức, mối liên hệ nào để giải quyết, thực hiện công việc? Hãy chắt lọc và trình bày một cách hấp dẫn để khiến câu trả lời của bạn có giá trị hơn.
4. Trình bày kết quả mang lại
Kết quả chính là đánh giá xác thực nhất cho toàn bộ trải nghiệm của bạn. Điều bạn cần làm là chia sẻ với nhà tuyển dụng bài học, giá trị, hoặc một điều gì đó bạn rút ra từ công việc/dự án mà bạn đã thực hiện.
Các nhà tuyển dụng có xu hướng không mấy quan tâm đến những gì bạn làm nhưng nếu kết quả là một sự bất ngờ (tức bạn vượt qua được những chỉ tiêu) thì đó sẽ là màn chốt hạ tuyệt vời. Hãy chia sẻ thật kết quả của bạn, bày tỏ những hạn chế và các giải pháp khắc phục (nếu có) vì người thành công luôn biết cách nhận ra những bất cập còn tồn đọng.
Mô hình STAR tuy còn mới mẻ nhưng nếu bạn luyện tập thường xuyên, bạn có thể dễ dàng chinh phục những câu hỏi khó từ nhà tuyển dụng. STAR được ứng dụng nhiều trong việc ứng tuyển qua CV, hay những câu hỏi trong các buổi phỏng vấn vào các tổ chức xã hội, chương trình, câu lạc bộ, đội nhóm,… Hi vọng với STAR, bạn sẽ dần tìm ra được những cách thức trả lời hấp dẫn để chinh phục mục tiêu phỏng vấn đồng thời tiến gần hơn với ước mơ nghề nghiệp.
React Context có phải là viên đạn bạc sẽ giải quyết mọi vấn đề thay cho Redux hay không?
Để chia sẻ được state giữa các component với nhau, React cung cấp API Context, với lời hứa ngon ngọt mà bạn có thể đọc đâu đó trên mạng “có thể thay thế redux”. Từ kinh nghiệm thực tế của team Atlassian cũng như của bản thân mình (là tui luckyluu), sử dụng nó trên các module lớn, hoặc trên toàn bộ App (gốc trên cùng của cây React) là một cơn Ác mộng cho lập trình viên.
Khá sạch đẹp, đúng không? Lúc component được mount vào DOM chúng ta fetch dữ liệu, đặt giá trị cho state loading, vâng vân.
Tình huống gặp phải là chúng ta cũng muốn sử dụng danh sách categories này trên một component nào đó khác. Việc cứ phải bọc (wrap) component lại dạng cha con, rồi truyền danh sách categories thông qua props không phải là lựa chọn khôn ngoan, chúng ta cần lưu nó ở một nơi tập trung (store) và truy xuất ở bất kỳ đâu, chúng ta có thể sử dụng createContext. Việc chuyển qua dùng createContext dễ như ăn bún
Chúng ta “chỉ” còn lại 2 vấn đề: đặt <CategoriesProvider/> ở đâu và chuyện gì sẽ xảy ra nếu Provider vì lý do nào đó không thể là cha chú của một component consumer?
Xử lý các vấn đề phức tạp xung quanh việc viết context thế nào cho hợp lý, fallback ra làm sao sẽ cần đến một bài viết dài dòng khắc, giờ cứ tưởng tượng bạn luôn cần Provider render “ở đâu đó” (nhiều khi là cùng với cả tá provider khác nữa khi bạn làm một ứng dụng lớn).
Lấy dữ liệu sau khi có tương tác
Đoạn code fetch dữ liệu lúc mount component ở trên trông rất hợp lý, nhưng sẽ có tình huống bạn cần trigger fetch không phải lúc mount.
Node A
- Node B
- Node C
Nếu đặt tình huống bạn fetch dữ liệu categories ở <Node A />, được <Node C/> hiển thị, nhưng user lúc sử dụng đôi khi chả bao giờ thấy đến <Node C/>, họ có thể dừng lại ở màn hình <Node A/> thì việc bắt trình duyệt đi lấy dữ liệu quá sớm không phải là một chuyện nên làm. Do đó chúng ta sẽ có nhu cầu trả về hàm lấy dữ liệu trực tiếp xuống context:
ĐỪNG BAO GIỜ LÀM NHƯ VẬY. Bạn có thấy được con bug “ngầm” trong cách viết trên không? Mỗi lần CategoriesProvider re-render, chúng ta truyền xuống một giá trị hoàn toàn mới cho value – một object được khởi tạo mới tinh. Tạo ra một object rồi truyền xuống thành props là lỗi căn bản cần tránh, tuy nhiên khi dùng cho Context Provider nó đặc biệt trầm trọng. Khi để ý thấy lỗi này, chúng tôi đã theo sự chỉ dẫn từ tài liệu của React Context guidelines, lưu phương thức đó vào state
Xong! Chưa thật sự xong đâu, khi thêm <CategoriesQuery/> ở 2 nơi khác nhau trên cây, nếu 2 component được mount cùng một lúc, fetch sẽ chạy 2 lần.
Bug nhỏ thôi mà đúng không? Chúng ta không kiểm tra state loading trước khi gọi fetch. Sửa nhanh trong Provider:
// class CategoriesProvider...
fetch = () => {
if (this.state.loading) return;
// ...
}
Thử refresh lại trang, với 2 CategoriesQuery mount và… BÙM Vẫn là 2 request network. Kiểm tra lại lần nữa nào, có gì đó lỗi rồi, không lỗi nữa, lại lỗi nữa, rồi bỗng dưng chúng ta nhận ra React setState là một async. Có nghĩa là việc giá trị loading vẫn là false trong cả 2 lần gọi thậm chí setState đã được gọi một lần. “Shitty React”
Bắt đầu tìm kiếm một cách làm “less shitty” (bớt nhảm shit) với chuyện setState async trong Context Provider (có 4 năm cách làm tùy theo độ sáng tạo), nhưng có thể đảm bảo rằng không có cách nào thập toàn thập mỹ. Luôn cảm thấy chúng ta đang chống lại cách làm chính quy từ React.
Đâu là giải pháp
Context API có rất nhiều điểm cộng ngay cả khi so sánh với Redux, cái chúng ta cần là một cách vẹn toàn cả cho cả 2.
Mình cũng gặp vấn đề y chang như vậy với ứng dụng đang làm. Tìm kiếm và cuối cùng chốt hạ dùng react-sweet-state cho cả team
import { createStore, createHook } from 'react-sweet-state';
// giá trị khởi tạo
const initialState = {
data: null,
loading: false,
error: null,
};
// define the actions that mutate the state
const actions = {
fetch: () => async ({ getState, setState }) => {
if (getState().loading) return;
setState({ loading: true });
try {
const data = await fetch('/categories');
setState({ data, loading: false });
} catch (error) {
setState({ error, loading: false });
}
}
}
// tạo store
const CategoriesStore = createStore({ initialState, actions });
// tạo components để truy cập dữ liệu từ store
const useCategories = createHook(CategoriesStore);
// sử dụng
const CategoriesQuery = ({ children }) => {
const [state, actions] = useCategories();
useEffect(
() => { if (!state.data) actions.fetch(); },
[state, actions],
);
return children(context);
}
Có nhiều điểm cộng cho react-sweet-state như nó vẫn dùng Context API, nhưng an toàn hơn, các action sẽ dễ test hơn, làm việc được với Redux DevTools, đã xử lý những lỗi vẫn hay gặp với React Context. Và nhiều điều hay ho khác nữa. Các bạn nhớ like cho repo này trên github.
Tuyển dụng nhân sự là một công việc quan trọng đối với bất kỳ một cá nhân hay tổ chức nào. Thế nhưng, hiện nay có nhiều công ty đang phải đau đầu vì số lượng đơn ứng tuyển nộp về ngày càng khan hiếm, công tác nhân sự cũng chưa thật sự được định hướng rõ ràng. Nguyên nhân dẫn đến vấn đề này chính là những sai lầm mà các công ty thường xuyên mắc phải trong công tác tuyển dụng của mình.
Cùng TopDev Blog tìm hiểu những sai lầm phổ biến nhất trong công tác tuyển dụng nhân sự thông qua bài viết sau đây.
1. Thu hẹp phạm vi tuyển dụng và đòi hỏi quá nhiều kỹ năng
Một trong những sai lầm lớn nhất của nhà tuyển dụng chính là việc họ khoanh vùng những ứng viên theo các tiêu chí như: tuổi, trình độ học vấn, kinh nghiệm, giới tính, gia cảnh,…
Mỗi người một thế mạnh riêng và vì thế, không nên thu hẹp phạm vi tuyển dụng. Bên cạnh đó, việc đòi hỏi nhiều kỹ năng không thật sự cần thiết càng khiến cho số lượng ứng viên giảm đi. Vì vậy, hãy mở rộng phạm vị tuyển dụng cho nhiều ứng viên tham gia tranh tài vì biết đâu chính những người này sẽ mang lại nhiều thành công lớn cho công ty của bạn về sau.
Ứng viên có thể thiếu sót về những kỹ năng nhưng nếu họ có bệ phóng kinh nghiệm thì nhà tuyển dụng nên tạo cho họ thêm cơ hội để học hỏi và phát triển năng lực của mình. Đó cũng chính là chìa khóa giúp các công ty tìm được những ứng viên giàu tố chất để đồng hành lâu dài.
Thế nên, khi nhận được một yêu cầu tuyển dụng từ cấp trên với quá nhiều kỹ năng, người tuyển dụng cần xem xét và đặt câu hỏi với họ liệu mức độ khả thi trong việc tìm kiếm ứng viên là bao nhiêu, từ đó quyết định giảm các kỹ năng không cần thiết.
2. Chưa nắm rõ mục đích, quy trình và quy tắc tuyển dụng
Nhiều ứng viên khi phỏng vấn chưa thật sự hiểu về trách nhiệm, công việc mà vị trí ứng tuyển yêu cầu. Nguyên nhân một phần chính là do người tuyển dụng chưa nắm rõ những mục đích và quy tắc tuyển dụng. Quy trình tuyển dụng là một thứ quan trọng bởi nó ảnh hưởng đến thời gian của các ứng viên. Việc không giải thích quy trình một cách rõ ràng sẽ khiến các ứng viên cảm thấy mệt mỏi và họ sẽ có những cảm nhận, đánh giá không mấy tích cực đối với công ty của bạn.
Nhà tuyển dụng nên nắm rõ mục đích và quy trình tuyển dụng để giúp ứng viên kịp thời giải đáp các thắc mắc. Bằng cách cung cấp một mô tả rõ ràng, chính xác về công việc, bạn có thể thu hẹp và tìm thấy nhóm ứng viên tiềm năng, làm quá trình tuyển dụng dễ dàng hơn.
Sai lầm phổ biến khác của các công ty trong công tác tuyển dụng nhân sự là chưa xây dựng hệ thống quy tắc tuyển dụng rõ ràng. Chẳng hạn, nhiều nhân viên muốn ứng tuyển vào các vị trí quan trọng với những hợp đồng dài hạn như quản lý, lãnh đạo,.. nhưng họ nhận thấy công ty không có những quy tắc trong hợp đồng, các thể chế pháp lý để đảm bảo đầy đủ quyền lợi cho họ nếu gắn bó lâu dài, nên họ từ chối. Để tuyển dụng thành công, một tổ chức, doanh nghiệp trước hết cần sở hữu quy tắc tuyển dụng đúng chuẩn, đồng thời có thể đảm bảo chất lượng nguồn nhân lực, khẳng định được uy tín trong mắt những ứng viên đang tìm kiếm cơ hội.
3. Tuyển chọn ứng viên có kinh nghiệm từ các công ty đối thủ
Đây cũng được xem là một cách tuyển chọn nhân sự của các công ty, tập đoàn lớn. Họ nghĩ rằng những ứng viên có nhiều kinh nghiệm, sẽ có thể “nhập cuộc” nhanh với quy trình, mô hình và tiến độ phát triển của công ty, nên không phải đào tạo thêm.
Tuy vậy, nếu đánh giá một cách kỹ lưỡng trên nhiều góc độ, chúng ta sẽ nhận thấy nhiều bất cập có thể phát sinh:
Người có nhiều kinh nghiệm sẽ yêu cầu lương cao. Vì quá hiểu về vị trí và những vấn đề về chuyên môn sẽ thực hiện trong công việc nên họ rất tự tin, đôi lúc hơi quá trong vấn đề deal lương;
Đòi hỏi những vị trí, cấp bậc cao hơn vì đó là nhu cầu chính đáng để giúp phát triển sự nghiệp;
Khi ứng viên quá giỏi về một lĩnh vực nào đó thì mong muốn của họ là tìm kiếm những cơ hội phát triển thêm. Nên khi nhận được nhu cầu tuyển dụng từ cấp trên, bạn nên đặt câu hỏi vị trí này trong 6 tháng hay 1 năm nữa sẽ làm gì tiếp theo? Hãy mạnh dạn đề nghị thảo luận thay đổi yêu tuyển dụng nếu cấp trên không chia sẻ được về định hướng phát triển cụ thể
Tuyển người từ công ty đối thủ có thể là tạo cơ hội cho đối thủ “cài người” vào nhân sự của công ty, những hậu quả sau đó sẽ rất nghiêm trọng.
Khi được phỏng vấn, chắc chắn những ứng viên có thực tài sẽ quan tâm rất nhiều đến nét đặc trưng, độc đáo của công ty chủ quản. Vì vậy nếu muốn thu hút được họ thì nhà tuyển dụng không thể quên việc phải giới thiệu những nổi bật trong văn hóa công ty đến các ứng viên bao gồm lợi ích, mức lương, quyền lợi đặc biệt và tính linh hoạt.
Đây là bước đi thông minh giúp tuyển dụng được những con người thực sự có tài năng, tâm huyết. Thông qua việc được cung cấp các ưu đãi, ứng viên sẽ có cái nhìn đầy thiện cảm đối với doanh nghiệp đồng thời cảm nhận được sự tôn trọng của doanh nghiệp với những mưu cầu, quan tâm của ứng viên đối với môi trường làm việc. tiêu đề tuyển dụng
Ngoài những sai lầm kể trên, việc một vị trí tuyển dụng bị chậm hoặc không hiệu quả thì có thể bắt nguồn từ nhiều phía: Chính sách phúc lợi, mức độ danh tiếng của công ty, sức ảnh hưởng của người lãnh đạo,… Dù cho nguyên nhân là gì, điều quan trọng là nên nhận biết và có kế hoạch phối hợp, điều chỉnh trong công tác tuyển dụng nhân sự của tổ chức, doanh nghiệp.
Để có thể quản lý được state của ứng dụng một cách tốt nhất, chúng ta cần sự phân chia phù hợp giữa local state (internal state của component) và state cửa ứng dụng đặt trong React Context. Một vài điều muốn chia sẽ để nâng cao khả năng bảo trì và trải nghiệm nếu sử dụng đến context trong React.
Đơn vị viewport trong css (vh, vw) không phải lúc nào cũng chạy đúng trên mọi trình duyệt điện thoại. Giống như chưa đủ khổ cho dev nên mỗi trình duyệt mobile lại có cách xử lý riêng cho đơn vị này.
Cách mà w3 định nghĩa cách tính đơn vị này. Với mobile cái chúng ta quan tâm nhiều nhất là đơn vị vh
1vh = 1% độ cao khởi tạo của khu vực trình duyệt dùng để hiển thị trang web.
Nghĩa là giá trị này không bao gồm các phần khác của trình duyệt, như thanh address, thanh bookmark (nếu có), tab bar, … và những thứ linh tinh khác mà user có thể add thêm vào trình duyệt của họ.
Nhưng khi bạn bắt đầu scroll trên điện thoại, câu chuyện trở nên phức tạp hơn, thanh address bar sẽ biến mất, giá trị của vh cần phải cập nhập lại, hiện tượng cà khịa xuất hiện trên màn hình.
Trình duyệt Safari trên iOS là người tiên phong sử dụng luôn một giá trị cố định đúng với kích thước màn hình (không phải kích thước khung hiển thị của trình duyệt). Chrome mobile cũng bắt đầu áp dụng cách này để chặn việc nội dung trang nhảy lung tung.
Điều này có ý nghĩa như thế nào? Nghĩa là khi bạn đặt giá trị 100vh nó sẽ vượt ra ngoài, user sẽ phải scroll trên trình duyệt để xem hết.
Để khắc phục nhược điểm này. Chúng ta không thể trông cậy vào css, phải dùng đến javascript túm lấy độ cao window.innerHeight, lưu giá trị đó lại thành một biến CSS và sử dụng nó thay cho đơn vị vh
.my-element {
height: 100vh; /* fallback khi trình duyệt không hỗ trợ biến css */
height: calc(var(--vh, 1vh) * 100);
}
Chúng ta sẽ túm lấy và định nghĩa --vh bằng javascript
// Trước tiên lấy viewport height và chuyển thành giá trị 1%
let vh = window.innerHeight * 0.01;
// Đặt biến css
document.documentElement.style.setProperty('--vh', `${vh}px`);
Còn một vấn đề nhỏ còn lại cần phải xử lý là cập nhập lại giá trị này khi trình duyệt thay đổi kích thước (xoay trái, xoay phải, xoay ngang, xoay dọc)
// chạy lại khi window resize
window.addEventListener('resize', () => {
// làm tương tự 2 bước đã làm
let vh = window.innerHeight * 0.01;
document.documentElement.style.setProperty('--vh', `${vh}px`);
});
