karina hart
Member
câu này để lòe sinh viên thì đc
Giờ it khó tìm việc rồi à
- Người tạo chủ đề whynotmeee
- Ngày bắt đầu
darkcloud09
Member
Ielts ko cần nếu bạn giao tiếp, viết và sử dụng tiếng Anh được. Mình chưa bao giờ học và cũng chả có Ielts.
darkcloud09
Member
Câu này đơn giản mà, "worst case scenario"câu này để lòe sinh viên thì đc
.Net 8.0
Senior Member
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
chiyeuemthoi
Senior Member
giờ trung tâm họ toàn dạy academic hết rồi bác à k thấy general mấy
ColdBailey
Đã tốn tiền
ấ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â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.
ColdBailey
Đã tốn tiền
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.
karina hart
Member
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).
FighterVn
Senior Member
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ể).
Tôi cũng từng ngồi ở cả 2 đầu (tuyển dụng và đi phỏng vấn) nên cũng hiểu là hỏi kiểu lý thuyết nhiều khi còn lọc luôn ứng viên xịn do người ta ko thích
Raiha173
Member
Công ty cho bạn đi phỏng vấn người khác mình thấy khá sai lầm đó.
ColdBailey
Đã tốn tiền
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.
-
Sửa lần cuối:
FighterVn
Senior Member
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...
ColdBailey
Đã tốn tiền
vậy thì thay vì hỏi bigO, bạn có thể đưa thẳng vấn đề này ra
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...
Có hỏi hết bạn, thuật toán chỉ chiếm 2/15 câu bên mình phỏng vấn. Còn lại là git, quy trình làm việc, thiết kế hệ thống và phần lớn nhất chiếm 8/15 câu pv là chuyên môn lập trình như PHP/ Python.
Thuật toán mình cũng chỉ hỏi cơ bản thôi. Kiểu bubble sort độ phức tạp bao nhiêu hoặc cùng lắm tìm thuật toán tối ưu để tìm phần tử chung giữa 2 mảng chứ đưa cái fib này vào trong pv thì hơi đánh đố nhau quá.
Nhưng mình bất ngờ vì khái niệm cơ bản kiểu bigO mà không ai trả lời được cho đủ.
blackhawk5
Đã tốn tiền
Tính ra cái giếng của mình từ lúc tốt nghiệp đi làm tới giờ toàn người chém và thảo luận tiếng Anh với khách hàng US UK CN TW IN như gió mà tuyệt nhiên không có cái bằng IELTS nào (mình TOEIC 890 thi lúc trường yêu cầu thi để xét tốt nghiệp), chứ trong thớt này nhiều ông tiếng Anh bập bẹ (mấy ổng nói vậy) mà lương cũng cao phết nhỉ. Chả bù cho mình, OT sml mới được 40tr chưa đủ 2k nữa với hơn 4 năm kinh nghiệm, trong khi mấy ông trên này tiếng Anh tèn tèn không phải đi giao tiếp mà 2k 2k5 như là giá sàn bình thường cmnr
via theNEXTvoz for iPhone
via theNEXTvoz for iPhone
manano16
Senior Member
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
Thêm nữa trình độ bạn kém thì nên xem mình kém ở đâu mà khắc phục, đừng lôi cái yếu kém của mình rồi đổ lỗi cho môi trường, hoàn cảnh. Tây nó cũng bào không kém gì Việt đâu bạn, quan trọng là sau khi bị bào thì bạn thu lại được những gì?
cuongstar9x
Senior Member
Bộ nhớ dùng là cấp phát bộ nhớ hay sao bác
Gâu Gâu Gâu Gâu
Senior Member
Software engineering nó khác competition programming. Anh đang ở góc nhìn competition thì thấy nó ok có vẻ nhanh. Còn nếu ở góc nhìn engineering thì tôi thấy fibonacci là 1 chuỗi cố định, backend nhận 10k rps thì phải tính lại 10k lần hết sức dư thừa.
Tất nhiên ko phải để nói algorithm là vô dụng, nhưng nó chỉ là 1 phần nhỏ của engineering. Senior engineer đôi khi họ phải deal với các vấn đề về system nhiều hơn và quên 1 vài định nghĩa cơ bản là điều bình thường.
ColdBailey
Đã tốn tiền
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.
cuongstar9x
Senior Member
À có chứ, xưa mấy ô thầy dạy tiếng Việt mà không dùng giờ quên thôi, bài toán thực tế của bác yêu cầu critical performance nên cần nắm rõ, còn hầu hết code ở VN không cần đến mức đó nên người ta quên cũng là điều dễ hiểu, dù gì học mấy cái này cũng không có gì khó so với nhiều cái khác
Gâu Gâu Gâu Gâu
Senior Member
vậy thì thay vì hỏi bigO, bạn có thể đưa thẳng vấn đề này ra
Nhiều người thích đưa algo vào trường hợp cụ thể, nhưng việc này khá khó, đòi hỏi interviewer phải cực kì kinh nghiệm vì những cái có thể đưa vào hầu hết đều có cách khác để xử lý hoặc có sẵn lib.
Ví dụ bài trên, nếu nó là 1 performance issue thì cách giải quyết sẽ rất khác. Tôi chỉ cần define 1 cái array 10000 items với value chính là giá trị của của fibo(index). Complexity của cả time và space đều là 1, ăn đứt mấy cái cách trên. Basic engineering solution.
Quay lại cái định nghĩa BigO là gì, người pv trả lời “số phép tính trong trường hợp xấu nhất” tôi ko biết lấy ở đâu nhưng tôi tin tưởng là nó sai. Complexity để đánh giá mức độ “scale” chứ ko phải đơn giản là số lượng phép tính.
Comment này là chính xác nhất về vấn đề này.
Chủ đề tương tự
