thảo luận [Thread tổng hợp] Chia sẻ về mức lương tại các công ty - Part 2

BE dev 10 năm đọc xong đi ra :cry:
Xưa giờ chỉ có code sao cho nó dễ scale, log sao cho dễ support prod... chứ cũng không có dive deep vào mớ tool kia bao giờ. Thường mấy món đó đẩy cho devops config.
Haha, mình y chang thím. Ví dụ như Jenkins thì cài đặt chắc đọc tut 30p là làm được thôi, nhưng cái ăn tiền là mớ DSL để support dự án kia kìa không rõ trong đây được bao nhiêu thím không phải là devops mà làm cái này?
 
đây là vấn đề đưa cái cá nhân vào khi interview, thím thích là 1 chuyện, còn việc tuyển là cần người fit với job, job có range , tìm người fit là đc, chứ lại tìm người theo sở thích cá nhân thì sao tuyển được ? giả sử họ deep dive vào 1 vấn đề khác, ví dụ ở trên thím hỏi về kafka, nhưng sở thích cá nhân họ deep dive vào OS chẳng hạn, thế là cũng fail với thím đúng ko ? nên là interview thì phải có process, requirement rõ ràng, chứ đừng có mang quan điểm hay cảm xúc cá nhân vào
trong cv có gì em hỏi cái đó, 90% backend sẽ dính message queue, database, ... còn thuật toán em k đánh đố mà đợt đó em cũng chả hỏi thuật toán. Nhưng dự án em k có con nào deep dive OS, cứ vững cache, msg queue, index, partition db, log, normalize, ... em cứ hỏi những cái này bác ạ, còn bác deep dive gì em k biết nhưng phải match những cái dự án em yêu cầu. Mà đợt đó em ms junior nên đánh đố tí, nhưng 90% dev em hỏi trên 1 tiếng là em cho pass rồi mặc dù nhiều câu em k ưng cho lắm
các topic trên là default đối vs em 1 ng backend phải biết, còn devops, em sẽ k yêu cầu quá cao, ví dụ biết cách dùng docker, hay cài đặt jenkins để khi merge code từ nhánh dev vô hoặc push code nó sẽ tự động deploy lại... còn nếu ứng viên biết sâu, ví dụ java đi, em sẽ hỏi về hiểu cách JVM hoạt động k, các tp C1, C2, thuật toán GC, phân biệt GC Z, GC G1, ... sự khác biệt các version java, light weight thread và reactor thôi k nói nữa lộ hết đề :v
Hỏi lý thuyết là đặc trưng của các bạn ít exp rồi. Ng ta quan tâm problem solving thôi b. 1 vấn đề hoàn toàn mới thì họ giải quyết sao mới là quan trọng.
Còn câu chuyện kafka rabbit trừ khi b đang integrate từ rabbit sang kafka. Quan điểm của m thấy nó chả có ý nghĩa gì thể hiện ứng viên tốt hay ko cả.
 
Haha, mình y chang thím. Ví dụ như Jenkins thì cài đặt chắc đọc tut 30p là làm được thôi, nhưng cái ăn tiền là mớ DSL để support dự án kia kìa không rõ trong đây được bao nhiêu thím không phải là devops mà làm cái này?
Tôi thuần dev, làm feature thì cao lắm là đến môi trường UAT thôi. Lúc code thì dĩ nhiên biết phải scaling, HA, sharding, backup... nhưng đek có công ty nào làm mấy cái env bên dưới giống hệt Prod. Như môi trường Dev với QA bên tôi cũng có messageQ nhưng chỉ xài 1 node đơn giản với default config là đủ chạy. Mấy món config cao siêu kia thì tôi chả động tới bao giờ.
 
Tôi thuần dev, làm feature thì cao lắm là đến môi trường UAT thôi. Lúc code thì dĩ nhiên biết phải scaling, HA, sharding, backup... nhưng đek có công ty nào làm mấy cái env bên dưới giống hệt Prod. Như môi trường Dev với QA bên tôi cũng có messageQ nhưng chỉ xài 1 node đơn giản với default config là đủ chạy. Mấy món config cao siêu kia thì tôi chả động tới bao giờ.
Thế thì hơi ghê, bên mình UAT và NFT là 1:1 với Prod.
 
thôi đằng nào mọi ng k biết mình là ai và mình cũng k engage 1 cái interview nào nữa, mình chia sẻ 1 bài toán mình 90% hỏi ứng viên đợt 2022 của mình

a hãy thiết kế cho em 1 con OTP đơn giản, khi ng dùng xác thực 2FA, hệ thống sẽ gửi về OTP về và chỉ valid trong 10 phút. Ngoài ra, hệ thống OTP của bên em không được phép chết khi xác thực vì nếu chết thì ng dùng k thể vào được, anh hãy tìm cách xử lý

keypoint bài toán mình : dùng redis invalid để lưu time + userid + mã otp, còn auto scaling có thể chọn k8s hoặc thiết kế con alert trên aws, vượt ngưỡng tài nguyên thì tự động bật

case 2 : hiện tại server đang chạy 5 node service Schedule, ở đây tức là cứ 6 PM hệ thống sẽ synchronize 1 số data đã thay đổi dưới DB với service Cache. Nếu em thiết kế @schedule , thì cả 5 con cùng chạy 1 lúc, a sẽ thiết kế ntn để chỉ có 1 con chạy lúc 6PM mà k phải cả 5 con.
 
BE dev 10 năm đọc xong đi ra :cry:
Xưa giờ chỉ có code sao cho nó dễ scale, log sao cho dễ support prod... chứ cũng không có dive deep vào mớ tool kia bao giờ. Thường mấy món đó đẩy cho devops config.
Ko biết cty làm về cái gì mà hỏi ghê quá, ko biết trả lương cao ko nữa mà hỏi rõ lắm :shame: kêu balance cái binary search tree ko biết có balance được ko :shame:
 
case khác , mở rộng từ case OTP này, làm thế nào để hạn chế ng dùng SPAM tin nhắn. Ví dụ : 1 người dùng không có tên tuổi trong db của mình, sử dụng mạng local công ty(tất cả nhân viên cùng 1 dàn IP) thì chặn spam như thế nào. nếu mình chặn IP đó thì người dùng "k có ý định spam" trong công ty đó cũng bị mất cơ hội.
thôi đằng nào mọi ng k biết mình là ai và mình cũng k engage 1 cái interview nào nữa, mình chia sẻ 1 bài toán mình 90% hỏi ứng viên đợt 2022 của mình

a hãy thiết kế cho em 1 con OTP đơn giản, khi ng dùng xác thực 2FA, hệ thống sẽ gửi về OTP về và chỉ valid trong 10 phút. Ngoài ra, hệ thống OTP của bên em không được phép chết khi xác thực vì nếu chết thì ng dùng k thể vào được, anh hãy tìm cách xử lý

keypoint bài toán mình : dùng redis invalid để lưu time + userid + mã otp, còn auto scaling có thể chọn k8s hoặc thiết kế con alert trên aws, vượt ngưỡng tài nguyên thì tự động bật

case 2 : hiện tại server đang chạy 5 node service Schedule, ở đây tức là cứ 6 PM hệ thống sẽ synchronize 1 số data đã thay đổi dưới DB với service Cache. Nếu em thiết kế @schedule , thì cả 5 con cùng chạy 1 lúc, a sẽ thiết kế ntn để chỉ có 1 con chạy lúc 6PM mà k phải cả 5 con.
 
thôi đằng nào mọi ng k biết mình là ai và mình cũng k engage 1 cái interview nào nữa, mình chia sẻ 1 bài toán mình 90% hỏi ứng viên đợt 2022 của mình

a hãy thiết kế cho em 1 con OTP đơn giản, khi ng dùng xác thực 2FA, hệ thống sẽ gửi về OTP về và chỉ valid trong 10 phút. Ngoài ra, hệ thống OTP của bên em không được phép chết khi xác thực vì nếu chết thì ng dùng k thể vào được, anh hãy tìm cách xử lý

keypoint bài toán mình : dùng redis invalid để lưu time + userid + mã otp, còn auto scaling có thể chọn k8s hoặc thiết kế con alert trên aws, vượt ngưỡng tài nguyên thì tự động bật

case 2 : hiện tại server đang chạy 5 node service Schedule, ở đây tức là cứ 6 PM hệ thống sẽ synchronize 1 số data đã thay đổi dưới DB với service Cache. Nếu em thiết kế @schedule , thì cả 5 con cùng chạy 1 lúc, a sẽ thiết kế ntn để chỉ có 1 con chạy lúc 6PM mà k phải cả 5 con.
Ơ case 1 đơn giản mà phải gắn thêm Redis à? Con Redis tạch thì sao

Đố bạn code đc con backend (language/framework gì cũng được) để làm bài trên mà ko cần gắn db vào đấy :D
 
case khác , mở rộng từ case OTP này, làm thế nào để hạn chế ng dùng SPAM tin nhắn. Ví dụ : 1 người dùng không có tên tuổi trong db của mình, sử dụng mạng local công ty(tất cả nhân viên cùng 1 dàn IP) thì chặn spam như thế nào. nếu mình chặn IP đó thì người dùng "k có ý định spam" trong công ty đó cũng bị mất cơ hội.
1 phút quảng cáo, nếu bác junior hay middle nào mong muốn học thêm những kiến thức em vừa take note trên, thậm chí đó chỉ là 5% trong số kiến thức em sẽ dạy mùa hè này thì chấm em nhanh nhé, em dự định mở youtube riêng để dạy nên tiện dạy các bác luôn hehe
 
Case 2 của bạn thì đề bài có vấn đề, chẳng ai chạy chung scheduler với service trên cùng 1 worker cả, phải tách con scheduler ra chạy độc lập.
 
1 phút quảng cáo, nếu bác junior hay middle nào mong muốn học thêm những kiến thức em vừa take note trên, thậm chí đó chỉ là 5% trong số kiến thức em sẽ dạy mùa hè này thì chấm em nhanh nhé, em dự định mở youtube riêng để dạy nên tiện dạy các bác luôn hehe
. như nào đây bác ạ :D
 
Case 2 của bạn thì đề bài có vấn đề, chẳng ai chạy chung scheduler với service trên cùng 1 worker cả, phải tách con scheduler ra chạy độc lập.
lý thuyết là thế bác, nhưng mà do hệ thống cũng to r sếp k muốn migrate sang thôi. Hoặc đơn giản là 1 cách vô tình nào đó 2 service cùng gọi xuống DB 1 request giống nhau, như vậy mình muốn nói tới distributed lock ạ
 
Thế thì hơi ghê, bên mình UAT và NFT là 1:1 với Prod.
Tiền UAT khách hàng trả thì không sao, chứ nếu công ty trả thì vẫn cứ "tạm chấp nhận được" thôi các thím :doubt: Giờ lên cloud chi phí đắt lắm.

Mà UAT vẫn phải đủ các component mà, chỉ là do ít người xài nên giảm mỗi component xuống tối thiểu thôi. Ví dụ như sql Prod 32GB RAM, 1 master + 2 replica đi, thì UAT gom hết lại 1 instance 8GB RAM thôi. blah blah
 
Last edited:
e 2 năm r không đi interview chém gió cũng quên nhiều r, do cũng gà các bác góp ý em thôi nhé đừng gạch em, e hỏi đánh đố tí chứ trên 1 hour em interview cho pass hết rồi ạ hichic
 
chết tui cuốn quá lâu r k chém gió, ae đợi tôi xử xong thằng ai eo này r tôi đi PV lại xem, lâu r trình chém gió lụt hết cả tay =((
 
1 phút quảng cáo, nếu bác junior hay middle nào mong muốn học thêm những kiến thức em vừa take note trên, thậm chí đó chỉ là 5% trong số kiến thức em sẽ dạy mùa hè này thì chấm em nhanh nhé, em dự định mở youtube riêng để dạy nên tiện dạy các bác luôn hehe
Anh cứ làm và share lên, vozer sẽ tự giác vào xem nếu nó chất lượng
 
  • Tên công ty: East automotive (rejected)
  • Lương tháng/năm (gross): 20 gross
  • Thời điểm (năm nào): 2023
  • Bonus: Tháng 13 14 15
  • Số năm kinh nghiệm khi nhận offer: 4 năm
  • Số năm kinh nghiệm vị trí ứng tuyển: 6 tháng


  • Tên công ty: Fsoft (rejected)
  • Lương tháng/năm (gross): 40 gross
  • Thời điểm (năm nào): 2023
  • Bonus: Tháng 13
Đang tìm job nào để wlb nhưng chưa thấy, chắc chờ năm sau thị trường ấm lên rồi nhảy vậy.
 
thôi đằng nào mọi ng k biết mình là ai và mình cũng k engage 1 cái interview nào nữa, mình chia sẻ 1 bài toán mình 90% hỏi ứng viên đợt 2022 của mình

a hãy thiết kế cho em 1 con OTP đơn giản, khi ng dùng xác thực 2FA, hệ thống sẽ gửi về OTP về và chỉ valid trong 10 phút. Ngoài ra, hệ thống OTP của bên em không được phép chết khi xác thực vì nếu chết thì ng dùng k thể vào được, anh hãy tìm cách xử lý

keypoint bài toán mình : dùng redis invalid để lưu time + userid + mã otp, còn auto scaling có thể chọn k8s hoặc thiết kế con alert trên aws, vượt ngưỡng tài nguyên thì tự động bật

case 2 : hiện tại server đang chạy 5 node service Schedule, ở đây tức là cứ 6 PM hệ thống sẽ synchronize 1 số data đã thay đổi dưới DB với service Cache. Nếu em thiết kế @schedule , thì cả 5 con cùng chạy 1 lúc, a sẽ thiết kế ntn để chỉ có 1 con chạy lúc 6PM mà k phải cả 5 con.
Theo m, b nên đi apply vài chỗ để xem họ pv như nào đi. Cách b đặt vấn đề m đã thấy đặc kiểu over fit case cho b rồi. Ko có 1 câu trả lời cố định nào cả. B hãy coi nó như 1 buổi tech talk thôi.
M đang võ đoán b khoảng 3-4 năm exp, mới control được 1 design và rất tâm đắc về nó.
 
Theo m, b nên đi apply vài chỗ để xem họ pv như nào đi. Cách b đặt vấn đề m đã thấy đặc kiểu over fit case cho b rồi. Ko có 1 câu trả lời cố định nào cả. B hãy coi nó như 1 buổi tech talk thôi.
M đang võ đoán b khoảng 3-4 năm exp, mới control được 1 design và rất tâm đắc về nó.
hồi em hỏi mấy câu trên e có 1 năm bác à, nhưng em làm startup nên phần lớn các vấn đề trong hệ thống đó em cũng sắn tay vô, những case e thấy hay ho trong quá trình làm e lấy ra hỏi các bác ý. Còn giờ lụt tay nghề r, khéo qua hè này phải đi học lại à. E cảm ơn bác nhé đợi em thi xong cái AI EO này với ôn luyện lại vài tháng r em đi PV luôn ạ, em rất thích dải CV vì đi PV nhiều khi ấy, mình đc học thêm kiến thức mới từ bên người ta cũng hay lắm ạ, hay chơi vs vài dev giỏi khác.
 
Back
Top