Giờ it khó tìm việc rồi à

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
JGdqgzY.png
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:sweat: 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.:byebye: 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ì
zFNuZTA.gif


via theNEXTvoz for iPhone
 
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.
câu này để lòe sinh viên thì đc :D
 
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.
 
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
JGdqgzY.png
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.
 
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.
giờ trung tâm họ toàn dạy academic hết rồi bác à k thấy general mấy
 
câu này để lòe sinh viên thì đc :D
ấ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.
 
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.
--
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.

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
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.
 
ấ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.
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).
 
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.
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 :D
 
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.
Công ty cho bạn đi phỏng vấn người khác mình thấy khá sai lầm đó.
 
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).
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ự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.

1680771638911.png

-
 
Last edited:
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ự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.
vậy thì thay vì hỏi bigO, bạn có thể đưa thẳng vấn đề này ra :D 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ể

Nó scan chart liên tục và vẽ các đường fibonacci trên các chart để tìm kháng cự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.

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...
 
vậy thì thay vì hỏi bigO, bạn có thể đưa thẳng vấn đề này ra :D 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...

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 đủ.
 
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
7AvAW5L.png


via theNEXTvoz for iPhone
 
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
zls7LCb.png

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
9r0IgBI.gif
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.
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ì?
 
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.
Bộ nhớ dùng là cấp phát bộ nhớ hay sao bác
 
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ự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
-

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.
 
Bộ nhớ dùng là cấp phát bộ nhớ hay sao bác
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.
 
Back
Top