3x đi apply web có ổn không các bác

Boss Lacotes

Senior Member
mình học chuyên ngành cntt ở cao đẳng, sau đó mình đi thực tập với đi làm 2 cty , tầm 6 tháng, ở cty thứ 2 thì đã vào làm đc 1 tháng, tuy nhiên lúc đó mình vào làm thì thấy các bạn cùng cty ai cũng ĐH hết ,nên mình quyết định tạm dừng việc làm để học liên thông lên ĐH tiếp

học được 2,5 năm đùng cái dịch covid kéo dài đến tận 2022 mình mới xong,từ 2021 đến 2023 , mình có làm freelance với 1 team , công việc chủ yếu là viết tool auto hỗ trợ làm mmo , và làm các website dạng nhỏ kiểu shop bán hoa, shop quần áo, shop bán acc ....

và cũng nhận được 2 dự án trung bình ( đối với mình) , 1 cái là làm cho khách bên mỹ , làm mất 1 năm, bao gồm cả sửa chửa, thêm mới,bảo hành theo yêu cầu của khách
1 cái là làm cms cho 1 công ty , cũng mất 1 năm , cũng tương tự cái kia , cũng bảo hành, sửa chửa,thêm mới theo yêu cầu của khách
2 cái này mình làm theo task dùng php, laravel, vuejs , tổng tiền mình kiếm đc từ nó tầm (160tr)

những tưởng con đường freelance này ổn, thì đùng cái ông lead có chuyện nên giải tán
giờ mình muốn nộp đơn vào cty làm lại thì mình muốn hỏi

1. tầm 3x tuổi này người ta có nhận vào làm junior hoặc thậm chí mình chấp nhận làm cả fresher (tiền bạc mình ko quan trọng lắm)
2. mình làm qua mấy dự án kia, thú thật là đúng là làm outsource và freelance nên chất lượng code mức trung bình, cũng chỉ là crud thôi >>> nên mình cũng phân vân khi nộp cv , vì jd đòi junior mà mình ko biết đủ trình chưa
3. khi viết cv thì mình nên ghi bao nhiêu prj vào cv , chỉ cần ghi 2 prj mình thấy tâm đắc nhất (hay ghi thêm vài cái xuống dưới cho nó nhiều ?) , và có được để source code của 2 prj kia lên cv không

mong các bác tư vấn
 
Nếu ở Hà nội và đủ kiến thức về Drupal thì PM mình cv mình xem thử. Mình cần dev về Drupal viết các module dùng làm ERP quản lý công ty. Mô hình thiết kế cơ sở dữ liệu bắt buộc biết mô hình Entity Attribute Value, Lập trình backend Phải thật sự biết về hướng đối tượng nâng cao của Symfony + design pattern vì nếu kg sẽ kg hiểu lập trình module trong drupal, về phần Front thì chủ yếu là vuejs 3
 
Nếu ở Hà nội và đủ kiến thức về Drupal thì PM mình cv mình xem thử. Mình cần dev về Drupal viết các module dùng làm ERP quản lý công ty. Mô hình thiết kế cơ sở dữ liệu bắt buộc biết mô hình Entity Attribute Value, Lập trình backend Phải thật sự biết về hướng đối tượng nâng cao của Symfony + design pattern vì nếu kg sẽ kg hiểu lập trình module trong drupal, về phần Front thì chủ yếu là vuejs 3
chưa sài drupal bao giờ bác ơi , mà mình ở đà nẵng nữa
 
Thử dev với Drupal đi nó đưa bác lên tầm cao mới, tư duy lẫn kiến thức lập trình, sau đó dòm lại mấy cái web bác tự hào làm cả năm so với drupal chắc là chiện nhỏ.
 
Thử dev với Drupal đi nó đưa bác lên tầm cao mới, tư duy lẫn kiến thức lập trình, sau đó dòm lại mấy cái web bác tự hào làm cả năm so với drupal chắc là chiện nhỏ.
sẽ mất bao lâu để học cách sử dụng và dev drupal bác, cái eav thì em cũng nghe nói lâu rồi, kiểu 1 cấu trúc database thích hợp cho mọi loại hình e-com lúc xưa có đọc qua, nhưng dưới bài viết nó lại ghi là tốc độ ko đc tối ưu so với mấy cấu trúc chuyên cho từng loại web nên ko tìm hiểu thêm

thực sự mấy web em làm chỉ là hơn web cỏ 1 tý thôi bác, chứ chả có công nghệ gì hay ho trong đó,nên em mới nghĩ tầm đó như fresher hơn 1 tý thôi
 
muốn dev drupal thì đường cong học tập rất dốc gần như thẳng đứng vì quá nhiều kiến thức mới,
1708002262869.png

Hoặc là bạn đã nghe qua trong lúc học nhưng đi làm thì làm web cỏ kg bao giờ biết đến. Muốn dev drupal thì phải từng bước bác phải giỏi về php hướng đối tượng, đã thành thào một framework nào đó laravel hay symfony cũng được. Thông thạo các design pattern Dependency Injections, Factory, Singleton, Observer, Decorator,.. vì khi viết bắt buộc phải theo. ít nhất đã triển khai + bảo trì các dự án thật sự rồi thì mới hiểu tại sao dev drupal phải làm theo chuẩn drupal nó cover hết 90% trường hợp mà khi triển khai phần mềm phải đối mặt. Tư duy dữ liệu thì nếu bác còn nhìn dữ liệu theo dạng bảng thì vứt, nhìn phát biết hướng đối tượng dữ liệu là ok. Phần lập trình front thì cái nào cũng được nhưng đơn giản là jquery hay vuejs. bác tưởng tượng các site onepage thì nói chỉ đơn giản là một module trong drupal thôi, mà một app của công ty thì có n cái onepage app như vậy. Lúc làm việc thì cần kiên nhẫn tìm kiếm trong kho module của drupal trước sau đó đem về rồi kế thừa viết tiếp chứ kg viết lại từ đầu, tất nhiên phải đủ kiến thức lướt qua biết module đó làm gì... Theo thông kê thì fresher drupal sẽ bỏ ngang sau 6 tháng vì kg dám học thêm kiến thức mới. còn đám senior sử dụng thành thạo thì sẽ theo tiếp tục lâu dài vì mọi thứ có sẳn hết rồi chỉ thiếu nhân công để làm.
Mình thấy bác có gần đủ các yếu tố thành dev drupal rồi.
 
cái eav thì em cũng nghe nói lâu rồi, kiểu 1 cấu trúc database thích hợp cho mọi loại hình e-com lúc xưa có đọc qua, nhưng dưới bài viết nó lại ghi là tốc độ ko đc tối ưu so với mấy cấu trúc chuyên cho từng loại web nên ko tìm hiểu thêm
Ví dụ thiết kế dạng bảng bác học thì tất cả dữ liệu đều quăng vào một bảng mỗi dữ liệu tuơng ứng một cột. tất nhiên là nhỏ query nhanh rồi. Nhưng đời dek bao giờ là mơ khi làm việc bác sẽ gặp đủ thứ vấn đề mà nếu tư duy dạng bảng vứt, làm từ đầu còn nhanh hơn. còn EAV thì chuyện nhỏ. Mình ví dụ:
  • Công ty hiện tại nó còn chưa biết dữ liệu cuối sẽ nhu thế nào nó thay đổi liên tục thêm bớt cột thì thằng dev phải vào thay đổi, sửa cấu trúc dữ liệu, chạy vào form thêm bỏ, tìm hết trong code có cái nào liên quan đến cot do rồi thay đôi, với eav thì dek có chuyện này muôn thêm thì thêm mà xóa bỏ thì chẳng phải dụng gì đến code cả.
  • Một ngày đẹp trời công ty kiu mỗi bản ghi tao cần lưu lại version để biết thằng nào trong công ty thay đổi xóa dữ liệu có track thì mới nói chuyện được. với dev thì bác phải làm thêm công việc tạo bản mới lập trình một đống thứ để có được tính năng này. EAV bản chất nó có sẳn luôn rồi.
  • Tuơng tự một khi công ty lớn nó muốn app nó nhiều người xài đa ngôn ngữ đa vùng, thiết kế theo dạng bảng thì bác cũng phải lọ mọ làm lại nhiều khi phải làm lại mới vì thiết kế ban đầu kg tính.
  • Một số yêu cầu thường có trong công ty là phân quyền dữ liệu vì dụ hồ sơ nhân viên có cột luơng kg thể đứa nào cũng coi được chỉ co kế toán và giám đốc coi được thì nếu ngay từ đầu bác để cột luơng trong tab user thì coi như ăn cám vì việc rò rỉ dữ liệu nếu coi được bảng user thì có được hết thông tin cái này fail toàn tập. bản chất cái bảng này là một file dữ liệu lưu trong thư mục data database vậy hacker vào chôm file nay là xong. với EAV thì attribute nó tách riêng ra và phân quyền dữ liệu là nó nằm trong thiết kế rồi.

EAV thì mấy đứa vừa ra trường gần như kg làm được vì khi chưa hiểu phải làm thủ công, chứ eav chẳng ai làm thủ công toàn dung code để generate ra hết. viết query tổng hợp dữ liệu thì với mô hình EVA nó nhân n lần dữ liệu so với table cổ điển thì viết tay chỉ có khóc thôi, tổng hợp dữ liệu thì cứ leftjoin, innerJoin loạn cả lên kg tỉnh táo hay kg có tool generate ra câu query thì khỏi làm luôn chứ viết tay gì nỗi
 
Ví dụ thiết kế dạng bảng bác học thì tất cả dữ liệu đều quăng vào một bảng mỗi dữ liệu tuơng ứng một cột. tất nhiên là nhỏ query nhanh rồi. Nhưng đời dek bao giờ là mơ khi làm việc bác sẽ gặp đủ thứ vấn đề mà nếu tư duy dạng bảng vứt, làm từ đầu còn nhanh hơn. còn EAV thì chuyện nhỏ. Mình ví dụ:
  • Công ty hiện tại nó còn chưa biết dữ liệu cuối sẽ nhu thế nào nó thay đổi liên tục thêm bớt cột thì thằng dev phải vào thay đổi, sửa cấu trúc dữ liệu, chạy vào form thêm bỏ, tìm hết trong code có cái nào liên quan đến cot do rồi thay đôi, với eav thì dek có chuyện này muôn thêm thì thêm mà xóa bỏ thì chẳng phải dụng gì đến code cả.
  • Một ngày đẹp trời công ty kiu mỗi bản ghi tao cần lưu lại version để biết thằng nào trong công ty thay đổi xóa dữ liệu có track thì mới nói chuyện được. với dev thì bác phải làm thêm công việc tạo bản mới lập trình một đống thứ để có được tính năng này. EAV bản chất nó có sẳn luôn rồi.
  • Tuơng tự một khi công ty lớn nó muốn app nó nhiều người xài đa ngôn ngữ đa vùng, thiết kế theo dạng bảng thì bác cũng phải lọ mọ làm lại nhiều khi phải làm lại mới vì thiết kế ban đầu kg tính.
  • Một số yêu cầu thường có trong công ty là phân quyền dữ liệu vì dụ hồ sơ nhân viên có cột luơng kg thể đứa nào cũng coi được chỉ co kế toán và giám đốc coi được thì nếu ngay từ đầu bác để cột luơng trong tab user thì coi như ăn cám vì việc rò rỉ dữ liệu nếu coi được bảng user thì có được hết thông tin cái này fail toàn tập. bản chất cái bảng này là một file dữ liệu lưu trong thư mục data database vậy hacker vào chôm file nay là xong. với EAV thì attribute nó tách riêng ra và phân quyền dữ liệu là nó nằm trong thiết kế rồi.

EAV thì mấy đứa vừa ra trường gần như kg làm được vì khi chưa hiểu phải làm thủ công, chứ eav chẳng ai làm thủ công toàn dung code để generate ra hết. viết query tổng hợp dữ liệu thì với mô hình EVA nó nhân n lần dữ liệu so với table cổ điển thì viết tay chỉ có khóc thôi, tổng hợp dữ liệu thì cứ leftjoin, innerJoin loạn cả lên kg tỉnh táo hay kg có tool generate ra câu query thì khỏi làm luôn chứ viết tay gì nỗi
hix nãy giờ em lên mấy chỗ tuyển dụng ko thấy nó tuyển drupal nhiều bác nhỉ , hay thằng này cũng giống magento , kén dự án
 
ở việt nam rất ít người biết, chỉ có mấy thằng lớn xài như vin, ngân hàng, và mấy công ty nước ngoài nhất là châu âu thì chắc chắn xài. Còn mấy công ty outsource thì ổn định kg cần tuyển thêm. Mà tuyển thì toàn lên group fb tuyển chứ nó đâu tuyển đại trà. bác cứ lấy luơng của mấy senior larvel x2 thì ra luơng drupal nhưng họ kg tuyển người mới bắt đầu toàn tuyển người kinh nghiệm kg thôi
 
Thử dev với Drupal đi nó đưa bác lên tầm cao mới, tư duy lẫn kiến thức lập trình, sau đó dòm lại mấy cái web bác tự hào làm cả năm so với drupal chắc là chiện nhỏ.
thằng drupal vẫn còn sống à? tưởng php bây h chỉ còn là cuộc chơi của wp với laravel á . eav có vẻ hay nhưng khi triển khai thật sự quá ít bên nào dùng, thím có thể chỉ giúp 1 site nào xài eav tầm wordclass traffic vào trăm m daily cho ae học hỏi dc ko?
 
ở việt nam rất ít người biết, chỉ có mấy thằng lớn xài như vin, ngân hàng, và mấy công ty nước ngoài nhất là châu âu thì chắc chắn xài. Còn mấy công ty outsource thì ổn định kg cần tuyển thêm. Mà tuyển thì toàn lên group fb tuyển chứ nó đâu tuyển đại trà. bác cứ lấy luơng của mấy senior larvel x2 thì ra luơng drupal nhưng họ kg tuyển người mới bắt đầu toàn tuyển người kinh nghiệm kg thôi
Drupal m biết từ 2010, cùng vs joomla wp magento. Nhiều người kêu nó khó nhưng m thấy nó rất trực quan. Tiếc là sau ko đi theo nó
 
mình học chuyên ngành cntt ở cao đẳng, sau đó mình đi thực tập với đi làm 2 cty , tầm 6 tháng, ở cty thứ 2 thì đã vào làm đc 1 tháng, tuy nhiên lúc đó mình vào làm thì thấy các bạn cùng cty ai cũng ĐH hết ,nên mình quyết định tạm dừng việc làm để học liên thông lên ĐH tiếp


mong các bác tư vấn
bác có nhiều kinh nghiệm thực chiến thế thì mạnh dạn apply junior đi bác
em cũng gần 30, vừa xuất ngũ, kiến thức reset hết rồi giờ xin việc không dám phỏng vấn vì kiến thức cần ôn lại quá nhiều mà kiến thức mới cần cập nhật trong 2 năm qua cũng không ít.
Cộng thêm làn sóng sa thải mạnh mẽ bây giờ nữa
Thực sự cảm thấy bị đào thải khỏi ngành luôn ý.
Đang tính chạy ship đây, bác nào có kinh nghiệm nên làm ship cho bên nào chỉ e với
 
bác có nhiều kinh nghiệm thực chiến thế thì mạnh dạn apply junior đi bác
em cũng gần 30, vừa xuất ngũ, kiến thức reset hết rồi giờ xin việc không dám phỏng vấn vì kiến thức cần ôn lại quá nhiều mà kiến thức mới cần cập nhật trong 2 năm qua cũng không ít.
Cộng thêm làn sóng sa thải mạnh mẽ bây giờ nữa
Thực sự cảm thấy bị đào thải khỏi ngành luôn ý.
Đang tính chạy ship đây, bác nào có kinh nghiệm nên làm ship cho bên nào chỉ e với
đang tìm chỗ đây bác, 1 là nó tuyển inter, 2 là nó tuyển mid, junior tầm này chả thấy luôn khổ như chóa =((
 
Back
Top