thảo luận Hội Dev 35 đi phỏng vấn tìm việc.

Kaiser2013 · 18/11/25

Hướng tới đa phần là senior dev có kiến thức và hiệu quả làm việc tốt. Không quá sâu và rộng về tech để bứt lên SA, Tech lead. Cần phải lao ra thị trường vì đa phần vì bị tư bản cắt hợp đồng.
Mọi người ở trường hợp trên 1-2 năm nay có offer nào tốt ko? Mình có thử phỏng vấn mà thấy khó khăn quá.

ultraego · 18/11/25

giờ mấy cháu code khá lắm, đám 35t đứa nào còn job cũng bám ghế thật chặt hết rồi, trừ khi bị "short-listed" để cắt giảm chứ giờ giữ đc job là còn may ấy.

ultraego · 18/11/25

Lụm review túm tắt thị trường htai (vn):

như tao đang làm. 2022,2023 rât dễ kiếm remote , có nhiều job 5000,6000 là bình thường. h khó chết mẹ, ngày xưa bố hãy tìm việc trên angelist, tokyodev nhưng pv h khó vcl, éo có home assignment đâu , whiteboard hết rồi , nó cho 1,2 tiếng pair code với senior nó éo có Al , éo có stackoverflow , thi thoảng google hói han ) ,mà éo phải thuật toán ko đâu ,h nó bắt dựng cả 1 mini app . System thì hỏi toàn trên trời, mệt vkl . PV éo gì toàn 2,3 tuần mới xong -> rồi trượt
Đi làm cho các công ty outsource: làm outsource dễ kiếm nhưng lương thấp, trăm củ đến BU lead ở fsoft chưa chắc đc . Nhưng ko phải ko có, làm outsource các vị trí PM/PO/Brse thường cao nhất là biết tiếng nhật (N1 trở lên) , hàn nhưng nói thật làm vị trí này tù ng có thể trăm triệu nhưng ngoài kỹ năng chém gió - thông dịch ra, kỹ năng IT éo có mấy. Tao từng làm chung 1 ông pm /Brse (U50) đến git éo biết dùng hỏi loạn xạ cả lên.
Đi làm product cho water house (Vnpay , ...) hay ngân hàng : Đc. Nhưng bên này quy tắc nó rõ ràng , 1 .Mày có quan hệ , 2. Mày phải trội , giỏi hơn thị trường

dthien0511 · 19/11/25

Em 34t tính ko bác?

Pv 4 cty, em từ chối tiếp tục 1 cty, dc 3 offers. 2 cái range 65-75M, 1 cái range 95M.

Tất cả đều là senior level, cty product.

tayanhbangsat · 19/11/25

thớt hỏi xong đọc cmt chắc trầm cảm mất cả tháng

Tiền Trong Dân Còn Nhiều · 19/11/25

hóng các bác SA chia sẻ kinh nghiệm về phỏng vấn system desgin,micro service ,problem solving này nọ ạ

eminter_25391 · 19/11/25

luvziro đã nói:
Em 33 tính không bác
Em không làm manager, phỏng vấn 5 công ty đc 3 offers. Công ty cũ 65*15, offer mới 70*14, 80*13 và 105*13
Thấy cũng không khó lắm

Bác làm mảng nào thế, có thể chia sẻ kinh nghiệm tips trick phỏng vấn không ạ

TryHard · 19/11/25

cũng tính đi phỏng vấn mà ở HN ít job quá

ultraego · 20/11/25

Thanh Niên Ưu Tú đã nói:
Nghe nản nhỉ

middle nè

JyRAICK · 20/11/25

Bác thử học tiếng nhật, anh xem. Ta nói hr nó come across ầm ầm luôn á tầm 35

zollback2 · 20/11/25

luvziro đã nói:
Em 33 tính không bác
Em không làm manager, phỏng vấn 5 công ty đc 3 offers. Công ty cũ 65*15, offer mới 70*14, 80*13 và 105*13
Thấy cũng không khó lắm

công nhận, ae trong này thấy khó khăn vậy nhỉ. tôi 36 cũng đang chuẩn bị nhảy job 250 * 14

ultraego · 20/11/25

zollback2 đã nói:
công nhận, ae trong này thấy khó khăn vậy nhỉ. tôi 36 cũng đang chuẩn bị nhảy job 250 * 14

tặng bạn 1 câu, cứ coi như tôi nói đùa đi, Không Hình Chò Nó Tin

martin999 · 20/11/25

ultraego đã nói:
middle nè
Xem tệp đính kèm 3344664

Htrc cũng tình cờ thấy post này. Gớm trên thị trường được mấy hệ thống có triệu users, khéo cái thằng pvan cũng chưa từng làm hệ thống triệu users bao giờ :look_down:

TryHard · 20/11/25

ultraego đã nói:
middle nè
Xem tệp đính kèm 3344664

khác đéo gì ddos server nhỉ, không biết rút dây điện có được không

dthien0511 · 20/11/25

ultraego đã nói:
middle nè
Xem tệp đính kèm 3344664

Mình nghi là bạn này nghe lõm bõm ko xác định lại số với người pv, lại càng ko thấy thông tin về assumption này nọ.

1M total users với 1M total users cùng lúc nó khác nhau lắm. Thêm cả, cùng lúc ko bao giờ nghỉ hoặc cùng lúc trong 1 khoảng thời gian ngắn nó lại càng khác.

Hôm nọ mình có design 1 bài take-home test cho ny tập đi interview, 32M người dùng tổng cộng, thì tính toán sơ peak time tầm dc 130K concurrent requests liên tục trong 1 tiếng => 35 request per second. Con số này quá là bé cho 1 cái service cụ thể và cực kì dễ làm.

Kể cả 1M concurrent request trong 1 tiếng cũng chỉ có 277 RPS, cứ tính toán cẩn thận lại ra được lượng instances cần scale thôi (tầm 6 cho light workload service, 10-12 cho heavy workload service, etc.)

Cái sai của kì pv kia là hỏi quá dàn trải (backend-devops-frontend), gặp mình cũng ko trả lời dc. Mà cũng có khi bạn pv yếu quá rồi lại drama hoá cái kì pv lên, để ra vẻ nó quá thiếu hợp lí, và bạn trẻ kia pv rớt vì pv quá rộng, chứ k phải bản thân bạn kia kém.

Chứ xoáy vào 1M concurrent users em lại thấy quá bình thường.

NewestOfVoZ · 20/11/25

Cảm lạnh quá.
Mấy bác kêu bình thường thì có đánh giá gì không? độ khó/dễ PV so với trước đây, range lương thay đổi nhiều k... Còn k thì chắc do out trình thật.

seichan502 · 20/11/25

dthien0511 đã nói:
Mình nghi là bạn này nghe lõm bõm ko xác định lại số với người pv, lại càng ko thấy thông tin về assumption này nọ.

1M total users với 1M total users cùng lúc nó khác nhau lắm. Thêm cả, cùng lúc ko bao giờ nghỉ hoặc cùng lúc trong 1 khoảng thời gian ngắn nó lại càng khác.

Hôm nọ mình có design 1 bài take-home test cho ny tập đi interview, 32M người dùng tổng cộng, thì tính toán sơ peak time tầm dc 130K concurrent requests liên tục trong 1 tiếng => 35 request per second. Con số này quá là bé cho 1 cái service cụ thể và cực kì dễ làm.

Kể cả 1M concurrent request trong 1 tiếng cũng chỉ có 277 RPS, cứ tính toán cẩn thận lại ra được lượng instances cần scale thôi (tầm 6 cho light workload service, 10-12 cho heavy workload service, etc.)

Cái sai của kì pv kia là hỏi quá dàn trải (backend-devops-frontend), gặp mình cũng ko trả lời dc. Mà cũng có khi bạn pv yếu quá rồi lại drama hoá cái kì pv lên, để ra vẻ nó quá thiếu hợp lí, và bạn trẻ kia pv rớt vì pv quá rộng, chứ k phải bản thân bạn kia kém.

Chứ xoáy vào 1M concurrent users em lại thấy quá bình thường.

Từ đâu để estimate số instance cần sale ra bác nhỉ (back-of envelop calc rồi giả định 1 request tốn bao nhiêu ram, cpu và 1 instance cấu hình ra sao để tính toán hay như thế nào). Bác có nguồn nào để học sys design này không, e có xem hellointerview mà thấy nó hơi tổng quát quá, bị hỏi cụ thể ra số như này chắc không trả lời được.

vodka_hanoi1 · 20/11/25

dthien0511 đã nói:
Mình nghi là bạn này nghe lõm bõm ko xác định lại số với người pv, lại càng ko thấy thông tin về assumption này nọ.

1M total users với 1M total users cùng lúc nó khác nhau lắm. Thêm cả, cùng lúc ko bao giờ nghỉ hoặc cùng lúc trong 1 khoảng thời gian ngắn nó lại càng khác.

Hôm nọ mình có design 1 bài take-home test cho ny tập đi interview, 32M người dùng tổng cộng, thì tính toán sơ peak time tầm dc 130K concurrent requests liên tục trong 1 tiếng => 35 request per second. Con số này quá là bé cho 1 cái service cụ thể và cực kì dễ làm.

Kể cả 1M concurrent request trong 1 tiếng cũng chỉ có 277 RPS, cứ tính toán cẩn thận lại ra được lượng instances cần scale thôi (tầm 6 cho light workload service, 10-12 cho heavy workload service, etc.)

Cái sai của kì pv kia là hỏi quá dàn trải (backend-devops-frontend), gặp mình cũng ko trả lời dc. Mà cũng có khi bạn pv yếu quá rồi lại drama hoá cái kì pv lên, để ra vẻ nó quá thiếu hợp lí, và bạn trẻ kia pv rớt vì pv quá rộng, chứ k phải bản thân bạn kia kém.

Chứ xoáy vào 1M concurrent users em lại thấy quá bình thường.

Mình không biết nhưng tưởng tượng như thực tế thôi, 1m user cùng lúc thì cứ chia ra cho chúng nó xếp hàng, xử lý từng thằng 1 như kiểu vào quán Phúc Long xếp hàng order nước ấy, , sau khi đặt hàng xong sẽ được phát cái máy chip thì ngồi vào ghế chờ khi nào máy chip nó báo ting ting thì lấy nước ra ngôi thưởng thức. (Trong lúc mấy thằng khách đã được order rồi thì sẽ tiếp theo có người khác order), nếu muốn tăng độ xử lý làm nước hoặc xử lý order thì cứ tạo thêm khu order/làm nước, và tăng thêm số nhân viên order/làm nước.
-> Với case này với 1m người dùng upload mỗi người 1 file -> 1m file upload thì mình sẽ suy ra như sau
Về FE 1m user truy cập thì sẽ dùng CDN cache static lại nên sẽ không bị get content từ ORIGIN nên FE sẽ chịu được tải để load trang không sập -> người dùng upload file vào sẽ đẩy vào BE nhưng chỉ đẩy API thông tin file -> đẩy file vào queue -> worker móc ra xử lý file -> upload lên abc gì đó như s3, minio và lưu thông tin vào db. Nhưng trước khi xử lý upload thì phải nén file lại để giảm tải size, sau đó up lên từ từ. Còn lại có thể áp dụng kỹ thuật chia nhỏ upload ra làm nhiều phần (nhưng cái này phía kỹ thuật backend)
Về phần infra dùng k8s có autoscaling nên các pod request vào sẽ được load balancing dàn trải ra nên sẽ giảm tải được bottleneck đầu API.

buitruong1689 · 20/11/25

ultraego đã nói:
middle nè
Xem tệp đính kèm 3344664

Tôi code backend bằng C++ (Drogon) mặc định nó xử lý 140k~500k requests/second trên con server tầm $250/month. Éo cần phải algorithm, patterns, solid blah blah gì sất :beauty:

Mấy fen senior backend phán xem liệu có pass được mấy câu hỏi về performance như trên không :sweet_kiss:

ENG 14 Benchmarks (https://github.com/drogonframework/drogon/wiki/ENG-14-Benchmarks)

tuandht97 · 20/11/25

ultraego đã nói:
middle nè
Xem tệp đính kèm 3344664

e BE đi pv cũng toàn bị hỏi case 1M này mà trả lời trong tầm hiểu biết của mình nên cũng không biết đúng hay sai

thảo luận Hội Dev 35 đi phỏng vấn tìm việc.

Senior Member

Senior Member

Senior Member

Member

Member

Senior Member

Member

Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Member

Senior Member

Member

Đã tốn tiền

Member

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này