O que devo perguntar em uma entrevista MySQL DBA?

Não é uma lista completa, mas uma lista aproximada de coisas que eu tentaria cobrir. Também depende se eles serão o primeiro DBA "verdadeiro" ou em uma equipe de DBA. Se o DBA é responsável pelas máquinas também ou apenas pelo banco de dados em cima disso. etc.

• qual configuração de RAID deve ser usada
• estratégias de backup para bancos de dados.
• Coisas específicas do MySQL, como diferenças entre MyISAM e InnoDB
• estratégias de backup e recuperação
• Deixe-os fazer algumas consultas SQL e alguma otimização de consulta (uso de explicação, etc., mesmo ao usar o hibernate. Às vezes, é bom ignorar o hibernate para obter desempenho)
• eu mencionei estratégias de backup
• Para escalabilidade, um DBA deve conhecer os diferentes modos de replicação (RBR, SBR, replicação de modo misto, manutenção de replicação, como observar o atraso da replicação e a manutenção do binlog)
• Ajuste do InnoDB
• Que tipo de arquivos estão sendo gravados pelo banco de dados (por exemplo, ibdata e arquivos de log) e como eles podem ser organizados (por exemplo, um arquivo ibdata por tabela, mova-os em diferentes partições, compactação InnoDB)
• Discutir ferramentas de monitoramento. O que você está usando, eles têm experiência com essa ferramenta ou similar?
• Eu também procuraria ferramentas do sistema como iostat/memstat/vmstat/qualquer que seja o seu sistema operacional. Dê a eles um sistema com alguma carga e deixe-os encontrar a causa
• E talvez discutir problemas no backup do MySQL e especialmente restaurar ;-)

Tenho certeza que outros aqui podem estender esta lista

Eu sugiro olhar também algumas listas já estabelecidas sobre entrevistas de DBA:

• As 10 principais perguntas da entrevista de DBA do SQL Server - por nosso próprio Brent Ozar

  • perguntas favoritas:
  • "Você pode me dar referências de outros DBAs e desenvolvedores que não estão na sua empresa?"
  • "Uma gerente de projeto precisa de um novo SQL Server. O que você pergunta a ela?"

• Perguntas de entrevista de DBA júnior - pelo nosso próprio Thomas LaRock

  • pergunta favorita: "Se eu pedisse para você aprender a fazer uma consulta mais rápida, onde você iria?"

• Perguntas de triagem de banco de dados - por Grant Fritchey

  • pergunta favorita: "Você é o DBA. O telefone toca. Um dos usuários está na linha. Eles dizem "O banco de dados está lento". Então eles desligam. O que você faz?

Eles são todos ótimos escritores do SQL Server. Sei que algumas das perguntas podem ser orientadas para o SQL Server, mas a maioria não é e pode ser usada em uma entrevista geral de DBA.

Escrevi sobre isso há algum tempo , depois de contribuir com o processo de entrevista na Percona.

Eu acho que para avaliar alguém, você tem que tentar fazer com que ela faça o que ela faria no dia-a-dia normal. Perguntas aleatórias como "O que é um tipo de dados seriais no MySQL?" ou questões de inteligência como "por que os buracos humanos são redondos?" não consiga isso.

Você também quer ter certeza de dar a todos o mesmo teste. Se você tiver uma entrevista apenas para conversa aberta, as pessoas mais confiantes e (um pouco manipuladoras) se destacarão, pois podem sutilmente contornar suas perguntas e transformá-las em outras que sejam boas em responder. Você nem sempre vai perceber quando isso está acontecendo, mas geralmente contém algo como "quando comecei como DBA, tínhamos 2 MB de RAM e fitas usadas ... blá, blá, blá": P

Dito isso, aqui está minha lista padrão de perguntas:

• Descreva o processo pelo qual a replicação do MySQL funciona?
• O que o componente D do ACID significa em termos práticos?
• O que innodb_flush_method=O_DIRECT muda? (Tenha cuidado com este: o entendimento comum disso geralmente está errado .)
• Digamos que eu escreva uma consulta como "INSERT INTO my_table (a,b) VALUES (1,2)". Descreva-me com o máximo de detalhes possível o que acontece dentro do MySQL.

Embora eu concorde que as muitas perguntas aparentemente aleatórias da entrevista (por exemplo, a tampa do bueiro), não são realmente úteis ... (exceto, talvez para um designer industrial, e apenas para esse caso).

Depois de superar o aspecto trivial de muitos deles, eles devem ser coisas para as quais você não sabe a resposta e, portanto, você terá que descrever como faria para encontrar a resposta. Ou não. Por exemplo:

• invente algo plausível e/ou tente fazer besteira. (pode ser útil para vendas e marketing? qualquer outro campo, não contrate.)
• estimar com base em outras informações
• explique como você obteria as informações necessárias para resolver o problema

... etc.

Quando estive encarregado do processo de contratação no passado, tento fazer uma entrevista por telefone completamente não agendada de 5 a 15 minutos (basta ligar para eles, se eles puderem lhe dar alguns minutos... nem todos podiam, pois alguns estavam no trabalho que planejavam sair) ... só para avaliar o quanto eu acho que eles estão falando besteira em seus currículos.

Por exemplo, quando estávamos contratando um programador PL/SQL sênior, eu perguntava quais eram as partes de um bloco PL/SQL. Hoje em dia, é a primeira coisa que aparece no Google ... não era o caso em 2003. A maioria das pessoas que entrevistamos pode ter usado Oracle antes, pode ter escrito SQL para Oracle ... mas se você não pode me dar uma pista de que você sabe como é um bloco PL/SQL, você não está pronto para um trabalho de programador PL/SQL sênior.

...

E, dito isso, minha pergunta para qualquer entrevista pessoal é:

Guerra nas Estrelas ou Jornada nas Estrelas?

Em parte, você consegue ver como eles lidam com uma situação em que não há a melhor resposta, se são diplomáticos em suas respostas ou se pensam fora da caixa (por exemplo, Dr. Who ou Firefly são respostas válidas). Onde eu trabalho atualmente (um laboratório de física espacial), dizer que você nunca viu nenhum dos dois pode ser um fracasso, a menos que você seja estrangeiro. Dizer que você também não gosta e explicar por que com um bom motivo seria um passe, no entanto. Falar demais sobre qualquer um deles ainda pode ser um fracasso (já que ninguém quer trabalhar com essa pessoa)