Entrevistar a alguien para habilidades generales de Unix [cerrado]

¿Cómo probaría a un desarrollador que afirma tener experiencia en shell * nix?

Estaba pensando en hacer que resuelvan un problema de obtener información de los archivos de registro, lo que implicaría algunos conceptos básicos como cat, grep, cut, ... combinados con tuberías.

¿Qué otro conocimiento básico pedirías? Una vez más, esto no es para entrevistar a alguien que desarrollará para sistemas * nix, y tampoco para administradores de sistemas * nix, sino solo para desarrolladores regulares que a veces necesitan trabajar en un sistema * nix.

Según mi experiencia personal, el desarrollador que trabaja en un sistema * nix necesita saber:

• variables de shell (cómo establecer / obtener + conocimiento sobre las especiales como PATH)
• redirección de shell (captura de salida de un programa)
• tuberías (extraer un poco de información del archivo de registro es un excelente ejemplo)
• control de proceso (ps, nice / renice, kill)
• derechos de acceso a archivos (ls / chmod / chown / chattr)
• usuarios (pero principalmente en el contexto de archivos / procesos, es decir: ¿este proceso puede acceder a este archivo? ¿por qué puede / no puede?)

... y como extra:

• iniciar / detener servicios del sistema

Tal conjunto de habilidades permite realizar la mayoría de las tareas relacionadas con el desarrollador con facilidad.

Desde mi experiencia con mis numerosos colegas desde que comencé a trabajar, nadie quiere fingir el conocimiento de Unix: o " conocen la línea de comando " o simplemente dicen "¡de ninguna manera!".

Simplemente pregunte si el candidato está dispuesto a trabajar en una estación de trabajo Unix y déjele decirle hasta dónde puede llegar con bash. Eventualmente nombrará algunos comandos; la mayoría de los más obvios son cd, cat, moreo less, vio emacs, grep, awk, sed. Escuche atentamente si menciona man.

Si es para el desarrollo, debe estar familiarizado con makey Makefile, y algunos interfaz de línea de comandos de control de origen ( svn, git, cleartool, hg, cvs...)

¿Por qué hacer esto?

Los shells * nix (y otros shells del sistema operativo, fwiw) son entornos de trabajo muy profundos y amplios. Es posible que alguien pase años trabajando allí y use solo un porcentaje muy pequeño de la capacidad de los depósitos.

Si no espera que la persona a) el programa shell, o b) administre el sistema desde el shell, ¿por qué es importante? Todo lo que se haga estará en un nivel tan básico que una práctica hoja de trucos * nix compensará con creces la "falta de habilidades".

De mi cabeza, probablemente les preguntaría dos cosas:

1. Cuando utilizó la línea de comandos * nix antes, ¿encontró un caso en el que un comando bien pensado le ahorró mucho tiempo? Si es así, elabora.

2. Explique las principales diferencias entre la línea de comandos * nix y un escritorio estándar de Windows. ¿Cuáles son las ventajas y desventajas de cada uno?

Claramente, el primero le dará una indicación de cuán profundo es el conocimiento del solicitante sobre la línea de comando. Si trabajó durante años en un * nix, no solo te dirá que estaba orgulloso de haber tenido una mala racha. No espere que recuerden los comandos exactos, por supuesto (siempre hay páginas de manual para eso), sino la idea general de lo que hicieron.

En cambio, la segunda pregunta verifica si entienden en qué es realmente buena la línea de comandos y para qué no es una herramienta adecuada. Es fácil aprender a usar un martillo, pero es mucho más difícil cambiar a otra herramienta en caso de que el martillo no sea adecuado. Por lo tanto, esta pregunta le da una buena indicación de la opinión del solicitante fuera del cuadro * nix, además de que es lo suficientemente abierta como para que pueda (y deba) calificar con su conocimiento. (Nada peor que responder algo como "uh ... Windows tiene esas ventanas")

Depende de lo que quieras que hagan.

Para obtener información de los archivos de registro, su sugerencia para cat + grep tiene mucho sentido. Agregaría ls, cd y less / more a eso.

Si espera que también realicen algunas ediciones menores (por ejemplo, en archivos de configuración), entonces tendría sentido agregar pruebas para vi y / o emacs y para cosas como cp / mv / rm / mkdir.

Recomiendo que conozcan emacs o vi / m, tar, sed, e / f / grep, los diversos compiladores, algunos scripts de shell. Quizás ejecute una prueba en la que tengan que usar estas herramientas para obtener algún código de un archivo sin abrirlo, insertarlo en otro programa; luego compile el programa que se romperá en algún error trivial. Luego necesitan usar un editor de texto para entrar y encontrar el error, hacer que el código funcione y archivar el binario. Luego envíelo por correo a algún lugar mientras le da permisos al destinatario para ejecutarlo.

No sé sobre ti, pero me molestaría un poco si mi entrevistador me preguntara y no supiera cómo trabajar en Linux.

Realmente no debería importarle lo que saben ahora , sino lo que pueden aprender si tienen la oportunidad. Aprender las herramientas * nix no es demasiado difícil, pero requiere un poco de determinación: realmente debes probar la habilidad en lugar del conocimiento.

Depende del nivel de experiencia que desee que tengan. Si esto no es para alguien que desarrollará para sistemas * nix, y tampoco para administradores de sistemas * nix, sino solo para desarrolladores regulares que a veces necesitan trabajar en un sistema * nix, ¿cuánta experiencia realmente necesitan?

Cualquier cosa que tal desarrollador pueda necesitar en shells * nix (ls, chmod, cat, etc.) probablemente podría escribirse en una hoja de trucos de una sola página. Si es así, requerir conocimiento de shell * nix donde no se requiere podría eliminar algunos buenos candidatos.

Por lo general, elijo una tarea simple y le pido a la persona que escriba un script de shell en una pizarra.

"Tiene un directorio" foo "y un directorio de respaldo" foo_backup ". Escriba un script de shell para ver qué ha cambiado en" foo "desde que" foo_backup "ha cambiado.

'Explicar el proceso de inicio de sesión en Linux, con tantos detalles como te sientas cómodo' es una buena pregunta. El proceso de inicio de sesión implica cambiar usuarios, permisos y propiedades, y mucha filosofía general de Unix. Si pueden explicar claramente cómo y por qué hay un /etc/passwdy /etc/shadow, y cómo un usuario no privado puede cambiar su propia contraseña pero no la de los demás, eso significa que 'obtienen' Unix.

Otra buena es cualquier cosa con análisis de registros o auditorías de seguridad rápidas. Si pueden sumar el ancho de banda total servido para un vhost particular de un registro de Apache, o si hay otros usuarios en el sistema con un uid de 0, son útiles en la línea de comandos.

Y una cosa que NO debe hacerles: no les hagas hacerlo en papel / pizarra. Dales un sistema en vivo (pero no internet porque eso es casi trampa), y míralos ir. Si conocen bien las páginas de manual y pueden construir expresiones de múltiples tuberías sobre la marcha, es una buena señal. Si necesitan google para todo, entonces su conjunto de habilidades es cuestionable.

¿Por qué hacer que escriban un programa funcional? ¿Qué tiene de malo decir "dime la diferencia entre grep y sed, o qué hace el comando X? etc. de esa manera, puedes guiarlos un poco.

si ellos pierden la tarea específica que les das, es posible que no pienses que son inteligentes. pero si haces preguntas generales, les das la oportunidad de mostrarte lo que saben, que puede ser sustancial pero de una manera diferente a lo que te estabas preguntando.

Los gurús de Unix tienen comandos básicos de línea de comandos como sed, grep, etc. en un dedo y pueden usarlos fácilmente para lograr lo que quieren, usando todo tipo de citas, expresiones regulares avanzadas, etc., por lo que a veces ves el script y piensas que sería más fácil de entender escrito en chino;)

Puede esperar que, independientemente de la programación de shell, conozcan al menos un lenguaje de script adicional, como Perl.

Conocerían la configuración interna del sistema Unix, por lo que si les pide que cambien la distribución del teclado (fg agregue algún enlace a la derecha alt +) no se confundirán.

La administración de los paquetes instalados tampoco sería un problema. Instalar Oracle, ejecutar 4 servidores de aplicaciones, cada uno con otra JVM, tampoco hay problema. La configuración de red virtual, el enrutamiento avanzado y el filtrado de puertos, las máquinas virtuales, etc., la gestión de la seguridad, también van allí.