Từ lúc tốt nghiệp thì anh xác định theo con đường Solution Architect luôn hay có một career path anh đặt ra và làm theo nó hay anh thử sức với nhiều vị trí khác nhau và cuối cùng chọn con đường này?
Mình cũng chưa từng nghĩ mình làm ra là trở thành Solution Architect gì cả. Tới bây giờ mình mới hiểu được là rất khó để một bạn developer nào tốt nghiệp ra trường lại lựa chọn con đường đó, cái đó giống như là khi mình thành công mình quay lại mình tô vẽ career path mình đi thì nó hợp lý hơn. Bất cứ ai cũng đều muốn việc mình thành công, nên đơn giản là một người sinh viên ra trường việc họ muốn là thành công, cái sự thành công đó tùy theo giai đoạn. Ví dụ như mình đi làm cũng hơn 10 năm, mỗi lúc nghĩ về sự thành công nó đều khác nhau. Ví dụ như thời còn trẻ mới ra trường, thành công của mình là title gì đó nghe nó kiêu kiêu, như là leader chẳng hạn để mình kiếm được nhiều tiền, sau này rồi thì thấy sự thành công khác đi. Tạm thời mình đủ ăn đủ mặc rồi, nên bây giờ mình mong muốn là làm sao để đóng góp giá trị bản thân mình cho công ty, cho cộng đồng. Bây giờ mình đi làm đã 10 năm rồi , những khó khăn trong khi mình đi làm, mình muốn có một người leader có tâm, họ training cho mình, họ hướng dẫn cho mình, họ làm mentor cho mình, thì mình nhận thấy mình cần phải làm như vậy, cần có trách nhiệm như vậy để hỗ trợ lại các bạn. Trong bản thân mình cần phải thay đổi suy nghĩ đó, khiến cho mình biết mình muốn làm gì và mình đầu tư vào đúng điểm mạnh của mình, điều mà mình nghĩ mình làm tốt. Tại sao Sendo lại lựa chọn mình trở thành Solution Architect, hoặc trước kia ở các công ty là người design các hệ thống, là bởi vì trước đây mình là người xây dựng các hạ tầng, ví dụ mình làm ra cái đó mình sẽ chịu trách nhiệm đến cùng với nó. Không thể lúc nào mình desgin từ ban đầu cũng đúng, nhưng khi có cái gì sai thì mình là người có trách nhiệm đi khắc phục, khi đó mình được tin tưởng từ người mentor của mình, người lãnh đạo của mình, họ cho mình cơ hội để mình thực hành chuyện đó.
Anh có thể làm rõ hơn về vấn đề làm một leader có tâm là như thế nào không?
Mình nghĩ trong trải nghiệm cuộc đời mình, hơn 10 năm đi làm thì khi mọi người làm chung với nhau, cái mình gọi đồng nghiệp, anh em cũng chỉ là tạm thời thôi, mình có thể làm cong ty đó 3, 5, 6 năm nhưng các anh em cứ ra vào. Vậy như thế nào là leader có tâm, thì mình tin vào một người, khi mà mình gặp bế tắc, người đó sẽ chỉ, giúp mình, mình sai từ đâu và mình nên làm lại như thế nào cho đúng, làm bản thân mình strong lên, mình có thể đủ lông, đủ cánh, mình có thể tiếp tục cống hiến cho công ty đó tiếp hay mình có thể rời bỏ để chuyển vị trí khác, mình làm, mình phát triển được bản thân. Một người leader, mentor có tâm như một người anh có tâm, không thể để em của mình, đồng nghiệp của mình núp sau bóng mình mãi được. Đối với mình như vậy là có tâm.
Lúc đảm nhiệm vị trí Solution Architect thì anh tưởng tượng công việc đó như thế nào? Và thực tế nó có giống như anh tưởng tượng không?
Mình tốt nghiệp đại học, mình là cử nhân hay kỹ sư gì đó, đó như là certificate chuẩn do bộ cung cấp rồi. Một người đạt tiêu chuẩn như vậy hầu như đều có background về toán học, về triết học, hay cái gì đó nó giống như nhau, gần như là có nền tảng giống nhau. Còn nói về vị trí công ty, mình nói về vị trí rất đơn giản như senior, ở đây họ là senior nhưng ở kia chưa chắc là senior. Một vị trí như full-stack developer, thì ở chỗ khác họ define full bao gồm cả devops hay thế này thế nọ, còn ở chỗ khác thì anh biết làm web, anh biết làm back-end, front-end như vậy thì là full-stack rồi. Thì vị trí solution architect cũng vậy, cũng tùy công ty định vị về vai trò này nọ khác nhau. Đối với vị trí của solution architect mình nghe mọi người nói vị trí Architect cần có 4 định hướng hay thấy mọi người làm về chiến lược, về chiến thuật, hay làm về article hay planning. Phần lớn các tiệm ăn thiên về các mảng phía dưới, không phải làm về chiến lược, chủ yếu làm về chiến thuật, làm về emplacement , planning. Ví dụ như khi công ty giao cho mình việc gì đó, mình nghĩ về mặt placement thì như thế nào, về mặt các kĩ thuật, chiến thuật mình làm như thế nào. Ví dụ các bài toán phải đòi hỏi thực sự về tư duy, về cách làm, chứ không phải cứ nhào vô mà làm được. Ví dụ như mình làm bài toán về notification chẳng hạn, mảng thương mại điện tử, một user có rất nhiều device , mình không biết user xài cái nào và có hàng chục triệu user như vậy. Thì tất nhiên các nền tảng bây giờ mình nghe đơn giản là đã có, chẳng hạn như Google Drive Space này nọ nó bắn rồi, vậy mình care cái gì về nó. Giả sử mình cần thống kê về số lượng notification ai đọc và chưa đọc, mình phải lưu lại thông tin user đó với tin nhắn đã đọc hay chưa True – False , nó lên đến hàng triệu messages , nói chung con số nó khủng khiếp, và nhiều tháng thì con số nó khủng khiếp hơn nữa. Và mỗi lần bắn 1 tin marketing như vậy nó có thể hoàn toàn gây ra tắc nghẽn hay đình trệ . Câu hỏi đặt ra là mình cần có chiến thuật, cách làm để mình đảm bảo được requirement và vừa phát triển tính năng đó không bị bế tắc, nếu như mà sập hệ thống là mình bế tắc rồi. Mình có thể làm được điều đó bằng cách planning, bước 1 làm gì, bước 2 làm gì, thường thường công việc của anh hướng như vậy.
Anh có thể tóm gọn khái niệm về Solution Architect theo quan điểm của anh được không? Anh có đề cập Solution Architect liên quan đến chiến thuật, vậy những vị trí khác như Technical Architecture hay Structure Architecture liên quan đến mảng nào (như chiến lược hay những khía cạnh nào khác)?
Mình có thể tìm hiểu các tổ chức lớn, khi define role như thế nào thì mình có thể nhìn theo đó một cách tổng quát. Nhưng trong buổi phỏng vấn mình chia sẻ về Software Architect thiên về hướng emplacement , về chiến thuật, còn ví dụ như về Technical Architect thiên về strategy cộng với emplacement, đó là các tổ chức người ta làm. Còn khi mình nói chung một người làm về software, về mặt bản thân người đó cần có một số skills nhất định, tóm gọn là một người làm về kỹ thuật cần có skill về kỹ thuật là một điều kiện kiên quyết, nhưng ngoài ra cần có hiểu biết về business nữa, người làm business đã cực khổ đi kiếm khách hàng về, nhưng người làm về kỹ thuật không hiểu biết về business lại trách móc khách hàng stupid thì hai bên sẽ khó giao tiếp với nhau. Rồi mình phải hiểu về process để cho mọi thứ hoạt động trơn tru, một tổ chức càng lớn thì process càng hoàn thiện. Cuối cùng kỹ năng gần như chúng ta cần phải học suốt đời, thực sự rất là khó đó là kỹ năng communication, xây dựng các mối quan hệ tốt đẹp, giống như là relationship. Bây giờ mình nghe đâu đó trên facebook, hay nghe đâu đó người ta chia sẻ nhan nhản câu chuyện liên quan tới thống kê của một trường đại học hàng đầu thế giới, người ta thống kê cuộc nghiên cứu 70 năm cho rằng “Mối quan hệ giữa con người quyết định sự thành công”, mình khoan bàn đến chuyện cái đó đúng sai tới đâu hay là mình áp dụng nó như thế nào, nhưng mà mình biết mình có kỹ năng giao tiếp tốt thì ảnh hưởng như thế nào, nghĩa là kỹ năng giao tiếp tốt giúp mình diễn đạt được ý của mình ra cho người khác hiểu và người khác sẽ nhìn vào đó và hiểu được mình, đôi khi họ thông cảm cho mình. Ví dụ một cách đơn giản, hai ông có trình độ như nhau, hai ông đều giỏi như nhau, tại sao khi ông kia nói cái gì thì boss hay mentor đều biết hết, còn khi mình nói ra thì mọi người nghi ngại, thì đó là do kỹ năng mình truyền đạt có thể là nó thuộc yếu tố mối quan hệ giữa hai người đó và niềm tin nữa, nhưng mà kỹ năng giao tiếp nó rất là quan trọng. Rồi mối quan hệ giữa con người có nghĩa là mình không thể tách vỡ, nhưng mình cứ lên đọc mấy cuốn sách đóng gói dạy con người ta làm cái này cái kia, như vậy nó sẽ trở nên rất là máy móc, mình không thể đem sách vở ra mà đối nhân xử thế được. Theo mình mối quan hệ giữa con người đến từ sự chân thành, ví dụ như mình, khi làm việc rất đơn giản, ai hỏi gì mình cũng đều trả lời cả, rất là nhiệt tình, không có gì phải dấu giếm, ta biết gì nói nấy. Giả sử khi mình có sai thì đồng nghiệp correct cho mình, cũng là cơ hội để mình improve, mình chỉnh sửa bản thân, chứ không phải ai cái gì cũng biết, cái gì cũng giỏi. Thì mình cho thấy cứ một người làm về developer hay software trong lĩnh vực IT không chỉ có solution architect đều cần hướng đến 4 kỹ năng đó.
Riêng những bạn muốn đi theo con đường Solution Architect thì anh có lời khuyên gì cho xuất phát điểm cũng như lộ trình học tập của mấy bạn không?
Giống như lúc nãy mình có nói, rất khó để mà mình khuyên một bạn nào đó ra trường đi theo con đường Solution Architect, làm thế nào để mà mình thuyết phục được người khác là tui giỏi lắm rồi, bây giờ tui sẽ đảm nhận vị trí solution architect ở công ty của mình, tui làm vị trí này, tui sẽ đem về benefit thật là lớn cho anh; rất là khó để nói như vậy. Ví dụ như Topdev có anh Bình đi, mình đi qua mình nói “Anh ơi, anh dẹp mấy thằng kia hết đi, để cho em vô làm solution architect, tất nhiên là anh sẽ cảm thấy bối rối vô cùng, và anh sẽ không biết mình phải như thế nào cả; hoặc là anh nghĩ cha này ngạo mạn hoặc là nhìn thấy giỏi nhưng cũng chưa chắc gì dám nhận; tại vì công ty mình có tổ chức, có những người đã từng đóng góp có người đồng hành của mình rồi, nên là mình không thể nào thấy một người này mà bỏ người kia, nó có rất nhiều yếu tố khiến cho người lãnh đạo – người đồng ý nhận mình làm vị trí solution architect – họ phải cân nhắc, mình phải thỏa các điều kiện không chỉ bản thân mình thôi là mình sẽ làm được. Nhưng mà như nãy mình chia sẻ, một bạn developer làm thế nào trong quá trình từng giai đoạn mình phát triển bản thân thì mình phát triển đúng với giai đoạn của mình; tức là mình tìm hiểu ở giai đoạn đó mình cần những skill gì và mình phát triển nó. Ví dụ như mình mới ra trường, một trong những điều mình thiếu là skill về technical, tại vì ở trường người ta dạy tổng quát chứ không dạy để ra là một công ty nào đó họ dạy tổng quát để người đó có thể ra và bơi được bất kỳ ở đâu và tất nhiên mình cũng phải hoàn thiện các skill còn lại mà ở trường không dạy, về mặt ngôn ngữ, hệ thống, chiến thuật, database và tất cả những gì mà mình chưa biết, sau đó mình tiếp tục hoàn thiện các skill về business. Và tất nhiên đầu tiên mình là người mới ra trường, chẳng ai đi trao đổi business với mình cả, mình chưa thấy ai như vậy cả, bởi vì không được tin cậy cho lắm, mình là người mới ra trường mà đi ra ngoài bô bô về business thì thấy hơi trẻ con một chút, ví dụ là vậy; rồi nói về quy trình, những người làm về quy trình phải có kinh nghiệm mới làm về quy trình được, chứ mình còn trẻ mà vào làm quy trình thì sẽ bị xáo trộn mọi thứ, rồi sau này mình lớn, mình trở thành senior rồi thì tất nhiên mình mới nói về xây dựng mối quan hệ tốt đẹp, ý là lúc mình còn trẻ mình cũng có nhưng đó là với bạn bè, đồng nghiệp thôi, còn xây dựng mối quan hệ mà mình muốn đề cập để lúc nào mình làm việc cũng smoothly. Mình nghĩ mọi người cứ đi theo từng giai đoạn, từng nấc của cuộc đời như vậy, đến một lúc nào đó trở thành Solution Architect vị trí manager, hoặc có thể mình chọn trở thành vị trí lập trình viên bình thường thôi, cũng là sự lựa chọn của bản thân mình, happy với sự lựa chọn đó. Ví dụ như mình làm Solution Architect, và lúc nào mình cũng phải đi tranh luận, thuyết phục người khác, rất là tốn năng lượng và mất rất nhiều thời gian, mình nghĩ chuyện này chuyện kia, không có thời gian chăm sóc gia đình con cái, còn khi mình là lập trình viên, mình lên mình nhận đúng task và mình làm và tất nhiên mình cũng tạo ra mọi thứ tốt đẹp trên thế giới này thôi và rồi mình về mình ăn ngon ngủ yên, đó là sự lựa chọn của cuộc đời.
Tại sao anh chuyển sang làm về E-commerce? Có phải do tiềm năng nào đó hay có thách thức mà anh muốn khám phá không?
Bản thân mình mọi thứ đến với mình một cách tự nhiên, hồi còn trẻ khi đi xin việc, ở đâu ai nhận thì mình làm thôi giống như là hồi mình làm về Gameloft, nhưng mà khi làm về Gameloft mình học được rất nhiều điều hay. Ở những công ty lớn họ có rất nhiều điều hay để mình học hỏi, giống như mình nghĩ ở một công ty nhỏ tất nhiên nó đã có một đầu vấn đề rồi mình làm mình cũng biết, nhưng khi ở công ty to nó càng có nhiều vấn đề nữa và làm thế nào để học vận hành bộ máy to như vậy thì đó là một cái thách thức, nếu như mình nhìn vào và nghiên cứu kỹ phần đó sẽ thấy được cách họ giải quyết rất là hay. Ở Gameloft là một công ty rất to, vận hành có lớp lang, những người mới vào được training một cách bài bản, công việc thì có công cụ để mà khi giao đến từng người thì rõ ràng, mạch lạc; một công ty có giàn hậu thuận đằng sau rất lớn những người giỏi về mặt kỹ thuật, do vậy khi mình ở đó mình được học rất là nhiều. Bài học đầu tiên ở Gameloft mà mình học được đó là các mình em đồng nghiệp rất là máu lửa, tầm nhìn rất là xa, thời điểm đó mình ra trường, mình không hiểu vì sao họ lại có được tầm nhìn xa như vậy, và nó giúp mình đặt ra được khát vọng để mình được giống như họ. Lần thứ 2 là mình hiểu được áp lực của người làm business là như thế nào. Hồi xưa lúc mình đi làm thời mới ra trường, mấy ông làm business đi làm ổng ăn ổng chơi ổng nói gì đâu không à, ổng không làm việc mà mình làm mệt chết được, nhưng khi mình làm mistake thì mình lên cái bàn của một mình ở vị trí rất là cao, cao nhất nhì ở công ty, thì mình bảo ảnh sẽ giải thích những mistake mình đã làm, đã viết trong email, mình vô tình mình lướt qua mình đã thấy email thế này, giống như là cấp trên nữa, ở nước ngoài gửi email, rất ngắn gọn thôi, cái thứ nhất là xin chào, cái thứ hai là giải thích điều gì đang xảy ra, tại sao lại có sai lầm như thế này và tất cả những cái này yêu cầu phải trả lời ngay lập tức trong vòng 15 phút tới. Mình thấy là mình là người Việt Nam, sếp mình làm bự kinh khủng ở Sendo, ai cũng phải nể trọng mà thế nào ổng lại nhận một email có nội dung thô thế này, thì từ đó suy nghĩ là làm vị trí to như thế này phải chịu những áp lực rất là kinh khủng chứ không phải đơn giản là mình thấy ông ngồi đó suốt ngày và ngồi chơi và chẳng làm gì cả. Từ đó mình mới thấy thông cảm cho vị trí quản lý của mình, họ chịu rất nhiều áp lực, đó là bài học đầu tiên khi mình làm ở Gameloft mình nhận được. Sau đó mình làm về công ty outsourcing, cũng làm về product, nhưng mà trong công ty có phát triển sản phẩm chuyên đi thu thập dữ liệu và tách ra thành công ty gọi là Unit Media, để làm về thu thập và phân tích dữ liệu, ở đó cũng có nhiều bài học, là nơi mình trưởng thành thật sự về mặt kỹ thuật. Tức là requirement của sản phẩm đó, nghe thì đơn giản nhưng mà nó phức tạp thế này, mình phải thu thập dữ liệu làm sao nhanh nhất, những nội dung mà người VN mình trao đổi bằng tiếng Việt có ở tất cả các kênh truyền thông giống như là facebook, youtube, diễn đàn hay thậm chí đến cả comment của các trang như VnExpress, thì mình phải thu thập về sau nhanh nhất để khách hàng của mình ví dụ như Vietjet để họ biết được khách hàng của mình đang complain chuyện gì đó trong thời gian rất ngắn, tức là trong vòng 5 đến 15 phút đã họ đã biết ai đó nói không tốt về mình, để mà đội xử lý truyền thông can thiệp kịp thời, đánh giá tình hình, xem xét và xem cách giải quyết như thế nào. Mình hay được nghe nói làm về big data hay là về AI, đó là lần đầu tiên mình làm dự án có những đặc tính như vậy, tức là lượng thu thập về rất nhiều, mình xử lý, tính toán thông minh bằng cách nào đó để xử lý lượng dữ liệu khổng lồ như vậy, thì nó giúp mình trưởng thành về mặt kỹ thuật. Rồi giai đoạn sau mình làm ở Sendo, Sendo là công ty to và phát triển nhanh, vì vậy nó đòi hỏi mình phải thiết kế hệ thống thích nghi được sự phát triển nhanh như vậy, cũng như là mình có lượng người dùng, lượng traffic lớn, và mình cũng phải thiết kế hệ thống làm sao đáp ứng được những chuyện đó. Về thương mại điện tử thì các công ty đều quan tâm yếu tố security, thì mình cũng phải tìm hiểu những chuyện như vậy, đó là tất cả những gì mình nghĩ quá trình mình đi làm ở công ty mình học được. Quay lại câu hỏi của em “cơ duyên nào chuyển qua thương mại điện tử”, thực ra mình nghĩ đó chuyện cũng giống bao người, tức là ngày trước mình đi làm cũng có anh em đồng nghiệp tốt, đến khi anh em rời bỏ vị trí cùng làm chung với mình họ qua phát triển ở một nơi khác, sau đó mình cũng trưởng thành và cần tìm một môi trường khác thử thách hơn, trước đó mình có những mối quan hệ tốt đẹp, người anh đó hiểu năng lực của mình và giới thiệu mình sang một nơi khác phù hợp với bản thân và mình tiếp tục qua đó đón nhận những thử thách mới, và đó là lúc mình qua làm e-commerce, và mình thấy đó là quyết định đúng đắn.
Anh có thể chia sẻ case thành công khiến anh tự hào nhất cũng như những case thất bại đã cho anh nhiều bài học đáng nhớ không?
Cái case thành công nhất là khi xưa mình làm ở Gameloft, thì hàng năm có những cuộc thi dành cho developer trong công ty thi thố với nhau, tức là mang cái game có tính đối kháng giống như mình chơi cờ tướng chẳng hạn thì cái thời điểm đó là game đánh cầu thì mình sẽ nâng cấp 2 thuật toán với nhau để mà thi đấu với nhau, thì mình thấy hàng năm thì có những sự kiện đó thì tổ chức nó không được, kiểu như là xài cái phần mềm có sẵn, để cấp các thuật toán thì mọi người bu xung quanh cái máy tính để bàn để xem, thì mình quyết định là đem hết tất cả loại để build cái ứng dụng cũng như ứng dụng quay vậy đó, mọi người sẽ submit các ứng dụng của mình rồi các ứng dụng nó sẽ được lọc và cách nào đó nó sẽ random ngẫu nhiên các thuật toán để thi đấu hoặc là để cái người up lên họ có thể chọn cái đống thông nào đó, mình biết trong đó có mấy ông viết thuật toán rất là giỏi để mà thi đấu với ổng, sau đó mình lập trình để mà nó chia bảng với nhau, thi đấu tới trận chung kết để dừng lại đó rồi mình sẽ livestream trên toàn bộ, ở Gameloft nó gọi các studio tại vì nó làm game, và cái từ đúng đắn của nó gọi là video game chứ không hẳn về game không, tức là nó như ngành phim ảnh vậy đó chứ nó không phải là cái ngành kỹ thuật đơn thuần và mình gọi cái nơi phát triển văn phòng game là studio, người sản xuất game là producer, mình gọi những người mà làm về graphic designer mình gọi là artist, thì mình làm cái ứng dụng để mà mình chiếu trên, do Gameloft nó có nhiều studio, như ở Saigon có Sài Gòn 1, Sài Gòn 2, nó có Đà Nẵng, thì mình chiếu tất cả lên trên đó để mọi người tham gia cái game đó, và mình thấy chỉ là cái người sinh viên mới ra trường 1-2 năm và mình làm cái việc đó nó thu hút, nó tạo ra được cái ấn tượng đến tất cả những lập trình viên, nó rất là tự hào.
Còn nói về cái mistake mà mình làm, khi xưa mình làm ở YouNet Media thì ngoài việc làm về Social Hit – 3 năm sau mới thành công, về đi sale đi bán đến 1 khách hàng ứng dụng của mình thì trong giai đoạn mình về product thì nói chung mình cũng lấy ngắn nuôi dài, mình cũng phải làm những cái dự án gọi là outsourcing thời điểm đó, có 1 cái dịp rất là lớn của VNG, mình không nhớ rõ hình như là sinh nhật 10 hay 15 năm của họ thì công ty xác nhận để làm 1 album để cho mọi người lookback lại những hành tình mà họ đến cùng VNG cũng như họ chia sẻ 1 cái video mp3, mình làm những cái đó lại để thành 1 cái album để họ lookback giống như kiểu của facebook làm thôi. Mình làm cái đó nó bị thất bại vì mình không đánh giá được, đối với VNG cái sản phẩm đó phải hoàn chỉnh đến mức độ gọi rất là tỉ mỉ và chính xác tại vì ngày xưa mình làm ở Sendo thì các khách hàng của mình thường là khách hàng nhỏ thôi, cái thứ 2 là khách hàng business thôi và những cái chuẩn business đó những người businessman họ làm với nhau thôi, mình làm kĩ thuật đơn giản bắt mình làm 1 thì mình làm 1 thôi, nhưng khi mình làm cái chuyện này thì release ra là end user, người dùng bên ngoài vào và khi 1 cái sản phẩm của VNG ra thì nó có 1 cái thông điệp gì, giống như chúc cho mọi người nhìn lại cái hành trình mà họ đã đến với VNG thì cái kỳ vọng của người dùng họ rất là lớn, nhưng mà sản phẩm ra thì kết hợp data lớn nên nó bị trục trặc, thế này thế kia, mình không lường trước cái chuyện đó nên cái sản phẩm cuối cùng nó phải dừng lại không chạy nữa, thì cái chuyện đó nó làm cho mình rất là buồn, nhưng mãi sau này mình mới học được 1 điều đó là 1 sản phẩm như vậy thì 1 cá nhân như mình không thể làm được, đó là bài học mình rút ra được.
Anh có thể chỉ ra công nghệ nào đáng sử dụng cũng như ưu/nhược điểm của công nghệ đó không?
Thì mình nghĩ là những câu hỏi này, các bạn làm về kỹ thuật hay đặt ra câu hỏi và tìm kiếm câu trả lời, cá nhân mình cho rằng là cái câu hỏi đó nó có những điểm đúng và không đúng. đối với suy nghĩ của mình thì ngôn ngữ của 1 bạn lập trình viên thì nên học ít nhất là 2 ngôn ngữ và nên giỏi ít nhất là 2 ngôn ngữ thí dụ như mình có thể giỏi về Golang cả PHP, hay PhP và NodeJS chẳng hạn, rồi về mặt Database, mình nên giỏi cả dựng như cơ sở dữ liệu quan hệ như MySQL và các cơ sở dữ liệu không mối quan hệ như MongoDB mình còn gọi là NoSQL á. Về mặt framework mình cũng nên biết ít nhất là 2, mình nghĩ như vậy là bởi vì nó giúp cho mình có 1 cái nhìn rộng mở hơn 1 vấn đề, vì lúc nào mình cũng nghĩ về 1 thứ nên mình tự bóp hẹp bản thân mình và nhìn ngắm bản thân mình trong 1 cái gì đó, khi mình nhìn rộng ra 2 hướng, thì nó sẽ có tính tương hỗ và tương thích với nhau thí dụ cái kia nó làm cái này, cái kia nó làm cái khác, 2 cái đó không thể nào giống nhau được, do đó là mình mới hiểu được những người Creator của ngôn ngữ đó họ suy nghĩ gì, họ có cái triết lý gì, họ có cái quan điểm gì trong bản thân họ. Và đó là cái điều mà khi mình biết những chuyện đó, giống như là mình học hỏi được từ những người đi trước, từ những bộ não siêu việt, là những người thiết kế ra ngôn ngữ, cái framework là họ có cái tư duy về hệ thống rất là tốt, tư duy về tổ chức này nọ, và đó là cái khiến cho mình trở nên gọi là mình hiểu biết rộng ra, không chỉ sâu mà rộng.
Anh có thể chia sẻ về những lỗi nào mà một người nhiều kinh nghiệm như anh vẫn có thể gặp phải không và điều đó làm anh thay đổi như thế nào?
Một trong những cái mistake mình hay gặp phải, thí dụ như là mình đo lường cái vấn đề nó dưới mức mà vấn đề đó thực sự có thể đối mặt. Bởi vì mình có thể do chủ quan dựa trên kinh nghiệm của mình, cái thứ 2 là mình không nhận đủ các nguồn thông tin, không phải người khác dấu mình cái gì mà do trong quá trình trao đổi và nói chuyện với nhau mình có thể dễ dàng bị miss những cái thông tin như vậy, dẫn đến mình estimate cái gì thì mình hay under cái mức đó, thí dụ như các bạn lập trình viên bình thường, thì thường over các task được giao, vì khi manager họ nghĩ được rồi, họ chia cái task cho nó nhỏ nhất đến mọi người, nhưng ông manager lại có cái lỗi là hay estimate 1 vấn đề là dưới ngưỡng cái mức đó, dẫn đến là nhiều cái dự án thất bại như vậy.
Đó là những lời thay cho manager thường gặp, còn đối với người làm kỹ thuật thông thường như mình, những lỗi hay gặp là mình bị thiếu cái kỹ năng, ví dụ mình không đánh giá hết hậu quả về vấn đề liên quan tới tài chính network, security, mình không đánh giá được tại 1 thời điểm nào đó, cái mạng với cái băng thông của mình nó sẽ có vấn đề, rồi mình cũng không biết trong cái tổ chức của mình nó có những cái lỗ hổng gì về bảo mật, hay lỗi gì mà nó có thể xảy ra, tại vì những lỗ hổng về cái security không hẳn về yếu tố kỹ thuật phải tốt mà nó còn về yếu tố con người, vận hành về hệ thống, nó rất là khó để cho mình có cái nhìn nào mà hoàn thiện về nó hay ngăn ngừa được những chuyện như vậy, nên nó sẽ vẫn diễn ra.
Quay lại với Solution Architect, theo anh đâu là 3 tiêu chí tiên quyết cần có đối với vị trí này?
Mình cũng muốn ý này là không chỉ ở vị trí kiên quyết, mình xin nhắc lại không phải kiên quyết của vị trí solution architect mà đối với 1 bạn lập trình viên, thì cái đầu tiên quan trọng và kiên quyết nhất là kỹ thuật xây dựng thì các kỹ năng về mặt kỹ thuật phải được xây dựng dựa trên yếu tố phần lớn là phải tự học, không ai hơi đâu mà chỉ, hay ngồi dạy cho mình, còn người khác dạy hay chia sẻ với mình là bởi vì cả 2 cùng nhận ra được điều còn thiếu của người này, mình học hỏi được người này, mình học hỏi từ người kia, cho nên bản thân mình phải là người biết tự học để mình chia sẻ kiến thức với người khác và nhận được từ người còn lại, thì cái kỹ năng tự học đối với mình là cực kỳ quan trọng, coi lại những điều mà cần trước để mấy bạn phát triển bản thân lên, để trở thành 1 lập trình viên giỏi, thì 1 senior hay 1 người chuyên về làm architect á, đầu tiên là kỹ năng tự học, thì mục tiêu của nó chính là không phải cái gì mình cũng sẽ được biết hết ở trường, hay là tất cả mọi thứ mình sẽ nhận được từ người khác, mà những kiến thức đó nó nằm trên mạng, trong các framework, hay trong các opensource, hay trong những bài viết, bài chia sẻ, có rất nhiều kênh, hay những kênh giáo dục này nọ, mình phải học nó thì mình tiếp cận với những người đồng nghiệp anh em của mình, mình chia sẻ lại đó và nhận lại những cái chia sẻ ngược lại từ những mảng kiến thức khác người khác dành cho mình, thì mình improve bản thân. Thì nói về tự học, 1 trong những cái đặc điểm mình cho rằng là khả năng ghi chép tất cả những thứ đã được học, dùng đầu óc của mình để nhớ và tự trong 1 môi trường công việc nó áp lực và chịu nhiều căng thẳng, tức là đôi khi mình sẽ quên mất hôm trước mình làm cái gì rồi, do đó mình phải ghi chép lại tất cả mọi thứ được học, mình phát triển kỹ năng, việc block lại tất cả thông tin mình học được, những cái lỗi mà mình đã gặp phải để mà review lại bản thân, hay là mình sẽ đem nó chia sẻ lại cho các bạn junior, những người mà mình sẽ thành trainer trực tiếp cho các bạn đó.
Cái thứ 2 là kỹ năng thấu hiểu, thấu hiểu về công việc của người khác, tại vì mình phải thấu hiểu cho bộ phận làm business, như khi mình làm về công ty outsourcing theo kiểu là tìm kiếm và dành lấy từ khách hàng để công việc nó rất là khó rồi mình cũng thấu hiểu cho đồng nghiệp của mình, họ cũng gặp những cái khó khăn trong cái công việc nhất định, tức là mình đi làm mình không thể nào chờ mistake của người khác để mình tấn công họ, mình phải nhìn ra, thông cảm, ông làm wrongmain sẽ thông cảm cho ông làm HM, và ngược lại, thì cái chuyện đó nó giúp mình xích lại gần, hiểu họ.
Theo em thấy việc xây dựng 1 đội dev làm việc hiệu quả rất là quan trọng và cần nhiều yếu tố khác nhau. Anh có thể chia sẻ tips hoặc lời khuyên nào không? Và anh có sử dụng các hình thức như pair programming, cross-training,… hay tạo điều kiện cho các juniors thử sức hay không?
Như em nói mong muốn trở thành người đồng nghiệp tốt của người khác là mong muốn của mình, suy nghĩ của mình đơn giản lắm, mình không muốn ai đi theo sau cái bóng của mình, mình mong muốn tất cả mọi người đều đi song hành cùng mình, tiến lên phía trước cùng mình, vì vậy mà kỹ thuật hay những điều mà mình có thể giúp cho đồng nghiệp của mình bằng cách trực tiếp hay là những cái âm thầm lặng lẽ, mình đều cố gắng làm cả, những cái chiến thực cần có giống như làm pairwork theo nghi thức, đó là phương pháp phát triển phần mềm của công ty, công ty nó có nhu cầu thì mình làm thôi, không vấn đề gì, nhưng tất cả tình cảm, suy nghĩ của mình, mình phải có cái suy nghĩ luôn luôn thúc đẩy các anh em đi lên phía trước, tức là nếu mà có những cái thử thách, hay tìm hiểu những cái điều gì hay mình cũng suy nghĩ làm thế nào để làm cho mọi người thích cái đó, muốn tìm hiểu cái đó, và muốn làm được cái đó, thì cá nhân mình, mình luôn muốn như vậy, thì với những cái suy nghĩ như vậy, cho nên là mình sợ cái người mà minh chia sẻ tất cả mọi thứ, biết tất cả mọi người, giúp cho mọi người hiểu rõ vấn đề, thì khi hiểu rõ mọi người sẽ hiểu là mình có muốn làm chuyện đó hay không, và hiểu rõ thì nhiều khi sẽ thấy thú vị và thấy thú vị thì mọi người sẽ muốn làm, còn mình hay dở trong cái việc mà trở thành 1 người manager tốt giống như là quan tâm chuyện tâm tư tình cảm, gia đình, tình yêu, hay họ ở những cái khía cạnh khác, thì mình không phải là người giỏi trong lĩnh vực đó, như những cái chuyện như là nhiều khi chuyện tình cảm với nhau mình cũng hơi bối rối, mình phải feedback lại hay là mình phải trả lời câu đó như thế nào, nếu câu trả lời của mình hời hợt thì mình nghĩ lại người khác sẽ buồn, mà cái câu hỏi là mình nghĩ để trả lời cho chính xác thì mình phải đào sâu vào trong mối quan hệ đó, thì mình không có thiên hướng như vậy.
Làm thế nào để một bạn xác định được là mình nên đi theo con đường Solution Architect? Anh có lời khuyên nào dành cho các bạn đang muốn hướng tới công việc này không?
Nếu thực sự có quyết tâm để trở thành người top talent về mặt SQL thì giống như mình đã từng xem 1 cái video của TopDev của anh Tùng Nguyễn, trước là làm head về engineering Tiki, sau đó khoảng 1 thời gian mình cũng có buổi ngồi nói chuyện với ảnh, trong quán cà phê, thì giống ảnh chia sẻ, nói chung để mà trở thành top talent về mảng SQL, thì có nghĩa là mình viết code giỏi, một cách bài bản, mình phải kiểm chứng và test những phần mềm như QC thực thụ, mình có thể deploy vừa delivery sản phẩm của mình như 1 DevOps 1 cách hoàn chỉnh, thì mình có thể tâm đắc với các chia sẻ của ảnh, cách thứ 2 là nhìn vào tính cách của những người như anh Tùng Nguyễn, ảnh là người điềm tĩnh, 1 người cẩn trọng, 1 người thông minh nhưng mà khiêm nhường, tại vì mình phải xác định được những điều mình làm, và tất cả những việc làm đó mình sẽ phải học hỏi, thì phải có ai đó, đồng nghiệp chia sẻ mình, giúp đỡ mình, thì với những cái tính cách, công việc thành công như vậy mình có thể tham khảo, học hỏi, nhìn vào đó để đối chiếu với bản thân mình, thì với tính cách của anh Tùng, ảnh rất là dễ chia sẻ với người khác, dễ dàng nhận sự hỗ trợ khác, có thể cùng tìm hiểu vấn đề đó chưa đúng, hoàn thiện nó, thì anh nghĩ đó là hình mẫu mà 1 người thành công muốn tham khảo.
Trong team anh có vị trí full-stack developer không? Theo quan điểm của mình, anh có nhận xét gì về vị trí và vai trò của full-stack developer?
Vị trí fullstack developer trong giai đoạn quá trình lịch sử của nước mình nó chia nhiều giai đoạn. Giai đoạn đầu tiên là giống như mình là 1 vương quốc, đế chế như vậy, thì 1 ông vừa biết làm PHP backend có thể làm các HTML frontend thì trở thành fullstack, nên biết làm jQuery, hay Angular này nọ thì trở thành fullstack. Sau này thì những ông biết làm fullstack, thì đòi hỏi cao hơn 1 chút, như biết 1 chút về backend như PHP, biết 1 chút về Frontend, viết app mobile chẳng hạn thì trở thành fullstack. Rồi thậm chí là biết làm về Database nữa, thì gom tất cả những cái đó thì thành fullstack.
Ngày nay fullstack là 1 người có đầy đủ tất cả kỹ năng develop về mặt testing, về mặt operate giống như là DevOps, thì những người đầy đủ tất cả các kỹ năng trở thành fullstack, nhưng mà cho đến thời điểm hiện tại của năm 2020, thì chúng ta sẽ thấy, khái niệm nó bị tác động bởi những cái tổ chức lớn như là Google, Amazon thì phải thêm 1 cái yếu tố mà người developer phải biết nữa đó là security thì tất cả những chuyện đó, trở thành fullstack. Tại sao có sự phát triển đó, thì bởi vì đơn giản, kiến thức nó có sự kế thừa, thí dụ như đất nước mình, mảng công nghệ thông tin cách đây 10 năm chỉ là PHP. Bây giờ mình đã tham gia vô sâu hơn trong cái gọi là cái dây chuyền sản xuất, hay cái dây chuyền công nghệ thông tin của thế giới, mình cũng dần dần tiếp cận và được nhận về những cái project, dự án đó, mình cũng có thể có những công ty được xem là kỳ ân, do đó là mình cũng phải áp dụng mấy cái tư tưởng cao như vậy, để mà duy trì và tiếp tục phát triển, do đó là những cái nền tảng đó, đã được đưa về nước mình và được áp dụng, và nhiều cái đã áp dụng thành công. Bây giờ cái khái niệm đó, nước mình cũng đạt được những cái mức độ cạnh tranh như vậy.
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?