¿Cómo se entrevista a un solicitante de programador / administrador de bases de datos?

Durante la entrevista, hago preguntas básicas de diseño de bases de datos. La normalización (cuándo-por qué) es una de mis preocupaciones cuando se trata del diseño de bases de datos. Algunos escenarios I sitio que implica servidores sincronizados y qué / por qué / cómo toman en cuenta los problemas relacionados; problemas de seguridad, etc.

1. ¿Les preguntaría desde el contexto de un sistema de base de datos particular (por ejemplo, Oracle) que prefieren?
2. ¿Qué tipo de preguntas técnicas les harías?
3. ¿Qué escenarios ubicaría y qué buscaría como respuesta a esos escenarios?
4. ¿Cómo averiguaría si tienen conocimiento en el manejo de problemas de seguridad?
5. Otras preguntas relacionadas (por ejemplo, Restauración / Copia de seguridad de DB)

Gracias.

Aquí están mis 10 preguntas principales para los administradores de bases de datos senior, y aquí están las 10 preguntas principales de Tom LaRock para los DBA junior.

Me he dado cuenta de que otras personas sugieren que el candidato debe solucionar los problemas de un servidor. Si adopta ese enfoque, use una máquina virtual con una instantánea. Configure un servidor de una manera específica con ciertos problemas de configuración o rendimiento, tome una instantánea del mismo y luego, después de cada entrevista, pueda volver a la instantánea.

Si haces eso, limita las tareas a los tipos de tareas que realmente harías que hicieran. No le pregunte a un DBA de producción acerca de la normalización, y no le pregunte a un DBA de desarrollo por qué un nodo no se unirá al clúster.

Las tareas de producción de DBA pueden ser:

• Configure trabajos para copias de seguridad, mantenimiento de índices y DBCC. Vea si le preguntan con qué frecuencia desea que se realice una copia de seguridad de la base de datos y si desea que se realice una copia de seguridad local o en toda la red. No les pregunte cómo configurar un software de copia de seguridad de cinta en particular a menos que ya esté en su currículum.
• Descubra por qué Johnny no puede iniciar sesión y ejecutar su consulta.
• Alguien se queja de una consulta lenta. Muéstrame dónde buscarías para saber qué está pasando. Luego diga que acaban de llamar y dijeron que su consulta ha finalizado, pero quieren asegurarse de que no vuelva a suceder.
• Restaurar una sola tabla de la copia de seguridad de la noche anterior.

Las tareas de desarrollo pueden ser:

• Depure este procedimiento almacenado.
• Interpreta este plan de ejecución.
• Cree una vista para unir clientes a las facturas.

Use el esquema AdventureWorks. Lo más probable es que no hayan jugado recientemente, pero al menos es fácil de explicar.

En mi equipo de software como parte de la entrevista, probamos la comprensión de las bases de datos.

Presentamos un diseño muy pobre (piense en la aplicación de tipo CRM) y les pedimos que mejoren el diseño, después de aproximadamente 30 minutos de tiempo de reflexión.

Luego les hacemos más preguntas en función de lo que hablan.

Estamos investigando para comprender

• Performance V Normalistion
• Diseño clave e integridad de referencia
• Lugares para la mejora -es decir, Estructura de base de datos alternativa - Disparadores, Vista, Procedimientos
• Áreas que son débiles en el diseño: cómo superar muchas relaciones
• Cómo afecta esto al servidor - mantenimiento
• Problemas de seguridad de datos
• Problemas de seguridad de la aplicación

Nosotros, como equipo, hemos pensado en lo que consideraríamos respuestas de tipo Junior / Senior / Architect para este tipo de preguntas.

Entonces para - Rendimiento v Normisalación -

vería el problema en primer lugar y podría discutir por qué (Junior)

recomendaría 4/5 NF pero entendería el problema con el rendimiento si lo normalizarían y entenderían cómo articular el problema (Senior)

recomendarían un tipo diferente de diseño, por ejemplo, Star Schema y discutirían las implicaciones en muchos niveles (Arquitecto)

• Diseño clave e integridad referencial

Vería que la integridad de referencia es necesaria para hacer cumplir las relaciones de datos y podría discutir esto, pero no vería el problema con Key Choice and Design (Junior)

Discutiría cuestiones relacionadas con los volúmenes de datos y los tipos de datos v buscando claves naturales en los datos y sería capaz de analizar por qué los están analizando, y los problemas que siguen con integridad referencial (Senior)

Podría argumentar varios puntos de vista relacionados con las claves y la integridad y ser capaz de proponer varios modelos reales para un diseño rápido (Arquitecto)

Te dan la imagen.

Si desea que agregue más, publique comentarios y detallaré lo que pensamos sobre el resto, pero solo incluí los dos primeros para darle una idea de lo que pensamos.

El punto es pensar en 1. las preguntas 2. Nosotros, como equipo, hemos pensado en lo que consideraríamos respuestas de tipo Junior / Senior / Architect para este tipo de preguntas.

Hago hincapié en el equipo ya que el candidato y el equipo tienen que confiar en las habilidades de la persona que ingresa, y si han llegado a lo que ven como respuestas a diferentes niveles, la persona que ingresa con suerte encajará mejor con el equipo. También le da al equipo la capacidad de influir en la elección del candidato. También nominan a una persona para que forme parte del panel de preguntas. Ayuda mucho con la aceptación del equipo.

Podría crear una base de datos ficticia en la que hubiera algunos problemas de normalización, posibles fallas de seguridad pero que en general se ve bastante típica, como una base de datos de empleados. Luego, puede comenzar haciendo preguntas sencillas al entrevistado sobre cómo conseguirían obtener ciertos datos en la base de datos a través de uniones, avanzando hacia preguntas más difíciles sobre los problemas de normalización y seguridad.

Ver inteligente y hacer las cosas

... y pregúntales qué libros han leído últimamente, qué blogs leen y qué podcasts escuchan. Y pregunte si participan en stackoverflow.com y serverfault.com ;-)

Esto no está necesariamente relacionado con la base de datos, pero las cosas que me gusta agregar a una entrevista son la resolución práctica de problemas y un escenario de diseño.

Para el problema práctico, tenga un sistema o sistemas a los que la persona pueda acceder y haga que solucionen un problema abierto. Mis favoritos personales aquí son problemas de rendimiento, ya que no necesariamente es algo que se puede reproducir a pedido para una entrevista y rara vez hay una respuesta correcta. En cambio, puede ver al candidato ejecutar su proceso de solución de problemas y también necesitará abrir una discusión con usted para obtener más información sobre el entorno. La clave es que el entrevistador sea honesto sobre el problema y no convierta el escenario en una búsqueda de huevos de pascua para un entorno mal configurado o algo así.

Para el escenario de diseño, le doy al candidato un resumen general de un nuevo proyecto (es decir, sin dependencias heredadas) y le pido que presente un diseño general en su área particular (ya sea DBA, sistemas o red) que cumpla con los objetivos del proyecto. La clave es mantener el proyecto lo suficientemente pequeño como para que alguien pueda tener todo el escenario en su cabeza y no demore más de unos minutos en explicarlo.

Un ejemplo que uso aquí para mis sistemas y personas de la red es describir su diseño para una sucursal pequeña que se está configurando, dadas ciertas restricciones de nuestro negocio. En el lado de DBA, tal vez use una aplicación CRUD pequeña / obvia. En cualquier caso, no está buscando un diseño detallado, sino más bien una visión general y ver si el candidato busca los problemas comunes que surgen.

El punto importante para estos dos escenarios es abrir una discusión sobre el tema y dejar que el candidato dirija la discusión con sus propias preguntas. Debe quedar claro que no está pidiendo una respuesta exacta a ninguno de los dos.

Como puede imaginar, me disgustan mucho las trivias en las entrevistas, y creo que esto me da una comprensión mucho más profunda de las habilidades de los candidatos.

déjalo hablar. pregunte acerca de la experiencia pasada, pregunte qué problemas encontró [s] y cómo se manejaron. ¿Cuál fue la motivación para elegir esto o aquello para resolver problemas comunes [copia de seguridad? ¿supervisión? ampliación, ampliación, seguridad].

Creo que se puede decir mucho sobre la persona simplemente escuchando.

maleducado, entonces, si está buscando experiencia específica en un área determinada, haga preguntas detalladas; la sugerencia de Stefan Thyberg es muy buena.