chiyeuemthoi
Senior Member
fen nêu mấy cái nổi bật thôi, overview key feature gộp làm 1 , vt ngắn gọn lại, chỉ yếu show ra cái mình làm thôiCái này là em đã rút bớt rồi đấy bác ạ
như cái này ghi 1 dòng app về gì là được
Xin review CV Fresher Developer
- Người tạo chủ đề truong.dev
- Ngày bắt đầu
như cái này ghi 1 dòng app về gì là được
iwanttobecomeajavadev
Senior Member
Ok Bác
taititans
Senior Member
iwanttobecomeajavadev
Senior Member
Đang tính giữa năm đi học lấy cái bằng ĐH đây bác. Có nên bỏ tên trường ra luôn ko? Dù gì cũng làm đc 1 năm
chiyeuemthoi
Senior Member
ko nên bác ít ra cũg phải có education bác hc văn bằg 2 đi ổn đấyĐang tính giữa năm đi học lấy cái bằng ĐH đây bác. Có nên bỏ tên trường ra luôn ko? Dù gì cũng làm đc 1 năm
iwanttobecomeajavadev
Senior Member
Tui hog có VB1 nên giờ phải học VB1 nè. 3 - 3.5 năm nếu thuận lợi. Nhưng giờ phải kiếm được job trước mới có xiền đi học bác ah
tích lũy 1 năm bay hơn 1 nửa rùi 
ankeongonthe
Senior Member
kh phải ý gì cơ mà bác không có vb1 mà vẫn đi làm đc áTui hog có VB1 nên giờ phải học VB1 nè. 3 - 3.5 năm nếu thuận lợi. Nhưng giờ phải kiếm được job trước mới có xiền đi học bác ah
v chắc dựa vào skills là chủ yếu nhỉ
chiyeuemthoi
Senior Member
sao đâu thím kia có bằg aptech kìa vs cả trc IT cũg k qtrg bằgkh phải ý gì cơ mà bác không có vb1 mà vẫn đi làm đc á
iwanttobecomeajavadev
Senior Member
May mắn mới có job thôi bác. Giờ layoff rùi. 2 tháng nay rải gãy tay vẫn chưa thấy gìkh phải ý gì cơ mà bác không có vb1 mà vẫn đi làm đc á
iwanttobecomeajavadev
Senior Member
Cty trước của tui ko quan trọng bằng interview ok là lụm. Mà giờ năm nay hơi khó ít việc cần người duy trì thôi nên tinh gọn bớtkh phải ý gì cơ mà bác không có vb1 mà vẫn đi làm đc á
talavuavoz113
Senior Member
Dạo này hiếm việc lắm bác ạCty trước của tui ko quan trọng bằng interview ok là lụm. Mà giờ năm nay hơi khó ít việc cần người duy trì thôi nên tinh gọn bớt
chiyeuemthoi
Senior Member
h fen nhảy vc thì khoai tg fen còn đag làm toi chính quy cũg móm
iwanttobecomeajavadev
Senior Member
Thật ra thì tui cũng có đọc CV của mấy bác. Cũg coi mấy project
- Chỉ là ý kiến cá nhân thui nha:
+ Về tech stack các bác ăn đứt tui lun. Đợt đi làm tui chỉ đụg framework + redis + kafka thôi. May mắn là được làm mấy cái tích hợp với bên thứ 3 cũng biết thực tế làm việc với bên thứ 3 nó như nào.
+ Tui thì hog bít trên CTY mấy bác làm như thế nào. Nhưng mà tui nhìn project cá nhân thì.
Hmm
Chỉ là cảm nhận của tui thôi nha
Tui thấy code khá là khó để debug và maintain ấy. Tui thấy mấy bác try catch nguyên cái service và đoạn controller lúc response khá dài. Và vấn đề chung là code lặp đi lặp lại khá nhìu, code vẫn chạy được nhưng 1 khi cần fix bug và maintain thì dễ bị mất kiểm soát code vì lỡ sai là phải sửa n chỗ, dự án càng phình thì càng dễ mất kiểm soát. Có 1 kỹ thuật để giải quyết vấn đề này nó là AOP (Bác nào bít rồi thì thôi nhá) chỉ try/catch 1 lần và mãi mãi, nếu ko có trường hợp đặc biệt nào khác xảy ra. Đoạn response ở controller các bác nên làm 1 con service phục vụ cho việc response để giảm thiểu lặp code với lại tui thấy có vài chỗ hardcode khá nhìu. Đợt còn đi làm tui đập code xây lại mấy lần vì mấy cái này nên share cho các bác (bác nào biết rồi thì thôi).
- Chỉ là ý kiến cá nhân thui nha:
+ Về tech stack các bác ăn đứt tui lun. Đợt đi làm tui chỉ đụg framework + redis + kafka thôi. May mắn là được làm mấy cái tích hợp với bên thứ 3 cũng biết thực tế làm việc với bên thứ 3 nó như nào.
+ Tui thì hog bít trên CTY mấy bác làm như thế nào. Nhưng mà tui nhìn project cá nhân thì.
Hmm
Chỉ là cảm nhận của tui thôi nha
Tui thấy code khá là khó để debug và maintain ấy. Tui thấy mấy bác try catch nguyên cái service và đoạn controller lúc response khá dài. Và vấn đề chung là code lặp đi lặp lại khá nhìu, code vẫn chạy được nhưng 1 khi cần fix bug và maintain thì dễ bị mất kiểm soát code vì lỡ sai là phải sửa n chỗ, dự án càng phình thì càng dễ mất kiểm soát. Có 1 kỹ thuật để giải quyết vấn đề này nó là AOP (Bác nào bít rồi thì thôi nhá
) chỉ try/catch 1 lần và mãi mãi, nếu ko có trường hợp đặc biệt nào khác xảy ra. Đoạn response ở controller các bác nên làm 1 con service phục vụ cho việc response để giảm thiểu lặp code với lại tui thấy có vài chỗ hardcode khá nhìu. Đợt còn đi làm tui đập code xây lại mấy lần vì mấy cái này nên share cho các bác (bác nào biết rồi thì thôi).iwanttobecomeajavadev
Senior Member
Tui có nhảy đâu mà đợt này hết features để làm chỉ cần duy trì nên CTY tinh gọn. Trong danh sách tinh gọn có tui thui
. Sếp tui thì bảo ko cần đi học VB1 nên đi làm nhiều hơn, mà tui thì nghĩ vẫn nên có cái VB1 mới an yên được
chiyeuemthoi
Senior Member
fen có git repo ko xin source pet prj fen tham khảo vớiThật ra thì tui cũng có đọc CV của mấy bác. Cũg coi mấy project
- Chỉ là ý kiến cá nhân thui nha:
+ Về tech stack các bác ăn đứt tui lun. Đợt đi làm tui chỉ đụg framework + redis + kafka thôi. May mắn là được làm mấy cái tích hợp với bên thứ 3 cũng biết thực tế làm việc với bên thứ 3 nó như nào.
+ Tui thì hog bít trên CTY mấy bác làm như thế nào. Nhưng mà tui nhìn project cá nhân thì.
Hmm
Chỉ là cảm nhận của tui thôi nha
Tui thấy code khá là khó để debug và maintain ấy. Tui thấy mấy bác try catch nguyên cái service và đoạn controller lúc response khá dài. Và vấn đề chung là code lặp đi lặp lại khá nhìu, code vẫn chạy được nhưng 1 khi cần fix bug và maintain thì dễ bị mất kiểm soát code vì lỡ sai là phải sửa n chỗ, dự án càng phình thì càng dễ mất kiểm soát. Có 1 kỹ thuật để giải quyết vấn đề này nó là AOP (Bác nào bít rồi thì thôi nhá
iwanttobecomeajavadev
Senior Member
Tui có làm prj trên CTY thôi, chứ ko làm dự án cá nhân á. Prj hồi đi học thì bỏ đi chưa trôn là hay rồi
truong.dev
Senior Member
phần work experience của fen sao tui thấy giống phần personal project hơn á
iwanttobecomeajavadev
Senior Member
Cũng giống thiệt đang si nghĩ sửa sao
iwanttobecomeajavadev
Senior Member
Tui chỉ muốn tô lên xem mình đã đi làm qua những dự án gì thôi, chứ hog có ghi chung chung
truong.dev
Senior Member
Cám ơn chia sẽ của bro nha. Tui hay quản lí lỗi bằng global exception để hạn chế try-catch với cũng cố gom các đoạn code bị trùng chung lại á. Nhờ bro chia sẽ nên tui mới biết thêm về con service cho response. Có gì nhờ bro chia sẽ thêm để cùng học hỏi ạThật ra thì tui cũng có đọc CV của mấy bác. Cũg coi mấy project
- Chỉ là ý kiến cá nhân thui nha:
+ Về tech stack các bác ăn đứt tui lun. Đợt đi làm tui chỉ đụg framework + redis + kafka thôi. May mắn là được làm mấy cái tích hợp với bên thứ 3 cũng biết thực tế làm việc với bên thứ 3 nó như nào.
+ Tui thì hog bít trên CTY mấy bác làm như thế nào. Nhưng mà tui nhìn project cá nhân thì.
Hmm
Chỉ là cảm nhận của tui thôi nha
Tui thấy code khá là khó để debug và maintain ấy. Tui thấy mấy bác try catch nguyên cái service và đoạn controller lúc response khá dài. Và vấn đề chung là code lặp đi lặp lại khá nhìu, code vẫn chạy được nhưng 1 khi cần fix bug và maintain thì dễ bị mất kiểm soát code vì lỡ sai là phải sửa n chỗ, dự án càng phình thì càng dễ mất kiểm soát. Có 1 kỹ thuật để giải quyết vấn đề này nó là AOP (Bác nào bít rồi thì thôi nhá
