thảo luận Câu hỏi phỏng vấn - làm sao nodejs chạy với 1 thread?

[jiiren]

Câu này phù hợp với phần mềm và thỉnh thoảng tôi cũng có hỏi. Không biết trước thì dự đoán có cơ sở là đủ tốt rồi. Giải thích nó phải trên cơ sở cách quản lý và cấp phát bộ nhớ của kiểu dữ liệu vector. Chứ giải thích vì context switch thì còn trừ điểm chém lung tung.

Thì rõ ràng là nó không có liên quan gì tới Context Switching mà thím, nên em mới thắc mắc là bên C# cái n đó có gì đó đặc biệc

 

[CodingCat]

Cái này mình thắc mắc từ hồi 2017, hồi đó mình code C#, nhưng cứ thắc mắc trong đầu là làm sao phần mềm nó biết network package khi nào về, chả nhẽ 1 cpu core scan card mạng liên tục?
Rồi mình cũng không hiểu tại sao cpu biết khi nào con chuột nó move? chả nhẽ scan liên tục?
Sau đó tìm hiểu thêm rồi mới hiểu là cách đó k hiệu quả và thiết bị phải có chip riêng của nó, nó sẽ thông báo lại cho CPU chứ không thể bắt cpu scan trực tiếp được.
Tiếp đến hồi đó có làm với IIS trên backend, bị 1 vài vấn đề nên bắt buộc phải tìm hiểu xuống bên dưới để giải quyết vấn đề.
Chưa kể ai hiểu về cái này rồi thì sẽ khắc hiểu về context switch và hiểu nó tốn kém như nào, đến khi viết code c# thì sẽ không còn dùng var arr = new List<int>(); nữa mà thay vào đó sẽ dùng var arr = new List<int>(n);
Thành thử, đối với mình nó không phải là 1 thú vui tìm hiểu để rồi khè thiên hạ, nó là kiến thức giúp mình hàng ngày trong công việc. Dev biết thì tốt, không biết mình k trách, nhưng bảo là kiến thức cho hay thì mình k đồng ý.

Ngoài ra, nó cũng đâu có khó hiểu:

Vị huynh đài này nói chuyện lan man vậy, chắc lủng môn hệ điều hành đúng không? Đó giờ đi phỏng vấn có bị ứng viên xin về sớm không?

Kể cả bạn có hỏi AI thì câu trả lời chắc chắn vẫn quá nông và không nói được bản chất vấn đề, bởi OS cũng là phần mềm, nó vẫn phải dùng CPU thôi.

Ở process level thì sẽ có 5 trạng thái, new -> runnable-> running -> blocked -> terminate.
Bản chất 1 http request đến nodejs hay bất kì runtime environment nào thì hệ điều hành vẫn xem đó là 1 process, khi 1 process nó phải rơi và waiting state thường là 2 CPU bounded và I/O bounded. Tùy hệ điều hành mà kernel sẽ có cơ chế để resume thread từ trạng thái waiting -> running. Trong linux phổ biến nhất chắc là dùng epoll để đợi data từ i/o. Lúc này thì thread sẽ bị block, OS sẽ chọn thread ở trạng thái blocked hoặc runnable để chạy tiếp.
Còn về network thì trong *unix kernel level thì tất cả mọi vật là file descriptor hết nhé.
Lần sau đi phỏng vấn thì hỏi cái mình chắc thôi, cái nào chưa chắc đừng hỏi nha thím

 

[Trình Hà Lân]

Chưa kể ai hiểu về cái này rồi thì sẽ khắc hiểu về context switch và hiểu nó tốn kém như nào, đến khi viết code c# thì sẽ không còn dùng var arr = new List<int>(); nữa mà thay vào đó sẽ dùng var arr = new List<int>(n);

lọan ngôn rồi

 

[lekhoa3287]

Mình đã phỏng vấn khá nhiều ứng viên về cả backend lẫn frontend trong nhiều năm, chỉ có 1 câu hỏi mà gần như không có bạn nào trả lời đúng cả, đó là:
Nếu nodejs là single threaded, vậy tại sao nó có thể gọi 1 http api bằng await, đợi http api đó trả lời rồi tiếp tục chạy code phía sau dòng await.

Tại khi await thì thread sẽ chạy đi làm việc khác, vậy cái gì ngồi đó đợi cái http request đó?

Câu trả lời mình thường nhận được là: cái event loop nó, nó loop đi loop lại để check xem cái http request đó xong chưa.

Ok, nhưng nếu cái event loop đó cứ loop đi loop lại để check cái request đó xong chưa, vậy thì phải có cái gì đó khác chạy ở bên dưới để đợi các network request rồi báo cho event loop là network request đó xong rồi chứ đúng không?

Ứng viên thường trả lời: Ừ chắc đúng vậy, nodejs bên trên là JS nên dùng event loop, bên dưới runtime của nodejs phải có multitask/multi thread mới xử lý được.
Câu trả lời này sai, JS runtime ko có dùng thêm thread nào cả.
Kể cả bạn có hỏi AI thì câu trả lời chắc chắn vẫn quá nông và không nói được bản chất vấn đề, bởi OS cũng là phần mềm, nó vẫn phải dùng CPU thôi.


Xem tệp đính kèm 3653639
Xem tệp đính kèm 3653711

Lý do mình post câu hỏi này lên đây bởi đây không chỉ là vấn đề của nodejs, mà là cách máy tính vận hành nói chung. Dev viết code nhưng không hiểu code bên dưới chạy như nào. Câu hỏi này cũng áp dụng cho mọi ngôn ngữ khác, bởi nó là bản chất cách máy tính hoạt động.
Tuy nhiên, mình cũng không mong đợi dev trả lời đúng, đây chỉ là 1 câu hỏi xem dev có kiến thức về low level software hay ko thôi, trả lời được thì mình đánh giá rất cao, còn k trả lời được thì mình coi như chưa hỏi, ko sao cả.

Câu trả lời đúng là: Không có cái gì từ phía CPU ngồi đợi cái http request đó cả. Việc xử lý và thông báo kết qủa http request được xử lý ở mức phần cứng, cái card mạng báo cho CPU là việc CPU giao cho nó đã xong, nó bắn một message cho CPU để báo rằng nó đã xong việc, cpu báo với OS, OS báo lại với nodejs.

Nói chung là vậy, câu trả lời trên hơi sơ sài, nhưng để hiểu và trả lời được vậy thì phải hiểu được một nùi thứ từ phía phần cứng + hệ điều hành.
Mình post câu hỏi này lên đây để cho mọi người suy nghĩ, bởi không sớm thì muộn, bạn sẽ đụng phải các khái niệm low level như stack, heap, context switch ...
Có chút kiến thức về low level software sẽ rất tốt cho mọi người.
Cháu mình chắc năm sau vào đại học, có lẽ cái đầu tiên mình dạy nó sẽ là mấy cái cơ bản này.

Tiện đây share với các bạn 1 kênh youtube rất hay mình kiếm được, ông này giải thích rất tốt về các khái niệm bên trên, hy vọng sẽ giúp ích cho mọi người.

Core Dumped

Hello and welcome to Core Dumped. I'm a CS Engineer and I love teaching others about complex concepts I've learn over the years, but in a simple and easy to understand format.

www.youtube.com

Không biết bạn đã thực sự hiểu hay chưa mà lại đặt ra câu hỏi như vậy???

Thread với async/await là khái khái niệm khác nhau hoàn toàn.

Thread là đơn vị luồng của hệ điều hành (tức là khi phần mềm chạy đăng kí một Thread vào hệ điều hành thì hệ điều hành sẽ cấp một vùng nhớ để lưu các biến, hàm, ... cho riêng luồng đó ở trong bộ nhớ RAM).

Async/await là khái niệm bất đồng bộ không chặn, nó dựa trên cơ chế nonblocking I/O ngắt phần cứng, và nó không liên quan gì đến Thread (luồng), nó là cách thức một chương trình, luồng làm thế nào để xử lý dữ liệu.

Để mình lấy ví dụ thế này cho dễ hiểu.
Khi viết một ứng dụng đa luồng (MuiltiThread) bằng C++ hay C# chẳng hạn thì mỗi luồng tương tự như một người thợ làm việc, các luồng này tách biệt hoàn toàn về bộ nhớ Stack (chung nhau Heap và phần Data).
Còn bên trong mỗi một luồng thì dùng blocking (nếu như luồng đó chỉ thuần tính toán logic CPU) hoặc là non-blocking không chặn (Async/Await) nếu như luồng đó xử lý các vấn đề liên quan đến phần cứng như truy cập ổ cứng, card mạng, ...

Quay lại câu hỏi của bạn, cái gì bên dưới thực sự nhận dữ liệu khi Async/await.

Thì bên trong OS có cơ chế khác nhau để xử lý trao đổi dữ liệu với phần cứng (nhận dữ liệu từ card mạng, đọc ổ đĩa,. .. ), và cái luồng của NodeJS khi gặp câu lệnh await thì nó gửi yêu cầu I/O cho hệ điều hành và tạm dừng hàm async lại và chạy tiếp câu lệnh tiếp theo ngoài hàm async, OS tiếp nhận yêu cầu sau đó xử lý bất đồng bộ dựa theo cơ chế nhắt phần cứng (trên Linux là epoll, còn trên window là IOCP). Khi dữ liệu sẵn sàng, OS sẽ đánh thức luồng của Nodejs dậy để nhận dữ liệu.

 

[buitruong1689]

Ông thớt trình độ giống thanh niên gì chuyên post buzzwords trong box lập trình khác mỗi cái join date

Quá nhọ cho ai được ông thớt phỏng vấn. Domain knowledge trải dài từ FE bụp phát xuống Embedded thì cty thớt trả lương chắc là cao

 

[Mục Thiên Tôn]

Vậy ý b là SE role ko cần biết cái này, chỉ cần biết OS là 1 cái blackbox, nó sẽ xử lý giúp mình là được và ở trên tầng application biết cái này là thừa?
Nếu b nói là đúng thì để t chỉ ra vài case mà nó trở nên quan trọng.

Chuẩn đó, anh nên coi OS là 1 cái blackbox, nếu anh không chịu coi OS là 1 cái blackbox thì tại sao anh chấp nhận coi cpu là 1 cái blackbox? Còn nếu anh không xem cái cpu là 1 cái blackbox thì có nghĩa là anh cũng không được xem từng con NAND từng cái transistor là 1 cái blackbox luôn, và rồi anh cũng không thể xem các chất bán dẫn là blackbox nữa vì nếu vậy thì anh nên ngừng ngay ở tầng os rồi. Cuối cùng thay vì tuyển 1 thằng SE anh đang cố gắng tuyển một thằng kỹ sư vật liệu + thiết kế phần cứng + os developer + 1 se. Như anh thấy đấy, ý tưởng đó nó ngu vcl.

 

[DarkDiablo]

Đang làm nhúng, mấy cái low level, multicore, multi task/thread mà đọc câu trả lời mà mắc ói
Làm trên Linux hay Win x86 thì liên quan đầy đến userpsace, rồi nào system call, interrupt, nested interupt, message queue bla bla.

Ông nội thớt chắc éo biết http/https được handle ra sao trong mô hình OSI, rồi cái "card mạng" làm cái gì để transfer từ ethernet packet, ip packet, network packet tới applicatio packet (trong trường hợp này là http). Tóm lại sai bét.

bro thật sự làm nodejs và nói về low level
thằng thớt muốn học OS ấy, thì lên gg tải cuốn OSTEP về mà đọc, có ví dụ trên github nữa, lấy ra chạy đi rồi hẳn pv người ta sau, nhé

 

[lekhoa3287]

Anh nói đúng nhưng cũng không nên toxic quá. Thời bọn tôi học lập trình mạng vẫn chưa có cơ chế async/await. Thời đó vẫn còn phổ biến long polling nữa cơ.

Bây giờ đội già bọn tôi trong đầu có thể hình dung một cái mô hình mọi thứ hoạt động như thế nào và dựa vào đó để tra cứu các công nghệ cập nhật chứ cũng không nắm được hết. Đặc biệt là tên gọi cụ thể.

Ok fen.
Nhưng ma chủ thớt đang bị lẫn lộn giữa hai khái niệm đa luồng (MuiltiThread) và bất đồng bộ (Async/await). Đây là hai hai niệm căn bản nhưng mà nhiều người hay bị nhầm.

 

[cool-girl]

Đi phỏng vấn sợ nhất gặp tụi sen như thờ, tỏ ra nguy hiểm low level nhưng giá trị mang lại = 0

 

[hoctrokha]

fency có thực sự hiểu những gì về những cái vừa viết ko vậy...
đoạn đầu thì ko nói làm gì, chứ đến đoạn C# là toàn nói linh tinh@@
Biết trước capacity thì khai báo n chứ không biết trước size thì làm sao mà khai báo n được.
Và List<int>() và List<int>(n) thì là memory allocation chứ liên quan gì context switch đâu...
Context switch là câu chuyện về thread/process chứ tự dưng cho vào đoạn này nghe hỏi chấm?

Câu này phù hợp với phần mềm và thỉnh thoảng tôi cũng có hỏi. Không biết trước thì dự đoán có cơ sở là đủ tốt rồi. Giải thích nó phải trên cơ sở cách quản lý và cấp phát bộ nhớ của kiểu dữ liệu vector. Chứ giải thích vì context switch thì còn trừ điểm chém lung tung.

Hình như thím đó đang nhầm lẫn giữa Context Switching với lại việc memory nó đc allocate liên tục

Yeah, mình lộn Context Switch với Mode Switch, nói chung với mình nó vẫn là 1 thứ không rẻ.

Không biết bạn đã thực sự hiểu hay chưa mà lại đặt ra câu hỏi như vậy???

Thread với async/await là khái khái niệm khác nhau hoàn toàn.

Thread là đơn vị luồng của hệ điều hành (tức là khi phần mềm chạy đăng kí một Thread vào hệ điều hành thì hệ điều hành sẽ cấp một vùng nhớ để lưu các biến, hàm, ... cho riêng luồng đó ở trong bộ nhớ RAM).

Async/await là khái niệm bất đồng bộ không chặn, nó dựa trên cơ chế nonblocking I/O ngắt phần cứng, và nó không liên quan gì đến Thread (luồng), nó là cách thức một chương trình, luồng làm thế nào để xử lý dữ liệu.

Để mình lấy ví dụ thế này cho dễ hiểu.
Khi viết một ứng dụng đa luồng (MuiltiThread) bằng C++ hay C# chẳng hạn thì mỗi luồng tương tự như một người thợ làm việc, các luồng này tách biệt hoàn toàn về bộ nhớ Stack (chung nhau Heap và phần Data).
Còn bên trong mỗi một luồng thì dùng blocking (nếu như luồng đó chỉ thuần tính toán logic CPU) hoặc là non-blocking không chặn (Async/Await) nếu như luồng đó xử lý các vấn đề liên quan đến phần cứng như truy cập ổ cứng, card mạng, ...

Quay lại câu hỏi của bạn, cái gì bên dưới thực sự nhận dữ liệu khi Async/await.

Thì bên trong OS có cơ chế khác nhau để xử lý trao đổi dữ liệu với phần cứng (nhận dữ liệu từ card mạng, đọc ổ đĩa,. .. ), và cái luồng của NodeJS khi gặp câu lệnh await thì nó gửi yêu cầu I/O cho hệ điều hành và tạm dừng hàm async lại và chạy tiếp câu lệnh tiếp theo ngoài hàm async, OS tiếp nhận yêu cầu sau đó xử lý bất đồng bộ dựa theo cơ chế nhắt phần cứng (trên Linux là epoll, còn trên window là IOCP). Khi dữ liệu sẵn sàng, OS sẽ đánh thức luồng của Nodejs dậy để nhận dữ liệu.

Ok fen.
Nhưng ma chủ thớt đang bị lẫn lộn giữa hai khái niệm đa luồng (MuiltiThread) và bất đồng bộ (Async/await). Đây là hai hai niệm căn bản nhưng mà nhiều người hay bị nhầm.

Thì mình hiểu vậy mà, chắc do diễn giải không mạch lạc nên bạn thấy lủng củng.
Như 1 số bạn có comment, mình đang mix 2 thứ k cùng 1 tầng với nhau lại để nói, thành ra gây khó hiểu.

Chuẩn đó, anh nên coi OS là 1 cái blackbox, nếu anh không chịu coi OS là 1 cái blackbox thì tại sao anh chấp nhận coi cpu là 1 cái blackbox? Còn nếu anh không xem cái cpu là 1 cái blackbox thì có nghĩa là anh cũng không được xem từng con NAND từng cái transistor là 1 cái blackbox luôn, và rồi anh cũng không thể xem các chất bán dẫn là blackbox nữa vì nếu vậy thì anh nên ngừng ngay ở tầng os rồi. Cuối cùng thay vì tuyển 1 thằng SE anh đang cố gắng tuyển một thằng kỹ sư vật liệu + thiết kế phần cứng + os developer + 1 se. Như anh thấy đấy, ý tưởng đó nó ngu vcl.

Yeah, mình k muốn xem NAND là blackbox (cái này là sở thích muốn tìm hiểu thôi, k ai đi phỏng vấn ứng viên cái này cả). Mình k làm ở tầng lowlevel, nhưng mình vẫn cần kiến thức ở tầng hệ điều hành để troubleshoot các vấn đề ở tầng cao hơn. Còn phỏng vấn mình ko bao giờ hỏi ứng viên về libuv hay mmap hay những thứ trung gian mà khả năng họ không biết. Nhưng mình sẽ hỏi về những nguyên lý, cách phần cứng tương tác và "wakeup" phần mềm. Những thứ trung gian đó mình mới thường xem là blackbox.
Việc này hết sức bình thường, tại t là nhân chứng cho nhiều vụ công ty thuê VPS để host software, sau đó do thiếu kiến thức về low level nên cơ bản đưa ra giả thuyết sai, fix hoài ko xong.
Nhưng mình cũng có nói ở đầu bài, nếu biết thì là điểm cộng, ko biết thì cũng ko sao, coi như mình chưa hỏi. Nhưng ko thể nói biết low level 1 xíu là thừa được.

 

[java_lover]

Định hướng đặt câu hỏi phỏng vấn của chủ thớt không sai. Có chăng nên hỏi về những kiến thức nào mình nắm chắc thì hơn.
Chắc các bạn đều đã nghe đến những cuộc phỏng vấn biến thành những cuộc cãi vã vì kiến thức của cả hai bên không chắc rồi Tạo ra ấn tượng không tốt cho cả hai bên.
Mình nhấn mạnh lại chỗ này: Kiến thức chắc = giải thích mạch lạc, gãy gọn dễ hiểu. Không có chuyện nắm chắc kiến thức mà giải thích lòng vòng khó hiểu.

 

[hoctrokha]

Định hướng đặt câu hỏi phỏng vấn của chủ thớt không sai. Có chăng nên hỏi về những kiến thức nào mình nắm chắc thì hơn.
Chắc các bạn đều đã nghe đến những cuộc phỏng vấn biến thành những cuộc cãi vã vì kiến thức của cả hai bên không chắc rồi Tạo ra ấn tượng không tốt cho cả hai bên.
Mình nhấn mạnh lại chỗ này: Kiến thức chắc = giải thích mạch lạc, gãy gọn dễ hiểu. Không có chuyện nắm chắc kiến thức mà giải thích lòng vòng khó hiểu.

Ok bạn, nhưng mình k đồng ý vụ kiến thức chắc = giải thích mạch lạc nhé.
Nhiều vấn đề k giải thích mạch lạc được ko phải do k hiểu, nó phụ thuộc vào người diễn đạt và dòng suy nghĩ của họ vào thời điểm đó. Ví dụ giải thích về 1 khái niệm của domain driven design chẳng hạn, mình tin là mình vững, nhưng mình không tự tin rằng sẽ giải thích mạch lạc nếu như không soạn văn cho kỹ. Hoặc về 1 vấn đề bên kinh tế chẳng hạn, nếu bạn vào profile của mình, qua box kinh tế sẽ thấy mình viết nhiều bài về macro econ, nhưng những bài mình viết về neo-classical econ theo kiểu tóm tắt mạch lạc thì cơ bản lại dễ theo hướng nguỵ biện và đơn giản hoá vấn đề.
Nhưng khi viết 1 bài khác nói về modern monetary theory, diễn giải rõ ràng thì cơ bản chả ai hiểu, ko ai quan tâm.
Riêng bài này thì là sai lầm của mình khi mình nghĩ nói tóm tắt lại như vậy theo luồng suy nghĩ của mình thì mọi ng sẽ hiểu về mặt idea rồi tự đi tìm hiểu, ko ngờ mọi ng lại hiểu ra 1 hướng hoàn toàn khác.

 

[java_lover]

Mình không muốn đi sâu vào vấn đề này, loãng topic. Hồi mới vào nghề mình cũng từng nghĩ như bạn, đổ cho khả năng giao tiếp của mình kém. Cho đến khi mình đọc được câu này:
"If you can't explain it simply, you don't understand it well enough." Albert Einstein

 

[Diệp Vô Ưu]

Mình không muốn đi sâu vào vấn đề này, loãng topic. Hồi mới vào nghề mình cũng từng nghĩ như bạn, đổ cho khả năng giao tiếp của mình kém. Cho đến khi mình đọc được câu này:
"If you can't explain it simply, you don't understand it well enough." Albert Einstein

Trư cứ tưởng câu này của feyman
K ngờ lại là của einstein

 

[hoctrokha]

Mình không muốn đi sâu vào vấn đề này, loãng topic. Hồi mới vào nghề mình cũng từng nghĩ như bạn, đổ cho khả năng giao tiếp của mình kém. Cho đến khi mình đọc được câu này:
"If you can't explain it simply, you don't understand it well enough." Albert Einstein

Uhm, nói mình cũng ko muốn loãng, cảm ơn vì góp ý của bạn, nhưng vẫn phải nói mình cũng không ủng hộ câu đó của Einstein (tại mình cũng có kinh nghiệm rất mệt mỏi với vụ này qua nhiều bài viết về economic, biology và philosophy của mình trên voz, hiện có 1 bài viết về philosophy mình đang viết nhưng phải dừng lại tại mình không muốn bị rơi vào cái bẫy "explain it simply"). Có 1 thời gian mình cũng tin câu đó cho đến khi mình thấy được những thứ không đơn giản và có quá nhiều biến số để có thể "explain it simply" được. Bạn cứ đọc qua chia sẻ này và k cần reply để mọi ng có thể quay lại với topic, nó cũng chỉ là quan điểm của mình.

Mình muốn thành thật thừa nhận rằng kiến thức low level của mình chưa well enough, mình hiểu kiến thức của mình là hạn chế và nó chỉ đủ dùng cho công việc trong mảng của mình. Kiến thức low level của mình phần lớn ở mức idea/model, thành thử khi explain sẽ bị khớp về mặt ngôn ngữ với mấy bạn làm embed, nhưng mình vẫn tin là idea/model của mình k sai và nó rất hữu ích trong công việc.

Nhưng việc hiểu 1 topic hoàn toàn không liên quan đến việc explain nó tốt hay không, thậm chí là ngược lại nữa. Nếu bạn "Explain it simply", khả năng cao là bạn là expert nhưng over simplify topic đó, khiến nó không còn giữ được nguyên bản, hoặc thậm chí do thiếu kiến thức/góc nhìn về topic đó cũng khiến cho họ over confident và over simplify topic.

Việc này xảy ra rất phổ biến trong giới scientist/economist, nếu một người model 1 hệ thống theo góc nhìn simple thì họ sẽ đưa ra những lý thuyết đơn giản, dễ hiểu, họ cũng trả lời câu hỏi 1 cách rất tự tin. Nhưng cùng 1 hệ thống, nếu 1 expert khác model nó theo dạng complex system thì gần như các câu trả lời của họ thường rất lòng vòng, khó hiểu. Nếu bạn có hứng thú xem qua các trường phái economic hoặc biology khác nhau thì có lẽ rất dễ để nhận ra vấn đề này.

Nói chung câu bạn trích dẫn của Einstein có thể sẽ đúng với các hệ thống simple, giống như computer science, nhưng khả năng cao sẽ sai với các hệ thống khác, nên tốt nhất đừng lấy nó làm kim chỉ nam cho philosophy của bạn.

 

[GlutenFreePlease]

Thấy kéo page nên vào đọc thử. Khuyên có, trả lời, thông não có NHƯNG thằng thớt vẫn không nhận thiếu kiến thức, chẳng qua ăn nói kém hoặc người khác ngu quá không hiểu ý nghĩa hay hàm ý của nó .

 

[Esquie]

Thấy kéo page nên vào đọc thử. Khuyên có, trả lời, thông não có NHƯNG thằng thớt vẫn không nhận thiếu kiến thức, chẳng qua ăn nói kém hoặc người khác ngu quá không hiểu ý nghĩa hay hàm ý của nó .

Khó sửa nắm, cái này nằm trong năng lực tuy duy rồi.

Không hiểu rõ > vẫn dùng làm câu hỏi > nâng cao quan điểm "nó quan trọng" > khi bị chửi thì "do khả năng giải thích" > luôn thể hiện mình là người ham hiểu biết

Quá nhiều red flag khi chọn môi trường làm việc

 

[james094]

Khó sửa nắm, cái này nằm trong năng lực tuy duy rồi.

Không hiểu rõ > vẫn dùng làm câu hỏi > năng cao quan điểm "nó quan trọng" > khi bị chửi thì "do khả năng giải thích" > luôn thể hiện mình là người ham hiểu biết

Quá nhiều red flag khi chọn môi trường làm việc

Chắc bắc ý học nhiều quá cũng tẩu hoả nhập ma đó. Học nhiều quá quên cả nhiều từ tiếng Việt rồi.

 

[hoctrokha]

Tiện đây chia sẻ luôn với mọi người về một câu chuyện tưởng là đùa nhưng có thật, đây cũng là 1 phần lý do mình luôn hỏi ứng viên câu hỏi bên trên, không phải do mình muốn khè, mà với mình nó là kiến thức rất quan trọng.

Cũng vào năm 2017, mình có làm cho 1 công ty product cũng khá nổi tiếng ở Việt Nam, mình làm với 1 anh lead, anh này nền tảng Java nhưng qua code .Net, khi nói về async/await mình nói là async/await của .net nếu là IO thì khả năng cao không có dùng thêm thread, anh này thì bảo là phải có thread ngồi dưới đợi. Mình thấy cũng k quan trọng lắm nên cũng ko muốn tranh luận.

Gần 2 năm sau mình move qua 1 c.ty outsource, làm 1 dự án cho IBM. Mình làm với 1 team code Java khá cứng, lúc đó mình nhảy vào code Java, bắt đầu làm Hibernate và nhận ra Java ko có Async Await, lúc đó mình hỏi mấy anh làm ở đó xem nếu Java ko có async await thì khi gọi db nó phải có 1 thread ngồi đợi à? Mấy anh í bảo là đúng, phải có thread ngồi đợi. Vụ này khiến mình rất bất ngờ, tại sao 1 ngôn ngữ lâu đời như Java lại phải bỏ 1 thread ra ngồi đợi db call.
Mấy hôm sau ngồi nói chuyện, phòng có 1 anh thạc sỹ, đọc cũng nhiều, mình nói chuyện về async của nodejs và async của .net và mình bảo cơ chế của bọn nó cũng same same nhau. Anh í bảo làm sao same same được, 1 thằng single threaded, 1 thằng multi thread.

Lúc đó mình hiểu ngay tại sao anh lead cũ của mình lại bảo async await của .net là multi thread và phải có 1 thread bên dưới để handle mỗi request từ client. Tất nhiên cơ chế async/await của .Net sẽ khác nhau cho từng môi trường, nhưng với môi trường mà bọn mình làm thì điều đó không đúng.
Điều này cho thấy khả năng các anh í đem logic của Java qua áp cho .net và chưa hiểu cách async/await hoạt động. Mình chỉ làm Java tạm bợ 1 thời gian ngắn nên cũng k biết Java giờ như nào, nghe bảo mới có cái virtual thread, nhưng hồi đó nó là như vậy.
Và cũng bởi vậy, các anh í nghĩ rằng khi xử lý 1 cái gì đó cần đợi thì bắt buộc phải có thread ngồi đó đợi.

Ngược lại, mình nghĩ nếu như cho 1 bạn làm embed thử vọc java hoặc python chẳng hạn, mình nghĩ câu hỏi đầu tiên các bạn í sẽ hỏi là tại sao lại ko dùng async/await chứ không xem đó là thực tại hiển nhiên được.

P/S: đợi bạn @java_lover reply

 

[hoctrokha]

Thấy kéo page nên vào đọc thử. Khuyên có, trả lời, thông não có NHƯNG thằng thớt vẫn không nhận thiếu kiến thức, chẳng qua ăn nói kém hoặc người khác ngu quá không hiểu ý nghĩa hay hàm ý của nó .

Thực lòng t ko có giận b hay gì cả, nhưng t cũng hiểu EQ của b đang có vấn đề, tại người thích chửi như b t gặp cũng nhiều rồi.
Giờ vậy đi, b giải thích lý do t sai, t sẽ theo hướng dẫn của bạn để tìm hiểu 1 cách nghiêm túc, b là expert kiến thức chắc chắn phải hơn tôi rồi, cái này t nói thật lòng.
Nếu b bảo là "tao nói mày nãy giờ rồi, mày mù à?". Ừ, bây giờ b thử tưởng tượng ai đó lên stackoverflow đặt câu hỏi như tôi và bạn lên đó trả lời y chang nãy giờ b trả lời coi, chắc bạn được upvote nhiều lắm luôn.
Comment của bạn k có 1 xíu gì đóng góp cả, đây là câu đầu tiên của b:

Đang làm nhúng, mấy cái low level, multicore, multi task/thread mà đọc câu trả lời mà mắc ói
Làm trên Linux hay Win x86 thì liên quan đầy đến userpsace, rồi nào system call, interrupt, nested interupt, message queue bla bla.

Ông nội thớt chắc éo biết http/https được handle ra sao trong mô hình OSI, rồi cái "card mạng" làm cái gì để transfer từ ethernet packet, ip packet, network packet tới applicatio packet (trong trường hợp này là http). Tóm lại sai bét.

Tất cả các khái niệm trên t đều biết cả, thành thử k biết bạn nói cái gì để t tìm hiểu thêm nữa. Nếu b giải thích rõ hơn thì có phải hay hơn ko, tổng số comment chửi rủa của bạn từ đầu đến giờ cũng đủ cho 1 bài giải thích đàng hoàng rồi.
B kêu tôi thượng đẳng, nhưng hài ở chỗ b không thử nhìn lại thái độ của b có thượng đẳng hay ko.

Bạn nên nhớ 1 điều, thế giới này không reward cho kẻ đúng, nó reward cho kẻ được lắng nghe. Khi tôi được lắng nghe, bạn có chửi bao nhiêu đi nữa cũng k xi nhê, tôi cứ đạp lên lời chửi rủa của bạn mà đi tiếp thôi. Cái này k chỉ về phần mềm, nó là về cách sống.
Nếu bạn cứ tiếp tục tư duy chửi rủa, k có đóng góp thì dĩ nhiên sẽ dần dần mất đi chỗ đứng. Ví dụ trong bài này, nếu tôi k rep lại bạn thì cỡ vài ngày sau bạn cơ bản sẽ chỉ là noise hoặc cũng là 1 comment tăng tương tác cho post của t thôi.

Ráng thay đổi nhé b.