SupremeTech

Dù anh làm không tốt, dự án anh không tốt nhưng kì sau anh lên chức cao nhé các em

Tổng hợp và tóm gọn review SupremeTech từ congtytui.net 1. **Môi trường làm việc**: - Môi trường kém, quản lý yếu, máy cũ (Mac Air 2017) cản trở công việc. 2. **Lương thưởng và phúc lợi**: - Lương thấp, khó tăng lương, bị cho là "hút máu nhân viên". 3. **Quy trình tuyển dụng và HR**: - HR phản hồi chậm, thiếu chuyên nghiệp, nghi ngờ tuyển "ảo". 4. **Ý kiến trái chiều**: - Review chủ yếu tiêu cực, nhưng có ý kiến kêu gọi nhìn nhận khách quan; phúc lợi trung bình. 5. **Cảm nhận chung**: - Đa số chê lương, quản lý, môi trường; cần kiểm chứng thêm

tụi bây lo tập trung làm tốt công việc và nhiệm vụ của bản thân mình đi. rảnh quá lên đây comment lung tung kiểu mấy thằng drama thì nghỉ đi. dev thì lo tập trung code cho ngon, cho đẹp, chạy cho mượt mà. task khó hay cần chất lượng thì gắng mà làm, không ghi nhận thì tìm cơ hội mới (😂l, việc gì phải xoắn. đừng hổ thẹn với bản thân tụi bây là được, bớt kêu ca cho đời vui vẻ. tụi bây code cho xong việc tới lúc lòi bug, code ẩu, chắp vá, kém chất lượng khách hàng gai con mắt thì dự án nó toang đấy thôi (nhìn dự án PC và C mà xem) 👌 techlead và PM thì lo mà quản lý dự án của mình cho ra hồn, coi mấy thằng dev cần gì thì support tech lẫn non-tech. thằng nào kêu ca máy yếu thì coi cấp được cho nó ngon hơn đc thì cấp, làm phước cho đời. tụi nó làm ko ra hay ko rõ cái gì đi hỏi thì support tụi nó vui vẻ niềm nở. 🖖hãy nhớ thành công của các dự án, của công ty là của tất cả mọi thành phần, mọi roles. không phải phán xét hay xỉa xói gì, nhưng PM, leaders cũng nên nhớ bản thân quản lý và lead 1 dự án thành công cũng nhờ vào members cả. manager team dev cũng hưởng cái "tiếng thơm" từ member của mình đấy thôi. hãy xem 1 số dự án cũ nát & toang (tự nhớ tên đi) thì đi tông cả nùi từ PM đấy thôi 😪. .dài dòng rồi, chấm hết. Nghe thì làm, không thì tự chịu.

2. “Nếu yếu kém trong code và quản lý thì sếp sẽ tự nhìn ra, không cần ai lên tiếng” Đây là một giả định khá thụ động. Không phải sếp nào cũng đủ thời gian, năng lực hoặc dữ liệu để tự phát hiện ra mọi vấn đề của nhân viên. Trong thực tế, nhiều công ty lớn có hệ thống quản lý phân cấp, và sếp có thể không trực tiếp thấy được sự yếu kém nếu không có phản hồi từ đồng nghiệp hoặc số liệu cụ thể (ví dụ: bug trong code, dự án trễ hạn). Nếu ai cũng im lặng vì “đến lượt sếp tự nhìn ra”, thì môi trường làm việc sẽ trì trệ, và người yếu kém không bị đào thải ngay đâu – họ có thể tồn tại lâu hơn bạn nghĩ, gây ảnh hưởng đến cả đội.

Mỗi công ty, mỗi quản lý sẽ có góc nhìn riêng về con người” Bạn nói đúng ở chỗ mỗi công ty hay mỗi quản lý có tiêu chí đánh giá riêng, nhưng điều này không có nghĩa là mọi nhân viên đều được “đặt niềm tin” chỉ vì họ đáp ứng được một phần nhu cầu. Thực tế, trong môi trường cạnh tranh, nếu một người không tốt ở một khía cạnh quan trọng (ví dụ: kỹ năng chuyên môn hoặc thái độ làm việc), thì việc “đáp ứng nhu cầu” chỉ là tạm thời. Một lập trình viên code dở nhưng giao tiếp tốt có thể được giữ lại trong ngắn hạn, nhưng nếu không cải thiện, họ sẽ bị thay thế bởi người khác toàn diện hơn. Quan điểm “không tốt ở một mặt nhưng vẫn được tin” có phần hơi lý tưởng hóa, vì công ty không phải tổ chức từ thiện – lợi nhuận và hiệu suất thường là ưu tiên hàng đầu.

Tranh luận nhiều về vấn đề con người làm gì nhỉ. Mỗi công ty 1 quản lý sẽ có góc nhìn về con người riêng, có thể họ không tốt ở 1 mặt nào đó nhưng chung quy lại vẫn đáp ứng được nhu cầu của công ty thì vẫn sẽ được đặt niềm tin thôi, không có vấn đề gì. Nếu mà thật sự yếu kém trong việc code cũng như manage thì sẽ không đến lượt mình lên tiếng vì chính các sếp sẽ nhìn ra vấn đề, yếu kém sẽ bị đào thải thôi. Còn nếu mà thấy không thích văn hoá, hoặc cảm thấy không phù hợp thì nghỉ thôi :)) lên công ty làm gì rồi suốt ngày này nọ kia. Thuận mua vừa bán. Gửi bác hay phản biện bằng GPT

Nếu PM dùng MacBook M3 trong khi dev vẫn phải chịu MacBook Intel đời cũ, điều này thực sự bất hợp lý nếu xét về hiệu suất công việc. Vấn đề ở đây là gì? 1. Dev mới là người trực tiếp build, test, debug Dev phải chạy các tác vụ nặng như build project, chạy CI/CD, container, máy ảo, trong khi PM chủ yếu dùng các ứng dụng văn phòng, quản lý task. Nếu dev dùng MacBook Intel cũ, thời gian build sẽ lâu hơn, làm việc chậm hơn → delay sản phẩm. Nếu PM dùng MacBook M3, hiệu suất công việc của họ không tăng đáng kể, vì hầu hết công cụ của họ không yêu cầu phần cứng mạnh. 2. Lãng phí tài nguyên Nếu công ty đầu tư MacBook M3 cho PM thay vì dev, thì công ty đang không tối ưu tài nguyên. MacBook M3 thực sự mạnh, nhưng có thực sự cần thiết cho PM? Nếu chỉ để mở Notion, Jira, Slack thì có khác gì MacBook Air M1 không? 3. Tư duy “chức danh cao thì xài đồ xịn” là lỗi thời Nếu cấp quản lý chọn thiết bị theo vai vế thay vì tính chất công việc, thì đang có vấn đề về tư duy quản lý. Công ty nên đầu tư thiết bị theo nhu cầu thực tế, chứ không phải theo chức danh. Giải pháp hợp lý hơn? ✅ Dev cần MacBook M3/M2 Pro vì họ chạy code nặng, build nhanh, tối ưu hiệu suất làm việc. ✅ PM có thể dùng MacBook M1/M2 vì họ không cần sức mạnh phần cứng quá lớn. ✅ Nếu PM thật sự cần Mac mạnh (ví dụ: chạy AI, thiết kế Figma nặng), thì họ có lý do chính đáng. Nhưng nếu chỉ để họp hành, gõ Notion, thì hoàn toàn không hợp lý. Kết luận Nếu công ty cấp MacBook M3 cho PM nhưng để dev chịu MacBook Intel lag lòi, thì đó là quyết định thiếu tối ưu. Công ty không chỉ làm dev mất năng suất, mà còn tự làm chậm tiến độ. Đây là vấn đề về quản lý tài nguyên, không phải ghen tị!

Dev làm tốt, bỏ công bỏ sức, vậy mà vẫn bị nói qua nói lại, chẳng được yên. Còn mấy lão đệ – chẳng rõ của ai – làm thì cũng thường thôi, chẳng có gì nổi bật, ấy vậy mà được nâng đỡ lên cao dễ như bỡn. Ai có người chống lưng thì người đó kéo, chẳng cần nhìn năng lực. Thôi, bớt mấy kiểu này đi, đừng để người ta nhìn vào rồi cười mỉa. Tôi còn biết nhiều chuyện hơn nữa. Điều chỉnh lại chút đi, hãy vừa phải thôi, để người ta còn chút tôn trọng. Nếu không, tôi nói hết ra thì lúc đó người ngoài lại có cớ mà cười đấy.

Nói thẳng luôn: bớt ra vẻ ta đây, cứ ôm mấy cái máy xịn, máy mạnh, trong khi chính dev – lực lượng gánh team, kiếm tiền chính cho công ty – lại phải cày bừa trên mấy con máy cùi bắp. Tao thấy cái logic này nó sai sai. Đã không code, không đóng góp trực tiếp vào sản phẩm, thì nhường mẹ nó cái máy xịn cho anh em dev đi, đừng có chiếm dụng rồi ngồi đó gõ Word với Excel, chat Slack, .... Team dev mà không có công cụ ngon, delay deadline hay sản phẩm lởm thì ai chịu? Chẳng phải công ty thiệt à? Nói sâu hơn tí, tao hiểu managers với PM có vai trò chính là hỗ trợ, làm sao để dev tập trung cày code, ra sản phẩm chất nhất. Nhưng cứ kiểu “ngồi trên cao” mà không thấu cái khó của anh em dưới, thì đừng hỏi sao team nó hậm hực. Vậy nên, tỉnh táo chút, nhường cái cần nhường, ưu tiên đúng người đúng việc, công ty nó mới đi lên được. Chứ cứ thế này, e là ngoài thì vui vẻ chứ trong lòng bức xúc nhiều lắm :))

Công ty đâu phải trường học đâu mà dạy dỗ, đi làm nhận lương thì lôi cái kiến thức tự học ở nhà ra xài đi, đừng trông chờ công ty phải chỉ từng li từng tí, về nhà tự lo mà học thêm nhé!