Lời khuyên từ Việt Trần – CTO DOF Hunt “Cách quản trị tốt nhất chính là không quản trị”
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 cùng TopDev nhé!
- 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 anh 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ó cái 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 anh 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 anh 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à lớn, thường thì Architect bên anh 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à cái 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 anh 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 mình 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à mình 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à mình được phép lựa chọn ở đây thì chắc là mình sẽ lấy 1 ví dụ cá nhân ra thôi: backend mình thường sử dụng Golang, bên Database thì mình sẽ xài MySQL, Mongodb và Elasticsearch để làm 1 search engine và những công cụ cache thì mình có Redis Cache thì nó đã quá nổi tiếng rồi, rồi Message broker thì mình 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ể mình mới biết là mình chọn cái gì, nó mới đúng hơn.
- 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 anh, thật ra anh đã làm Software Architect được 1 thời gian rồi, chỉ qua là anh 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 mình cũng sẽ gặp nhưng mà ít ra thì mình 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.
- 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 mình 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 là 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ì anh vẫn tin Big Data sẽ là tương lai và xu thế.
- Theo em thấy là 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ì mình 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, thì theo anh thì đó 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 anh 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 cái lực học của mỗi người, nghĩa là có nhiều bạn anh 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 là 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 là 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 là 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à anh 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 thì 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, thì đó 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 anh 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 thì 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, anh nghĩ cái sai lầm này đến phần nhiều là do những cái mình đã biết, anh 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 á, thì 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 với anh, 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ễ, thì lúc trước anh là như thế, nhưng mà sao 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 anh 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ư anh thì anh 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 anh 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 anh đ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ì mình lại không được phép can thiệp vào hệ thống của họ để mình làm, thì đó cũng là 1 khó khăn rất là nhiều, nhưng lần đó thì mình đưa ra 1 cái chiến lược là mình xây mới, tức là mình dời qua từ từ, cũng giống như câu chuyện ở Sendo thôi. Từ từ từ từ mình tìm cách mình chứng minh là nó tốt hơn, sau đó họ mới chấp nhận. Đó là 1 kỷ niệm hồi mình cũng chưa có chuyên nghiệp lắm về mảng này, thì mình đã có trải qua về nó.
- 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à mình 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ì mình 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 cái thử thách, thì những người như vậy sẽ mang đến cho mình 1 cái trải nghiệm rất là khác. Bên anh 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ì anh 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 là không biết cái mình đang làm có thực sự là tốt hay không, thì đó là phần lớn những cái anh 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 là 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 là nhiều rồi, mình cũng không cần phải lo lắng nhiều như vậy nữa.
- Theo em thấy thì 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?
Anh 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 là khó để tìm đến được với nhau. Lý do phần lớn theo anh 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.
- 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 anh 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 anh 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 anh 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 anh tuyển dụng, nếu cho DOF Hunt thì anh thấy nó đơn giản hơn, thông thường anh 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 anh. Còn nếu 1 bạn fresher, tức là chưa biết gì thì đến DOF Hunt anh 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ì anh nghĩ mấy bạn sẽ là người phù hợp.
- Cơ duyên nào đưa anh đến với việc khởi nghiệp DOF Hunt?
Thật ra anh là 1 người rất thích khởi nghiệp, tuy nhiên anh là 1 người làm về kỹ thuật, và anh 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 anh được giới thiệu cái máy chụp hình, thật ra thì trước đó anh có làm 1 giải pháp liên quan tới nén hình ảnh thì trong hình ảnh anh 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, anh thấy nó khá là hay và anh 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 anh đi tham gia 1 số các câu lạc bộ offline chụp hình.
Từ đó anh 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ì anh 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 anh 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é!
Có thể bạn quan tâm:
1. Gặp gỡ Nguyễn Sơn Tùng CTO Viec.co – Quán quân StartupViet 2019