Tôi có nên lo lắng về việc áp đảo các bài tập lập trình được đưa ra trong quá trình phỏng vấn không? [đóng cửa]

Gần đây tôi đã có một cuộc phỏng vấn qua điện thoại với một công ty. Sau cuộc phỏng vấn qua điện thoại đó, tôi được yêu cầu hoàn thành một bài tập lập trình ngắn (một chương trình nhỏ; không nên mất hơn ba giờ). Tôi chỉ được hướng dẫn trực tiếp để hoàn thành bài tập và bật mã. Tôi đã được tự do hoàn toàn để sử dụng bất kỳ ngôn ngữ nào tôi muốn và không được cho biết chính xác làm thế nào để bật mã.

Ngay lập tức tôi đã lên kế hoạch ném nó lên Github, viết một bộ thử nghiệm cho nó, sử dụng Travis-CI (tích hợp liên tục miễn phí cho các kho lưu trữ Github công cộng) để chạy các bộ thử nghiệm và sử dụng CMake để xây dựng các tệp tạo tệp Linux cho Travis-CI. Bằng cách đó, tôi không chỉ có thể chứng minh rằng tôi hiểu cách sử dụng Git, CMake, Travis-CI và cách viết bài kiểm tra, mà tôi còn có thể liên kết đơn giản đến trang Travis-CI để họ có thể thấy đầu ra của các bài kiểm tra. Tôi đoán rằng sẽ làm cho nó một chút thuận tiện hơn cho người phỏng vấn.

Vì tôi biết rõ những công nghệ đó, nên về cơ bản nó sẽ không có thời gian để chuyển nhượng.

Tuy nhiên, tôi hơi lo lắng rằng làm tất cả điều này cho một nhiệm vụ tương đối đơn giản sẽ trông tệ. Mặc dù nó sẽ không thêm nhiều thời gian hơn cho tôi, tôi không muốn họ nghĩ rằng tôi dành quá nhiều thời gian cho những thứ đơn giản.

Là một người phỏng vấn, tôi sẽ rất vui khi thấy kiến ​​thức về quá trình phát triển phần mềm được thể hiện bằng phương pháp này; trái ngược với việc chỉ viết mã.

Đặc biệt, có một bộ kiểm tra cho các vấn đề thậm chí rất đơn giản sẽ là một dấu hiệu tốt (thậm chí mức FizzBuzz). Tôi đã thấy các ứng cử viên gửi giải pháp thậm chí không giải quyết được vấn đề và một bộ thử nghiệm đơn giản sẽ cho họ thấy điều này. Ngoài ra, có lịch sử cam kết cho phép tôi có được ý tưởng về quá trình suy nghĩ mà ứng viên đã sử dụng để đi đến giải pháp.

Mặt khác, tôi đã biết mọi người bị một số công ty từ chối ở giai đoạn đầu của quá trình cho kỹ thuật quá mức. Tuy nhiên, trong hầu hết các trường hợp, điều này là do kỹ thuật quá mức của giải pháp không nhất thiết là các quy trình được sử dụng.

Là một người được phỏng vấn, một người hiểu những thứ như kiểm soát phiên bản, CI, kiểm tra đơn vị và những thứ tương tự sẽ là một bước tiến lên trên những gì tôi thường thấy.

Mặc dù, đối với tôi, điều quan trọng nhất là vấn đề đã được giải quyết và giải quyết tốt, biết rằng ứng viên hiểu cách để cải thiện chất lượng của sản phẩm có thể giao được của họ chắc chắn sẽ thu hút sự chú ý của tôi.

Những gì tôi thường thấy là những người không chỉ không hiểu vấn đề mà còn không hiểu cách giải quyết vấn đề - và họ sẽ bị bỏ qua cho dù họ có sử dụng bao nhiêu công cụ bổ sung trong quy trình.

Hãy nhớ rằng có một giới hạn thời gian về nó. Người phỏng vấn biết điều này, vì vậy điều này có nghĩa (nếu tôi là người phỏng vấn) anh ta sẽ thấy bạn không chỉ giải quyết vấn đề trong thời gian quy định, mà còn nhanh đến mức bạn còn thời gian để mạ vàng, đó là một dấu hiệu tốt của bạn khả năng giải quyết vấn đề cũng như sự đánh giá cao của bạn về sự nghiêm túc và siêng năng.

Quá kỹ thuật là một từ tồi tệ khi bạn đang tạo AbstractFactoryManagerAdaptors được cắm vào để phát BuzzManager và FizzManager chỉ để giải quyết FizzBuzz.

Những gì bạn đang làm là siêng năng quá mức, thậm chí không phải là một điều (mặc dù sự siêng năng chắc chắn là).

Điều đó nói rằng, nếu bạn kết thúc theo thời gian hoặc với một số giải pháp bị tấn công một nửa bởi vì bạn đã sử dụng thời gian của mình cho các tính năng bổ sung mà bạn cho là "không thêm chút thời gian nào", điều này sẽ có vẻ như bạn hiểu rất kém về việc nó trông nhỏ đến mức nào nhiệm vụ có thể được. Đây có thể là một thuộc tính nguy hiểm trong một kỹ sư và quá phổ biến giữa các đàn em. Ưu tiên thích hợp và thực hiện các công cụ tín dụng bổ sung chỉ sau khi hoàn thành giải pháp cần thiết .

Một quan điểm khác để xem xét là cách tiếp cận của bạn không tốt cũng không xấu. Tôi có thể tưởng tượng những người phỏng vấn sẽ xem xét nó quá nhiều và tôi có thể tưởng tượng những người phỏng vấn sẽ yêu thích kỹ thuật hơn nữa.

Đừng lo lắng quá. Thay vào đó, hãy giải quyết vấn đề theo cách bạn cho là tốt nhất và bạn có thể sẽ nhận được lời mời làm việc từ những người đồng ý với bạn. Đó là bước đầu tiên tuyệt vời đối với môi trường làm việc hiệu quả. Hãy nhớ rằng, các cuộc phỏng vấn đi hai cách. Phản hồi của người phỏng vấn về giải pháp của bạn cũng sẽ cho bạn biết rất nhiều về họ. Bạn có thực sự muốn làm việc với những người tin rằng bản năng phát triển và triết lý của bạn là sai?

Trong thực tế, không ai quan tâm liệu ứng cử viên có thể đánh một git repo hoặc tạo ra các makefile vội vàng không, bởi vì đó chỉ là nhớ lại những gì anh ta hoặc cô ta đã học được bằng cách học vẹt. Đây là những kỹ năng phụ cho khía cạnh giải quyết vấn đề và thiết kế thực tế của câu hỏi phỏng vấn.

Vì vậy, có, trực giác của bạn phát hiện ra rằng nó có khả năng trông tệ, bởi vì nó có thể trông như thể ứng viên tin rằng ai đó có thể lấy lại một vài lệnh và mô hình ghi nhớ để tạo ra bộ xương dự án có kỹ năng phần mềm ấn tượng.

Các khía cạnh bộ thử nghiệm của giải pháp là tốt mặc dù. Cung cấp một câu trả lời với một bộ kiểm tra hồi quy có thể sẽ kiếm được điểm của bạn. Tất cả nhiều hơn như vậy nếu bộ kiểm tra của bạn thực hiện các trường hợp nổi bật trong mã. Bộ thử nghiệm không cần phải có nhiều bẫy chính thức và dựa vào các công cụ; thực tế là bằng cách nào đó bạn có một cái trong đó là đủ tốt cho một cuộc phỏng vấn. Rõ ràng là nếu bạn có thể kết hợp một số bài kiểm tra đơn vị ad hoc trong một bài kiểm tra phỏng vấn, bạn có thể làm điều đó với các công cụ trong một dự án thực tế.

Gần đây tôi đã có một cuộc phỏng vấn qua điện thoại với một công ty. Sau cuộc phỏng vấn qua điện thoại đó, tôi được yêu cầu hoàn thành một bài tập lập trình ngắn (một chương trình nhỏ; không nên mất hơn ba giờ).

Tôi sẽ tiến hành thận trọng. Đánh giá mức độ phù hợp của thách thức đối với công việc và chắc chắn việc hoàn trả trong tương lai từ nhà tuyển dụng sẽ khiến 3 giờ thời gian của bạn trở nên đáng giá.

Tôi đặt câu hỏi về giá trị trong các loại bài kiểm tra này, và thà đánh giá ai đó về những thành tích trong quá khứ của họ. Một nhiệm vụ ngắn được xác định trước không thể cho nhà tuyển dụng biết bất cứ điều gì về những gì bạn có thể làm. Chỉ những gì bạn không thể làm và điều đó có thể nhanh chóng được xác định bằng một vài câu hỏi qua điện thoại.

Kiểm tra không có chỗ của nó. Tự hỏi bản thân các câu hỏi sau đây về bài kiểm tra, và trả lời tương ứng.

1. Là hội chợ kiểm tra cho mức độ nghề nghiệp hiện tại của bạn?
2. Liệu bài kiểm tra có một câu trả lời đúng được xác định rõ ràng?
3. Người phỏng vấn có quan tâm đến tiềm năng của bạn như một người hay họ thể hiện sự quan tâm nhiều hơn đến kết quả kiểm tra (tức là các cơ quan tuyển dụng rất tệ cho việc này).
4. Bài kiểm tra có đại diện cho loại công việc bạn sẽ thích làm hay đó là một xác minh kỹ năng mơ hồ (nghĩa là kiểm tra nếu bạn biết cú pháp Java).

Tôi chỉ được hướng dẫn trực tiếp để hoàn thành bài tập và bật mã.

Bạn vừa trả lời câu hỏi của riêng bạn.

Ngay lập tức tôi đã lên kế hoạch ném nó lên Github, viết một bộ thử nghiệm cho nó, sử dụng Travis-CI (tích hợp liên tục miễn phí cho các kho lưu trữ Github công cộng) để chạy các bộ thử nghiệm và sử dụng CMake để xây dựng các tệp tạo tệp Linux cho Travis-CI.

Không, đó không phải là những gì họ yêu cầu bạn làm.

Bằng cách đó, tôi không chỉ có thể chứng minh rằng tôi hiểu cách sử dụng Git, CMake, Travis-CI và cách viết bài kiểm tra, mà tôi còn có thể liên kết đơn giản đến trang Travis-CI để họ có thể thấy đầu ra của các bài kiểm tra. Tôi đoán rằng sẽ làm cho nó một chút thuận tiện hơn cho người phỏng vấn.

Tôi sẽ cẩn thận thể hiện các kỹ năng quá sớm hoặc quá muộn trong quá trình phỏng vấn. Nếu bạn cảm thấy mình đã không làm tốt trong cuộc phỏng vấn và hiện đang cố gắng bù đắp thì nó sẽ không hoạt động. Mặt khác, làm quá nhiều khi không được hỏi quá thể hiện sự háo hức. Điều này có thể dẫn đến việc nhà tuyển dụng phản đối với một đề nghị lương thấp hơn mà bạn đang mong đợi.

Tuy nhiên, tôi hơi lo lắng rằng làm tất cả điều này cho một nhiệm vụ tương đối đơn giản sẽ trông tệ.

Vâng, nó có vẻ xấu. Việc giải quyết thách thức của họ bằng một dòng mã sẽ ấn tượng hơn nhiều so với một dự án hoàn chỉnh.

Theo kinh nghiệm của tôi, đây không phải là cách bạn giành chiến thắng trong cuộc phỏng vấn xin việc, mà đó là một cách để mất việc. Kiểm tra mã là một vấn đề kiểm soát chất lượng. Mọi công ty sử dụng kiểm tra mã khi tuyển người đều làm như vậy, vì trước đây họ không sử dụng kiểm tra mã. Họ đã có một trải nghiệm tồi tệ về việc ai đó trượt qua các vết nứt của quá trình phỏng vấn không nên có.

Họ sẽ lấy mã nguồn của bạn và chuyển nó xung quanh văn phòng. Mọi người sẽ bình luận về nó, và điều bạn không muốn họ nói là "Anh ấy đã mắc lỗi này? Nhưng đã dành thời gian sử dụng Git, CMake và Travis-CI. Thật là một thằng ngốc vì đã bỏ lỡ sai lầm này."

Đó là nó. Bạn đã mất.

Họ muốn biết bạn có thể viết mã, vì họ không thể dạy bạn điều đó. Git, CMake và Travis-CI có thể dễ dàng được dạy.

Tôi nghĩ rằng cách tiếp cận của bạn là không tốt cũng không xấu cho mỗi gia nhập . Tôi sẽ hỏi người phỏng vấn xem có ổn không khi sử dụng Github và các công cụ khác. Như @Izkata đã chỉ ra trong các bình luận, bạn đang công khai giải pháp của mình.

Là một người phỏng vấn, tôi biết thường không có hại gì trong việc ứng viên cố gắng làm rõ một vài điều. Ngoài ra, hỏi một hoặc hai câu hỏi có thể là một dấu hiệu tốt, vì bạn không vội vàng làm những việc mà bạn không hiểu.

Tuy nhiên, hãy nhớ rằng điều quan trọng nhất là vấn đề được giải quyết, và giải quyết tốt. Về vấn đề đó, mọi người đều đồng ý rằng một bộ thử nghiệm sẽ giúp. Nhưng, để làm điều đó, có lẽ bạn chỉ cần gửi một vài lớp kiểm tra cùng với dự án / giải pháp của bạn.