.Net 8.0
Senior Member
Mấy role Dev thì như thế nào vậy bác?
Mấy role Dev thì như thế nào vậy bác?
Thật là mình không biết học theo cái giáo trình hay course nào là tốt nhất cả, với hồi sv nghèo chết moẹ, tiền éo đâu đi học IELTS thế nên mình chốt tự học theo cái tài liệu phổ biến nhất là học IELTS Cambridge. Thím hỏi nó có bổ trợ trực tiếp ko thì mình xin trả lời là có. Vì chung quy lại vẫn là kiến thức vào đầu thôi mà, miễn là có học bài bản thì vẫn hơn là ko học gìthím học ielts à thấy có bổ trợ nhiều trong ngành mình ko ( như là làm việc , phỏng vấn , deal lương ... ) , thấy nhiều ông trên đây bảo hc ielts thì hơi thừa do nó thiên về học thuật quá trừ khi đi du học thì cần ielts
câu này để lòe sinh viên thì đcGần đây phỏng vấn 35 ông dev backend chưa ông nào trả lời được trọn vẹn câu "Độ phức tạp thuật toán bigO tính thế nào" dù CV phông bạt tới 2/3 khoe là leader.
Câu trả lời đơn giản "Là số phép tính hoặc bộ nhớ dùng trong trường hợp xấu nhất".
Nhiều khi muốn khóc trong phòng PV luôn các thím.
Câu này đơn giản mà, "worst case scenario"câu này để lòe sinh viên thì đc
Confirm là IELTS thừa nhé. Nhưng mà IELTS có 2 loại lận: IELST Academic(thường ng ta ns IELST là ns cái này) vs IELTS General. Nếu bác chỉ có nhu cầu đi làm thì IELST General lại hợp hơn vì mục đích của nó là cho những ng đi làm. Còn nếu học IELTS để đi du học thạc sĩ này nọ thì phải học IELST Academic.thím học ielts à thấy có bổ trợ nhiều trong ngành mình ko ( như là làm việc , phỏng vấn , deal lương ... ) , thấy nhiều ông trên đây bảo hc ielts thì hơi thừa do nó thiên về học thuật quá trừ khi đi du học thì cần ielts
giờ trung tâm họ toàn dạy academic hết rồi bác à k thấy general mấyConfirm là IELTS thừa nhé. Nhưng mà IELTS có 2 loại lận: IELST Academic(thường ng ta ns IELST là ns cái này) vs IELTS General. Nếu bác chỉ có nhu cầu đi làm thì IELST General lại hợp hơn vì mục đích của nó là cho những ng đi làm. Còn nếu học IELTS để đi du học thạc sĩ này nọ thì phải học IELST Academic.
ấy thế mà tất cả các dev mình pv đều không trả lời được dù range năm sinh mình pv từ 86 -> 2000. 1-2 người gì đó trả lời được ý time complexity.câu này để lòe sinh viên thì đc
Cũng không càn rành đâu thím.Anh nên bỏ biết điều kiện vào JD như là rành thuật toán, biết tính toán độ phức cmn tạp của thuật toán. Để người ta chọn giá + chọn nơi đúng.
T đi pv chắc gần 2 chục công ty trong suốt 8 năm đi làm, chắc chỉ có khoảng 2 cty của mỹ nó có hỏi, và nó có hỏi xoáy vào thuật toán vì JD nó có ghi như vậy.
--
Mình có pv vài bạn từ Âu Mỹ về (không phải đợt này) thì thấy kiến thức nền tảng rất vững. Có thể do ở Âu Mỹ dạy tốt hơn nên câu này người ta mặc định biết nên không hỏi.Bạn pv mình hỏi mình câu này mình trả lời đc nhưng mình sẽ ko tiếp tục phỏng vấn nữa.
1. Câu này hỏi ai mới ra trường thì phù hợp hơn do chưa có kinh nghiệm làm việc thực tế. Thành ra chỉ có thể hỏi về lý thuyết. Mà giỏ lý thuyết thì chưa chắc thực hành giỏi.
2. Trừ trường hợp vị trí đặc thù cần kiến thức CS vững thì đa số các việc engineering bình thường rất ít đụng tới bigO. ko biết bigO ko có nghĩ là engineer tệ, và biết bigO ko có nghĩa là engineer giỏi. Và cũng có trường hợp tuy ko biết khái niệm bigO nhưng vẫn tối ưu đc hệ thống
Trong suốt 10 năm đi làm ở Phần Lan, chưa hề có 1 cty nào hỏi mình kiểu này. Cũng có phỏng vấn dạo mấy cty US chơi cho biết thì cũng chả ai hỏi mấy cái lý thuyết này. Nhớ có duy nhất 1 cty hỏi kiểu này, tôi trả lời xong hết cho đúng phép lịch sự rồi gửi email ko tiếp tục nữa
bác cho mình 1 case thực tế bác gặp nếu biết tính complexity sẽ cho ra kết quả tốt hơn đi. Đó giờ mình chưa bao giờ phải ngồi tính xem func mình viết ra complexity là bao nhiêu (trừ mấy cái quá đơn giản như 2 loop thì O(n^2), 1 loop thì O(n), hashmap thì O(1), mà thật ra ko biết tính thì cũng tự hiểu 2 loop sẽ complex hơn 1 loop).ấy thế mà tất cả các dev mình pv đều không trả lời được dù range năm sinh mình pv từ 86 -> 2000. 1-2 người gì đó trả lời được ý time complexity.
Câu đó tiếp theo sẽ phỏng vấn thuật toán sử dụng ở 1-2 tình huống thực tế (cũng easy thôi) nhưng kết quả cũng chán lắm.
mấy cái tối ưu kiểu này nên hỏi từ ví dụ thực tế hơn là hỏi thẳng lý thuyết. Ví dụ như thay vì hỏi bigO là gì thì bạn nên hỏi: "Trong 1 API, nếu như mình cần lấy 1tr rows từ database sau đó tính toán [x] với 1tr dòng đó, thì làm cách nào để tối ưu" (kiểu như vậy để ứng viên tưởng tượng ra 1 cái trường hợp cụ thể).Cũng không càn rành đâu thím.
Câu khó nhất mình hỏi cũng chỉ kiểu cho 1 mảng có n phần tử và 1 mảng m phần tử, tìm các phần tử chung giữa 2 mảng và tính độ phức tạp của thuật toán bạn vừa nêu. Cái này thì gặp nhiều khi code. Nhưng cũng chỉ 3/35 bạn trả lời được.
Sinh viên với học trung tâm giờ vàng thau lẫn lộn, hỏi thuật toán easy còn không trả lời được thì làm sao tối ưu được các luồng code.
Mình có pv vài bạn từ Âu Mỹ về (không phải đợt này) thì thấy kiến thức nền tảng rất vững. Có thể do ở Âu Mỹ dạy tốt hơn nên câu này người ta mặc định biết nên không hỏi.
Ở VN mình phỏng vấn mới bắt đàu bằng kiến thức nền tảng kiểu đó đã chết gần hết, sợ lắm bác.
Công ty cho bạn đi phỏng vấn người khác mình thấy khá sai lầm đó.Gần đây phỏng vấn 35 ông dev backend chưa ông nào trả lời được trọn vẹn câu "Độ phức tạp thuật toán bigO tính thế nào" dù CV phông bạt tới 2/3 khoe là leader.
Câu trả lời đơn giản "Là số phép tính hoặc bộ nhớ dùng trong trường hợp xấu nhất".
Nhiều khi muốn khóc trong phòng PV luôn các thím.
1 ví dụ đơn giản. Mình lọc ra từ 1 file python bên mình. Mình có 1 startup bé bé về tài chính. Nó scan chart liên tục và vẽ các đường fibonacci trên các chart để tìm kháng cự và hỗ trợ (khái niệm tài chính chỉ đỉnh, đáy) để khuyến nghị cho khách. Hàm fib sẽ phải tính trên rất nhiều khung thời gian và hàng ngàn mã realtime.bác cho mình 1 case thực tế bác gặp nếu biết tính complexity sẽ cho ra kết quả tốt hơn đi. Đó giờ mình chưa bao giờ phải ngồi tính xem func mình viết ra complexity là bao nhiêu (trừ mấy cái quá đơn giản như 2 loop thì O(n^2), 1 loop thì O(n), hashmap thì O(1), mà thật ra ko biết tính thì cũng tự hiểu 2 loop sẽ complex hơn 1 loop).
vậy thì thay vì hỏi bigO, bạn có thể đưa thẳng vấn đề này ra mặc dù là nó cũng chung quy về tối ưu thuật toán nhưng sẽ ko nặng về lý thuyết. Hoặc hay hơn nữa là đưa thẳng cái trường hợp cụ thể1 ví dụ đơn giản. Mình lọc ra từ 1 file python bên mình. Mình có 1 startup bé bé về tài chính. Nó scan chart liên tục và vẽ các đường fibonacci trên các chart để tìm kháng cự và hỗ trợ (khái niệm tài chính chỉ đỉnh, đáy) để khuyến nghị cho khách. Hàm fib sẽ phải tính trên rất nhiều khung thời gian và hàng ngàn mã realtime.
Hàm thứ nhất là đệ quy được dạy trong sách, thường mới học code sẽ code kiểu này.
Hàm thứ 2 cũng là đệ quy nhưng có cache các kết quả trước đó
Hàm thứ 3 thay vì đệ quy có 1 bạn khá thuật toán đã dev và nó chạy nhanh hơn hàm 1 khoảng 300 000 lần, nhanh hơn hàm thứ 2 tầm 3-4 lần.
Nếu các bạn nghĩ backend không cần biết các khái niệm cơ bản như tính độ phức tạp thuật toán thì ok mình sai, mình xin lỗi vì đã làm các bạn mất thời gian.
Nó scan chart liên tục và vẽ các đường fibonacci trên các chart để tìm kháng cự và hỗ trợ (khái niệm tài chính chỉ đỉnh, đáy) để khuyến nghị cho khách. Hàm fib sẽ phải tính trên rất nhiều khung thời gian và hàng ngàn mã realtime.
vậy thì thay vì hỏi bigO, bạn có thể đưa thẳng vấn đề này ra mặc dù là nó cũng chung quy về tối ưu thuật toán nhưng sẽ ko nặng về lý thuyết. Hoặc hay hơn nữa là đưa thẳng cái trường hợp cụ thể
Rồi hỏi ứng viên sẽ thiết kế hệ thống ra sao. Lúc tui phỏng vấn thường phần kĩ thuật chỉ chiếm 1/3. Ngoài ra còn những cái khác để xác định engineer phù hợp cho team như observability, business-oriented hay technical-oriented, system design etc...
Bạn và các bạn của bạn bị vắt chanh bỏ vỏ, không đồng nghĩa với việc những người khác cũng bị vắt tương tự, nhìn thấy bản thân bị vắt nhưng vẫn không có phương án đối ứng thì tôi cũng hiểu trình độ của bạn thế nào rồi. Có chẳng cũng thuộc dạng chỉ đâu đánh đó, đụt trĩ mà thôi.Với tuổi đời 30 thì tôi và mấy thằng bạn thấy cái này méo đúng ở VN, thằng giỏi là thằng bị vắt chanh bỏ vỏ, xong dự án là đuổi, ko giỏi đấu đá chính trị và lo làm nên cảm thấy tủi thân nhảy việc như đi chợ. Đa số các công ty IT toàn mấy thằng dốt + thủ đoạn được lên làm quản lý, như bên FPT software là cả 1 tập đoàn chính trị từ ngoài đó đưa vào, tụi này thường ko ưa mấy thằng giỏi vì nó hay chống đối và ko biết điều, như bên Nash Tech bây giờ toàn intern gọi là rookie
Bớt sách vở như xã hội phương Tây đi thanh niên, đây là VN môi trường làm việc toxic số 2 thế giới thì méo có nước nào dám nhận số 1 đâu
Bộ nhớ dùng là cấp phát bộ nhớ hay sao bácGần đây phỏng vấn 35 ông dev backend chưa ông nào trả lời được trọn vẹn câu "Độ phức tạp thuật toán bigO tính thế nào" dù CV phông bạt tới 2/3 khoe là leader.
Câu trả lời đơn giản "Là số phép tính hoặc bộ nhớ dùng trong trường hợp xấu nhất".
Nhiều khi muốn khóc trong phòng PV luôn các thím.
1 ví dụ đơn giản. Mình lọc ra từ 1 file python bên mình. Mình có 1 startup bé bé về tài chính. Nó scan chart liên tục và vẽ các đường fibonacci trên các chart để tìm kháng cự và hỗ trợ (khái niệm tài chính chỉ đỉnh, đáy) để khuyến nghị cho khách. Hàm fib sẽ phải tính trên rất nhiều khung thời gian và hàng ngàn mã realtime.
- Hàm thứ nhất là đệ quy được dạy trong sách, thường mới học code sẽ code kiểu này.
- Hàm thứ 2 cũng là đệ quy nhưng có cache các kết quả trước đó
- Hàm thứ 3 thay vì đệ quy có 1 bạn khá thuật toán đã dev và nó chạy nhanh hơn hàm 1 khoảng 300 000 lần, nhanh hơn hàm thứ 2 tầm 3-4 lần.
Nếu các bạn nghĩ backend không cần biết các khái niệm cơ bản như tính độ phức tạp thuật toán thì ok mình sai, mình xin lỗi vì đã làm các bạn mất thời gian.
View attachment 1763071
-
Bạn đọc khái niệm Time Complexity và Space Complexity nhé. Thường học ở trường hay dạy về Time Complexity nên nhiều bạn ko biết còn có Space Complexity.Bộ nhớ dùng là cấp phát bộ nhớ hay sao bác