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.
- ¿Les preguntaría desde el contexto de un sistema de base de datos particular (por ejemplo, Oracle) que prefieren?
- ¿Qué tipo de preguntas técnicas les harías?
- ¿Qué escenarios ubicaría y qué buscaría como respuesta a esos escenarios?
- ¿Cómo averiguaría si tienen conocimiento en el manejo de problemas de seguridad?
- Otras preguntas relacionadas (por ejemplo, Restauración / Copia de seguridad de DB)
Gracias.
database
database-administration
DragonBorn
fuente
fuente
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
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)
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.
fuente
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.
fuente
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 ;-)
fuente
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.
fuente
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.
fuente