¿Cómo entrevistar a un candidato sysadmin? [cerrado]

¿Qué tipo de preguntas haría y qué escenarios describiría, qué tipo de respuestas buscaría?

No hago preguntas específicas. Me gustaría saber qué estrategia de entrevista es buena para seleccionar candidatos que estén calificados para el trabajo.

Hago preguntas en 3 categorías:

• Conocimiento técnico : quiero asegurarme de que el candidato sepa lo que debe saber. Por ejemplo, dígame la diferencia entre RAID 0, RAID 1, RAID 5, RAID 1 + 0 y RAID 0 + 1. Si es administrador de AD Directory Services, dígame los roles FSMO de nivel de bosque y dominio y qué hacen cada uno. Además, aquí es donde les pregunto qué tecnología les interesa. ¿Construyen robots a un lado? ¡Bueno! ¿Programan dichos robots? De Verdad? Así que tengo a alguien que puede codificar un poco y conoce los problemas de la solución de problemas. ¡Excepcional! Ese tipo de cosas.
• Personalidad : hago preguntas sobre cómo manejarían diferentes escenarios. Situaciones como: "El primer ministro se da cuenta de que se ha cometido un error en el cronograma. Usted sabe que el error es culpa del primer ministro. Ese error hará que trabaje dos fines de semana consecutivos. ¿Cómo lo maneja?" Básicamente preguntas que revelan cómo piensa el candidato y si sabe o no qué hacer para ser parte de un equipo. Esto no eliminará a las personas que conocen las respuestas correctas y no las hacen, pero eliminará a las personas que no tienen idea de cómo jugar bien con los demás. También hago preguntas sobre la participación de la comunidad.
• Experiencia previa : por lo general, pido que el candidato me dé una situación o proyecto en el pasado que haya salido bien donde era una parte importante. Quiero saber qué desafíos enfrentaron y cómo los manejaron. También pido que me den una situación en la que las cosas no salieron bien. ¿Cuáles fueron las lecciones que aprendió el candidato? ¿Qué podría haber hecho el candidato, pensando en retrospectiva, para posiblemente cambiar la situación (y si el candidato no pudo, el candidato lo reconoce)?

Esta respuesta cubre las tres áreas principales que deben investigarse. Sin embargo, una cosa que debe permitirse, particularmente en tiendas más pequeñas donde se espera que las personas de infraestructura sean multidisciplinarias, es hacer preguntas técnicas que tengan un alcance muy amplio y que puedan responderse en diferentes niveles de abstracción dependiendo de La experiencia del candidato. Esto le permite tener una idea de lo que cada uno es capaz de hacer, y les permite demostrar su experiencia específica, al tiempo que le permite comparar directamente las respuestas de diferentes candidatos.

Una gran pregunta que una vez me preguntaron es:

Imagina que te conecté a una máquina aquí y saqué una terminal. Que escribe wget http://www.google.com/. ¿Lo que pasa?

Yo, con mi sesgo de red, respondí comenzando con la resolución de DNS, pasando a la configuración de proxy y luego a la decisión de enrutamiento y al establecimiento de una conexión TCP; otro candidato respondió en términos de la conversación HTTP. Cuando le pregunté al entrevistador cuál era la mejor respuesta que había escuchado, su respuesta fue:

"Bueno, comenzó con la interrupción del teclado ..."

Las preguntas técnicas son importantes, y el método de respuesta es casi tan importante como tener la respuesta correcta. (Lo último que necesita el departamento de TI es que alguien sabotee su buena voluntad en toda la organización con hostilidad y condescendencia).

Pero aquí está mi pregunta más importante:

Mi primera entrevista con una empresa de TI "real" terminó cuando llegué a una pregunta técnica a la que respondí: "No sé".

La respuesta fue: "Genial, ¿cuándo puedes comenzar?"

Recién salía de la universidad y mi entrevistador quería saber que era capaz de reconocer los límites de mi conocimiento / experiencia. Es algo que he guardado conmigo, y creo que es el atributo más importante para un administrador de sistemas. El conocimiento específico es excelente y le dará una ventaja, pero si no puede admitir que no lo sabe, progresará muy lentamente, si es que lo hace.

A menudo entrevisto personas para puestos de nivel de entrada, lo que significa que no puedo hablar sobre un historial laboral significativo. Usualmente discuto proyectos personales, pero dos preguntas que siempre hago son "¿Puedes describirme tu red doméstica?" y "¿Cómo haces una copia de seguridad de tus máquinas domésticas?" Una persona realmente interesada podría pararse en una pizarra blanca durante 30 minutos discutiendo esto, entrando en el direccionamiento IP, seguridad inalámbrica, etc. Un pobre candidato se encogerá de hombros y le dirá a su hermano que lo configuró.

No haga preguntas "trivia": preguntas con una sola respuesta altamente específica. Las personas pueden olvidar ese tipo de cosas cuando están bajo estrés. Si su trabajo requiere que sepan qué pin en una interfaz V.35 se usa para transmitir datos, pueden buscarlo cuando tengan el trabajo. Las preguntas generales lo ayudan a comprender más sobre candidatos que trivialidades ... También no nos gustan los acertijos.

La práctica de la administración de sistemas y redes

Haga diferentes tipos de preguntas que lo ayudarán a conocer al candidato. Y cómo encajarán con su grupo de trabajo. En los dias antiguos. La mayoría de las SA eran físicos, astrónomos, matemáticos e ingenieros. ¿Por qué? Probablemente porque tenía excelentes habilidades para disparar y tomó muy buenas notas.

Algunas preguntas para hacer:

Técnico

• Descríbame, como si no supiera nada, cómo funciona una red TCP / IP.
• Descríbame, como si no supiera cómo funciona una computadora (un dispositivo básico de Von-Neumann)
• Dibuje un diagrama de red simple: tiene 20 sistemas, 1 enrutador, 5 conmutadores, 2 servidores y un pequeño bloque de IP. Ir.
• Según el anuncio de trabajo, ¿qué esperas hacer aquí?
• Descríbame lo que espera lograr aquí.
• ¿Cuál es el mejor método para mantener actualizada la documentación?
• ¿Cuál es el peor incidente de recuperación de desastres en el que ha estado involucrado? Dime qué hiciste.
• ¿Por qué te gusta ser una SA?
• ¿Cómo te calificarías como una SA?

Negocio

• ¿Cree que la TI impulsa el negocio o que las empresas impulsan la TI?
• ¿Qué opinas sobre nuestro modelo de negocio actual?
• ¿Qué podrías hacer para hacernos más rentables?
• ¿Cómo interactúa TI con nuestra empresa?

Personal

• ¿Cuál es tu broma favorita?
• ¿Qué libro debería leer mañana? ¿Por qué? (luego ve a la biblioteca y hojeala)
• Quien es Thomas Limoncelli? (je je je GOTCHA!)

Casi cualquier persona puede verse bien en papel. Algunas personas pueden abrirse camino a través de discusiones técnicas. Y muchas personas son pobres oradores públicos. Debe hacer preguntas abiertas. No "Sí o No", observe sus procesos de pensamiento y sus capacidades de resolución de problemas. Lo más revelador son las metáforas que usan para describir procesos complejos.

Contratar una SA es una tarea muy difícil. Es poco probable que una entrevista técnica describa a quién contratará. No es tanto lo que saben ahora. Es lo que están dispuestos a aprender, y qué tan rápido lo aprenderán y lo aplicarán.

Si fuera parte de un panel de entrevistas para un administrador de sistemas en una compañía de software donde se espera que mantengan el software de la compañía ejecutándose en sus servidores, me interesaría saber qué espera el candidato de los desarrolladores. ¿Cómo interactúan con los desarrolladores: "nosotros contra ellos" o "todos juntos con experiencia diferente"? ¿Tienen alguna experiencia de una situación en la que el desarrollo y la TI (o como se llame al departamento) terminaron en conflicto, y cómo se resolvió? ¿Están interesados ​​en conseguir algo conocimiento de la tecnología y la terminología utilizada por los desarrolladores, y están dispuestos a ayudar a educar a los desarrolladores en sus propias áreas de especialización, para que todos puedan comunicarse mejor?

Es cierto que esto sería en parte para satisfacer mi propio interés en la relación entre administradores de sistemas y desarrolladores, así como para juzgar al candidato.

Asegúrate de que no sea solo un libro inteligente. Siento que es bueno dar algún tipo de prueba práctica.

Las preguntas de "pizarra en blanco" son las que realmente separan a las ovejas de las cabras. "Este es el límite de la red; esta es una aplicación web que se ejecuta en IIS, este es su servidor SQL; este es un cuadro de UNIX con otro servicio de recuadro negro en él. ¿Cómo hacer que esto sea tolerante a fallas, seguro, etc.? "

La única respuesta que recibí de un candidato fue un error "estás bromeando, ¿verdad?"

Estoy contratando administradores de Linux para un inicio, por lo que mis preguntas son las que deberían descubrir la experiencia de la inexperiencia. Pantalla del teléfono:

1. ¿Puede nombrar tantos directorios de nivel superior en un sistema Linux moderno (FHS) como pueda (hay alrededor de 20, nadie recibe más del 75%, incluso aquellos que lo manejan todos los días)?
2. ¿Para qué se utiliza la variable de entorno PATH?
3. Nombra a una persona famosa por su participación en software libre / de código abierto (que no sea Linus Torvalds) (respuesta más frecuente: Richard Stallman)

Para la entrevista telefónica, trato de que hablen sobre sus proyectos anteriores, la red doméstica, cuántas computadoras tienen y qué hacen con ellos, etc.

En persona, me gusta darles un problema real que estoy enfrentando y pedirles que lo resuelvan por mí. Compararé su respuesta con cualquier solución que ya esté considerando. Si su respuesta es mejor, mi proyecto avanza. Si su respuesta es peor, el proceso de entrevista ha avanzado. De cualquier manera, puedo seguir comprometido con mis propios proyectos y refinar o descartar candidatos o ideas.

De lo contrario, se habla más en profundidad sobre lo que esperan de un entorno de trabajo, tratando de averiguar si son un 9-5er o si realmente se preocupan por lo que están haciendo --- a falta de otros factores, los tipos de Linux tienden preocuparse (aunque pueden apestar) y los ingenieros de red tienden a ser 9-5ers (que también pueden apestar) ... Solo mi experiencia.

Suponiendo que pasan todo eso, también me gusta configurarlos con una nueva caja de Linux en una red aislada cuya configuración de red es incorrecta, con un equipo extraño conectado y un cable suelto para el "tornillo" final, y hacer que lo recuperen en línea. Los dejo en paz y vuelvo periódicamente para revisarlos, aunque podría flotar con la misma facilidad si quisiera ser duro con eso.

Por lo general, a una persona que ha superado el resto de la entrevista le lleva unos 30 minutos entrar en este entorno totalmente desconocido y hacer que vuelva a funcionar. Es una increíble prueba del mundo real de exactamente cuánto tiempo les lleva resolver problemas en un entorno totalmente nuevo y totalmente roto.

Después de ordenar cuidadosamente el currículum, todavía tenía 20 candidatos. 20 personas de ~ 150 pasaron la primera selección que me permitió pasar tres o cuatro horas para entrevistar a cada uno de ellos. Los principales criterios de selección para mí fueron:

• capacidad de entrenar en un lugar
• habilidad para elegir el enfoque óptimo
• habilidad para reunir y resolver un problema en una situación no estándar
• Una buena base de conocimientos: eso significa que el candidato debe conocer la historia de las técnicas informáticas, poseer la teoría a un alto nivel, saber no solo " qué hacer", sino también saber "por qué" .

Para conocer su habilidad para reunir y resolver un problema en una situación no estándar, me preguntaron, por ejemplo: "Cómo estropear un sistema Windows, si tiene acceso físico a la computadora, pero no tiene ninguno contraseñas de cuenta? y, después de eso, les pregunté sobre "¿Cómo parchear el sistema estropeado?". Di algunos ejemplos de acción de virus y pregunté qué harían para evitar daños y devolver la funcionalidad y la pérdida de datos con la menor cantidad posible de instrumentos y más preguntas sobre el uso de instrumentos no estándar. Una vez, le pregunté a un candidato: "¿Qué pregunta me harías, si me estuvieras entrevistando, para saber qué tan bueno soy con situaciones no estándar?" :-)

Para saber qué tan buenos son para encontrar un enfoque óptimo, les di un poco de práctica en la configuración de la web, el servidor de correo o la puerta de enlace de red para parámetros particulares ("Necesito que sea un servidor web muy rápido para un pequeño número de clientes conectados y sí, quiero un poco de lenguaje de script del lado del servidor para mostrarme algunas estadísticas, ¿qué debo elegir y por qué crees que es mejor? ¿Podrías mostrarme en nuestro servidor de prueba, si has te quedan 20 minutos? ")

La capacidad de entrenar en un lugar, no es realmente fácil de verificar, pero les pedí a algunos candidatos que hicieran un archivo de configuración de muestra o un script, y luego les di una pequeña pista para ver si podían hacerlo mejor después de eso.

La base de conocimiento: una de mis partes favoritas: ¿Qué es OSI? ¿Por qué TCP / IP se llama " pila de protocolos "? ¿Qué héroes informáticos conoces? ¿Qué es el registro de Windows? ¿Y qué hay de los sistemas tipo Unix?

Y algo muy importante: ¡DEBEN amar su trabajo! "¿Leyó algunos de los autores clásicos, como K&R?", "¿Cuánto tiempo le interesa mucho la técnica informática?", "¿Con qué comenzó a estudiar computadoras?", "¿Tiene computadoras de prueba / poca red? ¿en casa?" (si es verdad, ¡es una muy buena señal!).

K. La lista de Brian Kelley es excelente, pero me gustaría enfatizar que hacer preguntas para solucionar problemas es importante. Elija un par de problemas difíciles que haya enfrentado y haga que el candidato le diga cómo tratarían de resolver el problema. Conocer muchos datos técnicos es importante, pero poder resolver problemas con un enfoque metódico es muy importante en mi opinión.

Me gusta hacer preguntas que son lo opuesto a la forma normal de esa misma pregunta. Por ejemplo, en el desarrollo web, una pregunta común es "¿cuándo PUBLICA un formulario en lugar de GET?" Pero pregunto lo contrario: "¿Cuándo usas GET en lugar de POST?" Esto obliga a las personas a pensar en inconvenientes en lugar de ventajas, o a considerar qué compensaciones están haciendo cuando toman una decisión.

Una pregunta representativa para TI podría implicar dos opciones tecnológicas similares; tal vez una pregunta como "¿Cuándo elegirías un grupo de trabajo de Windows en lugar de un dominio?"

Siempre mantengo una nota en papel y lápiz de todas las cosas extrañas y extrañas que encuentro en el trabajo normal del día a día, no el tipo de cosas que están en los libros de "cómo ...". Entonces puedo recurrir a una o dos de estas situaciones en una entrevista, a menudo más para comenzar una conversación que como una prueba, estoy más interesado en CÓMO enfrentarían la situación que si supieran la respuesta. Siempre hago una pregunta con respecto a la tecnología 'de vanguardia' para ver si están interesados ​​en la nueva tecnología (o DEMASIADO interesado).

Un poco fuera de tema, pero una historia interesante del Blog oficial de Google:

Cómo llegué a Google (Capítulo 1)

Sin embargo, nuestros ingenieros tienden a venir por rutas más variadas y ocasionalmente más extrañas. Algunos son reclutados fuera de la escuela de posgrado, o por amigos o ex colegas. Otros simplemente envían sus currículums a jobs@google.com. Sin embargo, para algunos ingenieros, el camino ha sido más interesante.

Lea el resto de la publicación del blog sobre ese método poco convencional pero, en mi opinión, válido para contratar a las personas adecuadas.

Al entrevistar, en realidad no estoy buscando ver si un candidato puede responder preguntas técnicas específicas. Creo que es más importante que un candidato sepa a dónde ir para encontrar una respuesta.

Un candidato no debería decir simplemente "No lo sé". Estoy buscando una respuesta más similar a "Me gustaría buscar eso en Google" o algo similar a "Soy miembro de [ACM | SAGE | LOPSA | Falla del servidor] y revisaría el [sitio web de archivos de la lista de correo | ] para encontrar ayuda para responder esta pregunta ".

Averiguar a dónde acudirá un candidato cuando no sepa la respuesta a una pregunta es una buena manera de hacerse una idea de sus capacidades.

He entrevistado a personas como empleado de una gran empresa y como propietario de una pequeña empresa. La cualidad número uno que busco es una personalidad equilibrada entre 'visionario' y 'tinkerer'.

Si tienes demasiado visionario, obtienes un sistema construido como Twitter. (Si no ha leído nada, la mitad de sus primeras descripciones de sus instrucciones de ingeniería conducirán a la mayoría de los tipos de administradores a hacer un facepalm y dirigirse a la barra). Si tiene demasiado manipulador, tiene 200 sistemas increíbles en varios estados de deterioro en todo el lugar, y todos sus sitios web se ejecutan en una caja de diez años con BSD 4.2 debajo del escritorio del administrador del sistema.

De plano, la mejor persona que contraté fue un tipo con una doble licenciatura en Religión y Filosofía de una pequeña universidad privada en Connecticut. Era creativo, dedicado, inteligente y perseverante ante la adversidad. Estaba revisando el código a través de un teléfono celular conectado hasta una hora antes de que naciera su primera hija. Ha hecho cosas increíbles y ahora es el líder de la comunidad de un importante framework PHP. Gran chico.

La peor persona con la que he trabajado fue un tipo muy inmerso en la organización para la que ambos trabajamos. Su padre trabajaba allí y había trabajado allí desde la secundaria. Hubo al menos una docena de veces en las que casi le dije que si no le gustaba su trabajo, debería renunciar y ahorrarle el dolor de cabeza al resto de nosotros. Él era un ingeniero. Y casualmente, un gran fanático de BSD y Gentoo.

Aparte de eso, cualquier administrador de sistemas en un rol * nix debería poder describir por qué esto es divertido .

Siempre le pido al candidato que se califique de 1 a 10 en ciertos aspectos del puesto. Luego, en base a esa respuesta, hago preguntas que coinciden con el nivel que se colocaron.

Si el puesto requiere el uso de secuencias de comandos, siempre pediré ejemplos y luego, en una segunda entrevista, les daré un escenario y les pediré que automaticen su respuesta. Solo necesito asegurarme de que su enfoque no sea cortador de galletas.