Những loại câu hỏi bạn sẽ hỏi và những kịch bản bạn sẽ mô tả, những loại câu trả lời bạn sẽ tìm kiếm?
Tôi không hỏi những câu hỏi cụ thể. Tôi muốn biết chiến lược phỏng vấn nào là tốt để chọn ứng viên đủ tiêu chuẩn cho công việc.
Những loại câu hỏi bạn sẽ hỏi và những kịch bản bạn sẽ mô tả, những loại câu trả lời bạn sẽ tìm kiếm?
Tôi không hỏi những câu hỏi cụ thể. Tôi muốn biết chiến lược phỏng vấn nào là tốt để chọn ứng viên đủ tiêu chuẩn cho công việc.
Câu trả lời:
Tôi đặt câu hỏi trong 3 loại:
Câu trả lời này bao gồm ba lĩnh vực chính cần được điều tra. Tuy nhiên, một điều cần được cho phép, đặc biệt là trong các cửa hàng nhỏ nơi người dân cơ sở hạ tầng dự kiến sẽ đa ngành, là đặt câu hỏi kỹ thuật có phạm vi rất rộng và có thể được trả lời ở các lớp trừu tượng khác nhau tùy thuộc vào chuyên môn của ứng viên. Điều này cho phép bạn cảm nhận về khả năng của từng người và cho phép họ thể hiện chuyên môn cụ thể của mình, trong khi vẫn cho phép bạn so sánh trực tiếp câu trả lời của các ứng viên khác nhau.
Một câu hỏi tuyệt vời mà tôi từng được hỏi là:
Hãy tưởng tượng tôi đã đăng nhập bạn vào một máy ở đây và đưa ra một thiết bị đầu cuối. Bạn gõ
wget http://www.google.com/
. Chuyện gì xảy ra
Tôi, với xu hướng mạng của mình, đã trả lời bắt đầu bằng độ phân giải DNS, chuyển sang cấu hình proxy và sau đó chuyển sang quyết định định tuyến và thiết lập kết nối TCP; một ứng cử viên khác đã trả lời về cuộc hội thoại HTTP. Khi tôi hỏi người phỏng vấn câu trả lời hay nhất mà anh ta nghe được là gì, câu trả lời của anh ta là:
"Chà, nó bắt đầu bằng việc ngắt bàn phím ..."
Các câu hỏi kỹ thuật rất quan trọng và phương pháp trả lời gần như quan trọng như có câu trả lời đúng. (điều cuối cùng mà bộ phận CNTT cần là ai đó phá hoại thiện chí của nó trong toàn tổ chức với sự thù địch và nhượng bộ).
Nhưng đây là câu hỏi quan trọng nhất của tôi -
Cuộc phỏng vấn đầu tiên của tôi với một công ty IT "thực sự" đã kết thúc khi tôi gặp một câu hỏi kỹ thuật mà tôi đã trả lời, "Tôi không biết."
Câu trả lời là: "Tuyệt vời, khi nào bạn có thể bắt đầu?"
Tôi mới ra trường và người phỏng vấn của tôi muốn biết rằng tôi có khả năng nhận ra giới hạn của kiến thức / kinh nghiệm của mình. Đó là thứ tôi đã giữ bên mình và tôi nghĩ đó là thuộc tính quan trọng nhất đối với một sysadmin. Kiến thức cụ thể là rất tốt, và sẽ giúp bạn nhanh chóng, nhưng nếu bạn không thể thừa nhận là không biết, thì bạn sẽ tiến bộ rất chậm, nếu có.
Tôi thường phỏng vấn mọi người cho các vị trí nhập cảnh, nghĩa là tôi không thể thảo luận về lịch sử công việc có ý nghĩa. Tôi thường thảo luận về các dự án cá nhân, nhưng hai câu hỏi tôi luôn hỏi là "Bạn có thể mô tả mạng gia đình của bạn cho tôi không?" và "Làm thế nào để bạn sao lưu (các) máy gia đình?" Một người thực sự quan tâm có thể đứng trên bảng trắng trong 30 phút để thảo luận về vấn đề này, nhận được địa chỉ IP, bảo mật không dây, v.v. Một ứng cử viên nghèo sẽ nhún vai và nói với bạn rằng anh trai của anh ta đã thiết lập nó.
Đừng hỏi những câu hỏi "đố" - những câu hỏi với một câu trả lời duy nhất, rất cụ thể. Mọi người có thể quên điều đó khi bị căng thẳng. Nếu công việc của họ yêu cầu họ biết pin nào trên giao diện V.35 được sử dụng để truyền dữ liệu, họ có thể tra cứu khi họ có công việc. Các câu hỏi chung giúp bạn hiểu nhiều hơn về các ứng cử viên hơn là những câu đố ... Chúng tôi cũng không thích những lời trêu ghẹo não.
Thực hành quản trị hệ thống và mạng
Hỏi các loại câu hỏi khác nhau sẽ giúp bạn tìm hiểu về ứng viên. Và làm thế nào họ sẽ phù hợp với nhóm làm việc của bạn. Thời xưa. Hầu hết SA là các nhà vật lý, nhà thiên văn học, nhà toán học và kỹ sư. Tại sao? Có lẽ bởi vì đã có những kỹ năng chụp ảnh rắc rối tuyệt vời và ghi chú rất tốt.
Một vài câu hỏi để hỏi:
Kỹ thuật
Kinh doanh
Cá nhân
Hầu hết mọi người có thể nhìn tốt trên giấy. Một số người có thể BS theo cách của họ thông qua các cuộc thảo luận kỹ thuật. Và nhiều người là những người nói công cộng nghèo. Bạn phải đặt câu hỏi kết thúc mở. Không "Có hoặc Không", quan sát quá trình suy nghĩ của họ và khả năng khắc phục sự cố của họ. Hầu hết nói, là những ẩn dụ họ sử dụng để mô tả các quá trình phức tạp.
Thuê SA là một nhiệm vụ rất khó khăn. Không chắc là một cuộc phỏng vấn kỹ thuật sẽ mô tả bạn sẽ tuyển dụng ai. Đó không phải là quá nhiều những gì họ biết bây giờ. Đó là những gì họ sẵn sàng học hỏi, và họ sẽ học và áp dụng nó nhanh như thế nào.
Nếu tôi là thành viên của một nhóm phỏng vấn cho một sysadmin tại một công ty phần mềm nơi họ dự kiến sẽ giữ phần mềm của công ty chạy trên máy chủ của họ, tôi sẽ muốn biết ứng viên mong đợi gì từ các nhà phát triển. Làm thế nào để họ tương tác với các nhà phát triển - "chúng tôi so với họ" hoặc "tất cả kéo theo cùng chuyên môn khác nhau"? Họ có bất kỳ kinh nghiệm nào về tình huống phát triển và CNTT (hoặc bất kỳ bộ phận nào được gọi) đã kết thúc trong xung đột, và nó đã được giải quyết như thế nào? Họ có quan tâm đến việc nhận được một số nhận thức về công nghệ và thuật ngữ được sử dụng bởi các nhà phát triển và họ có sẵn sàng giúp giáo dục các nhà phát triển trong lĩnh vực chuyên môn của mình, để mọi người có thể giao tiếp tốt hơn không?
Phải thừa nhận rằng điều này một phần là để thỏa mãn mối quan tâm của riêng tôi về mối quan hệ giữa sysadins và nhà phát triển cũng như để đánh giá ứng viên.
Hãy chắc chắn rằng anh ấy không chỉ là cuốn sách thông minh. Tôi cảm thấy thật tốt khi thử nghiệm một số loại.
Các câu hỏi "bảng trắng" là những câu hỏi thực sự tách cừu ra khỏi dê. "Đây là ranh giới mạng, đây là một ứng dụng web chạy trên IIS, đây là phần phụ trợ SQL của bạn, đây là một hộp UNIX với một dịch vụ hộp đen khác trên đó. Làm thế nào để bạn có thể chịu lỗi, bảo mật, v.v.? "
Câu trả lời duy nhất tôi nhận được từ một ứng cử viên là một câu nói "bạn đang nói đùa phải không?"
Tôi đang thuê quản trị viên Linux cho một công ty khởi nghiệp, vì vậy những câu hỏi của tôi là những câu hỏi nên trêu chọc kinh nghiệm từ thiếu kinh nghiệm. Màn hình điện thoại:
Đối với cuộc phỏng vấn qua điện thoại, tôi cố gắng khiến họ nói về các dự án trước đây của họ, mạng gia đình, họ có bao nhiêu máy tính và họ làm gì với họ, v.v.
Cá nhân, tôi muốn cung cấp cho họ một vấn đề thực sự mà tôi phải đối mặt và yêu cầu họ giải quyết nó cho tôi. Tôi sẽ so sánh câu trả lời của họ với bất kỳ giải pháp nào tôi đã nghiên cứu kỹ. Nếu câu trả lời của họ là tốt hơn, dự án của tôi di chuyển cùng. Nếu câu trả lời của họ tệ hơn, quá trình phỏng vấn đã được tiến hành. Dù bằng cách nào, tôi có thể tiếp tục tham gia vào các dự án của riêng mình và tinh chỉnh hoặc loại bỏ các ứng cử viên hoặc ý tưởng.
Mặt khác, nó nói sâu hơn về những gì họ mong đợi từ môi trường làm việc, cố gắng tìm hiểu xem họ là 9-5er hay họ thực sự quan tâm đến những gì họ đang làm --- vắng mặt các yếu tố khác, các loại Linux có xu hướng quan tâm (mặc dù họ có thể hút) và các kỹ sư mạng có xu hướng là 9-5ers (người cũng có thể hút) ... Chỉ là kinh nghiệm của tôi.
Giả sử họ vượt qua tất cả, tôi cũng muốn thiết lập chúng với một hộp Linux mới trên một mạng bị cô lập có cấu hình mạng bị sai, với thiết bị kỳ lạ được gắn và một dây cáp lỏng lẻo cho "vít bạn" cuối cùng và đưa họ trở lại Trực tuyến. Tôi để chúng một mình và định kỳ quay lại để kiểm tra chúng, mặc dù tôi có thể dễ dàng di chuột nếu tôi muốn trở thành một người khó tính về nó.
Thông thường sẽ mất khoảng 30 phút để một người đã vượt qua phần còn lại của cuộc phỏng vấn để bước vào môi trường hoàn toàn xa lạ này và khiến nó hoạt động trở lại. Đây là một thử nghiệm thực tế tuyệt vời về chính xác thời gian họ khắc phục sự cố trong một môi trường hoàn toàn mới, hoàn toàn bị phá vỡ.
Sau khi cẩn thận sắp xếp hồ sơ, tôi vẫn còn 20 ứng viên. 20 người từ ~ 150 đã vượt qua lựa chọn đầu tiên cho phép tôi dành ba bốn giờ để phỏng vấn từng người trong số họ. Các tiêu chí chính của lựa chọn đối với tôi là:
Để biết về kỹ năng của họ để thu thập và giải quyết vấn đề trong tình huống không chuẩn, tôi đã hỏi họ, ví dụ: "Cách làm hỏng hệ thống Windows, nếu bạn có quyền truy cập vật lý vào máy tính, nhưng không có bất kỳ mật khẩu tài khoản? " và sau đó, tôi hỏi họ về "Làm thế nào để vá hệ thống bị hỏng?". Tôi đã đưa ra một số ví dụ về hành động của virus và hỏi, họ sẽ làm gì để ngăn chặn thiệt hại và trả lại chức năng và dữ liệu bị mất với càng ít càng tốt, và càng có nhiều câu hỏi về việc sử dụng các công cụ không chuẩn. Một lần, tôi đã hỏi một ứng viên: "Bạn sẽ hỏi câu hỏi nào, nếu bạn đang phỏng vấn tôi, để biết, tôi tốt như thế nào với các tình huống không chuẩn?" :-)
Để biết, họ tìm được cách tiếp cận tối ưu tốt như thế nào, tôi đã cho họ một chút thực hành trong việc định cấu hình web, hoặc máy chủ thư hoặc cổng mạng cho các tham số cụ thể ("Tôi cần nó là máy chủ web rất nhanh cho số lượng nhỏ máy khách được kết nối với nó, và vâng, tôi muốn một số ngôn ngữ kịch bản phía máy chủ trên đó, để hiển thị cho tôi một số thống kê, tôi nên chọn cái gì và tại sao bạn lại thấy tốt hơn? Bạn có thể chỉ cho tôi trên máy chủ thử nghiệm của chúng tôi không, nếu bạn Còn 20 phút nữa à? ")
Khả năng đào tạo tại một địa điểm - không thực sự dễ kiểm tra, nhưng tôi đã yêu cầu một số ứng viên tạo tệp cấu hình mẫu hoặc tập lệnh, sau đó, cho họ một gợi ý nhỏ để xem liệu họ có thể làm tốt hơn sau đó không.
Cơ sở kiến thức - một trong những phần yêu thích của tôi: OSI là gì? Tại sao TCP / IP được gọi là " ngăn xếp giao thức "? Những anh hùng khoa học máy tính nào bạn biết? Windows-đăng ký là gì? Và những gì về hệ thống giống Unix?
Và điều rất quan trọng - họ PHẢI yêu công việc của họ! "Bạn đã đọc một số tác giả cổ điển, chẳng hạn như K & R?", "Bạn có hứng thú lớn với kỹ thuật máy tính bao lâu?", "Với những gì bạn bắt đầu học máy tính?", "Bạn có máy tính thử nghiệm / mạng nhỏ không ở nhà?" (nếu đó là sự thật, đó là một dấu hiệu rất tốt!).
Danh sách của K. Brian Kelley tuyệt vời, nhưng tôi muốn nhấn mạnh rằng việc đặt câu hỏi khắc phục sự cố là rất quan trọng. Chọn một vài vấn đề khó khăn mà bạn đã gặp phải và yêu cầu ứng viên cho bạn biết họ sẽ cố gắng giải quyết vấn đề như thế nào. Biết nhiều thông tin kỹ thuật là rất quan trọng, nhưng theo tôi, có thể giải quyết vấn đề bằng phương pháp có phương pháp là rất quan trọng.
Tôi thích đặt câu hỏi ngược lại với dạng bình thường của cùng một câu hỏi. Ví dụ: trong phát triển web, một câu hỏi phổ biến là "khi nào bạn POST một biểu mẫu thay vì GET?" Nhưng tôi hỏi ngược lại: "Khi nào bạn sử dụng GET thay vì POST?" Điều này buộc mọi người phải suy nghĩ về những hạn chế thay vì lợi thế hoặc xem xét những gì họ đang đánh đổi khi họ đưa ra quyết định.
Một câu hỏi đại diện cho CNTT có thể liên quan đến hai lựa chọn công nghệ tương tự; có thể là một câu hỏi như "Khi nào bạn sẽ chọn Nhóm làm việc Windows thay vì Miền?"
Tôi luôn luôn ghi chép lại tất cả những điều kỳ quặc, kỳ quặc mà tôi gặp trong công việc hàng ngày, không phải là những thứ trong cuốn sách 'làm thế nào để ...'. Sau đó tôi có thể gọi một hoặc hai trong số các tình huống này trong một cuộc phỏng vấn, thường là bắt đầu một cuộc trò chuyện nhiều hơn là một bài kiểm tra, tôi quan tâm đến việc họ sẽ giải quyết tình huống như thế nào nếu họ biết câu trả lời. Tôi luôn đặt câu hỏi liên quan đến công nghệ 'chảy máu' để xem liệu họ có quan tâm đến công nghệ mới (hay thực tế là rất quan tâm).
Một chủ đề nhỏ - nhưng một câu chuyện thú vị từ anh Blog chính thức của Google:
Tôi đã truy cập Google như thế nào (Ch. 1)
Các kỹ sư của chúng tôi, mặc dù, có xu hướng đến bởi các tuyến đường đa dạng hơn, và đôi khi khác. Một số được tuyển dụng ra khỏi trường, hoặc bởi bạn bè hoặc đồng nghiệp cũ. Những người khác chỉ cần gửi sơ yếu lý lịch của họ đến jobs@google.com. Đối với một vài kỹ sư, mặc dù, con đường đã thú vị hơn.
Xin vui lòng đọc phần còn lại của bài viết trên blog về điều đó độc đáo, nhưng - theo tôi - phương pháp hợp lệ để thuê đúng người.
Khi phỏng vấn, tôi không thực sự muốn xem liệu một ứng viên có thể trả lời các câu hỏi kỹ thuật cụ thể không. Tôi nghĩ điều quan trọng hơn là một ứng cử viên biết nơi để đi tìm câu trả lời.
Một ứng cử viên không nên nói, "Tôi không biết". Tôi đang tìm kiếm một câu trả lời nhiều hơn dọc theo dòng "Tôi sẽ Google điều đó" hoặc một cái gì đó tương tự như "Tôi là thành viên của [ACM | SAGE | LOPSA | Lỗi máy chủ] và tôi sẽ kiểm tra [lưu trữ danh sách gửi thư | trang web ] để tìm trợ giúp trả lời câu hỏi này ".
Tìm ra nơi mà một ứng cử viên sẽ quay đầu khi họ không biết câu trả lời cho câu hỏi là một cách hay để có được một bức tranh về khả năng của họ.
Tôi đã phỏng vấn mọi người với tư cách là nhân viên của một công ty lớn và là chủ sở hữu của một công ty nhỏ. Phẩm chất số một mà tôi tìm kiếm là một tính cách cân bằng giữa 'nhìn xa trông rộng' và 'tinkerer'.
Nếu bạn có quá nhiều tầm nhìn, bạn sẽ có một hệ thống được xây dựng như Twitter. (Nếu bạn chưa đọc bất kỳ của nó, một nửa số mô tả trước đây của họ về hướng dẫn kỹ thuật của họ sẽ dẫn hầu hết các loại admin để làm một facepalm và đầu cho quầy bar.) Nếu bạn có quá nhiều tinh chỉnh thì bạn có 200 hệ thống tuyệt vời trong nhiều tình trạng hư hỏng ở khắp mọi nơi và tất cả các trang web của bạn đang chạy trên một hộp mười năm tuổi chạy BSD 4.2 dưới bàn của sysadmin.
Nói thẳng ra, người giỏi nhất mà tôi từng thuê là một chàng trai có bằng Cử nhân Tôn giáo và Triết học kép từ một trường đại học tư thục nhỏ ở Connecticut. Ông là người sáng tạo, tận tụy, thông minh và kiên trì khi đối mặt với nghịch cảnh. Ông đã kiểm tra mã thông qua điện thoại di động buộc cho đến một giờ trước khi con gái đầu lòng của ông chào đời. Anh ấy đã tiếp tục làm những điều tuyệt vời và hiện là người lãnh đạo cộng đồng của một khung công tác PHP lớn. Anh chàng tuyệt vời.
Người tồi tệ nhất tôi từng làm việc cùng là một chàng trai rất say mê tổ chức mà cả hai chúng tôi cùng làm việc. Cha anh làm việc ở đó và anh làm việc ở đó từ thời trung học. Đã có ít nhất một chục lần tôi gần như nói với anh ấy rằng nếu anh ấy không thích công việc của mình, anh ấy nên nghỉ việc và cứu những người còn lại trong chúng tôi. Ông là một người thích mày mò. Và tình cờ, một fan hâm mộ BSD và Gentoo khổng lồ.
Ngoài ra, bất kỳ sysadmin nào trong vai trò * nix sẽ có thể mô tả lý do tại sao điều này là buồn cười .
Tôi luôn yêu cầu ứng viên tự đánh giá từ 1-10 về các khía cạnh nhất định của vị trí này. Sau đó, dựa trên câu trả lời đó, tôi đặt câu hỏi phù hợp với cấp độ mà họ tự đặt.
Nếu vị trí yêu cầu sử dụng kịch bản, tôi sẽ luôn hỏi ví dụ và sau đó trong một cuộc phỏng vấn thứ hai, hãy đưa cho họ một kịch bản và yêu cầu họ tự động hóa câu trả lời của họ. Tôi chỉ cần chắc chắn rằng cách tiếp cận của họ không phải là cắt cookie.