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

luvziro đã nói:

Vibe code và lương cao nó mâu thuẫn gì vậy? Hay ý là lương cao thì phải code chay không cần AI?

Nhấp để mở rộng...

pes2020 đã nói:

Vibe coding làm cái giao diện app ghẻ cũng khoe xong xóa
Có người nói đừng tin lương của dev vâu zơ không sai mà
Tôi còn chưa được 30tr 1 tháng dăm ba cái app tôi còn chả thèm vibe coding mà chỉ cần google cũng làm được như anh

Nhấp để mở rộng...

ultraego đã nói:

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

Nhấp để mở rộng...

pes2020 đã nói:

Anh này chém gió kinh, ở ngoài F17 thì khoe Vibe Coding xong xóa post

Nhấp để mở rộng...

luiz đã nói:

Chém gió mới được lương cao, t thấy nhiều ông làm kỹ thuật tuy giỏi nhưng k chém gió show off được nên lương đuối lắm, mấy người làm tạm tạm nhưng chém mạnh thì lương hay cao hơn

Nhấp để mở rộng...

• Làm sao các sàn có thể xử lý cùng lúc hàng triệu giao dịch mà vẫn ổn định?
• Mỗi giao dịch có Stop Loss và Take Profit, hệ thống quản lý và theo dõi các lệnh này như thế nào để không bỏ sót?
• Mỗi sàn nhiều đồng coin và giá thay đổi liên tục, họ cập nhật dữ liệu và tính toán lệnh realtime ra sao?
• Khi lệnh bị cháy (hit SL/TP), hệ thống kiểm tra và thực hiện ngay lập tức như thế nào?
• Kiến trúc backend, cơ sở dữ liệu, load balancer của họ ra sao để đảm bảo HA và chịu tải cao?

DeutschlandGreatAgain đã nói:

Round 2 Remitano, tech assessment fail.
Tiếp tục cày kiếm remote khác

Nhấp để mở rộng...

tenoroboebaroque đã nói:

Stack gì và hỏi những gì thế thím.

Nhấp để mở rộng...

DeutschlandGreatAgain đã nói:

mình làm bên data, xài cái j cũng được, miễn là ra báo cáo ok, kiểu như xử lí data, chắc sai phần insight, tại nó bên domain crypto
Em cũng domain crypto mà dạo này downtrend đuối vl.

Nhấp để mở rộng...

haidaqn đã nói:

Tiện trong post đang có nhiều anh có kinh nghiệm phong phú và level cao, em muốn hỏi vài vấn đề liên quan đến công nghệ của các sàn như Binance, MEXC,... và cách họ xử lý:

• Làm sao các sàn có thể xử lý cùng lúc hàng triệu giao dịch mà vẫn ổn định?
• Mỗi giao dịch có Stop Loss và Take Profit, hệ thống quản lý và theo dõi các lệnh này như thế nào để không bỏ sót?
• Mỗi sàn nhiều đồng coin và giá thay đổi liên tục, họ cập nhật dữ liệu và tính toán lệnh realtime ra sao?
• Khi lệnh bị cháy (hit SL/TP), hệ thống kiểm tra và thực hiện ngay lập tức như thế nào?
• Kiến trúc backend, cơ sở dữ liệu, load balancer của họ ra sao để đảm bảo HA và chịu tải cao?

Em cảm ơn mọi người nếu ai có thể chia sẻ một chút kiến thức hoặc insight ạ. Em cũng đã search và tra GPT qua, nhưng vẫn muốn nghe từ những người có kinh nghiệm thực tế để hiểu rõ hơn.

Nhấp để mở rộng...

Binance

Open source, from Binance with <3. Binance has 48 repositories available. Follow their code on GitHub.

github.com

GitHub - nautechsystems/nautilus_trader: Production-grade Rust-native trading engine with deterministic event-driven architecture

Production-grade Rust-native trading engine with deterministic event-driven architecture - nautechsystems/nautilus_trader

github.com

GitHub - QuantConnect/Lean: Lean Algorithmic Trading Engine by QuantConnect (Python, C#)

Lean Algorithmic Trading Engine by QuantConnect (Python, C#) - QuantConnect/Lean

github.com

buitruong1689 đã nói:

Mấy cái fen đang hỏi thì ở đây chắc không có ai trả lời được chính xác đâu, vì hầu như ít người nào làm về mảng này. Nó liên quan đến mảng High Frequent Trading (HFT) systems, low-latency programming (chi tiết thì search google)

Mấy sàn khác mình ko rõ chứ như Binance thì có vẻ sử dụng rất nhiều công nghệ khác nhau cộng với insfra đồ sộ để có thể đạt được tốc độ xử lý như vậy. Vào Github của Bininace thì thấy có rất nhiều ngôn ngữ được sử dụng:

Binance

Open source, from Binance with <3. Binance has 48 repositories available. Follow their code on GitHub.

github.com

Nếu fen muốn hiểu chi tiết về cách người ta implement/handle các lệnh trading real-time thì cách tốt nhất là đọc source code của một open-source trading system. Ví dụ

NautilusTrader

GitHub - nautechsystems/nautilus_trader: Production-grade Rust-native trading engine with deterministic event-driven architecture

Production-grade Rust-native trading engine with deterministic event-driven architecture - nautechsystems/nautilus_trader

github.com

Lean

GitHub - QuantConnect/Lean: Lean Algorithmic Trading Engine by QuantConnect (Python, C#)

Lean Algorithmic Trading Engine by QuantConnect (Python, C#) - QuantConnect/Lean

github.com

Nhấp để mở rộng...

DeutschlandGreatAgain đã nói:

công nhận nó viết gọn vl, tiếng anh cho phần chú thích thôi đọc cũng khó hiểu , nói chi code , fen trên kia bỏ đi mà làm người

Nhấp để mở rộng...

buitruong1689 đã nói:

Mảng này salary chắc top ngành IT. Trước tôi cũng định tìm hiểu mà thấy chúng nó default chỉ tuyển Master (trường top) trở lên trong khi mình thất học nên thôi

Nhấp để mở rộng...

buitruong1689 đã nói:

Mấy cái fen đang hỏi thì ở đây chắc không có ai trả lời được chính xác đâu, vì hầu như ít người nào làm về mảng này. Nó liên quan đến mảng High Frequent Trading (HFT) systems, low-latency programming (chi tiết thì search google)

Mấy sàn khác mình ko rõ chứ như Binance thì có vẻ sử dụng rất nhiều công nghệ khác nhau cộng với insfra đồ sộ để có thể đạt được tốc độ xử lý như vậy. Vào Github của Bininace thì thấy có rất nhiều ngôn ngữ được sử dụng:

Binance

Open source, from Binance with <3. Binance has 48 repositories available. Follow their code on GitHub.

github.com

Nếu fen muốn tìm hiểu chi tiết về cách người ta implement/handle các lệnh trading real-time thì cách tốt nhất là đọc source code của một open-source trading system. Ví dụ

NautilusTrader

GitHub - nautechsystems/nautilus_trader: Production-grade Rust-native trading engine with deterministic event-driven architecture

Production-grade Rust-native trading engine with deterministic event-driven architecture - nautechsystems/nautilus_trader

github.com

Lean

GitHub - QuantConnect/Lean: Lean Algorithmic Trading Engine by QuantConnect (Python, C#)

Lean Algorithmic Trading Engine by QuantConnect (Python, C#) - QuantConnect/Lean

github.com

Bonus video on High Performance Trading System in C++

Nhấp để mở rộng...

haidaqn đã nói:

Tiện trong post đang có nhiều anh có kinh nghiệm phong phú và level cao, em muốn hỏi vài vấn đề liên quan đến công nghệ của các sàn như Binance, MEXC,... và cách họ xử lý:

• Làm sao các sàn có thể xử lý cùng lúc hàng triệu giao dịch mà vẫn ổn định?
• Mỗi giao dịch có Stop Loss và Take Profit, hệ thống quản lý và theo dõi các lệnh này như thế nào để không bỏ sót?
• Mỗi sàn nhiều đồng coin và giá thay đổi liên tục, họ cập nhật dữ liệu và tính toán lệnh realtime ra sao?
• Khi lệnh bị cháy (hit SL/TP), hệ thống kiểm tra và thực hiện ngay lập tức như thế nào?
• Kiến trúc backend, cơ sở dữ liệu, load balancer của họ ra sao để đảm bảo HA và chịu tải cao?

Em cảm ơn mọi người nếu ai có thể chia sẻ một chút kiến thức hoặc insight ạ. Em cũng đã search và tra GPT qua, nhưng vẫn muốn nghe từ những người có kinh nghiệm thực tế để hiểu rõ hơn.

Nhấp để mở rộng...

• Stateful tức là dữ liệu phải được lưu lại (database)
• Stateless tức là đơn giản nhận lệnh xong xử lý trả về (API server), không cần lưu đi đâu

• Read là nhấc dữ liệu ra
• Write là ghi dữ liệu vào

• Buffer: để cho việc write diễn ra từ từ, tránh dẫn đến quá tải. Cái này mình nghĩ không cần giải thích thêm
• Partition/Sharding: bản chất là tách dữ liệu và lệnh trong phần stateful để đảm bảo 2 lệnh write có thể diễn ra cùng lúc. Ví dụ có 2 lệnh: tài khoản A +100, tài khoản B +200. Do 2 lệnh của 2 tài khoản không liên quan nên có thể diễn ra cùng lúc, nên hoàn toàn có thể tách ra 2 "cục" dữ liệu, 1 cục giữ tài khoản A và cục còn lại giữ tài khoản B. Lấy một ví dụ khác là 2 lệnh: tài khoản A +100, tài khoản A -200. Do lệnh sau phụ thuộc lệnh trước, nên bắt buộc phải cho cả hai chạy tuần tự

DeutschlandGreatAgain đã nói:

công nhận nó viết gọn vl, tiếng anh cho phần chú thích thôi đọc cũng khó hiểu , nói chi code , fen trên kia bỏ đi mà làm người

Nhấp để mở rộng...

vodka_hanoi1 đã nói:

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.

Nhấp để mở rộng...

đẩy file vào queue

Nhấp để mở rộng...

odkjabqpmzvmz đã nói:

Mình chưa được làm hệ thống to lắm, mà đọc cũng nhiều với thỉnh thoảng phỏng vấn/tự làm mấy cái system design vớ vẩn nên nghĩ trả lời như này:

1. Xử lý hàng triệu giao dịch

Bạn hình dung hệ thống phần mềm nhìn chung có 2 phần: stateful với stateless.

• Stateful tức là dữ liệu phải được lưu lại (database)
• Stateless tức là đơn giản nhận lệnh xong xử lý trả về (API server), không cần lưu đi đâu

Việc tăng độ chịu tải với các thành phần stateless khá... đơn giản: cứ việc làm horizontal scale/duplicate các phần stateless lên. Dễ thấy nhất là nếu API server bị load cao thì duplicate ra nhiều API server, xong đặt 1 cái load balancer đằng trước.

Tuy nhiên, vấn đề chủ yếu ở các phần stateful: do phải đảm bảo dữ liệu sẽ được lưu xuống, hoặc dữ liệu sau phụ thuộc trạng thái hiện tại (ví dụ như chỉ cho phép chuyển tiền nếu như hiện tại có đủ tiền), nên việc scale sẽ khó hơn. Lúc này tạm thời xét trong hệ thống phần mềm có 2 loại "lệnh": read và write.

• Read là nhấc dữ liệu ra
• Write là ghi dữ liệu vào

Muốn scale được việc read thì dùng cache. Ví dụ đơn giản thì mình có thể nói đến việc nấu bếp: gọi món là việc read, ông đầu bếp trả món là phần stateful. Nếu như mỗi lần gọi món đều bắt ông đầu bếp nấu thức ăn thì nhọc cho ổng nếu có nhiều món => có thể bảo một tay phụ bếp "bắt chước" nấu sẵn, và phục vụ ra. Tay phụ bếp là cache. Cốt lõi sẽ nằm ở việc có một người "phụ" giúp ông đầu bếp/thành phần stateful tiết kiệm thời gian nấu/tính toán.

Muốn scale được việc write thì có 2 cách:

• Buffer: để cho việc write diễn ra từ từ, tránh dẫn đến quá tải. Cái này mình nghĩ không cần giải thích thêm
• Partition/Sharding: bản chất là tách dữ liệu và lệnh trong phần stateful để đảm bảo 2 lệnh write có thể diễn ra cùng lúc. Ví dụ có 2 lệnh: tài khoản A +100, tài khoản B +200. Do 2 lệnh của 2 tài khoản không liên quan nên có thể diễn ra cùng lúc, nên hoàn toàn có thể tách ra 2 "cục" dữ liệu, 1 cục giữ tài khoản A và cục còn lại giữ tài khoản B. Lấy một ví dụ khác là 2 lệnh: tài khoản A +100, tài khoản A -200. Do lệnh sau phụ thuộc lệnh trước, nên bắt buộc phải cho cả hai chạy tuần tự

Một cái nữa mình thấy có thể giúp write, cũng là good practice trong thiết kế dữ liệu: bạn nên xác định xem có dữ liệu nào là immutable/append-only, sau đó đảm bảo cho các thành phần/dữ liệu khác chỉ việc dựa vào dữ liệu immutable/append-only để tính toán ra. Ví dụ như ngân hàng sẽ lưu các giao dịch tiền vào/ra thì là immutable/append-only, sau đó tính số dư thì chỉ việc dùng các giao dịch đó. Cái này giúp cho scalability ở việc: write vào append-only thì... nhanh, vì bản chất chỉ là thêm một dòng ở cuối. Đoạn đảm bảo cho dữ liệu append-only và các dữ liệu khác được đồng bộ có lúc sẽ phức tạp (ví dụ như giao dịch +100 -90 xong phải đảm bảo số dư hiện tại là 10), nhưng mình nghĩ nên cẩn thận tí là được

---

Mấy cái sau mình rảnh sẽ thử biên tiếp nhé. Giờ đang thấy mình viết dài quá rồi

Nhấp để mở rộng...

thisismyfirstclone đã nói:

Mình không rõ bạn ghi buffer writes thì lệnh writes ở đây ý bạn là ở mức high level (tức là queue requests) hay là low level (tức là buffer writes ở mức ghi ra đĩa).
Ở mức high level, các requests kể cả stateless vẫn cần queue vì số lượng process có hạn.
Ở mức low level, buffer writes là để tăng tốc độ ghi chứ không phải để việc write diễn ra từ từ. Vì khi buffer write vào memory trước khi ghi, file system có thể ghi các writes liên quan đến nhau theo một chuỗi các block liền kề. Nếu như write trực tiếp khi có lệnh write (random writes) thì sẽ bị tăng thời gian write, vì với mỗi lệnh write đĩa hdd cần thời gian để seek and rotate đầu đọc đĩa, n lệnh write sẽ tăng thời gian đó lên tỷ lệ thuận với n. Việc buffer writes làm giảm thời gian này đi.
Có thể đến đây bạn sẽ bảo là thế thì dùng SSD. Không, SSD vẫn dùng sequential writes vì random writes sẽ làm tăng tính bào mòn của transistors và giảm độ tin cậy của dữ liệu.
Mỗi một hệ thống làm ra đều cần cân bằng cả 3 yếu tố, performance, reliablity và durability. Không nên chỉ focus vào một yếu tố duy nhất (vd như performance). Lấy vd như buffer writes, nó làm tăng tốc độ ghi, nhưng thử suy nghĩ xem, nếu một mẩu dữ liệu quan trọng đến mức eventually phải ghi nó vào đĩa, nếu như xảy ra sự cố (mất điện, crash) ngay trước khi ghi vào đĩa (tức là data đã có trong memory nhưng chưa kịp ghi vào đĩa) thì sẽ có vấn đề còn nghiêm trọng hơn đấy là data inconsistency.

Nhấp để mở rộng...