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.
Xem thêm các vị trí tuyển dụng Software Architect từ các công ty HOT
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.
Tham khảo các vị trí tìm việc làm cho kỹ sư Devops tại TopDev
Đ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ì.
Tham khảo thêm các vị trí tuyển dụng Scrum , tuyển dụng lập trình Agile mới nhất
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é!
Đừng bỏ lỡ những bài viết hay:
- Product Manager là gì? Làm sao trở thành Product Manager giỏi
- Dân Product khác dân outsource 180 độ?
- Câu chuyện làm product tại FE CREDIT
Việc làm IT hấp dẫn nhất dành cho Lập trình viên tại đây.
