Ask A Developer: Thinking Outside The Box Để Làm Những Công Việc “Inside The Box” — Lê Duy Anh (QC & Tester)

Published in

lozi-teamblog

19 min readMay 6, 2022

🎧🎧 Lắng nghe toàn bộ buổi chia sẻ tại Life at Loship Podcast bạn nha!

Đóng vai trò của “người hướng nội cầu nối” — vai trò của Duy Anh tại team Tech như một người kết nối giữa team Tech và khách hàng mà chúng ta hay gọi vui là người chuyển đổi từ ngôn ngữ lập trình qua ngôn ngữ đời sống và ngược lại. Hãy cùng lắng nghe những chia sẻ về những khía cạnh xoay quanh công việc và cuộc sống của một người anh tự nhận mình là “thân thiện nhưng khó gần” này các bạn nha!

Chào anh đã đến với Ask A Developer, lần đầu tiên, anh có thể giới thiệu cho mọi người biết một chút về bản thân mình được không?

Đầu tiên thì xin chào Hiền, mình là Duy Anh, hiện đang giữ vị trí QC tại Loship, đồng thời mình cũng đang trực trên kênh Tech. Mình thuộc cung Ma Kết, là tuýp người hướng nội và mình thích đọc sách, đặc biệt là sách về chiêm tinh.

Anh muốn được người khác gọi mình như thế nào, là tên thật, hay là một cái tên gắn liền với công việc của anh, hay là một tên gọi với một ý nghĩa đặc biệt nào khác?

Trong Loship, mình có một biệt danh là Cá heo, do một lần mình mặc một chiếc áo thun hình con cá heo, và từ đó thì mọi người gọi mình bằng cái tên đó luôn (cười)

Theo em được biết, vị trí của một Tester thường bắt nguồn từ chuyên môn của một người Dev, vậy cơ duyên nào đã đưa anh đến với nghề nghiệp hiện tại và điều gì đã đưa anh quyết định đến với Loship?

Đến với nghề này thì đúng là dòng đời xô đẩy thật, ban đầu mình không có dự định làm QC đâu, định hướng ban đầu là làm bên mảng ERP hoặc là trở thành Developer (ERP có thể hiểu như 1 phần mềm có các module hỗ trợ các lĩnh vực khác nhau như kế toán, bất động sản, quản trị nhân sự, …) mình cũng đã thử sức ở 2 vị trí này nhưng cảm thấy bản thân không phù hợp.

Sau đó mình bắt đầu với vị trí QC do cũng muốn biết về vai trò này như thế nào và cảm thấy bản thân phù hợp với việc đi “bắt lỗi thiên hạ”, sau hơn 4 tháng ngao du ở ngoài thì vào cuối tháng 3 /2019, mình đến với Loship và giữ vị trí QC đến hiện tại.

Tester có nhiều mảng như QA, QC, đặc biệt là Manual Tester và Automation Tester, vậy đặc thù công việc của anh sẽ chuyên về mảng nào?

Manual sẽ là test phần mềm bằng thủ công — khi người QC sẽ phải ngồi test tay từng test case một, còn với Automation thì QC sẽ test phần mềm bằng một phần mềm khác, cụ thể là viết 1 đoạn code cho 1 tính năng cần test, sau đó để đoạn code đó chạy và tiến hành xác nhận output của từng case đã test.

Tùy theo mỗi mục đích mà người QC sẽ quyết định mình làm Manual hay Automation, ở Loship thì đặc thù công việc của mình là Manual Test.

Một ngày với vị trí của người Tester tại Loship sẽ như thế nào anh ha?

Nếu nói cụ thể một ngày thì hơi khó vì mỗi ngày công việc của mình sẽ không giống nhau, luồng công việc của mình sẽ là nhận task, đọc toàn bộ task, note ra những ý quan trọng và list ra những đầu việc mình cần làm, sau đó là trao đổi với team để hiểu rõ task, viết file test case, thực hiện test và cuối cùng là báo cáo lại với team. Nếu còn thời gian rảnh thì mình sẽ viết document.

Thử thách và khó khăn lớn nhất trong công việc mà anh từng gặp là gì và anh đã làm thế nào để vượt qua chúng?

Thử thách và khó khăn lớn nhất có lẽ là khi mình ở trong những tháng đầu tiên tại Loship, mình đã khá lo lắng và sợ, nhưng may mắn là có mọi người giúp đỡ. Lúc ấy, khi mình viết ra bộ test case, mình hay đưa cho anh Mặp PM để review, sau đó thì mình cũng lên mạng học hỏi về các quy trình kiểm thử, và mình hay test một cách không theo quy chuẩn.

Sau này mình mới phát hiện ra là có một kiểu test như thế, nó gọi là monkey testing, đại loại là khi mọi người “vọc app” thì hay gọi là monkey test, một kiểu test khác gọi là ad-hoc testing, tức là mọi người sẽ test theo những kiến thức mà mọi người biết về sử dụng app. Sau một khoảng thời gian thì mình đã đỡ “sấp mặt” hơn, lúc này mình cũng biết được một quy trình gọi là (STLC — Software Testing Life Cycle), quy trình đó đã giúp cho mình đỡ vất vả trong việc kiểm thử.

Điều khiến mình có thể vượt qua được thử thách trên là do bản thân mình luôn thúc đẩy bản thân tiến lên cộng thêm việc có mọi người giúp đỡ, đồng hành trong suốt khoảng thời gian khó khăn đó nên mình mới vượt qua được.

Anh có nhớ mình đã mất khoảng bao lâu để làm quen và vượt qua quãng thời gian đó không?

Mình nhớ là mất khoảng 4 đến 5 tháng để mình có thể làm quen với quy trình và tất cả mọi thứ, mọi người đúng nghĩa là cùng bơi với mình trong suốt quãng thời gian đó.

Làm việc trong môi trường tốc độ cao và nhiều áp lực như trong một startup, anh thường làm gì để hạn chế cho đầu óc mình không bị kiệt sức và rơi vào trạng thái burn out?

Với mình thì mình hạn chế burn out nhất có thể, bởi vì theo mình thấy bản thân đã kiệt sức và não đã bão hòa rồi thì làm gì chất lượng cũng ko còn như trước. Còn về việc làm như thế nào thì tầm 2–3 tiếng mình sẽ đi đâu đó quanh văn phòng để giải khuây chút rồi mới quay lại làm tiếp.

Thông thường thì đối với một quá trình mô tả lỗi (Description bugs), công đoạn nào sẽ là bước gặp nhiều khó khăn và tốn nhiều thời gian nhất: Bugs Steps hay Actual Result?

Công đoạn gặp nhiều khó khăn và tốn thời gian thì sẽ là Bugs Step, trong QC có một thuật ngữ gọi là Bug Report, khi mình nhận thông tin về 1 vấn đề mà người dùng gặp phải, mình cần hiểu là vấn đề thực chất là gì, khi hiểu được rồi thì sẽ dựng lại lỗi đó.

Một số lúc dựng lại lỗi là được ngay, còn lại sẽ là không đúng lỗi đó hay không biết làm thế nào để dựng lại lỗi đó thì sẽ mất thời gian hơn để kiểm tra.

Anh có thể mô tả nhiều hơn về cách mà chúng ta sử dụng kiểm thử hộp đen và kiểm thử hộp trắng trong quy trình phát triển sản phẩm tại Loship để có thể có 1 sản phẩm hoàn chỉnh và ít lỗi hơn không ?

Về hộp đen và hộp trắng thì sẽ ví dụ như người đi xe và thợ sửa xe, một người khi sử dụng xe máy thì chỉ cần biết khởi động xe và chạy, biết thêm về cách xử lý xe là điểm cộng, còn với thợ sửa xe thì sẽ biết được toàn bộ cơ cấu, thành phần đến tính năng của từng bộ phận.

Hộp đen và trắng cũng tương tự vậy, với người dùng thông thường thì sẽ nhìn thấy sản phẩm hoạt động như thế nhưng không biết rõ bên trong như thế nào, còn người developer sẽ biết bên trong sản phẩm như thế nào.

Thường thì anh sẽ áp dụng kiểm thử hộp đen nhiều hơn. Ví dụ như khi lập test case cho việc kiểm tra nhập dòng số điện thoại khi đăng ký tài khoản — hợp lệ là từ 10–11 số, đến đây mình sẽ dùng kỹ thuật kiểm tra giá trị biên, lúc đó sẽ có 5 test case được sinh ra là:

Kiểm tra khi nhập số điện thoại có 9,10,11,12, và không nhập số điện thoại.

Khi nhận được 1 thông tin về bug (lỗi) trên ứng dụng hoặc hệ thống, đôi lúc là lỗi thì sẽ rất là mông lung, hoặc 1 edge case nào đó. Làm thế nào để anh tư duy dựng được lại lỗi và báo về cho tech để tiến hành sửa lỗi

Thường thì khi nhận được 1 thông tin về lỗi thì mình sẽ cần hiểu lỗi mà người dùng đang gặp là gì, sau khi hiểu được rồi thì tiến hành dựng lại case đó xem có đúng với lỗi mà người dùng đang gặp hay không.

Nếu dựng lại được thì mình sẽ báo lại với bên báo lỗi kiểm tra lại xem thế nào, nếu không được thì mình sẽ dành thêm thời gian để kiểm tra xem là có những yếu tố khác ảnh hưởng đến lỗi hay không, và sau cùng, nếu vẫn “bó tay” thì mình sẽ nhờ team nhảy vào hỗ trợ.

Được biết, vai trò của anh tại Loship khá đặc biệt, vừa là 1 Tester, vừa lại là 1 Tech help, có thể xem là ngoài CTO và PM, thì anh là người nắm giữ rất nhiều thông tin về cách mà hệ thống chúng ta vận hành và hoạt động. Vậy thì công việc của anh tại loship có gì khác biệt với bên ngoài không và anh đã làm thế nào để thực hiện vai trò này tại Loship?

Khác biệt lớn nhất ở những nơi mình từng làm là mình chỉ được giới hạn một phần nhỏ trong project lớn, còn với Loship thì mình được tham gia vào tất cả project, và cảm giác hiểu và nắm được hệ thống vận hành như thế nào cũng khá là thú vị vì khi đó mình được học hỏi nhiều hơn, được biết nhiều hơn. Còn về việc làm thế nào thì cũng là quá thời gian tiếp xúc, mày mò, tìm hiểu, đôi là té sấp mặt thì thực hiện được thôi.

Anh nghĩ sao về quan điểm rằng: Mỗi người dev nên là 1 tester, và mỗi 1 nhân viên trong công ty dù ở bất cứ bộ phận nào cũng có thể trở thành 1 tester cho chính sản phẩm của công ty mình, và như vậy, sản phẩm sẽ dễ dàng và nhanh chóng phát hiện lỗi và hoàn thiện hơn? Và liệu chúng ta có nên áp dụng điều này cho tương lai?

Mình nghĩ hiện tại quan điểm đó cũng đang áp dụng tại team Tech của Loship, anh Thịnh CTO có hay nói mỗi người Dev khi code cũng nên test lại chính bản code đó của mình, và không chỉ riêng nhân viên mà với mỗi người dùng cũng chính là tester, khi mỗi ý kiến mà khách hàng đóng góp chính là feedback để team có thể cải thiện sản phẩm hơn.

Việc đứng giữa khách hàng và người dev khi không ngừng lắng nghe ý kiến của người trải nghiệm đồng thời phải giao tiếp, truyền đạt thông tin, test case với người viết code đã cho anh đúc kết được những góc nhìn và bài học như thế nào trong quá trình làm việc giữa 2 đặc thù rất khác nhau này?

Đối với riêng mình thì 2 đặc thù này không có quá nhiều sự khác biệt vì không chỉ riêng mình mà team Tech cũng có mindset rằng chúng ta làm đang làm sản phẩm, khi bắt tay vào công việc và nói về tính năng thì cũng đi từ tổng quan tới chi tiết, từ sản phẩm xuống những dòng code nên khi nói chuyện về sản phẩm thì người Tech cũng có thể giao tiếp bình thường với khách hàng.

Một số bài học mà mình thường thấy giữa hai góc nhìn này đó là có một số vấn đề dưới góc nhìn của người dùng thì đơn giản và dễ dàng, nhưng khi bàn với team tech thì nó là một vấn đề khác và cần thời gian để giải quyết và ngược lại, cũng có những vấn đề mà người dùng thấy bất khó khăn và mất thời gian nhưng team tech lại thấy những vấn đề này hệ thống hiện tại có thể giải quyết.

Mỗi tình huống sẽ luôn có sự khác biệt nhưng mình thấy nó sẽ không quá nhiều. Gọi là đa ngôn ngữ thì cũng đúng vì sẽ có sự khác biệt nhất định giữa 2 khái niệm này, nhưng đến khi quen rồi thì sẽ thấy chúng vẫn có sự liên kết với nhau.

Em rất tò mò việc 1 người Dev sẽ thường làm gì để nâng cao và mài dũa kỹ năng chuyên môn của mình, anh có thể chia sẻ một chút về điều này được không?

Theo mọi người luôn nói là chỉ có khi làm nhiều, rút ra được kinh nghiệm sau mỗi lần sai và luôn update kiến thức mới là cách để nâng cao và mài dũa kỹ năng chuyên môn của mình thôi, trong Triết học có một khái niệm rằng “Khi lượng đạt đến một mức độ nhất định sẽ dẫn đến thay đổi về chất”, bản thân mỗi người tích góp kinh nghiệm và kiến thức không ngừng nghỉ sẽ cập nhật bản thân sang một phiên bản mới tốt hơn phiên bản cũ.

Mình có đọc được một ý trong một quyển sách đại loại rằng kiên trì không phải là làm một việc lặp đi lặp lại nhiều lần, mà là bản thân mình vẫn tiếp tục thực hiện công việc đó dù cho có gặp bao nhiêu khó khăn, thời gian và công sức đi chăng nữa.

Trong hành trình sự nghiệp của mình, có bao giờ anh muốn rẽ hướng sang một công việc khác cũng trong ngành lập trình, kỹ thuật hay chuyển sang một công việc hoàn toàn khác với chuyên môn của mình hay không?

Nếu nói về việc chuyển hướng thì mình cũng đã từng mong muốn bản thân sẽ đi theo hướng cũng có liên quan đến ngành kỹ thuật, gọi là phân tích nghiệp vụ (BA — Business Analyst) hay gọi vui là bệnh viện đa khoa. Bệnh viện là một nơi mà mọi người vào để tìm bệnh hoặc chữa bệnh, BA cũng là một nghề “bắt bệnh” cho doanh nghiệp.

Và vì sao gọi là đa khoa, vì sẽ có nhiều khoa khác nhau được tập hợp trong một bệnh viện, BA được tiếp xúc với nhiều lĩnh vực, qua đó cũng sẽ hấp thụ được một số lượng lớn kiến thức, điều này cũng trùng khớp với tính cách thích học hỏi và tìm tòi những cái mới của mình.

Đồng thời, yếu tố khiến mình muốn làm công việc này đó là tham gia sâu vào quá trình phát triển của một sản phẩm từ khi nó chưa xuất hiện để giải quyết nhu cầu của người dùng đến khi sản phẩm mình làm ra có thể đáp ứng, hỗ trợ được nhu cầu của người dùng. BA sẽ cần phải giao tiếp rất nhiều, trong khi mình thì rất ngại giao tiếp với người khác, nên mình nghĩ đây cũng sẽ khiến cho mình được bước ra khỏi vùng an toàn và thử thách bản thân trước nỗi sợ vốn có của chính mình.

Gắn bó với Loship một quãng thời gian khá dài rồi, vậy thì có kỷ niệm nào mà anh nhớ nhất trong quá trình làm việc tại Loship không?

Kỷ niệm mà mình nhớ nhất là khi cả team cùng nhau ngồi làm tính năng cho đến gần 10h tối. Thời điểm đó thì Loship còn ở bên địa chỉ 302 Tô Hiến Thành, lúc đó mọi người đang phát triển tính năng cho chủ quán, mặc dù đã trễ nhưng mọi người đều quyết tâm làm cho xong tính năng này thì mới về, đến nỗi anh bảo vệ phải vào nói thì mới ngỡ là gần 10h tối rồi, mặc dù mệt lắm nhưng mình vẫn rất vui vì đã cùng mọi người chiến đấu được với cái gọi là áp lực về thời gian.

Anh cảm thấy môi trường làm việc tại Loship có gì khác so với những môi trường làm việc ở những nơi khác?

Môi trường ở đây khá là phù hợp với tính cách bản thân mình, một điều mà mình thấy sự khác biệt ở Loship so với những nơi mình từng làm qua là mọi người luôn giúp đỡ lẫn nhau mỗi khi gặp khó khăn.

1 điều ở Loship khiến anh cảm thấy yêu thích và 1 điểm ở Loship khiến anh chưa hài lòng nhất?

Điều khiến mình yêu thích ở đây là mọi người luôn năng động, tràn đầy năng lượng và luôn giúp đỡ đồng nghiệp.

Điều khiến mình chưa hài lòng thì chắc là không có, bởi mình điều đó đã được giải quyết hoặc là mình đã quên. Mình quan niệm rằng cuộc sống đã đủ thứ mình phải suy nghĩ rồi nên nếu có điều gì mình chưa hài lòng thì hoặc là mình sẽ giải quyết nó hoặc là quên nó đi.

Trong 6 giá trị cốt lõi của Loship, anh thích nhất là giá trị nào?

Mình thích nhất là 2 giá trị cốt lõi sau:

Tốc độ quan trọng hơn sự hoàn hảo: Mình muốn đi nhanh, nhưng bên cạnh đó thì tốc độ cần phải đủ tốt, đủ tốt ở đây sẽ nằm trong khoảng 90–98%, là dù đi nhanh, nhưng mình vẫn luôn phải đáp ứng được chất lượng tối thiểu mà các yêu cầu đề ra.

Mình là nguồn gốc của mọi vấn đề: Thật ra khi có vấn đề, mình thấy ngoài việc tham gia vào để hỗ trợ thì mình cũng sẽ học được 1 điều gì đó sau khi để sau này bản thân mình rơi vào vấn đề tương tự thì mình cũng có thể giải quyết được.

Nếu có 1 lời khuyên dành cho những bạn fresher, junior mới ra trường muốn dấn thân vào vị trí này, anh nghĩ đó sẽ là gì?

Vị trí này thực sự rất thú vị, do tính chất công việc là kiểm soát chất lượng sản phẩm mà, nên ngoài việc suy nghĩ theo hướng thông thường thì đôi lúc cũng sẽ cần thinking outside the box một chút , để trí tưởng tượng bay xa một chút.

Sau giờ làm, anh thường dành thời gian cho bản thân như thế nào?

Mình là một con người hướng nội, mình có đọc được ở đâu đó rằng khi người hướng nội sử dụng phần lớn thời gian và năng lượng của họ cho những hoạt động hướng ngoại thì họ sẽ rơi vào trạng thái cạn kiệt năng lượng khi đã dùng hết phần năng lượng dự trữ vốn có.

Đối với những ngày như vậy thì mình sẽ muốn đi đâu đó để sạc lại năng lượng, ngoài việc đó ra thì mình hay đọc sách, dạo qua các blog để học hỏi và tìm hiểu thêm kiến thức, chỉ muốn là có một khoảng thời gian để dành cho chính mình.

Điều gì tạo nên 1 ngày hoàn hảo đối với anh?

Một ngày hoàn hảo đối với mình là khi mình học thêm được một điều gì mới, một kiến thức mới, chỉ thế thôi thì cảm thấy bản thân hôm nay đã chất lượng hơn ngày hôm qua 1 phần rồi.

Trong 6 giá trị cốt lõi của công ty mình có một giá trị là Ownership — Bản thân mình là nguồn gốc của mọi vấn đề, em nghĩ điều đó cũng có liên quan đến câu nói “Mỗi một người Dev nên là một Tester cho chính sản phẩm của mình” đúng không ạ?

Mình nghĩ là tùy tình huống nữa, do ở thị trường hiện tại thì đang có 2 mô hình về công ty công nghệ, đó là công ty về product và công ty về outsource. Mình đã có cơ hội tham gia vào nhiều công ty về outsource, theo cá nhân mình thì với mô hình công ty này thì mỗi người Dev không nhất thiết phải là người đi test đoạn code đó, khi hoàn thành xong thì họ có thể chuyển qua cho QC làm công việc đó, mình thấy thì điều đó khá là mất thời gian cho QC.

Còn đối với các công ty về product — khi sản phẩm cũng chính là “đứa con tinh thần” của mỗi nhân viên, thì tính ownership, sự gắn bó và trách nhiệm của bản thân về sản phẩm đó cũng sẽ lớn hơn.

Theo em nghĩ, điều đau đầu nặng não với 1 tester là khả năng nghĩ và phát hiện ra các edge case hơn là 1 happy case, và bao gồm cả những case lỗi có thể chưa từng xảy ra trên thực tế. Vậy thì quá trình tư duy của anh sẽ như thế nào để có thể bao quát các trường hợp và phát hiện những lỗi tiềm ẩn như vậy? Anh có thể chia sẻ nhiều hơn được không?

Làm QC tại Loship, ở thời điểm ban đầu, mình cũng có suy nghĩ là sẽ tìm hết những lỗi có thể xảy ra, nói chính xác hơn là phải bao bọc được những lỗi có thể xảy ra và chưa từng xảy ra.

Nhưng sau thời gian đó thì mình cũng khá áp lực vì có làm như thế nào thì lỗi vẫn có thể xảy ra, mình có đọc được một bài viết rằng trong công việc của QC thì không thể nào kỳ vọng rằng sẽ không thể có một lỗi nào xảy ra được, việc người QC có thể làm là giảm thiểu thiệt hại những lỗi có thể xảy ra.

Thay vì cứ lo rằng lỗi đó có thể xảy ra hay không, thì mình nên lo rằng lỗi đó sẽ gây ra thiệt hại và ảnh hưởng bao nhiêu đến sản phẩm của mình, và mình có thể giảm thiểu được bao nhiêu thiệt hại trong từng lỗi đó.

Còn đối với edge case thì khá là khó để tìm được nó, nên mình thay đổi suy nghĩ thay vì tìm được nó, mình sẽ cố gắng giảm mọi thiệt hại tối thiểu nhát có thể mà nó gây ra, như thế sẽ nhẹ đầu hơn.

Được biết, ngoài công việc Tester, anh còn đảm nhận viết document cho sản phẩm. Với 1 công ty mà sản phẩm luôn cập nhật thường xuyên và luôn thay đổi nhanh chóng như Loship, vì việc viết tài liệu kỹ thuật cho Dev và cho người dùng công ty được thực hiện như thế nào vậy anh? Làm thế nào để anh có thể theo kịp được tốc độ thay đổi này?

Ở thời điểm hiện tại thì mình đang viết doc cho người dùng trước, mỗi 1 tính năng sẽ được đánh 1 số ID và gắn nó vào matrix traceability kèm theo các điều kiện đầu vào và đầu ra (mình hay gọi là sơ đồ kiểm soát thay đổi).

Khi có sự thay đổi về 1 tính năng nào đó, việc mình làm sẽ là kiểm tra ID của tính năng có sự thay đổi, và kiểm tra tính năng này sẽ là điều kiện đầu vào của tính năng nào, từ đó biết được khi tính năng này có sự thay đổi thì có bao nhiêu tính năng bị ảnh hưởng theo.

Sau đó là viết doc cho dev, doc của người dev thì mình cần một bản hoàn thiện và chi tiết với nhiều yếu tố đi vào chuyên sâu và kĩ thuật hơn.

Vậy thì sau khi bản doc được hoàn thiện, người dùng có thể truy cập vào đâu để có thể xem những thông tin này ạ?

Hiện tại thì mình đang viết trên một platform gọi là Notion, mới chỉ là những bước đi đầu tiên thôi, hy vọng có thể đến tay người dùng trong thời gian sớm nhất.

Chúng ta hãy đi qua một số câu hỏi nhanh về anh nhé, anh đã sẵn sàng rồi chứ?

3 từ để miêu tả về bản thân anh? Ít nói, thân thiện nhưng khó gần, có chiều sâu

Khía cạnh trong công việc mà anh không bao giờ thỏa hiệp? Sự không rõ ràng

3 điều anh thích nhất về công việc hiện tại? Sáng tạo, thỏa sức làm những điều mình muốn, làm đúng với đam mê của mình.

3 từ để miêu tả về văn hóa ở Loship? Thân thiện, năng động, vui.

3 gương mặt tại Loship ảnh hưởng đến quan điểm của anh trong công việc của anh nhiều nhất? Ở Loship, mình được tiếp lửa đam mê bởi khá nhiều người , một vài câu nói tiêu biểu như :

“Nếu đã mơ , tại sao không mơ cho lớn” - anh Trung CEO

“Xây dựng sản phẩm và xem sản phẩm đó như đứa con tinh thần của mình , từng ngày từng ngày thấy sản phẩm đó hoàn thiện như xem đứa con tinh thần của mình ngày càng hoàn thiện hơn” — anh Thịnh (Mặp) PM

“Nên đưa công nghệ về đúng giá trị của nó” — anh Thịnh CTO

“Mọi người nên biết và hiểu là những gì mọi người làm không chỉ là những dòng code mà nó còn ảnh hưởng đến công ty” — anh Quang (lead pair Growth)

Ngoài ra còn khá nhiều người khác như anh Nam , anh Tân ,….. và những nhân vật bí ẩn khác ngoài team Tech đã mang cho mình ngọn lửa của đam mê, của tuổi trẻ để mình có thể thỏa sức cháy hết mình.

💥Theo dõi Loship để cập nhật thông tin mới nhất:

Fanpage: fb.com/lozi.team
Linkedin: linkedin.com/lozi
Twitter: twitter.com/LoshipVN
Instagram: instagram.com/loshipvn/
Spotify: open.spotfify.com/lifeatloship