Como você entrevista um programador de banco de dados / candidato a administrador?

Durante a entrevista, faço perguntas básicas sobre o design do banco de dados. A normalização (quando-por que) é uma das minhas preocupações quando se trata de design de banco de dados. Alguns cenários do site envolvem servidores sincronizados e o que / por que / como eles levam em consideração os problemas relacionados; questões de segurança e assim por diante.

1. Você perguntaria a eles do contexto de um sistema de banco de dados específico (por exemplo, Oracle) que eles preferem?
2. Que perguntas técnicas você gostaria de fazer?
3. Quais cenários você localizaria e o que procuraria como respostas para esses cenários?
4. Como você descobriria se eles têm conhecimento no tratamento de problemas de segurança?
5. Outras questões relacionadas. (por exemplo, restauração / backup de banco de dados)

Obrigado.

Aqui estão as minhas 10 principais perguntas da entrevista para administradores de banco de dados sênior, e aqui estão as 10 principais perguntas de Tom LaRock para DBAs juniores.

Notei que outras pessoas sugerem que o candidato deve solucionar problemas de um servidor. Se você seguir essa abordagem, use uma máquina virtual com um instantâneo. Configure um servidor de uma maneira específica com determinados problemas de configuração ou desempenho, tire uma foto instantânea e, depois de cada entrevista, você poderá reverter para a foto instantânea.

Se você fizer isso, restrinja as tarefas aos tipos de tarefas que você realmente deseja que elas realizem. Não pergunte a um DBA de produção sobre normalização e não pergunte a um DBA de desenvolvimento por que um nó não ingressará no cluster.

As tarefas de DBA de produção podem ser:

• Configure tarefas para backups, manutenção de índice e DBCCs. Veja se eles perguntam com que freqüência você deseja fazer backup do banco de dados e se deseja fazer backup local ou através da rede. Não pergunte a eles como configurar um software de backup em fita específico, a menos que já esteja em seu currículo.
• Descubra por que Johnny não pode fazer login e execute sua consulta.
• Alguém está reclamando de uma consulta lenta. Mostre-me onde você procuraria para descobrir o que está acontecendo. Então diga que eles acabaram de ligar e disseram que a consulta terminou, mas querem garantir que isso não aconteça novamente.
• Restaure uma única tabela do backup da noite passada.

As tarefas de desenvolvimento podem ser:

• Depure este procedimento armazenado.
• Interprete este plano de execução.
• Crie uma exibição para unir clientes às faturas.

Use o esquema AdventureWorks. As probabilidades são de que eles não brincaram com isso recentemente, mas pelo menos é fácil de explicar.

Na minha equipe de software, como parte da entrevista, testamos o entendimento de bancos de dados.

Apresentamos um design muito ruim (pense no aplicativo do tipo CRM) e solicitamos que melhorem o design, após cerca de 30 minutos de tempo de reflexão.

Em seguida, fazemos mais perguntas com base no que elas falam.

Estamos buscando a compreensão de

• Normalização de desempenho V
• Design de Chaves e Integridade Referenital
• Locais para aperfeiçoamento - como estrutura alternativa do banco de dados - gatilhos, exibição, procedimentos
• Áreas que são fracas no design - como superar muitos e muitos relacionamentos
• Como isso afeta o servidor - manutenção
• Problemas de segurança de dados
• Problemas de segurança de aplicativos

Nós, como equipe, pensamos no que consideraríamos respostas do tipo Junior / Senior / Architect para esses tipos de perguntas.

Então, para - Performance / Normisalation -

veria a questão em primeiro lugar e seria capaz de discutir o porquê (Junior)

recomendaria 4/5 NF, mas entenderia o problema com o desempenho, eles desnormalizariam e entenderiam como articular o problema (Sênior)

eles recomendariam um tipo diferente de design, por exemplo, Star Schema e discutissem as implicações em vários níveis (arquiteto)

• Design de Chaves e Integridade Referencial

Veria que a integridade da referência é necessária para impor relacionamentos de dados e seria capaz de discutir isso, mas não veria o problema com Key Choice and Design (Junior)

Discutiria questões relacionadas aos volumes de dados e tipos de dados v procurando chaves naturais nos dados e seria capaz de discutir por que elas estão analisando essas informações - e os problemas que se seguem com integridade referencial (Sênior)

Poderia discutir vários pontos de vista relacionados a Chaves e Integridade e ser capaz de criar vários modelos reais para um design rápido (Arquiteto)

Você entendeu a foto.

Se você quiser que eu adicione mais, poste um comentário e detalhará o que pensamos sobre o resto, mas apenas incluímos os dois primeiros para lhe dar uma idéia do que pensávamos.

O objetivo é pensar nas 1. questões 2. Nós, como equipe , pensamos no que consideraríamos respostas do tipo Júnior / Sênior / Arquiteto para esses tipos de perguntas.

Enfatizo a equipe, pois o candidato e a equipe precisam estar confiantes nas habilidades da pessoa que entra, e se eles tiverem o que vêem como respostas para diferentes níveis, a pessoa que entrar entrará, esperançosamente, em se encaixar melhor na equipe. Também oferece à equipe a capacidade de influenciar a escolha do candidato. Eles também nomeiam uma pessoa para participar do painel de perguntas. Ajuda muito com a adesão da equipe.

Você poderia criar um banco de dados fictício no qual houvesse alguns problemas de normalização, possíveis falhas de segurança, mas que, em geral, parecem bastante típicos, como um banco de dados de funcionários. Em seguida, você pode começar fazendo perguntas simples ao entrevistado, seguindo as orientações de como eles obteriam determinados dados no banco de dados por meio de junções, trabalhando até perguntas mais difíceis sobre problemas de normalização e segurança.

Veja coisas inteligentes e concluídas

... e pergunte a eles quais livros eles leram recentemente, quais blogs eles lêem e quais podcasts eles ouvem. E pergunte se eles participam do stackoverflow.com e serverfault.com ;-)

Isso não é necessariamente relacionado ao banco de dados, mas o que eu gosto de adicionar a uma entrevista é a solução prática de problemas e um cenário de design.

Para o problema prático, tenha um sistema ou sistemas que a pessoa possa acessar e resolva um problema em aberto. Meus favoritos pessoais aqui são questões de desempenho, pois não é necessariamente algo que possa ser reproduzido sob demanda para uma entrevista e raramente há uma resposta correta. Em vez disso, você pode assistir o candidato executar seu processo de solução de problemas e eles também precisarão abrir uma discussão com você para obter mais informações sobre o ambiente. O segredo é que o entrevistador seja honesto sobre o problema e não transforme o cenário em uma caçada aos ovos de Páscoa para a configuração mal configurada ou algo assim.

Para o cenário de design, dou ao candidato um esboço geral de um novo projeto (ou seja, não há dependências herdadas) e peço que eles apresentem um design geral em sua área específica (seja DBA, sistemas ou rede) que atenda às metas do projeto. A chave é manter o projeto pequeno o suficiente para que alguém possa manter todo o cenário em mente e não leva mais que alguns minutos para explicar.

Um exemplo que uso aqui para meus sistemas e pessoal de rede é descrever seu design para uma pequena filial sendo configurada, dadas certas restrições de nossos negócios. No lado do DBA, talvez use um aplicativo CRUD pequeno / óbvio. Em ambos os casos, você não está procurando um design detalhado, mas mais uma visão geral e ver se o candidato procura os problemas comuns que surgem.

O ponto importante para esses dois cenários é abrir uma discussão sobre o tópico e deixar o candidato liderar a discussão com suas próprias perguntas. Deve ficar claro que você também não está pedindo uma resposta exata.

Como você pode imaginar, não gosto muito de curiosidades em entrevistas e acho que isso me dá uma compreensão muito mais profunda das habilidades dos candidatos.

deixe ela falar. pergunte sobre experiências passadas, pergunte quais problemas ele encontrou e como eles lidaram. qual foi a motivação para escolher isso ou aquilo para resolver problemas comuns [backup? monitoramento? expansão, expansão, segurança].

Eu acho que você pode contar muito sobre a pessoa apenas ouvindo.

certamente, se você estiver procurando conhecimentos específicos em determinada área, faça perguntas detalhadas - a sugestão de Stefan Thyberg é muito boa.