Tôi nên giúp đỡ bao nhiêu trong các cuộc phỏng vấn kỹ thuật? [đóng cửa]

Tôi được yêu cầu thực hiện hoặc ngồi trong nhiều cuộc phỏng vấn kỹ thuật. Chúng tôi đặt câu hỏi logic và các vấn đề lập trình đơn giản mà người được phỏng vấn dự kiến ​​sẽ có thể giải quyết trên giấy. . họ không có ý định là những câu hỏi mẹo).

Tôi chưa bao giờ nghe ông chủ của tôi đưa ra bất kỳ trợ giúp hoặc gợi ý. Anh ta chỉ cảm ơn người được phỏng vấn về câu trả lời (bất kể nó tốt hay xấu) và chuyển sang câu hỏi hoặc vấn đề tiếp theo. Nhưng tôi biết điều gì đó về lỗ thỏ đánh bại và dây thần kinh có thể dẫn bạn xuống, và làm thế nào nó vô hiệu hóa tâm trí của bạn, và tôi không thể tự hỏi nếu bây giờ cung cấp một chút trợ giúp và cuối cùng sẽ giúp chúng tôi kết thúc với các lập trình viên có khả năng hơn của nhiều cuộc phỏng vấn thất bại.

Tôi có nên cung cấp gợi ý và trợ giúp cho những người được phỏng vấn không (và nếu vậy, tôi nên đi bao xa trong khi vẫn công bằng với các ứng viên chuẩn bị kỹ lưỡng hơn)?

Khi tôi ở một vị trí tương tự, tôi sẽ nói với người được phỏng vấn: "Giả vờ tôi là Google. Nếu bạn cần tìm kiếm thứ gì đó chỉ cần nói như vậy."

Trong một câu hỏi người được phỏng vấn cần có thể tìm ra thể tích của một hình trụ, vì vậy tôi không phiền nếu ai đó nói, "Tôi phải Google cho công thức tính thể tích của một hình trụ." Tôi muốn biết liệu họ có biết cách tấn công vấn đề không, nếu họ ghi nhớ các công thức. Đối với công việc, họ phải có một nắm bắt tốt về cách dịch thế giới thực sang phần mềm, vì vậy đó là một khái niệm quan trọng.

Mặt khác, tôi sẽ không nói với họ rằng họ cần công thức đó.

Bạn đúng là dây thần kinh có thể là một vấn đề, nhưng tôi vẫn mong mọi người có thể thể hiện quá trình suy nghĩ của họ, ngay cả khi họ lo lắng. Đơn giản là không đưa ra một câu trả lời là không thể chấp nhận được.

Bạn có hai cách tiếp cận để giải quyết vấn đề và câu hỏi kỹ thuật ngắn:

1. Cái đầu tiên được sếp của bạn sử dụng: không cung cấp bất kỳ trợ giúp nào để kiểm tra cách người đó cư xử trong bối cảnh căng thẳng. Đó là một cách tiếp cận hoàn toàn hợp lệ, và có thể đưa ra một số gợi ý về người đó. Rốt cuộc, một khi bạn thuê người này, cô ấy sẽ không thể nhận được sự giúp đỡ liên tục từ tất cả các đồng nghiệp của mình.

2. Thứ hai là cung cấp gợi ý và hỗ trợ. Mức độ hỗ trợ không quá quan trọng; Điều duy nhất quan trọng là bạn càng giúp đỡ nhiều hơn cho người đó, bạn càng ít coi trọng thành công của cô ấy.

Cá nhân, tôi tin rằng bạn nên dành đủ thời gian để cả hai chắc chắn rằng người đó không thể tự mình giải quyết vấn đề và khiến người đó cảm thấy rằng cô ấy không thể giải quyết nó nếu không có sự giúp đỡ. Nhưng sau đó, bạn có thể cung cấp trợ giúp tiến bộ cho đến khi bạn nói với người đó câu trả lời.

Thí dụ:

- Bạn có thể cho tôi biết làm thế nào để bạn tạo các thuộc tính chỉ đọc trong C #, tức là các thuộc tính có giá trị chỉ có thể được khởi tạo trong một hàm tạo và không thể thay đổi sau này không?
- Tất nhiên. Tôi chỉ sử dụng từ khóa readonly.
- Bạn có chắc không? Bạn có thể giải thích cho tôi sự khác biệt giữa một tài sản và một lĩnh vực?
- Hừm. Một tài sản là ... bạn thấy ... nhận và thiết lập ...
- Ok. Vì vậy, một trường là một biến được khai báo bên trong một lớp hoặc một cấu trúc và hợp lệ trong phạm vi lớp / cấu trúc, trong khi một thuộc tính giống như một trường, nhưng cũng cung cấp một cơ chế để đọc, viết hoặc tính toán một giá trị. Bây giờ thì readonlysao? Được sử dụng với tài sản?
- Tôi tin rằng nó chỉ được sử dụng cho các lĩnh vực ...
- Phải. Vậy những gì về tài sản?
- Chúng không thể được đọc mà thôi.
- Bạn có chắc không? Điều gì về các thuộc tính chỉ có getters?
- Chúng chỉ được đọc.
- Điều đó có nghĩa là giá trị của chúng sẽ luôn giữ nguyên?
- Đúng.
- Không thật sự lắm. Việc bạn có một thuộc tính với getter không có nghĩa là giá trị của nó không thay đổi trong suốt vòng đời của thể hiện của lớp. Nếu getter đề cập đến một trường được tăng lên mỗi khi bạn truy cập vào thuộc tính, giá trị được trả về sẽ liên tục tăng.
- Đúng.
- Vì thế? Bạn có ý tưởng về cách bạn có thể thực hiện một tài sản với giá trị không bao giờ thay đổi không?
- Không.
- Chà, bạn có thể sử dụng trường sao lưu chỉ đọc. Bạn có biết một lĩnh vực sao lưu là gì?
[...]

Đưa ra câu trả lời là một ý tưởng tốt trong mọi trường hợp. Có một vài trường hợp khi người được phỏng vấn nhận xét câu trả lời của tôi một cách thú vị, cho thấy ngay cả khi anh ta không thể trả lời câu hỏi ngay từ đầu, anh ta vẫn biết những điều liên quan.

Ngoài ra, bằng cách chỉ hỏi một câu hỏi mà không cần trợ giúp thêm, bạn sẽ không có quá nhiều thông tin về người đó, ngoài thực tế là cô ấy biết hoặc không biết câu trả lời . Cung cấp trợ giúp tiến bộ có thể cho phép bạn xem người đó đang nghĩ về một vấn đề như thế nào .

Nó cũng có thể hiển thị những thứ khác mà người đó không biết. Lấy ví dụ ở trên: nếu tôi dừng lại ở câu trả lời đầu tiên, tôi sẽ không biết rằng người đó không thể giải thích sự khác biệt giữa trường và tài sản hoặc cô ấy không biết trường sao lưu là gì.

Nếu người trả lời ngay lập tức, nó ổn. Nếu cô ấy cần sự giúp đỡ, không có gì sai với điều này. Nếu bạn tự trả lời câu hỏi, đó là một dấu hiệu xấu và hy vọng người được phỏng vấn sẽ có thể trả lời những câu hỏi khác.

Tôi luôn muốn giúp đỡ những người được phỏng vấn nếu họ bị mắc kẹt trong một số điều đơn giản (như tên của một mẫu cụ thể nếu họ rõ ràng biết nó là gì) và để họ che đậy những thứ như chi tiết thiết lập kết nối cơ sở dữ liệu. Tuy nhiên, nếu họ đang cố gắng thiết kế một cái gì đó, tôi sẽ không nói nhiều vì tôi không muốn hướng dẫn họ hoặc vứt bỏ chúng nếu họ đang nghĩ về điều gì khác ngoài việc tôi đoán họ sẽ đi đâu.

Tôi nhớ đã được hỏi một câu hỏi giải quyết vấn đề cụ thể từ một người phỏng vấn, người có kết quả rất cụ thể trong đầu, nhưng anh ta không thể truyền đạt câu hỏi rõ ràng cho tôi. Điều này mô tả tình huống mà nhiều người được phỏng vấn gặp phải. Đôi khi, cái nhìn chằm chằm không phải vì người đó không phải là người giải quyết vấn đề tốt, mà bởi vì người đặt câu hỏi không rõ ràng trong những gì họ đang hỏi. Trong trường hợp đó, cách tiếp cận nói và không làm gì của đồng nghiệp của bạn chỉ chứng tỏ rằng ứng viên không nghĩ như đồng nghiệp của bạn, hoặc không ở trong đầu đồng nghiệp của bạn. Tôi nghĩ rằng việc cung cấp làm rõ câu hỏi bằng các từ khác nhau có thể cung cấp kết quả tốt hơn cho tất cả những người liên quan.

Cho rằng các lập trình viên (hầu hết chúng ta ít nhất) không làm việc trong môi trường chân không và các cuộc phỏng vấn đủ căng thẳng mà không có giới hạn nhân tạo, tôi có xu hướng cung cấp nhiều sự giúp đỡ như người được phỏng vấn yêu cầu hoặc cần.

Nhưng hãy tính đến tất cả khi đưa ra phán quyết cuối cùng về mức độ năng lực thực tế của người nộp đơn.

Một người đang tìm kiếm một vị trí cấp cao nhưng cần nhiều sự giúp đỡ sẽ gióng lên hồi chuông cảnh báo.

Đối với "người cao tuổi", tôi đưa ra những câu hỏi ngắn, kết thúc mở và chú ý nhiều hơn đến những câu hỏi họ hỏi hơn là câu trả lời. Tôi tìm những người cao cấp biết lắng nghe, giao tiếp, sử dụng lắng nghe tích cực, làm rõ, sau đó cung cấp giải pháp là loại tôi thích.

Đối với "kỹ sư đường dây", tôi đã sử dụng kỹ thuật này để kiểm tra lập trình trong đó bạn đưa cho ứng viên một máy tính và một vấn đề và vài giờ, sau đó bạn quay lại. Trong tình huống đó, chúng tôi đã hỏi người nộp đơn trước hệ điều hành và công cụ họ thích (cũng là một phần thú vị trong chuyên môn của lập trình viên). Khi họ đã hoàn thành, như một nhóm chúng tôi yêu cầu họ trình bày giải pháp và tại sao nó tốt hơn các giải pháp khác - đánh giá mã. Tất cả các kỹ năng tôi mong đợi từ một kỹ sư giàu kinh nghiệm vào ngày 1.

Điều quan trọng, toàn bộ nhóm phỏng vấn đã mất một buổi chiều để làm bài kiểm tra tương tự, vì vậy chúng tôi biết bài kiểm tra là công bằng. Chúng tôi đã dành một giờ để kiểm tra cách tiếp cận của mỗi người như với một người được phỏng vấn, điều này cho chúng tôi cảm giác về các cách tiếp cận khác nhau.

Kỹ thuật thứ hai này đã tìm cho chúng tôi một số lập trình viên "vô danh" tốt nhất (sơ yếu lý lịch tệ hại, kỹ năng phỏng vấn tệ hại) tôi từng tìm thấy.

Tôi thích bắt đầu các cuộc phỏng vấn với một câu hỏi dễ dàng xây dựng sự tự tin để giúp ứng viên thoải mái với quy trình. Khi điều này hoạt động, nó vẫn cho phép bạn thu thập càng nhiều thông tin càng tốt từ các câu hỏi sau này mà không tạo lợi thế cho các ứng viên hiểu ngôn ngữ cơ thể tốt hơn các tài liệu liên quan đến công việc.

Đôi khi cung cấp minor hintstrong cuộc phỏng vấn bằng miệng giúp xem ứng viên hiểu rõ chủ đề như thế nào. Tuy nhiên, cần có no hintscác bài kiểm tra tiêu chuẩn mà mỗi ứng viên được yêu cầu thực hiện.

Về cơ bản, có những two main thingsđiều bạn có thể muốn biết về ứng viên tiềm năng:

a) Đặc điểm cá nhân - anh ấy có phù hợp với công ty hoặc nhóm của bạn không

b) Kỹ năng kỹ thuật - anh ta có nền tảng kỹ thuật tốt và quan tâm đến việc chọn những thứ mới

Để tìm hiểu về những điểm được đề cập này, bạn phải lôi kéo ứng viên tiềm năng vào một cuộc trò chuyện. Điều quan trọng nữa là phải đảm bảo rằng ứng viên comfortable during the interviewcó được sự hiểu biết tối đa về các kỹ năng hiện tại của mình (cả mềm và công nghệ) cũng như tiềm năng của anh ta để thực hiện công việc.

Ngoài ra, kỹ năng giao tiếp của ứng viên tiềm năng cũng quan trọng như kỹ năng và năng lực kỹ thuật của anh ấy để giải quyết các vấn đề.

Một phần của những gì nên được xem xét là kỹ năng giao tiếp. Nếu ứng viên không rõ ràng về câu hỏi, anh ta nên đặt câu hỏi để làm rõ. Đây là một điều tốt, theo ý kiến ​​của tôi. Quá thường xuyên, các quyết định tồi được đưa ra bởi vì các giả định nhất định được đưa ra khi đọc thông số kỹ thuật hoặc, trong trường hợp này, xử lý một câu hỏi phỏng vấn. Ứng viên có thể trả lời dựa trên những giả định này và hoàn toàn bỏ lỡ điểm dự định. Câu hỏi có thể là thiếu sót, hoặc nó có thể là ứng cử viên. Trong cả hai trường hợp, cho phép làm rõ thông qua giao tiếp thể hiện một kỹ năng có giá trị, một kỹ năng mà nhà tuyển dụng nên tìm kiếm.

Tôi nghĩ rằng điều này cuối cùng xuất phát từ tính cách của bạn như một người phỏng vấn, và những gì bạn nghĩ là quan trọng và do đó thực sự chấm điểm cho ứng viên.

Cá nhân, tôi đánh giá khả năng thực tế / thực dụng hơn những chuyện vặt vãnh học thuật / bí truyền. Tôi quan tâm nhiều hơn đến một ứng cử viên có thể tham gia, làm việc và đóng góp hiệu quả theo một cách có giá trị nào đó cho bất kỳ dự án nào họ đang được thuê để làm việc hơn tôi về trí nhớ của họ về minutia tốt như thế nào.

Vì vậy, tôi sẽ huấn luyện một chút nếu ứng viên bị mắc kẹt vào một điều gì đó bí truyền, hoặc một sắc thái hiếm khi được sử dụng, hoặc một trường hợp cạnh có thể có liên quan trong một câu hỏi phỏng vấn trang điểm nhưng hiếm khi có liên quan trong cuộc sống thực. Đặc biệt là bất cứ điều gì họ có thể nhận được với một vài phút trên Google hoặc với một tài liệu tham khảo bàn tiện dụng hoặc "đặt nó và quên nó".

Tuy nhiên, tôi sẽ không huấn luyện họ về những thứ thực tế, phổ biến, chủ đạo, cơ bản, công việc hàng ngày. Đây là những điều tôi muốn được bẩm sinh với họ.

Tôi nghĩ rằng nó phụ thuộc vào tình hình phỏng vấn và các câu hỏi. Tôi đã sử dụng cả hai kỹ thuật.

Tại sao tôi có thể không muốn hỏi những câu hỏi tiếp theo? Khi tôi đang cố gắng tìm hiểu phản ứng của người đó đối với căng thẳng. Tôi đã phỏng vấn mọi người về một số công việc trong môi trường rất căng thẳng và họ có thể xử lý căng thẳng tốt như thế nào là một yếu tố quan trọng trong đánh giá của chúng tôi, vì vậy chúng tôi đã hỏi một số câu hỏi cực kỳ khó mà không ai có thể trả lời mà không bị căng thẳng.

Khi tôi đang cố gắng tìm hiểu kiến ​​thức kỹ thuật của họ, tôi hỏi những câu hỏi tiếp theo có thể chứa những gợi ý về những gì tôi đang tìm kiếm. Trái với suy nghĩ của người quản lý nói rằng bạn phải hỏi mọi người những câu hỏi tương tự để công bằng, tôi tin rằng điều này là công bằng miễn là một số điều kiện được đáp ứng. Đầu tiên mọi người được hỏi cùng một câu hỏi cơ bản. Thứ hai, bạn không nên đặt câu hỏi tiếp theo để chỉ giúp một người. Nếu bạn đã để người khác lúng túng mà không có sự giúp đỡ, bạn cần để cho tất cả những kẻ lập dị không có sự giúp đỡ. Thứ hai, bạn nên so sánh hiệu suất của ứng viên về câu hỏi, không chỉ về câu trả lời cuối cùng của họ mà còn về mức độ khó để kéo nó ra khỏi họ. Quá trình này vẫn đối xử công bằng với mọi người.

Phụ thuộc vào loại lập trình viên bạn muốn. Một người hướng nội có thể viết 20 dòng mã tuyệt vời trên giấy sẽ có vẻ tốt với sếp của bạn. Một nhà phát triển phần mềm có thể làm việc trên hàng triệu cơ sở mã dòng trong một nhóm để tạo ra phần mềm tốt một cách hiệu quả có thể sẽ không làm tốt lắm. Tôi thích những cuộc phỏng vấn như một ứng viên - họ nói với tôi rất nhiều về cách sếp đối xử với nhân viên của mình và văn hóa làm việc là gì. Trong một trường hợp như thế này, khi tôi rời cuộc phỏng vấn, tôi nói "Cảm ơn - Hãy tiết kiệm cho chúng tôi một chút thời gian, nếu không gọi cho tôi, tôi sẽ không gọi cho bạn." Khi được hỏi tại sao, tôi chỉ ra rằng tôi không muốn làm việc cho một công ty khiến tôi thất bại.

Bạn tiếp cận có khả năng nhận được các lựa chọn tốt hơn để phát triển phần mềm. Cách tiếp cận của ông chủ sẽ có tác dụng tốt đối với những người thu gom rác và những kẻ cầm kẹo mút Stop / Go tại các công trình đường bộ.

Phát triển phần mềm là một nỗ lực nhóm, không phải là một trò chơi độc lập / đọc / không tương tác. Có bao nhiêu dự án thất bại vì phần mềm làm những gì được yêu cầu, không phải những gì đã muốn.

Tôi gần đây đã ở trong một tình huống tương tự. Hướng tôi nhận được từ người quản lý và nhân sự của mình là chúng tôi cần phải hoàn toàn công bằng với tất cả 6 người được phỏng vấn, vì vậy tôi phải hỏi cùng một bộ câu hỏi kỹ thuật với sự giúp đỡ tối thiểu để xem mỗi người được phỏng vấn thực hiện như thế nào. Đôi khi khi họ biết câu trả lời nhưng bị mắc kẹt với một thuật ngữ kỹ thuật hoặc một cái gì đó tôi đã giúp họ gián tiếp với một số câu hỏi hướng dẫn họ đến thuật ngữ đó. Có một vòng phỏng vấn thứ hai sau vòng kỹ thuật về đặc điểm tính cách và hành vi nếu họ vượt qua được vòng đầu tiên.

Một phần của những gì bạn muốn ở một nhân viên là một người có thể tương tác với phần còn lại của nhóm. Bạn cần một người có kỹ năng cần thiết, đúng. Nhưng bạn cũng cần một người biết khi nào họ cần giúp đỡ và anh ta có kiến ​​thức và kỹ năng xã hội để làm điều đó. Bộ sill sau này sẽ được thiết lập sẽ xây dựng công ty tốt hơn về lâu dài hơn bất kỳ Du-jour ngôn ngữ máy tính cụ thể nào.

Theo cách tôi thấy, một cuộc phỏng vấn là một phiên làm việc thử nghiệm, không phải là một bài kiểm tra . Tôi chủ yếu cố gắng trả lời câu hỏi "cảm giác khi làm việc với người này là gì?" Đôi khi tôi thậm chí còn giả vờ rằng tôi đã quên câu trả lời cho câu hỏi, để làm cho bài tập cảm thấy hợp tác hơn.

Bạn đã bao giờ làm việc với một người mà bạn không thể vào cùng một trang với bất cứ khi nào bạn nói về một vấn đề chưa? Hoặc ai đó đã hỏi quá nhiều câu hỏi thay vì nhảy vào và giải quyết vấn đề? Trong một cuộc phỏng vấn tôi hầu như chắc chắn rằng người tôi đang nói chuyện không phải là một trong số họ. Có một yếu tố hóa học mạnh mẽ ở đó.

Trong quá trình tất nhiên tôi cũng sẽ học được những điều như, "cô ấy có viết mã sạch không", "cô ấy có quen thuộc với các khái niệm cần thiết không" và "cô ấy có thể khéo léo chọc một vấn đề để đi đến những hiểu biết không?" Ứng cử viên vẫn sẽ là người "lái xe" và viết mã. Nhưng trên đường đi, hy vọng cô ấy sẽ thoải mái hơn và tôi sẽ thấy một phiên bản của cô ấy gần với những gì tôi thực sự sẽ thấy hàng ngày như một đồng nghiệp.