Tình hình là giờ có 2 cái offer: 1/ Information Security Manager: vẫn làm ở công ty hiện tại (top 1 bank US), lương không tăng nhưng thuế giảm đc chút. Mình nghĩ đây là cơ hội cho mình tiến thân vào phân khúc nhiều tiền hơn mà không đòi hỏi quá nhiều về technical. 2/ Vẫn làm IT auditor, lương thưởng tổng cộng tăng gần 30%, free ăn uống, 1 tuần lên cty 1 ngày, hoặc sau này hết hứng khỏi lên cũng đc. Cty này nhỏ (top 10 health insurance), qua cách nc với người pv thì mình nghĩ mình đóng góp nhiều cho họ đc (góp ý tech policies, build team, phát triển audit culture cho nó). Nhược điểm là mình chán audit đến tận cổ rồi ... Vậy nên nhịn nhục theo bên ISM, lương thấp mà có tiềm năng về sau, hay là qua kia để tăng lương hả các bác. Mình làm IT audit cũng 8 năm cmnr, sợ làm lâu quá sau này muốn nhảy qua job khác bị khó, vì chỉ có mỗi kn về IT audit chứ cũng chả có kn gì khác.
Theo lời bác thì bác prefer cái 1 nhưng đang phân vân về lương bổng. Nếu xác định làm tiếp thì cũng nên xem khả năng tương lai có phát triển nhiều hơn offer mới bảo nhiêu %. Có thể chịu khổ 1-2 năm nhưng sau đó thu nhập x2... Lúc đó mới đáng để ở lại. Nên bác cứ vạch ra tương lai giả định từ 3-5 năm cho cả 2 job theo các tiêu chí lương, cơ hội thăng tiến, skills,... Cái nào đi xa hơn thì chọn job đó. Thật ra làm công việc mình không thích 1 thời gian dài cũng ảnh hưởng tâm lý. Nhưng mà môi trường công việc mới thoải mái, thời gian linh động, có thể ở nhà làm thêm cái mình thích hay học thêm skill cho job khác. Nếu nghĩ thoáng thì vẫn tốt. Gặp dân IT nerd auto chọn job mới. Như bản thân hiện tại cũng làm 1 công ty gần 4 năm rồi. Lương cũng không gọi là cao so với skills, năm nay tăng lương cũng thấp, chừng 4%. Nhưng mà làm remote, thời gian thoải mái, team có nhiều người giỏi để học và trao đổi. Nên hiện tại vẫn chưa có ý định tìm job mới. Chừng nào công ty IPO, bán được stock rồi tính sau
cái 1 dễ chém gió hơn. Title rộng, tha hồ mà xiaololz nếu jump ship. Phân nhánh ra nhiều dc cái 2 chém cỡ nào thì cũng chỉ là auditor thôi. giống QA, nhiều thằng dev cùng cực nhận làm QA nhưng sau này tìm job mới bị cái title nó dí theo ko thoát dc
Lương nhân viên Bank top 4 VN lương cũng có bao nhiêu đâu. Bảo hiểm chốt vài khách hàng là đủ ăn cả năm rồi
Ta cũng nghĩ theo hướng này. Làm ISM sau unlock đc nhiều career path hơn, cviec cũng không khác audit mấy, nhưng ít document hơn. Theo audit 8 năm rồi, cũng hơi sợ sau này dính đến nó cả đời luôn thì hơi oải. Nhân viên mới thuê vào lương cao thôi, chứ bọn làm lâu 1 chỗ lương thấp hơn. Khi nào nhận đc offer ở ngoài thì mới negotiate đc. Mà ta vừa nhận đc offer team mới, chưa cống hiến gì nên chưa dám negotiate ... chỉ biết là hình như lên max đc 140k, để tầm 1 2 năm nữa tính sau vậy.
@Catnarok làm ReactJS nhỉ? Cho mình xin tí exp với recommend về ReactJS với. Kiểu đôi khi bị rerender nhiều với performance có 1 số chỗ cảm giác ko ổn lắm mà ko biết nên improve thế nào, tìm hiểu cái gì. Có social nào để add cho học hỏi thì càng tốt
Cty lớn nó nhiều khi không trả ngon như startup với tech thường đâu. Chỗ mình sr nó trả lương cứng 145k là max band, thêm bonus với stock mới lên dc 200k. Muốn hơn phải lên lead với principal dev
IT audit lương thấp hơn dev mà. Với có khoảng thời gian tầm 3 năm hơn ta kiểu bị mất phương hướng trong csống, nên performance thấp nữa
đang hơi stuck công việc. team đang có đồng chí Ấn bên Úc lead, đồng chí thich làm kiểu Ấn - cày trâu. team có ku Junior cày trâu, bảo gì cũng làm => thích. Khổ cái ku này có 1 cái combo ko đỡ được là thích làm foundation (common components, SDK, utils) nhưng làm ko tới, nên làm tới đâu bể tới đó, của nó chạy của anh em hỏng, ko ai muốn report nhưng ko nói thì ko ai ghi nhận. Tao đề nghị để tao refactor code thì bị reject vì task giờ đang nhiều. Má nói thiệt chứ càng làm càng nát chứ ko có buy time được đâu. Người ta làm SDK, làm common component người ta có cả team mà thanh niên cứ thích làm, làm đc cái gì là bỏ vào SDK ngay. Tao cuối tuần nay suy nghĩ rồi, đã thế bố cũng cày trâu, bố cày nát cái source code tự là m ngoài giờ hết, xong bố ném cho các con giời làm để mà lấy credit, chứ kiểu này chết team mà bản thân ko đc đánh giá do làm toàn việc ko tên (mỗi lần làm component là phải refucktor 1 đống + các thanh niên kia làm thiếu tao ngồi làm lại thì đứng mũi chịu sào ko ). ức chế quá lên chửi.
vãi Ko có unit với integration tests hay sao? Mỗi lần nó push cái gì bắt nó chạy hết test. Pass thì mới dc merge request. Ko có test, ko review, cho merge thoải mái thì chịu thôi nó làm hỏng nhiều thì kéo nó ra 1 :1. trước team cũng có thằng ku viết code bố láo làm hư hết code. mỗi lần nó push cái gì mình pull vào viết lại hết. xong vài lần như vậy nó biết ý làm cẩn thận hơn
team flat nên khá tự do, nhưng vì có bác bảo kê nên nó cứ làm miễn sao deliver chức năng cho bác, và trong quá trình nó dev nó thấy cái gì hay nó cho thành sdk hết T_T.... team đang ko có lead, anh lead tạm cũ có lobby cho ta lên lead trước khi ảnh đi rồi nhưng vì lý do ko phải thân cận nên khó + EM cũ cũng review ok nhưng ảnh mới nghỉ đợt cuối năm nên ta lại bơ vơ . Ta vô hơi trễ nên ko nắm business 1 số feature ( feature thay đổi = verbal ko thì cũng khó nắm, trong họp ai có mặt hay gọi ai vào meeting thì người đó biết) + lúc đang show off thì dính combo bệnh + con bệnh+ vợ bệnh suốt 2-3 tháng cuối năm perfomance giảm nên khó nói chuyện. Giờ chỉ có thể cày trâu hơn thôi. Team cũng lành ta cũng thích, duy có case kuu đó khó giải quyết thôi. Ta hiểu tính nó cũng tốt, nhiệt tình nhưng mà đang ở giai đoạn phản vệ với mọi thứ khác nó nghĩ + ko tìm hiểu các factor trước khi làm 1 cái gì đó. sếp ơi khổ ở chỗ là cái cục sdk đấy nó tự tạo ra và maintain, có cần ai review để merge đâu nên mới khổ . để ví dụ cho 1 case thế này : - Mình viết 1 cái component <FormDropdown /> sử dụng FormField của Formik. - Thanh niên có 1 request là nếu drop down có 1 option và là required : thì tự động set thành readOnly (disable). Nếu có property là noAutoReadOnly thì ignore logic trên. Mã: // Origin code: const FormDropdown = (props) => { //logic component FormDropdown return <FieldItem {...props}> <UIDropdown /> </FieldItem> } solution của thanh niên là sửa thẳng luôn là thêm cái logic đc request ở trên, modify luôn cái logic render của FormDropdown. Lý do modify mình nghĩ là trong quá trình "refuktor" xóa 1 vài dòng của người khác làm cho component ko chạy nữa, nên thay vì bỏ lại thì cố chữa ngựa đang gãy chân phải thành lành chân phải vô tình làm cụt cmn chân trái. Mã: const FormDropdown = (props) => { const readOnly = props.readOnly || !props.noAutoReadOnly && props.options.length === 1 && props.required; // xóa code cũ //thêm code mới return <FieldItem {...props}> //thêm code render vào đây để fix vì code xóa gây ra <UIDropdown /> </FieldItem> } dưới đây là 2 solution của mình // cách 1: giữ render của FormDropdown, ko thay đổi, chỉ thay đổi attr readOnly cho phù hợp với hoàn cảnh Mã: const AutoReadOnlyFormDropdown = (props) => { const readOnly = props.readOnly || !props.noAutoReadOnly && props.options.length === 1 && props.required return <FieldItem {...props} readOnly={readOnly}> <UIDropdown /> </FieldItem> } cách 2: modify formdropdown, nhưng update cái basic formdropdown ban đầu thành 1 component tên khác, và render nó như default Mã: //rename FormDropdown => BasicFormDropdown const BasicFormDropdown= (props) => { //logic component FormDropdown return <FieldItem {...props}> <UIDropdown /> </FieldItem> } // implement FormDropdown const FormDropdown = (props) => { const logicReadOnly= !props.noAutoReadOnly && props.options.length === 1 && props.required if(logicReadOnly) { return <ReadOnlyFormDropdown {...props} readOnly /> } return <BasicFormDropdown {...props} /> } cách 1 thì logic về noAutoReadOnly sẽ ko có, vì cái đó đc quyết định từ thằng render ra <FormDropdown/> chứ ko phải thằng FormDropdown có nhiệm vụ handle nó ( <FormDropdown readOnly={isReadOnly && NOTAutoReadOnly/>) cách 2 thì nhượng bộ cho phép thêm attr noAutoReadOnly vào FormDropdown ( I will go to hell for this sh!t), nhưng ko đả động gì đến render bình thường của người ta, mà chỉ thay đổi cái readOnly nếu muốn. muốn modify cũng được, nhưng phải make sure cái người ta chạy bình thường, đằng này ko check đc hết các case và mình thì banh ta lông.
