Demo phỏng vấn Technical Round tại TikTok
Вставка
- Опубліковано 15 вер 2024
- Interviewer: Ms. Thien Anh Software Engineer from Microsoft
Interviewee: Mr. Hieu Software Engineer from Acronis Singapore
Fanpage: / engineerpro.official
Các bạn quan tâm thêm khoá học về Backend, Thuật toán, System Design bên EngineerPro vui lòng truy cập FB fanpage ở trên.
#DSA #Java #Algorithm #Bigtech #Amazon #Google #backend #Systemdesign #EngineerPro
Phần 1 fail
Phần 2 fail khủng khiếp hơn
Các db đều support mvcc nên mấu chốt nằm ở việc handle 1000 trans, phải xử lý queue và xử lý async post/get request, nếu ko sẽ bị nghẽn khi tps tăng đột biến dẫn đến respose lâu hoặc timeout.
Nhờ mvcc db sẽ tự lock update, còn read ko bao giờ bị lock, 1 số db hỗ trợ lock row như oracle thì sẽ mạnh hơn nữa.
Việc xử lý tuần tự trans là ko cần thiết vì lock đã đc handle, trừ khi business yêu cầu 1 số trans cụ thể phải đc xử lý tuần tự, ví dụ đặt lệnh chuyển tiền phải là A -> B, B-> C, khi vào queue thì bị xáo trộn hoặc nằm ở queue các khác nhau, có thể dùng consistant hashing giải quyết vấn đề này.
Phần 3: 1 số câu trả lời sai, kiến thức outdate như mysql đã có gtIDs
interview nào cũng chất lượng ạ, mong kênh ra nhiều để mọi người có kinh nghiệm nhiều hơn. Cảm ơn!
Bạn nhắn tin fanpage nhận info nhé:facebook.com/EngineerPro.Official?mibextid=LQQJ4d
T đang vừa rửa mặt và chill chill nghe 2 bạn này cho tới khi nghe 10k là 10^5😂 phải tua lại coi có nghe nhầm ko
Hi vọng có nhiều buổi mock interview chất lượng như này hơn ạ
Theo mình thì dùng upperbound() và upperbound() - 1 thì mới đúng. Bởi lowerbound() nó sẽ tìm phần tử đầu tiên >= khóa, trong khi mình cần tìm phần tử cuối cùng >= khóa vì phần tử này mới có length lớn hơn và check overlap ở đây mới đúng.
facebook.com/EngineerPro.Official bạn nhắn tin fanpage để được gửi solution nha
Phần 1:
1 - sort theo a
2 - sort theo b
3 - chọn b nhỏ nhất
4 - xóa hết các đoạn có a < b nhỏ nhất ở trên. Được đoạn đầu tiên.
5 - lặp lại bước 3 với các đoạn còn lại
bài toán chỉ đơn giản là tìm kiếm và check, xóa lm j cho phức tạp pro??:))))
Quan điểm tôi pv nha hông biết Technical Round chứ vòng này bạn đặt question như biến Interviewee thành thợ code vậy, technical interview chú trọng insight , limit callout, solution architechs mấy cái quan trọng đó áp dụng thực tế. Bạn viết 1 ứng dụng retail thì bạn cần tìm hiểu flow business( khảo sát dự án) là bước đầu tiên, sau đó solution architech (schema builder object), đến rủi ro (Limit, Authorize) integrated function.., Tôi không thích 1 bạn đặt câu hỏi chỉ chú trọng coding
❤
many thanks ❤
Good❤
đồng ý với bạn, những interviewer theo khuynh hướng "yêu" code quá mức thì sẽ chú trọng vào code rất nhiều khi phỏng vấn, dẫn đến việc đúng và chính xác về mặt code syntax, nhưng ngoài ra thì ko được quan sát gì thêm từ interviewee, vd như cách tiếp cận, clear communication, cách nhìn vấn đề, cách bạn interviewee xử lý vấn đề khi bị sai sót và cách mở rộng,...
công nhận :))) về cơ bản code thì coppy được nhưng tư duy phát triển dự án thì khó :))) tôi pv mà đòi code kiểu này tôi reject luôn :))) đấy là quan điểm của tôi
xem interview kiểu thời đại AI mà chúng ta đang ngồi nghĩ xem nên dùng tab hay space vậy. Bài toán thay đổi rất nhanh và Dev cần làm nhiều hơn là code
mình nghĩ bạn có thể sử dụng eventSourcing, việc tạo records transaction có thể dẫn đến case out of controll, thí dụ transaction của bạn trừ xiền của user mà user đó hết xiền thì có lẽ ko nên tạo thêm record.
Khi GET thường mình sẽ ko update db, và nó cũng đang là principle(CQRS) mà mình làm theo. Có thể tuỳ theo từng quan điểm của mỗi ng`.
interview code giải thuật này thật sự là nâng cao nha
bạn Thiên Anh cười rất xinh, tặng 1 like
Thấy đề bài có vẻ sai nhỉ, init data overlap nhưng khi add vào lại yêu cầu k dc overlap? bài toán kiểu này thực tế mình đã từng gặp khi book lịch phòng, về xử lý cũng k phải khó nhưng nếu chưa gặp lúc interview thì mình nghĩ việc căng thẳng sẽ ảnh hưởng đến tư duy. còn về cái orm bạn kia nói thì mình khá respect nhưng mình k nghĩ 1 feature nên dùng dc nhiều data base. orm thường thì nó chỉ cung cấp nhưng interface cơ bản thôi, còn việc dùng DB nào trong feature thì dựa vào tính chất business của feature đó, và thông thường với logic phức tạp thì đều phải dùng raw. cái orm bạn nói có thể là phần DAO(repository) để xử lý những logic liên quan đến DB, như vậy thì nó sẽ phụ thộc vào feature chứ để tách riêng ra dùng lại cho dự án khác thì độ khả thi không cao vì mỗi logic sẽ khác nhau ở mỗi feature khác nhau
đúng r, nếu mà overlap thì sort có tác dụng gì nữa, ví dụ (1;5], (2;4],(10;15], query là (4;5] thì xài binary search chả có tác dụng gì, chưa code nhưng nháp ra cái testcase là biết đề có vấn đề liền, bài này quy về check lower bound thuộc khoảng nào chứ cái upper bound không quan trọng
chuẩn
@@LongLe-mh1lu bài này mà dựa vào bài toán book phòng này nọ trên thực tế nếu cho như ví dụ thì bắt buộc phải có bước sort + merge các đoạn lại thì mới gọi là ổn chứ nhỉ :D đề bài với cách giải quyết trong video nghe có vẻ không cần thiết lắm, chỉ việc kiểm tra từng khoảng rồi output ra thôi chứ cần gì dùng tree
Chuẩn rồi, bài này đơn giản là nhặt các chuỗi cho vào một tập hợp sao cho ko cái nào trùng nhau.kết quả thu được là một tập hợp distinc các chuỗi đã nhặt và một list tracking boolean thể hiện chuỗi nào được nhặt là true, ko được nhặt là false.Vậy mà cả người pv và người được pv đều ko làm bật lên được bản chất bài toán.
@@LongLe-mh1lu mình hoàn toàn có thể ghép đoạn, r đó cứ tìm kiếm vào check
Thật ra mình nghĩ bài test Algo so sánh A_q với các A_i trong set sẽ hơi rối não.
Mình nghĩ theo như vầy, do tất cả querry trong set đều không overlap nhau nên sau khi sort thì A_1
thấy bài toán đơn giản mà ta.CustomRange có struct là start và end kiểu int, Input là list CustomRange và một CustomeRange để check có overlaped không,1 vòng lặp for và check từng phần tử và input có bị overlapped không. Check end input
Dạ cách của bạn chưa tối ưu đâu ah, nên dễ bị fail trong phỏng vấn lắm
@@EngineerPro-Official Bạn có thể cho mình kham khảo cách giải bài trên với
@@luongvantrong9627 facebook.com/EngineerPro.Official?mibextid=2JQ9oc bạn inbox page giúp admin nhé, mình gửi
Check từng phần tử thì là O(n). Còn binary search như video là O(log n) bạn ạ. Phỏng vấn big tech thường đòi hỏi most optimal cho những câu easy/medium như thế này.
@@98kidharpa ơi, e đang trình intern backend mà e xem cái đề còn hơi lú, nếu mà mức easy thật thì khoai quá. Btw, e ko giỏi thuật toán lắm, hay e nên chuyển sang FE ạ?hay có cách nào để e lấy lại nền giải dc mấy bài như này ko
hay quá ạ !
cho mình hỏi cuộc interview thông thường đề bài sẽ cho ở dạng người phỏng vấn sẽ đọc đề như thế kia à. tại mình nghĩ rằng như thế nó không chuyên nghiệp một chút nào cả. 1 bài toán tin học cần phải được giới hạn rõ ràng và cần có độ xác thực cao .
theo thực tế của mình là lúc pv thì khác lúc thi CP đó bạn.
Vòng đầu (vòng gửi xe) thì sẽ làm trên 1 cái web nào đó, có giới hạn với máy chấm cụ thể.
Qua vòng này rồi thì tới vòng pv như trong video, đề sẽ rất ngắn gọn, người pv viết ra hoặc đọc ngay lúc pv. Sau đó nói chuyện để làm rõ đề, rồi bắt đầu làm, nói luồng suy nghĩ của mình. Nếu còn nhiều thời gian thì interviewer mới bắt đầu đặt ra thêm constraint.
10000 = 10^4 nhỉ
Mình có ý tưởng giải bài 1 như sau:
Bước 1: Bài này mình nén tất cả các số a và b trong n đoạn đề cho và tất cả các số a,b trong m query lại để mapping nó về các số đâu đó dưới 4*10^5. Bằng cách là sort tất các số đó lại rồi duyệt qua gán thứ tự cho nó là oke. O((m+n)*log(n+m))
Bước 2: Tạo cây Lazy Segment Tree Rồi mình dùng để update cho n đoạn với kiểu là lấy max giá trị theo khoảng với 1(true) và 0(false). O((m+n)*log(n+m))
BƯớc 3: Tiếp đến với mỗi truy vấn mình dùng lại cây đã được build phía trên bằng Lazy Propagation của Segment tree trước đó lấy ra max của giá trị trong khoảng [a,b] để check xem xem trong đoạn đó có max là 1 => đoạn này đã bị OverLap,
ngược lại nếu lấy max trong đoạn [a,b] này ra mà có giá trị là 0 => đoạn này không bị Overlap thì mình sẽ cập nhật đoạn này lên bằng Lazy như n đoạn ban đầu.Rồi mình tiếp tục query.O(log(m+n))
=> TC = O((m+n)*log(n+m)) , Space = O(4*10^5)
Không biết mình giải như vậy có đúng không ạ? do chỗ lazy segment hơi dài dòng nên mình nói tóm tắt :)))
Lazy Propagation: vnoi.info/wiki/algo/data-structures/segment-tree-extend#2-lazy-propagation
Mình thấy lời giải như của bạn là đúng hơn đó. Lời giải của anh trong vid thì vẫn chưa bao quát được hết các trường hợp khi có các đoạn nằm hoàn toàn trong một đoạn khác.
@@haihoanghong1243 mình thấy cấn ở chỗ ban đầu cho các đoạn có thể bị chồng lên nhau thì hơi khó hiểu rồi
về bài toán thực tế thì phải sort + merge các đoạn chồng lên nhau trước rồi bắt đầu query thì mới ổn hơn chứ nhỉ
@@mob_psycho_134 đúng rồi đó bạn, ý kiến của mình là bài này phải không có đoạn nào chồng chéo nhau sẵn thì lập luận như anh trong vid mới chuẩn, chứ mình thử lấy một vài ví dụ thì nhận ra lập luận của anh ý không còn đúng nữa. Mình thấy cách giải của bạn ở trên là hợp lý nhất rồi á.
@@mob_psycho_134 với cách mà bạn ý nêu thì không cần tiền xử lý các đoạn mà vẫn sẽ giải được bài này
với cách giải của bạn thì phù hợp khi bạn biết hết tất cả các queries trước khi init. Tuy nhiên trên thực tế các queries sẽ đến trong thời gian thực và nếu thuật toán của bạn có thể xử lý được chúng mà ko quan tâm tập queries có bao nhiêu thì sẽ có nhiều điểm cộng hơn nha :D
phần design system cho em hỏi tại sao phải quan tâm đến transaction và lock khi crete/read balance vậy ạ? Em nghĩ là một user không thể liên tục tạo ra transaction trong một khoảng thời gian ngắn được nên có phải mình cần đặt sự quan tâm vào việc thiết kế mô hình db chịu tải tốt đúng không ạ?
bạn nhắn tin fanpage để nhận tư vấn solution nhé : facebook.com/EngineerPro.Official
Lock là để tránh tài khoản bị âm rồi mà vẫn chuyển tiền được, cái này liên quan tới tính đúng đắn của data, business. Còn vụ read thì nhiều bên khác nhau, chủ tài khoản xem trên app, trên web, rồi admin xem, export data để report. Nếu lock cái row đó mà ko cho read sẽ ảnh hưởng nhiều bên. Để giải quyết vấn đề này bạn tham khảo cái isolation level cho mấy transaction. Hoặc dùng replica như phần sau video cũng là 1 solution. Peace.
ông này học kma hay sao nhìn quen thế nhỉ, nếu đúng thì cắp sách học lại đi
create/read balace chính là giai đoạn check balance trước khi giao dịch đấy, vd có lỗi nào đó mà hackẻ bằng race condition tạo được 1 loạt transaction (read check valid value). Rồi nó mới process các transaction thì múc kut thui
@@vietd0x vâng mình học kma đây. Hình như bác hiểu lầm, về phần consistency thì không có gì để bàn cãi khi thiết kế rồi bác. Mình cũng không có vấn đề gì với vụ đó. Mọi thứ còn lại thì như 2 solutions mà bác @onghoangdata đã nói phía trên. Ngoài ra vấn đề tối ưu hệ thống để phục vụ số lượng lớn người dùng thì cũng cần kết hợp nhiều giải pháp từ nhiều layer khác nhau và cũng tuỳ theo business để thiết kế nữa. Mình vừa đút kết trong buổi trao đổi với một anh Techlead trong buổi pv gần đây.
1.Tại sao phải quan tâm đến transaction và lock: để đảm bảo không xảy ra race conditions làm cho balance bị sai
2. " User không thể tạo nhiều transaction thì không nên lock": Các ứng dụng lớn: thường sẽ có các batch job để xử lý business logic thì sẽ có rất nhiều transaction xảy ra đồng thời lên user đó nên việc lock là cần thiết. vd:ngân hàng, các ứng dụng tài chính hoặc nhiều lĩnh vực khác ..
Thiếu mất phần sum amount trong phần system design với câu query update nhỉ
Á đù Toàn :)))
- phần 1 bài pv thì by pass vì không có thêm comment gì,
- cơ mà sang phần 2 cảm giác trả lời hơi fail, chưa trả lời đúng được trọng tâm câu hỏi: 1000 transaction /1s tức là 1 transaction / 1 ms, tức là data phải xử lý gần như ngay lập tức, nếu dùng cơ chế lock như kia là chắc chắn fail, nó sẽ có 1 cơ chế khác giống như sử dụng std::atomic trong c++.
- phần 3 về câu hỏi thêm cũng trả lời chung chung, đại loại là, theo như mình biết là ... bla bla nhưng thực ra là mình chưa implement bao giờ nên mình chưa rõ :D.
Nếu nói về kết quả chiếu cố thì sẽ được là 1/3 PASS.
Sw Engineer tận bên Sing cũng không phải cao siêu lắm nhỉ :D
chung quan điểm, bài 2 quá lạc đề
lock của b ấy design là lock distributed. Ví dụ ứng dụng triển khai nhiều node vẫn work.
tps 1000 của bài toàn transfer money thì trong thực tế trong 1s thì chả user nào bấm đủ nhanh để chuyển > 2 lần. Còn tps như kia là vẫn bình thường.
Với k phải 1 transaction/ 1ms :)))) Đọc lại khái niệm tps.
@@namnguyenpt đây là bài toán xử lý mà bạn, đâu phải là bài toán thực tế chuyển tiền trên UI. Giả sử có 1000 request update field đó thì sao. Lock table thì đâu giải quyết được theo đề bài.
xịn nha
Nếu 1 transaction là chuyển từ ví A sang B mà POST request trừ tiền ví A fail mà POST request cộng tiền ví B succeed thì xử lí sao bạn ơi?
Và thường thì sẽ phải check amount của 1 ví trước khi chuyển tiền (ví dụ ví có 5$ thì chỉ được chuyển tối đa 5$). Mà nếu 2 transactions: chuyển 5$ từ 1 ví A(5$) sang ví B, và chuyển 5$ từ ví A(5$) sang ví C, được thực hiện cùng lúc. Thì cả 2 transaction này sẽ đều được check thành công và cả 2 ví B và C đều nhận được tiền đúng ko?
Idol Hiếu Trần. CHY, KSTN Hust :v
hay quá
Bạn inbox fanpage nhận nhiều tài liệu ôn tập hơn nữa nhé:facebook.com/EngineerPro.Official?mibextid=2JQ9oc
đoạn cuối là master node chỉ định ấy hả? master node chết rồi sao mà chỉ định được? thường nếu database dạng replica mà ko có cơ chết vote như mongodb thì sẽ cần 1 thằng đứng ra chỉ định, nhưng lại có 1 vấn đề là liệu thằng này có chết luôn ko
Hay quá ạ
Bạn nhắn tin fanpage nhận tư vấn nhé:facebook.com/EngineerPro.Official?mibextid=LQQJ4d
tks
Cần học những cái này nên bắt đầu từ đầu? Và hướng luyện tập sẽ như thế nào? E cảm ơn
m.facebook.com/EngineerPro.Official bạn nhắn tin fanpage nhé
Leetcode
vozzzz
code gym, cấu trúc dữ liệu và giải thuật+ kinh nghiệm 2,3 năm code business dự án thật
@@starlight9816 e mới có 1y kn be. DSA yếu. Nên rất khó để có thể hiểu được những gì trong video muốn chuyền tải.
Chị Thiên Anh code C++ ở Microsoft ạ
cho mình xin ý tưởng giải bằng segment tree ạ
Inbox fanpage , mình gửi nhé:facebook.com/EngineerPro.Official?mibextid=2JQ9oc
Phỏng vấn mà cứ nhìn lên trời hoặc sang ngang thế thì người interview sẽ nghi ngờ về sự minh bạch của thông tin bạn nói. hoặc đơn giản là thiếu tự tin
cái này hình như là xài laptop mà nhìn lên màn hình lớn hơn đó :v
Cái này level nào v ạ?
middle
intern
intern
Frontend và backend chưa phải fullstack bro.
ý bạn nói phải biết tester nữa phải k
@@minhchauvo6872 fullstack để mà nói thì đảm nhiệm hầu hết khâu trong SDLC. Theo tôi thì cả bao gồm việc deployment và maintenance ứng dụng.
yêu cầu thuật toán như này thì hầu hết là các công ty BigTech đúng không ạ?
Vâng ah
Bạn inbox fanpage nhận tư vấn nhé: facebook.com/EngineerPro.Official?mibextid=LQQJ4d
Bạn nhắn tin fanpage nhận tư vấn nhé:facebook.com/EngineerPro.Official?mibextid=LQQJ4d
Oh mình biết bạn Hiếu này, KSTN KHMT HUST, hay đi hi ICPC, nchung bạn này đỉnh kao, tốt nghiệp xong làm SE ở shopee (ngưỡng mộ)
em mới học lập trình đc 1 năm, cho e hỏi phải học bao nhiêu để giỏi như a trong vd ạ, chứ ac nói e chả hiểu gì ạ
Bạn ntin cho page nhận tư vấn nhé:facebook.com/EngineerPro.Official?mibextid=2JQ9oc
học kỹ môn cấu trúc dữ liệu và giải thuật + làm đề leetcode nhiều.
Mình cũng z 😅
Sao k nói tiếng anh ta ?
Chúng mình nói tiếng việt cho anh em dễ theo dõi ạ
hài thiệt :D
ờ hơi nhiều :)))
B bao nhiêu tuổi z
Mình tưởng pv bằng tiếng anh
Phỏng vấn demo bằng tiếng việt cho các bạn dễ xem ạ bạn
bạn nữ kia nói cứ ậm ờ khó chịu ghê
Phỏng vấn thì đừng nhìn lên trời thế, đứng phía interviewer thì mình trừ điểm rồi đấy
Đây là ngành kỹ thuật, yêu cầu khác với các ngành khác đấy bạn. Nếu cứ đòi hỏi một người nhìn máy tính 10 tiếng một ngày giao tiếp tốt, thì không bao giờ tìm được ứng viên chuyên môn cao đâu.
😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊😊!😊áQa1@@dominhtuan7787
.
Mấy bài này bằng bài HSG Tin lớp 9 :))
Thi Tin lớp 9 mà đã cỡ này r hả b
@@nguyenthang7805Đúng r bạn, bây h các bài thi HSG Tin khó hơn rất nhiều. Bạn có thể xem đề HSG THCS của Hà Nội, Vĩnh Phúc... Nếu bạn là hs Chuyên Tin THPT thì mấy bài này như mấy bài con nít.
Đúng r bạn, bây h đề HSG Tin khó hơn nhiều. Bạn có thể xem đề HSG THCS của Hà Nội, Vĩnh Phúc,... Nếu bạn là hs Chuyên Tin THPT thì mấy bài này như mấy bài con nít 😀
@@Dinhquang06bạn Hiếu này giải nhất HSG QG luôn b :v
kinh dị quá @@Dinhquang06
Quả 10000 = 10^5 cháy v~
kkkkkkk
nhầm xíu thôi mà
Định nghĩa fullstack của mn dễ nhỉ :))
dễ thì ai cx fullstack rồi
Bạn nhắn tin fanpage nhận tư vấn nhé:facebook.com/EngineerPro.Official?mibextid=LQQJ4d
kệ đi ò :v
Nên h dev thừa mứa ra ấy
10000 = 10^4 chứ cha nội
Chắc 2 bạn kia vozer =))