Entrevistando alguém para habilidades gerais em unix [fechado]

Como você testaria um desenvolvedor que afirma ter experiência com o shell * nix (apenas para deixar claro, não queremos testar se alguém pode desenvolver o * nix, apenas que eles conheçam a linha de comando).

Eu estava pensando em fazê-los resolver um problema de obter informações dos arquivos de log, o que envolveria alguns princípios básicos como gato, grep, corte, ... combinados com tubulação.

Que outro conhecimento básico você pediria? Mais uma vez, isso não é para entrevistar alguém que desenvolverá sistemas * nix, e também não para administradores de sistemas * nix, mas apenas para desenvolvedores regulares que às vezes precisam trabalhar em um sistema * nix.

Da minha experiência pessoal, o desenvolvedor que trabalha em um sistema * nix precisa saber:

• variáveis ​​de shell (como definir / obter + conhecimento sobre variáveis ​​especiais como PATH)
• redirecionamento de shell (captura de saída de um programa)
• pipes (extrair algumas informações do arquivo de log é um excelente exemplo)
• controle de processo (ps, nice / renice, kill)
• direitos de acesso a arquivos (ls / chmod / chown / chattr)
• usuários (mas principalmente no contexto de arquivos / processos, ou seja: este processo é capaz de acessar esse arquivo? por que ele pode / não pode?)

... e como um bônus:

• iniciando / parando serviços do sistema

Esse conjunto de habilidades permite executar a maioria das tarefas relacionadas ao desenvolvedor com facilidade.

Pela minha experiência com meus inúmeros colegas desde que comecei a trabalhar, ninguém quer falsificar o conhecimento do Unix: eles " sabem o que fazer na linha de comando " ou simplesmente dizem "de jeito nenhum!".

Basta perguntar se o candidato está disposto a trabalhar em uma estação de trabalho Unix e deixá-lo dizer até onde ele pode passar pelo bash. Ele eventualmente nomeará alguns comandos; As mais óbvias são cd, cat, moreou less, viou emacs, grep, awk, sed. Ouça com atenção se ele menciona man.

Se é para o desenvolvimento, ele deve estar familiarizado com makee Makefiles, e alguns interface de linha de comando de controle de origem ( svn, git, cleartool, hg, cvs...)

Por que fazer isso?

Os shells * nix (e outros shells do SO, fwiw) são ambientes de trabalho muito profundos e amplos. É possível que alguém passe anos trabalhando lá e use apenas uma% muito pequena da capacidade das conchas.

Se você não espera que a pessoa a) conceda um programa ou b) administre o sistema a partir do shell, por que isso importa? Tudo o que for feito será em um nível tão básico que uma cábula * nix útil compensará mais do que a "falta de habilidades".

Do alto da minha cabeça, eu provavelmente perguntaria a eles duas coisas:

1. Quando você usou a linha de comando * nix antes, encontrou um caso em que um comando bem pensado economizava muito tempo? Se sim, elaborado.

2. Por favor, explique as principais diferenças entre a linha de comando * nix e uma área de trabalho padrão do Windows. Quais são as vantagens e desvantagens de cada um?

Claramente, o primeiro fornecerá uma indicação de quão profundo é o conhecimento do candidato sobre a linha de comando. Se ele trabalhou durante anos no * nix, ele não apenas diz que estava orgulhoso de ter feito um grep. Não espere que eles se lembrem dos comandos exatos, é claro (sempre há páginas de manual para isso), mas da ideia geral do que eles fizeram.

A segunda pergunta verifica se eles entendem no que a linha de comando é realmente boa e para o que não é uma ferramenta adequada. É fácil aprender a usar um martelo, mas é muito mais difícil mudar para outra ferramenta, caso o martelo seja inadequado. Portanto, essa pergunta fornece uma boa indicação da visão do candidato fora da caixa * nix, além de ser suficientemente aberta para que ele possa (e deve) pontuar com seu conhecimento. (Nada pior do que responder a algo como "uh .. o Windows tem essas janelas")

Depende do que você quer que eles façam.

Para obter informações dos arquivos de log, sua sugestão para o cat + grep faz todo o sentido. Eu adicionaria ls, cd e menos / mais a isso.

Se você espera que eles também façam algumas edições menores (digamos, nos arquivos de configuração), faria sentido adicionar testes para vi e / ou emacs e para coisas como cp / mv / rm / mkdir.

Eu recomendo que eles conheçam emacs ou vi / m, tar, sed, e / f / grep, os vários compiladores, alguns scripts de shell. Talvez faça um teste em que eles tenham que usar essas ferramentas para pegar algum código de um arquivo sem abri-lo, insira-o em outro programa; então compile o programa que irá quebrar com algum erro trivial. Eles precisam usar um editor de texto para encontrar o erro, colocar o código em funcionamento e arquivar o binário. Em seguida, envie-o para algum lugar enquanto concede permissões ao destinatário para executá-lo.

Eu não sei sobre você, mas ficaria meio irritado se meu entrevistador me perguntasse e eu não soubesse trabalhar no Linux.

Você realmente não deveria se importar com o que eles sabem agora , mas com o que eles podem aprender se tiverem a chance. Aprender as ferramentas * nix não é muito difícil, mas é preciso um pouco de determinação - você deve realmente testar a capacidade e não o conhecimento.

Depende do nível de experiência que você deseja que eles tenham. Se isso não é para alguém que desenvolverá sistemas * nix, e também não para administradores de sistemas * nix, mas apenas para desenvolvedores regulares que às vezes precisam trabalhar em um sistema * nix, de quanta experiência eles realmente precisam?

Qualquer coisa que esse desenvolvedor possa precisar nos shells * nix (sl, chmod, cat etc.) provavelmente pode ser escrita em uma única página de dicas. Nesse caso, exigir o conhecimento do * nix shell onde não é necessário pode eliminar alguns bons candidatos.

Normalmente, escolho uma tarefa simples e peço à pessoa que escreva um script de shell em um quadro branco.

"Você possui um diretório" foo "e um diretório de backup" foo_backup ". Escreva um script de shell para ver o que mudou em" foo "desde que" foo_backup "foi alterado.

'Explique o processo de login no Linux, com o máximo de detalhes que você se sentir confortável', é uma boa pergunta. O processo de login envolve a troca de usuários, permissões e propriedades, e muita filosofia geral do Unix. Se eles puderem explicar claramente como e por que há uma/etc/passwd e /etc/shadow, e como um usuário não privado pode alterar sua própria senha, mas não outras, isso significa que eles 'obtêm' o Unix.

Outra coisa boa é qualquer coisa com análise de log ou auditorias rápidas de segurança. Se eles puderem adicionar a largura de banda total atendida para um vhost em particular a partir de um log do Apache, ou descobrir se há outros usuários no sistema com um uid de 0, eles serão úteis na linha de comando.

E uma coisa a NÃO fazer com eles: não os faça fazer em papel / quadro branco. Dê a eles um sistema ao vivo (mas sem internet porque isso é quase trapaça) e observe-os partir. Se eles conhecem as páginas de manual e conseguem criar expressões de vários canais rapidamente, isso é um bom sinal. Se eles precisam do google para tudo, então suas habilidades são questionáveis.

por que fazê-los escrever um programa funcional? o que há de errado em dizer "me diga a diferença entre grep e sed, ou o que o comando X faz? etc. dessa maneira, você pode orientá-los um pouco.

se eles se atrapalharem com a tarefa específica que você lhes der, talvez não pense que são inteligentes. mas, se você fizer perguntas gerais, terá a chance de mostrar o que elas sabem, o que pode ser substancial, mas de uma maneira diferente da que você estava pensando.

Os gurus do Unix têm comandos principais de linha de comando como sed, grep etc. em um dedo e podem facilmente usá-los para alcançar o que desejam, usando todos os tipos de citações, expressões regulares avançadas etc., portanto, às vezes, você vê o script e pensa que seria mais fácil de entender sendo escrito em chinês;)

Você pode esperar que, independentemente da programação do shell, eles conhecerão pelo menos uma linguagem de script adicional, como Perl.

Eles conheceriam as configurações internas do sistema Unix, portanto, se você pedir para alterar o layout do teclado (fg adicione alguma ligação à alt + alt direita), eles não ficarão confusos.

Gerenciar pacotes instalados também não seria problema. Instalar o Oracle, executando 4 servidores de aplicativos, cada um com outra JVM - também não há problema. Configuração de rede virtual, roteamento avançado e filtragem de portas, máquinas virtuais etc., gerenciando a segurança - também vai para lá.