Lập trình cho một cuộc phỏng vấn xin việc

Question

Công ty chúng tôi đã suy nghĩ về việc loại bỏ các thủ tục phỏng vấn của chúng tôi và đưa từng ứng cử viên ngồi trong vòng 4-5 giờ với một số lập trình viên và chỉ thực hiện một số chương trình ghép đôi.

Tôi thích ý tưởng về lý thuyết nhưng tôi không chắc chắn làm thế nào bạn thực sự có thể làm cho nó công bằng cho mỗi ứng cử viên. Bạn đánh giá họ như thế nào? Liệu đầu vào của họ có thực sự phụ thuộc vào những gì mỗi lập trình viên đang làm việc vào ngày đó không?

Bất kỳ ý tưởng nào về việc đây có phải là ý tưởng hay/ý tưởng tồi hay cách làm cho nó hoạt động là những gì tôi đang tìm kiếm ở đây.

Chúc mừng!

EDIT:

KẾT QUẢ - AS yêu cầu

Chúng tôi sẽ tiến hành những bước đầu tiên của cuộc phỏng vấn giống như trước. Điện thoại được theo dõi trực tiếp. Thay vì đưa họ trở lại cho một thứ ba và cuối cùng nướng, chúng tôi sẽ mang lại cho 3 nhà phát triển trở lại ngồi với tất cả 7 thành viên của đội. Chúng tôi đã quyết định để cho nhóm quyết định ai sau đó được thuê.

Chúng tôi đã đi đến kết luận này vì một vài lý do. Chúng tôi tin rằng điều này sẽ trao quyền cho các nhà phát triển bằng cách cho họ lựa chọn họ đang làm việc. Lý do thứ hai là nhóm động. Chúng tôi nghĩ rằng điều thực sự quan trọng là phải có một nhóm năng động và rất khó để nói cho đến sau khi bạn thuê một người nếu họ thích hợp hay không.

Vì vậy, kết quả cuối cùng là chúng tôi sẽ tiếp tục với các phiên lập trình ghép nối đôi nhưng theo một cách hoàn toàn khác và theo một cách hoàn toàn khác so với dự định ban đầu.

Bất kỳ suy nghĩ hoặc phê bình nào về phương pháp này đều được hoan nghênh hơn !! (bản chỉnh sửa này được đăng dưới dạng câu trả lời dưới đây, nếu bạn cảm thấy đây không phải là cách tiếp cận tốt nhất)

Answer 1

Tôi hy vọng bạn có một số bước tiến xa hơn. Để làm việc này, bạn cần có một bản lý lịch và màn hình điện thoại tuyệt vời. Bạn không muốn dành nhiều thời gian cho các ứng cử viên mà bạn không nên nói chuyện ngay từ đầu.

Vì vậy, bạn đề nghị một cuộc phỏng vấn ban đầu và có thể có cuộc phỏng vấn thứ hai như phiên lập trình cặp? - Ted Smith (1 phút trước)

Vâng. Bạn thậm chí có thể nghĩ đến việc có một cuộc phỏng vấn mã hóa đơn giản xảy ra trên web bằng cách sử dụng một cái gì đó như CoPilot.

Answer 2

Cách dễ nhất là cung cấp cho mỗi người cùng một lập trình viên làm việc cùng và cùng một đoạn mã chính xác.

Sự cố bạn sắp gặp phải là việc tuyển dụng không giống như lập trình. Không có quy trình từng bước để đưa ra câu trả lời đúng đắn cho người thuê. (bạn có thể có nhiều bước để đưa ra quyết định dễ dàng hơn). Bạn phải đánh giá từng người một về điểm mạnh của họ vv và về cơ bản đưa ra một dự đoán được giáo dục là cách tốt nhất để thuê. Đôi khi bạn đoán sai.

Điều khác về lập trình cặp bạn sẽ phải xem ra là lượng thời gian cần thiết để có từng ứng cử viên ở giai đoạn đó trải qua loại thử nghiệm đó.Nếu tôi đang tìm kiếm một công việc, tôi sẽ do dự khi đi phỏng vấn tại một công ty sẽ yêu cầu tôi làm điều đó. Tại sao? Bởi vì đó là rất nhiều thời gian, và nếu tôi phỏng vấn ở nhiều nơi, tôi có thể dành nhiều ngày chỉ để phỏng vấn các công việc mà tôi thậm chí không thể có hoặc muốn. Một số nơi như Google hoặc MS sẽ là một ngoại lệ, nhưng hầu hết các địa điểm không giống như hai địa điểm đó. (Chưa kể một thực tế là nếu họ đang làm việc trên mã thực, bạn về cơ bản yêu cầu họ làm công việc của một ai đó miễn phí).

Answer 3

Trừ khi bạn sử dụng chương trình ghép đôi rộng rãi trong phát triển trong thế giới thực, tôi sẽ rất do dự khi sử dụng tính năng này. Tôi đã gặp bất kỳ số lượng các nhà phát triển chuyên nghiệp chất lượng cao, những người đã đề cập đến một sự ác cảm mạnh mẽ để ghép nối lập trình và kỹ năng của họ sẽ không được đánh giá cao trong quá trình như vậy.

Answer 4

Tại sao không? Ngoài ra, nó không giống như các cuộc phỏng vấn luôn luôn (hoặc bao giờ) công bằng. Bạn nên đánh giá kết quả cuối cùng của phương pháp tiếp cận mới dựa trên cách tiếp cận dựa trên phỏng vấn truyền thống.

Ngoài ra, một cuộc phỏng vấn nhỏ trước phiên lập trình ghép đôi có thể là tốt để tránh lãng phí thời gian của các lập trình viên với những người sẽ không phù hợp.

Answer 5

Tôi thích ý tưởng này. Tuy nhiên tôi nghĩ rằng nó có thể là khó khăn để làm vì nó sẽ yêu cầu các ứng cử viên để có một số kiến ​​thức về dự án bạn sẽ ghép nối với anh ta. Ngoài ra, 4 đến 5 giờ có vẻ hơi dài. Điều gì sẽ xảy ra nếu bạn ngay lập tức thấy rằng nó sẽ không được giải quyết, bạn sẽ ngồi qua toàn bộ phiên họp với ứng cử viên?

Câu hỏi hay. Những điều cần suy nghĩ.

Answer 6

Để công bằng, bạn phải làm cho mọi nhân viên tham gia có một vấn đề chuẩn bị để đánh giá ứng cử viên. Tốt hơn là một cái gì đó được tạo thành thế giới thực trong kinh nghiệm của công ty họ, nhưng cái gì đó đã được giải quyết. Đây là cơ hội tốt để đánh giá kiến ​​thức về một vấn đề và đánh giá không chỉ kỹ năng lập trình.

Tôi ghét nó khi câu hỏi quá cụ thể được trả lời. Tôi đã có một cuộc phỏng vấn một lần mà một lập trình viên đã kiểm tra kiến ​​thức của tôi về STL mà tôi đã sử dụng rộng rãi và đã cố gắng để có được tôi để trả lời rằng một cấp phát tùy chỉnh là cần thiết. Tôi đã nghe nói về họ nhưng không bao giờ sử dụng chúng (đặc biệt là trong cửa sổ) và đã được thực hiện để cảm thấy câm. IOW, tránh bị phán xét. Vì vậy, quan điểm của tôi là, đặt câu hỏi thực tế mà không phải là quá nhiều về kiểm tra kiến ​​thức lập trình khi bạn có thể đánh giá tính cách chất lượng hơn và phương pháp giải quyết vấn đề nếu bạn sử dụng ý tưởng "lập trình đôi".

Câu hỏi hay!

Answer 7

Thành thật mà nói, điều đó nghe có vẻ như một ý tưởng tuyệt vời, mặc dù Jason Punyon chắc chắn đúng là bạn nên làm rất nhiều việc làm trước khi bạn lãng phí một lượng đáng kể thời gian của các nhà phát triển của bạn trên culls. Bạn có được một cái nhìn thoáng qua tại một số liệu quan trọng trong số đó là nếu không gần như không thể đạt được trong cuộc phỏng vấn: những gì một người nào đó muốn làm việc với.

Tôi không nghĩ rằng thực sự cần phải lo lắng về việc "công bằng" dựa trên vấn đề hoặc cố gắng trình bày các tình huống phù hợp với các ứng cử viên khác nhau, nếu bạn duy trì thái độ đánh giá đúng - rằng nó không phải là ' t về việc liệu họ có "câu trả lời đúng" hay nhảy qua tập hợp đúng đắn của hoops, nhưng loại nỗ lực nào, giải quyết vấn đề, khả năng giao tiếp và tính linh hoạt mà họ đã thể hiện. Bạn sẽ mất phần lớn lợi ích của bài tập bằng cách biến nó thành một bài kiểm tra nhân tạo, chưa kể đến việc thay đổi nó từ thứ gì đó mà các nhà phát triển của bạn có thể nhận được một số lợi ích từ (hoặc ít nhất vẫn nhận được một số công việc) thời gian của họ.

Answer 8

Joel Spolsky có một xuất sắc Guerrilla Guide to Interviewing mà nói về, trong số những thứ khác, nhiệm vụ lập trình.

Trivia: Joel Spolsky là người đồng sáng lập của stackoverflow.com

Answer 9

Là một giai thoại cá nhân, tôi đã vỗ xung quanh trong một cuộc phỏng vấn do một kỹ thuật như thế này. Tôi đã đi xa trong quá trình phỏng vấn của họ; thông qua kiểm tra sơ yếu lý lịch, việc gửi mã và đây là phần mặt đối mặt của cuộc phỏng vấn.

Tôi đã ra khỏi trường đại học và chưa bao giờ ghép đôi chương trình trước khi cũng không thực hiện TDD. Họ ngồi xuống để làm một cỗ bài tập bài và nó trôi dạt. Tệ! Tôi không hiểu tại sao người phỏng vấn lại viết các bài kiểm tra có vẻ ngớ ngẩn * (IE "trả về null;") và họ không giải thích tại sao và tất nhiên là ngoại quốc với TDD Tôi không biết câu hỏi nào. Kết quả cuối cùng là nó trông giống như tôi không thể lập trình theo cách của tôi ra khỏi một túi giấy.

Nếu bạn định thực hiện loại bài tập này, bạn cần phải phục vụ cho người được phỏng vấn bởi vì họ sẽ ở các vị trí khác nhau với khả năng của họ. Điều này có nghĩa là bạn sẽ nhận được các đánh giá khác nhau mà có thể không dựa trên tài năng thực tế và do đó sẽ bị thiên vị nặng nề.

** Bây giờ tôi hiểu TDD, tôi hiểu các xét nghiệm như thế này và làm thế nào nó là nghĩa vụ phải làm việc, nhưng người đàn ông đã làm điều đó bao giờ có vẻ ngu ngốc vào thời điểm đó! *

Answer 10

Một công ty cụ thể sử dụng một kỹ thuật gọi là cực phỏng vấn. Đối với cuộc phỏng vấn cực đoan, họ sẽ mang lại 30 nhà phát triển và nhóm chúng thành 15 cặp. Họ sẽ giải thích rằng họ đang tìm kiếm những người làm việc tốt với những người khác. Rằng họ sẽ đưa ra quyết định tuyển dụng dựa trên khả năng làm việc với người khác.

Họ sẽ cung cấp sự cố cho các cặp giải quyết. Họ sẽ nhấn mạnh rằng họ không quan tâm đến giải pháp mà mỗi người lập trình có khả năng làm việc với người khác. Đối với mỗi cặp họ sẽ cung cấp một người quan sát của cặp. Trong thời gian tập thể dục (khoảng 2 đến 4 giờ trong thời gian), người quan sát sẽ ghi chép về khả năng của một người để ghép nối ... không phải là giải pháp.

Họ ngạc nhiên về việc có bao nhiêu lập trình viên tập trung giải quyết vấn đề thay vì cộng tác. Trong số 15 cặp, họ sẽ xác định khoảng 4 đến 6 nhà phát triển cho một cuộc phỏng vấn thứ hai. Những nhà phát triển đó sẽ được yêu cầu quay lại và dành một tuần với nhóm (họ được trả tiền). Sau một tuần, họ quyết định ai sẽ giữ. Nói chung khoảng một nửa trong số họ (2 đến 3 nhà phát triển).

Khi hoàn tất, họ có các nhà phát triển có thể cộng tác và sau một tuần làm việc với các cặp khác nhau, nhóm có chỉ báo mạnh mẽ có thể phát triển phần mềm hiệu quả. Quá trình này vừa sáng tạo vừa hiệu quả. Họ đã có tỷ lệ thành công cao với những người mà họ đã thuê.

Answer 11

Tôi vừa có cuộc phỏng vấn với một công ty có trụ sở tại San Francisco tự hào về các phương pháp Agile/v.v. Tôi đã tự mình phỏng vấn CEO. Tôi có khoảng 20 năm kinh nghiệm trong ngành, nhưng chưa bao giờ được lập trình hoặc phát triển bằng phương pháp TDD. Tôi được cho biết đó sẽ là một "cuộc phỏng vấn lập trình" nhưng không biết phải mong đợi điều gì, và trước khi chúng tôi bắt đầu, anh ta nghĩ rằng tôi có thể đồng ý rằng tất cả các cuộc phỏng vấn nên được thực hiện theo cách này. (mà nhìn lại là không có gì nhiều hơn một tuyên bố kiêu ngạo).

Dù sao, tại cuộc phỏng vấn, bài tập là phát triển một lớp bằng TDD. Phải mất một giây để điều chỉnh suy nghĩ của tôi về toàn bộ quá trình, một lần nữa kể từ khi tôi chưa bao giờ ghép đôi TDD được lập trình hoặc thực hiện. Trong khi tôi vấp ngã ở đây và ở đó tôi đã làm ok cuối cùng. nhưng câu trả lời của anh ấy là tôi không thể hiện bản chất tích cực trở lại và ra mà họ yêu cầu cho môi trường lập trình đôi của họ. Bây giờ, điều đó cũng có thể là một cách nói dối mà nói rằng "Tôi không nghĩ rằng bạn đã làm rất tốt" loại tin nhắn.May mắn thay, tôi không cần công việc và thành thật mà nói, kinh nghiệm khiến tôi nhận ra rằng tôi muốn tìm một nghề nghiệp khác hơn là phải là một kỹ sư phần mềm HAS làm việc theo cặp, ngày này qua ngày khác, khi nó đến để phát triển mã. Điều kỳ lạ là nhân dịp tôi đã làm việc với một người khác trên mã đồng thời, vì vậy bất cứ điều gì là có thể.

Cuối cùng, tôi đoán đó là kết quả tốt vì họ không nghĩ tôi phù hợp và tôi không quan tâm đến phương pháp làm việc của họ. Nhưng chúng tôi đã đi đến cùng một kết luận, tôi đã nói chuyện một vài phút về bản thân mình và anh ấy đã cho tôi thêm một chút thông tin về cách họ đi về công việc của họ. Đó là để nói rằng có những cách khác để tìm kiếm một ứng cử viên phù hợp tốt hơn là đặt chúng thông qua sự căng thẳng của lập trình cặp với một người lạ hoàn toàn; cách không có thật để đánh giá năng lực imo.

Answer 12

Từ kinh nghiệm hạn chế của tôi, cảm xúc của tôi bị lẫn lộn. Tôi thích ý tưởng ghép nối như một phần của một cuộc phỏng vấn, đặc biệt. nếu công ty sử dụng ghép nối thường xuyên, bởi vì nó mang lại cảm giác tốt hơn cho phù hợp. Là một ứng cử viên, tôi thường xuyên trải qua các cuộc phỏng vấn, nơi tôi ngồi trong phòng trả lời các câu hỏi trong vài giờ, nhưng sau đó không có cảm giác tốt về những gì nó thực sự thích làm việc trong môi trường của họ. Ghép nối có thể có lợi hơn so với một bài tập mã hóa ngẫu nhiên, trừ khi người phỏng vấn có kỹ năng làm việc một người nào đó thông qua những người đó. Và tôi thích có thể thảo luận về các công cụ kỹ thuật từ cả hai phía. Và là một ứng cử viên, tôi muốn tương tác với một ai đó hơn là chỉ trả lời các câu hỏi hoặc giải quyết các vấn đề về mã của riêng tôi.

Nhưng ... như những người khác đã lưu ý, thời gian cần thiết có thể là một vấn đề. Tôi đã trải qua một vài ngày kết nối các cuộc phỏng vấn và thấy một số giai đoạn tốt, trong khi những người khác cảm thấy như một vài giờ đã lãng phí: một vì nhà phát triển đã không làm việc trên một cái gì đó cho vay để ghép nối (đặc biệt là nền của tôi), khác vì một vấn đề env ngăn chặn nhiều công việc hữu ích trong một thời gian. Nếu công việc không hiệu quả, có thể sẽ rất bực bội khi phải mất một hoặc hai ngày làm việc cho việc này.

Một nơi cố gắng cách tiếp cận này không chắc chắn liệu họ có nên nhờ ai đó bên ngoài công ty làm việc trong dự án của khách hàng hay không. Họ cũng lo lắng rằng việc giải thích miền và công việc đang được thực hiện sẽ mất quá nhiều thời gian, mặc dù không có ứng cử viên đó có thể không đóng góp được nhiều. Vì vậy, họ đã chọn một dự án mã nguồn mở mà nhân viên đang làm việc.

Điều này có vẻ là điểm mấu chốt: cần có một tác vụ được lựa chọn tốt mà ứng viên có thể hiểu nhanh và có thể đóng góp. Phần thứ hai sẽ phụ thuộc phần nào vào kỹ năng của ứng cử viên. Chìa khóa cũng sẽ là khả năng đánh giá một người nào đó với phương pháp này của nhân viên. Không phải ai cũng giỏi trong việc phỏng vấn bình thường, và điều đó có lẽ đúng hơn là một cuộc phỏng vấn ghép đôi.

Ngoài ra, nếu một công ty không thực hiện nhiều kết nối thì loại phỏng vấn này có thể không hữu ích. Có vẻ như có lợi khi nhìn thấy mã của ai đó (như ghi chú của Joel Spolsky), và đây có thể là một cách hay để làm điều đó. Nhưng nếu ghép nối không phải là một phần điển hình của công việc, thì có lẽ một phiên ghép nối đầy đủ không phù hợp. Có lẽ một phiên bản sửa đổi.

Tôi muốn tìm hiểu xem các công ty đã thực hiện phương pháp này nghĩ gì về kết quả. Đọc một số câu trả lời khác cho câu hỏi này cho thấy rằng nó không phải luôn luôn có vẻ lý tưởng từ quan điểm của ứng cử viên.

Answer 13

Tôi vừa mới có một cuộc phỏng vấn lập trình đôi vài ngày trước và thành thật mà nói, tôi không thực sự thích nó. Tôi đã được thông báo về điều này một ngày ngay trước cuộc phỏng vấn và sau đó người phỏng vấn nói với tôi rằng lập trình cặp đôi là cuối cùng tôi sẽ làm gì trong công việc. Tôi đã đi vào văn phòng và được ghép nối với một người là một kỹ sư phần mềm rất cao cấp. Công ty này ở San Francisco và họ là một công ty nổi tiếng về lập trình cặp đôi, tất cả mọi người đều tham gia chương trình trong văn phòng.Lúc đầu nó có vẻ ổn, ông giải thích về tất cả các công cụ họ đã sử dụng, khung kiểm thử đơn vị riêng của họ mà họ xây dựng và một chút của dự án. Sau đó, ông về cơ bản đã viết một loạt các bài kiểm tra đơn vị và muốn tôi làm việc trên thực hiện để làm cho nó vượt qua. Cũng như một FYI, cơ sở mã đã tồn tại rất lớn, tôi sẽ nói 10k dòng, nó không giống như một dự án siêu phức tạp, nhưng nó phức tạp cho ai đó chỉ cần bước vào và sau đó viết mã mà không cần sự hiểu biết trước về hệ thống phân cấp lớp vv Tôi thấy thật khó để tin rằng anh ta hy vọng ai đó sẽ nhảy ngay lập tức trong một dòng mã nguồn 10k đã tồn tại. Nó không phù hợp với một cuộc phỏng vấn lập trình đôi, một cơ sở mã nhỏ hơn sẽ giúp ích. Tôi đã vật lộn một chút khi điều hướng qua các lớp và đi qua lại bởi vì tôi không thể nhớ tên lớp vì tôi đã bị choáng ngợp bởi số lượng lớp/mã đã tồn tại. Thành thật mà nói, điều này thực sự làm tôi rất kinh khủng trong quá trình phỏng vấn. Cuối cùng tôi không cảm thấy thực sự tốt về nó. Tôi đã không thực hiện lập trình cặp trước đây, chủ yếu là chỉ trong các bài tập trong năm học đại học của tôi.

Với tôi sức mạnh của chương trình ghép đôi có thể được khai thác nếu bạn đã thành thạo/thoải mái với cặp của bạn, nhưng không thực sự phù hợp để phỏng vấn. Đôi khi tôi muốn đặt câu hỏi cho cặp của mình, nhưng sau đó tôi nghĩ nếu tôi hỏi quá nhiều câu hỏi, thì họ sẽ cho rằng tôi ngu ngốc và không thể biểu diễn. Nếu điều này đã được một công việc thực sự, tôi sẽ không ngần ngại hỏi, nhưng trong một cuộc phỏng vấn nó là khó .. bạn muốn hỏi vì cặp của bạn sẽ giúp bạn ra khi bạn đang mắc kẹt, nhưng đồng thời nó là một cuộc phỏng vấn , vì vậy bạn không thể thực sự yêu cầu nhiều.

Đó chỉ là kinh nghiệm của tôi rằng tôi có từ cuộc phỏng vấn lập trình cặp, gợi ý của tôi nếu bạn thực sự muốn làm điều này:

1. hãy chắc chắn rằng bạn không cung cấp cho các ứng cử viên để làm việc với một cơ sở mã lớn , hãy làm việc với một số nhỏ hơn và do đó anh/cô ấy có thể hiển thị kỹ năng của mình cho tối đa
2. đứng trước ứng cử viên trước cuộc phỏng vấn lập trình đôi, bạn có thể đặt câu hỏi khi bạn bị kẹt, bạn có thể để làm điều này và điều đó, bạn không thể làm gì
3. chi tiết như possibl e

Cuối cùng, tôi sẽ không đề xuất điều đó. Thật khó để đo lường hiệu suất của một ứng cử viên trong lập trình cặp, và nó có thể được thiên vị là tốt.