Làm thế nào để phản ứng với câu hỏi sai / không trả lời trong khi phỏng vấn? [đóng cửa]

Hôm nay tôi đã tổ chức cuộc phỏng vấn đầu tiên với các thực tập sinh tiềm năng. Trong khi điều này chủ yếu là các câu hỏi mở, tôi đã có một số nhiệm vụ lập trình tầm thường cho chúng:

• Viết hàm trả về true nếu các cạnh tam giác (tất cả các số nguyên) a, b và c có thể biểu diễn một tam giác vuông .
• FizzBuzz.
• Tính toán phần tử thứ N của Fibonacci bằng cách sử dụng đệ quy (nếu họ không biết Fibonacci là gì , tôi thậm chí sẽ viết cho họ định nghĩa F (n) = F (n-1) + F (n-2); F (1) = 1; F (0) = 1).
• Thực hiện cấu trúc Danh sách cho số nguyên và hàm viết để đảo ngược nó.

Đây rõ ràng là những nhiệm vụ rất dễ dàng và tôi đã không chuẩn bị cho ai đó không giải quyết chúng.

Tôi nên hành động thế nào khi họ vật lộn với những câu hỏi này? Tôi có nên từ bỏ câu trả lời? Đưa ra lời khuyên (tôi đã làm điều đó và cuối cùng tự giải quyết vấn đề)? Hoặc chỉ cần tiếp tục (hoặc có thể chỉ dừng lại) với cuộc phỏng vấn?

ps. Khi gặp vấn đề với các câu hỏi, tôi không có nghĩa là có lỗi, ý tôi là nếu chúng thậm chí không thể bắt đầu. Đây là một trường hợp với các câu hỏi về Fibonacci và Danh sách.

Bạn nói rằng bạn đang phỏng vấn cho các vị trí thực tập trong câu hỏi vì vậy đây là từ quan điểm đó, đối với các nhà phát triển toàn thời gian, thanh sẽ cao hơn một chút.

Khi bạn đang phỏng vấn thực tập, bạn phải nhớ rằng họ có thể chưa hoàn thành việc học và họ cũng có thể vào đại học mà không có bất kỳ nền tảng nào về lập trình và khoa học máy tính. Như vậy, bạn cần mở rộng kỳ vọng đến những gì bạn có thể mong đợi một cách hợp lý để ai đó biết và mức độ uy tín của vị trí (tức là Google có thể thoát khỏi những kỳ vọng mà một công ty mà mọi người chưa từng nghe thấy có thể).

Nhìn qua các câu hỏi mà bạn trình bày, tôi có thể sẽ xem chúng như sau trong một cuộc phỏng vấn:

1) Viết hàm trả về true nếu các cạnh tam giác (tất cả các số nguyên) a, b và c có thể biểu diễn một tam giác vuông.

Ứng dụng cơ bản của hình học với mã hóa đơn giản, hầu hết sinh viên sẽ có thể làm điều này mà không gặp nhiều khó khăn. Nhiều nhất là một lời nhắc nhở của Định lý Pythagore có thể cần thiết nếu họ đang thể hiện một chút căng thẳng vì đang trong một cuộc phỏng vấn. Điều này gần như có thể được coi là một vấn đề "tăng cường bản ngã" ở chỗ nó có thể giúp giải quyết một số người nếu họ rất lo lắng khi đi vào cuộc phỏng vấn.

2) FizzBuzz

Một lần nữa, một ứng dụng khác của một số tuyên bố kiểm soát cơ bản. Học sinh chưa được tiếp xúc với toán tử mô đun, hoặc chưa sử dụng nó nhiều, có thể cần được nhắc nhở về nó, nhưng không nên gặp bất kỳ vấn đề thực sự nào khi giải quyết vấn đề.

3) Tính toán phần tử thứ N của Fibonacci bằng cách sử dụng đệ quy (nếu họ không biết Fibonacci là gì, tôi thậm chí sẽ viết cho họ định nghĩa F (n) = F (n-1) + F (n-2); F (1 ) = 1; F (0) = 1).

Đây có thể là một vấn đề khá phổ biến vì vậy hầu hết (nếu không phải tất cả) sinh viên sẽ nhìn thấy nó tại một số điểm trước khi tốt nghiệp. Điều hấp dẫn là nó thường xuất hiện khi đệ quy được trình bày cho sinh viên vì nó cho vay chính nó hoặc một giải pháp dựa trên đệ quy hoặc vòng lặp mà sau đó có thể được so sánh để sinh viên từ các trường khác nhau có thể nhìn thấy nó vào các thời điểm khác nhau tùy theo trình tự các khóa học. Trong thực tế, nếu ai đó không thể đưa ra đệ quy tôi sẽ yêu cầu một giải pháp thay thế bằng cách sử dụng các vòng lặp và nếu họ không thể đưa ra điều đó thì tôi sẽ quan tâm hơn đến khả năng tiềm năng của họ.

4) Thực hiện danh sách cấu trúc cho số nguyên và hàm ghi để đảo ngược nó.

Câu hỏi này thực sự có thể hơi quá mở vì nó được viết nên nó cũng có thể là một câu hỏi hay để xem ứng viên tìm kiếm thông tin bổ sung như thế nào (ví dụ nên xóa các hàm, chuyển đổi sang mảng, v.v.), nhưng cũng được cung cấp tuyên bố vấn đề được xác định ("Thực hiện cấu trúc danh sách cơ bản cho các số nguyên cho phép các số được thêm vào cuối hoặc ở một chỉ số tùy ý, bị xóa và bao gồm một hàm để trả về một bản sao đảo ngược của danh sách") học sinh có thể giải quyết vấn đề miễn là danh sách là một cấu trúc phổ biến được trình bày trong khóa học cấu trúc dữ liệu ban đầu hoặc trong khóa học khoa học máy tính cơ bản sớm.

Về mặt đối phó với các ứng cử viên, nếu họ gặp khó khăn, hãy chắc chắn rằng họ thoải mái và cho phép họ một chút khoan dung vì họ có thể chỉ lo lắng về hiệu suất vì đây có thể là cuộc phỏng vấn thực sự đầu tiên của họ. Lời khuyên về việc giải quyết các vấn đề có thể được yêu cầu, hầu hết trong trường hợp của vấn đề thứ ba và thứ tư trái ngược với hai vấn đề đầu tiên.

Ngoài ra, cấu trúc quy trình phỏng vấn tổng thể để có các điểm "lối ra duyên dáng" được tích hợp. Ví dụ: bạn có thể có chương trình nghị sự sau:

• Gặp gỡ và chào hỏi, làm thủ tục phỏng vấn.
• Phỏng vấn ngắn với (các) nhân viên lập trình, các câu hỏi cơ bản về lý lịch.
• Trình bày bài kiểm tra lập trình.
• Phá vỡ
• Trở về sau giờ nghỉ, sa thải một số ứng cử viên không phù hợp.
• Phỏng vấn mở rộng với nhân viên lập trình viên.
• Phỏng vấn nguồn nhân lực (nếu được yêu cầu).
• Gói lại.

Luồng phỏng vấn này có xu hướng hoạt động tốt nếu bạn muốn có thể loại bỏ các ứng viên sớm vì họ biết ngay từ đầu rằng họ có thể bị đuổi việc sau giờ nghỉ. Cuộc phỏng vấn ngắn trước bài kiểm tra cũng có nghĩa là họ không xuất hiện để làm bài kiểm tra giúp họ thực hành phỏng vấn và cũng có thể cho phép họ quyết định rằng họ không phù hợp. Nếu có các lập trình viên khác quan sát bài kiểm tra hoặc hỗ trợ ứng viên trong suốt quá trình đó thì điều đó cũng cho họ cơ hội vượt qua / thất bại ứng viên trong khi họ đang nghỉ ngơi ngắn.

Tại mọi thời điểm khi bạn đang phỏng vấn thực tập và ứng viên là sinh viên, bạn phải nhớ rằng họ vẫn là sinh viên và có thể không thực hành nhiều với các cuộc phỏng vấn (dẫn đến lo lắng về hiệu suất có thể) và cũng có thể không đạt được điểm trong nghiên cứu của họ thậm chí có thể trả lời các câu hỏi có nghĩa là có thể nên gửi chúng theo cách của họ với một bản sao của "giải pháp lý tưởng" cho các vấn đề họ đưa ra.

Mục tiêu của tôi cho bất kỳ cuộc phỏng vấn việc làm nào, cho dù tôi ở bên nào, là kết thúc như tôi đang nói chuyện với một đồng nghiệp. Các đồng nghiệp đến văn phòng của tôi mọi lúc khi họ gặp vấn đề. Tôi nhờ các đồng nghiệp giúp đỡ khi tôi gặp khó khăn. Vì vậy, trong một cuộc phỏng vấn, tôi cố gắng tái tạo sự năng động đó.

Nói cách khác, bạn sẽ nói gì nếu một đồng nghiệp cần thực hiện một chuỗi Wikipedia và không biết đó là gì? Bạn sẽ giải thích cho họ cho đến khi họ nắm bắt được nó đủ để tiếp tục một mình. Không có sự xấu hổ trong sự thiếu hiểu biết miễn là nó không vĩnh viễn.

Nếu bạn trải qua bài tập đó mà vẫn không thể tưởng tượng mình đang làm việc với người đó, thì họ không phù hợp với công việc.

Điểm của việc đưa ra các câu hỏi như thế này trong một cuộc phỏng vấn là để xác định xem ai đó có thể tìm ra cách giải quyết vấn đề hay không. Công việc trở thành một lập trình viên thường bao gồm hai điều: "Lấy các yêu cầu này và thực hiện chúng theo mã" và "tìm hiểu tại sao việc triển khai không phù hợp với yêu cầu và khắc phục nó." Vì vậy, những gì bạn thực sự tìm kiếm không phải là một giải pháp cho những câu hỏi cụ thể này, mà là khả năng tìm ra mọi thứ.

Hiểu được điều này, tôi sẽ đưa ra một hoặc hai gợi ý để bắt đầu một ai đó, và có thể một số điều nữa nếu rõ ràng rằng họ đang tiến bộ thực sự nhưng thiếu một chi tiết ở đâu đó. Nhưng nếu nó trở nên rõ ràng rằng họ không thể tìm ra cách giải quyết vấn đề, thì bạn đã có câu trả lời của mình và không cần phải tiếp tục với bài tập.

Để đưa ra một ví dụ, khi tôi phỏng vấn tại công việc hiện tại của mình, tôi đã được hỏi một câu hỏi về việc tìm đường đi ngắn nhất từ ​​nút này sang nút khác trên biểu đồ. Tôi đã trả lời rằng tôi có thể sử dụng một cái gì đó như Thuật toán Dijkstra, mà tôi nhớ một cách mơ hồ đã học về một ngày ở trường đại học và chưa bao giờ sử dụng, và đã đưa ra một lời giải thích nhanh chóng (và không chính xác) về nó thỏa mãn các điều kiện cụ thể được đưa ra bởi câu hỏi Người phỏng vấn chỉ ra rằng giải pháp của tôi sẽ kết thúc trong một vòng lặp vô hạn nếu đồ thị được sửa đổi một chút và điều đó làm bộ nhớ của tôi bị hỏng, vì vậy tôi đã giải thích đúng cách để tránh vấn đề này. Và tôi đã kết thúc công việc.

Đối với vị trí thực tập, bạn có thể yêu cầu một chút.

Tôi không biết bạn thậm chí có ý gì với câu hỏi thứ 4. đối với việc đặt câu hỏi đệ quy, hơi không thực tế, hãy xem qua cơ sở mã của riêng bạn và xác định số lần đệ quy được sử dụng, tôi sẵn sàng đặt cược rằng không có gì. Các tình huống phỏng vấn rất căng thẳng và mong muốn các ứng viên thực hiện các chiến lược hiếm khi được sử dụng ngược so với hầu hết mọi thứ mà bạn từng lập trình là không công bằng với họ, đặc biệt là khi bắt đầu một cuộc phỏng vấn. Cá nhân tôi sẽ đặt câu hỏi trong đó họ phải giải thích những khái niệm quan trọng có nghĩa là gì / chúng được sử dụng như thế nào, cung cấp các ví dụ đóng hộp. Tôi sẽ quan tâm nhiều hơn đến các ứng viên có thể cho bạn biết cuốn sách X hoặc tìm kiếm Google Y sẽ cung cấp mọi thứ cần thiết để triển khai một cái gì đó cho cơ sở mã của bạn.

IMHO hai câu hỏi đầu tiên của bạn nên được giải quyết cho bất cứ ai gọi anh ấy / cô ấy là lập trình viên, có thể là học sinh cuối cấp hoặc cấp ba, ra khỏi trường hoặc tự học.

Nếu tôi thấy rằng người phỏng vấn đang vật lộn với một trong hai điều này, tôi sẽ cố gắng viết lại vấn đề và kiểm tra xem liệu anh ta có hiểu hết về nó không. Sau đó khuyến khích cô ấy sử dụng bút và giấy, bảng trắng, vẽ hình hoặc bất kỳ phương pháp nào cô ấy thích để giải quyết vấn đề. Tôi cũng yêu cầu cô ấy suy nghĩ nhiều, để có cái nhìn về quá trình suy nghĩ của cô ấy và nếu cần, đưa ra gợi ý nhỏ nếu cô ấy đi đúng hướng chỉ không dám tiến lên, hoặc có một số trở ngại. Nhưng nếu thậm chí một số gợi ý không giúp được gì, hoặc - như bạn đã đề cập ở trên - tôi sẽ giải quyết vấn đề cho cô ấy, có lẽ tôi sẽ kết thúc cuộc phỏng vấn để ngừng lãng phí thời gian hơn. Trong một cuộc phỏng vấn, tôi luôn cố gắng để xem và tập trung vào những gì ứng viên biết, thay vì những gì cô ấy không biết, nhưng nếu tôi dường như không thể tìm thấy bất kỳ kiến ​​thức quan trọng nào, tôi sẽ bỏ cuộc sau một thời gian.

Cái thứ 3 và thứ 4 có phần khó khăn hơn, vì vậy tôi có thể chấp nhận nếu một thiếu niên không thể có được chúng, nếu anh ấy thể hiện một cách tiếp cận giải quyết vấn đề tốt và sự nhiệt tình. Nhưng đối với một cấp cao, họ vẫn là phải.

Tôi đã phải tìm kiếm những gì bạn có nghĩa là "FizzBuzz"; Hóa ra tôi đã nghe nói về trò chơi và các quy tắc của nó nhưng không phải bởi cái tên đó và không phải trong một thời gian. Vì vậy, đừng nghĩ rằng bạn không phải cung cấp BẤT K information thông tin nào cho người được phỏng vấn.

Điều đó nói rằng, đây là tất cả các vấn đề mã hóa cơ bản mà tôi mong đợi ai đó phỏng vấn cho ngay cả một vị trí mã hóa cấp nhập cảnh để có thể suy nghĩ theo cách của họ, nếu họ không thể mã hóa câu trả lời bằng cách kiểm tra. Vì vậy, chúng tôi trên cùng một trang ở đó. Câu trả lời cho vấn đề của bạn phụ thuộc vào cách họ hiểu sai:

• Các vấn đề cú pháp nhỏ: Nếu bạn đang mong đợi mã bằng một ngôn ngữ nhất định, đừng bỏ qua quá nhiều nếu họ bỏ lỡ dấu chấm phẩy hoặc sai chính tả một lần sử dụng một số định danh. Hầu hết các IDE sẽ nắm bắt được điều đó ngay lập tức và mọi người đều mắc lỗi chính tả theo thời gian. Trong hầu hết mọi cuộc phỏng vấn mà tôi dự kiến ​​sẽ viết mã gì đó, "pseudo-C-ish" được chấp nhận miễn là thuật toán được truyền đạt đúng cho người phỏng vấn và logic là âm thanh.

• Lỗi logic nhỏ: Nếu thuật toán sẽ hoạt động như mong đợi trong hầu hết, nhưng không phải tất cả, trong các kịch bản dự kiến ​​(giả sử khi mã hóa FizzBuzz, 15 sẽ chỉ dẫn đến "Fizz" hoặc "Buzz" chứ không phải cả hai như nó dự định), sau đó là "người kiểm tra đơn vị" và chỉ ra rằng thuật toán sẽ thất bại trong trường hợp đó và xem liệu họ có thể sửa nó không. Họ có thể đã bỏ qua trường hợp cụ thể đó, hoặc họ có thể không hiểu các yêu cầu hoàn toàn đủ. Cả hai một lần nữa hoàn toàn dễ hiểu, sự xuất hiện hàng ngày trong mã hóa, cần được khắc phục dễ dàng bằng cách đơn giản cung cấp thông tin bổ sung hoặc phản hồi.

• Lỗi logic lớn: Nếu thuật toán sẽ không vượt qua hầu hết hoặc bất kỳ kịch bản thử nghiệm nào được đưa ra, hãy chỉ ra điều đó và xem liệu họ có thể sửa nó không. Đây là một vấn đề nhiều hơn; hoặc họ đã hiểu nhầm một số yêu cầu rất cơ bản của hệ thống, hoặc họ đã bỏ qua một số lỗ hổng logic. Nhưng, nếu họ có thể khắc phục nó, đưa ra chi tiết hơn về vấn đề, mà không được thông báo chính xác nơi mã của họ bị lỗi, hãy giải quyết nó theo yêu cầu không rõ ràng và tiếp tục.

• Không biết bắt đầu từ đâu / câu trả lời được mã hóa cứng cho các trường hợp cụ thể / không thể hiểu mã giả của chúng: Đây là những lá cờ đỏ. Nếu bạn yêu cầu ai đó viết mã thuật toán tuân theo các quy tắc FizzBuzz, giải thích các quy tắc đó cho họ và bạn sẽ có một cái nhìn trống rỗng, cuộc phỏng vấn đã kết thúc. Tương tự như vậy, nếu họ có thể đặt SOMETHING lên bảng nhưng nó thất bại ở những phần lớn của không gian vấn đề và bạn phải nắm tay họ khi minh họa lỗi và cách khắc phục, tôi sẽ không tiến hành một cuộc phỏng vấn thứ hai .

Nếu bạn thực sự có một thực tập sinh tiềm năng hoạt động như một con nai trong ánh đèn pha vì anh ta chưa bao giờ được phỏng vấn, có vấn đề lo lắng, chưa bao giờ ở trong một tình huống thực tế như thế (bạn thường chú ý từ ngôn ngữ cơ thể của họ), bạn có thể bắt đầu bằng hỏi họ những gì họ đã làm việc cuối cùng.

Sau đó, nó sẽ là lãnh thổ của anh ấy để anh ấy có thể không lo lắng điên cuồng. Khi bạn tìm thấy một nơi thích hợp, hãy hỏi, "Này, bạn đã thực hiện điều đó như thế nào?". Nếu anh ta có thể giải thích, nó có thể cung cấp cho bạn một cái nhìn sâu sắc về cách suy nghĩ của anh ta.

Đặt các bài kiểm tra của riêng bạn vào chương trình nghị sự sau đó.

Fizzbuzz là một yêu cầu tuyệt đối. Nếu họ không thể mã Fizzbuzz, bạn không nên thuê họ.

Tôi thường yêu cầu ứng viên cho một phiên mã trước khi phỏng vấn, nơi chúng tôi sử dụng Google Docs để giải quyết vấn đề lập trình (điển hình là Fizzbuzz + một vấn đề cấp cao hơn nếu họ có thể dễ dàng hoàn thành Fizzbuzz).

Tôi thường dùng điện thoại hoặc trên skype với họ trong thời gian này và vì tôi đang xem họ hoàn thành vấn đề (và nói với họ về những gì họ nghĩ ở một số điểm nhất định), tôi có thể tin tưởng một cách hợp lý rằng họ đã không ' t chỉ cần google câu trả lời.

Miễn là các vấn đề khác của bạn được chỉ định rõ (nghĩa là bạn cung cấp cho họ công thức cho từng vấn đề), thì câu hỏi của bạn sẽ ổn.

Khi tôi phỏng vấn ứng viên, tôi cố gắng bám sát các vấn đề lập trình mà họ có thể gặp phải. Tôi thích các vấn đề thao tác chuỗi bởi vì khi bạn ở trên web, mọi thứ người dùng phải đối mặt đều phải thực hiện với một số thao tác chuỗi. Làm thế nào họ xử lý đó là quan trọng.

Nó phụ thuộc vào tầm cỡ của vị trí bạn đang cố gắng lấp đầy.

Nếu bạn đang đi cho một nhà phát triển cao cấp, thì tôi sẽ mong họ biết tất cả những điều đó. Nếu họ hiểu sai và tôi cảm thấy xấu xa, tôi sẽ dừng cuộc phỏng vấn, cảm ơn và tạm biệt. Nếu tôi có tâm trạng lịch sự hơn, tôi sẽ chỉ cảm ơn họ và vội vàng trong suốt phần còn lại của cuộc phỏng vấn.

Nếu tôi đang đi cho một nhà phát triển cơ sở, thì những câu hỏi đó có thể được coi là khá khó khăn. Tôi sẽ thích thú hơn khi khám phá khả năng và sự sẵn sàng học hỏi của họ. Vì vậy, tôi sẽ thử đưa ra gợi ý cho họ và hướng dẫn họ cùng xem họ trả lời như thế nào.

Phỏng vấn thực tập là một giống khác nhau của cuộc phỏng vấn. Những gì tôi thường làm là sử dụng các câu hỏi dành cho nhà phát triển tiêu chuẩn của mình (như những câu hỏi bạn đã cung cấp) để đánh giá xem họ đang ở đâu trong giáo dục của họ. Khả năng giải quyết những vấn đề này sẽ thay đổi rất nhiều từ sinh viên năm hai đến người cao niên.

Sau khi tôi có thông tin đó, sau đó tôi tập trung vào cuộc phỏng vấn về các kỹ năng khác, chẳng hạn như họ có thể làm việc theo nhóm không, họ có thể dạy được không, họ có được hưởng lợi từ việc thực tập tại công ty chúng tôi không, họ có đam mê phát triển / học hỏi không, v.v.

Đối với tôi, đó là những thứ phi kỹ thuật thực sự khiến một thực tập viên khác biệt so với các ứng cử viên khác. Tôi thà dành vài tháng để huấn luyện / tư vấn cho ai đó được thúc đẩy để học hỏi và phát triển, hơn là một người chỉ muốn có một công việc cho học kỳ.

Hãy tự hỏi giá trị của người được phỏng vấn có khả năng thêm vào công ty của bạn. Yếu tố chi phí để có một người cố vấn tham gia, đặc biệt là nếu họ không thể giải quyết vấn đề ở cấp độ fizzbuzz. Nếu câu trả lời không tương xứng với mức lương dự định, thì bạn có một trường hợp kinh tế tốt là không thuê họ.

Đừng ngại quay lại với người quản lý của bạn và nói rằng "không có ứng cử viên nào sẽ bổ sung đủ giá trị cho công ty chúng tôi để làm cho họ thuê đáng giá". Đây phải là một hành động tốt hơn so với kết thúc với một người thực sự có giá trị tiêu cực, bởi vì chi phí để có ai đó liên tục giúp đỡ họ.

Câu trả lời của tôi có vẻ hơi không tốt hoặc bác bỏ, nhưng tôi nghĩ rằng nó hoạt động tốt. Để bắt đầu, tôi đưa ra cho ứng viên một câu hỏi rất dễ, đây là câu hỏi khởi động để giúp xây dựng sự tự tin của họ. Cho dù họ có thành công hay không, tôi chuyển sang một câu hỏi ít tầm thường hơn và liên quan trực tiếp đến những gì công việc đòi hỏi.

Tại thời điểm này, đó là tất cả hoặc không có gì. Nếu họ đi qua nó, thật tuyệt, không vấn đề gì. Nếu họ đấu tranh một chút, không có thăm dò, tôi sẽ giúp họ tiếp tục và sau đó chuyển sang các câu hỏi khác để đoán các khả năng khác.

Tuy nhiên, nếu họ hoàn toàn thiếu khả năng giải quyết nó, tôi sẽ tiếp tục và đốt cháy phần còn lại của thời gian phỏng vấn để giúp họ làm theo. Ứng viên vẫn cảm thấy tham gia vào cuộc phỏng vấn, nhưng tôi không phải điều khiển cuộc phỏng vấn theo những hướng khác nhau, không liên quan. Điều đó cũng tốt cho ứng viên, vì nó có thể mang tính giáo dục.

1. Hãy cố gắng trở nên tốt đẹp với họ. Bằng câu hỏi của bạn, người ta thấy rằng bạn không cố gắng trở nên tốt đẹp ngay cả ở đây. Bạn có nghĩ rằng mọi người nên biết thuật ngữ "fizzbuzz" này không? Hoặc chúng ta nên tìm kiếm trên mạng vì bạn lười viết nó? Ngược lại, tôi nghĩ, mọi người ở đây đều biết tam giác vuông là gì.
2. "Danh sách cấu trúc" là gì? Tôi không biết. Tôi biết "cấu trúc danh sách". Nó có nghĩa là gì: Danh sách cho số nguyên? Danh sách các số nguyên bạn có nghĩa là gì? Tôi cũng vậy, sẽ không biết bắt đầu như thế nào. Và làm ơn, đừng nói bạn không phải người Anh. Tôi cũng vậy. Và thậm chí tôi chưa từng đến một quốc gia nói tiếng Anh. Bạn chắc chắn biết rằng số nguyên ở số nhiều sẽ là số nguyên s . Nếu bạn không cố gắng để có thể hiểu được bằng số của bạn ở đây, tôi có thể tưởng tượng bạn đang làm gì ở đó .
3. Bất kỳ lập trình viên biết chữ nào cũng biết rằng hàng Fibonacci là một ví dụ về cuốn sách về những điều không nên làm bằng cách đệ quy. Bạn đang kiểm tra chúng về khả năng chống lại bạn hay cho các kỹ năng mã hóa? Làm công việc của bạn và tìm một ví dụ tốt hơn cho các kỹ năng kiểm tra trong việc sử dụng đệ quy.
4. "Khả năng làm việc dưới áp lực" đối với một lập trình viên có nghĩa là anh ta có thể làm việc vào ban đêm khi cần thiết. Nhưng nếu bạn muốn có những lập trình viên giỏi, họ sẽ chờ đợi rằng trưởng của họ là một người rất tốt bụng, hiểu biết và hữu ích. Nếu bạn không, bạn sẽ không bao giờ có lập trình viên tốt. Họ không phải là những con chuột alpha. Nếu họ sẽ cảm thấy bất kỳ sự căng thẳng nào, họ sẽ đơn giản đóng vỏ và không làm gì cả.

Vì vậy, câu trả lời của tôi là: hãy chuẩn bị tốt hơn.

PS Bạn đã là một người quản lý, vì vậy, bạn thực sự nên giữ căng thẳng.