Preguntas de Entrevista de SQL Server: Cómo Explicar tu Razonamiento de Base de Datos en Voz Alta

Las preguntas de entrevista de SQL Server rara vez se detienen en el recuerdo de sintaxis. Un panel ya sabe que puedes buscar la cláusula JOIN correcta o la función de ventana. Lo que realmente están probando es si puedes razonar a través de un problema de base de datos en tiempo real y explicar ese razonamiento a otra persona, ya sea que esa persona sea otro DBA, un desarrollador de aplicaciones o un interesado no técnico.

Para funciones orientadas a DBA, espera más peso en copias de seguridad, modelos de recuperación, mantenimiento de índices y configuración del servidor. Para funciones orientadas a desarrollador, espera más peso en patrones de T-SQL, diseño de consultas y cómo tu código interactúa con el optimizador de consultas. La mayoría de las empresas combinan ambos, ya que un desarrollador que entiende indexación escribe consultas más rápidas, y un DBA que entiende lógica de aplicación da mejores consejos de optimización.

Una pregunta de apertura común es algo como "camina por la estrategia de indexación que diseñarías para una nueva tabla de informes." No hay una sola respuesta correcta, así que el entrevistador realmente está puntuando tu proceso: cómo aclaras primero los patrones de consultas, cómo pesas el rendimiento de lectura contra el costo de escritura, y cómo validarías la opción después con datos reales en lugar de adivinar.

El hilo común en cada buena respuesta es la narración. Di qué verificarías primero, por qué lo verificarías, y qué te diría el resultado. Los entrevistadores escuchan un proceso de decisión, no una definición memorizada, y ese hábito de pensar en voz alta vale la pena practicar antes de sentarte frente a un panel.

Las preguntas de indexación son el punto de control técnico más común en una entrevista de SQL Server. Probablemente se te pedirá que describas la diferencia entre un índice clusterizado y uno no clusterizado, cuándo un índice de cobertura ayuda, y cómo acelerarías una consulta que se ejecuta lentamente.

Estructura tu respuesta alrededor de una ruta de diagnóstico real en lugar de una definición de libro de texto. Comienza con el plan de ejecución: "Obtendría el plan de ejecución real y buscaría una exploración donde espero una búsqueda, luego verificaría si las columnas del predicado están indexadas." Explica qué cuesta una búsqueda de clave y cuándo agregar una columna incluida la elimina. Menciona estadísticas: las estadísticas desactualorizadas pueden hacer que el optimizador elija un plan malo incluso cuando existe el índice correcto, y una actualización de estadísticas obsoletas es una de las primeras cosas que verifican los candidatos experimentados.

A los entrevistadores también les gusta profundizar con preguntas de seguimiento sobre índices filtrados, factor de relleno y fragmentación de índices. Prepárate para explicar que un índice filtrado solo cubre un subconjunto de filas y puede reducir dramáticamente el tamaño de un índice en una columna principalmente nula o principalmente inactiva, y que el factor de relleno intercambia algo de espacio desperdiciado hoy por menos divisiones de página después en una tabla con inserciones pesadas.

Respuesta de ejemplo: "Una consulta de informe se estaba agotando porque filtraba en una columna sin índice y unía tres tablas grandes. Obtuve el plan, vi una exploración de índice clusterizado y una clasificación costosa, agregué un índice no clusterizado en la columna de filtro con columnas incluidas para la lista SELECT, actualicé estadísticas, y la exploración se convirtió en una búsqueda. La duración cayó de doce segundos a menos de uno." Ese tipo de historia específica de causa y efecto es lo que distingue una respuesta fuerte de una genérica.

Más allá de las declaraciones SELECT básicas, los entrevistadores generalmente investigan un puñado de áreas de T-SQL: funciones de ventana como ROW_NUMBER, RANK y DENSE_RANK, expresiones de tabla común versus tablas temporales, lógica basada en conjuntos versus cursores, y cómo NULL se comporta en comparaciones y agregados.

Cuando se te pregunte por qué evitarías un cursor, no solo digas "los cursores son lentos." Explica el mecanismo: un cursor procesa filas una a la vez, mientras que una consulta basada en conjuntos permite que el optimizador trabaje en todo el conjunto de resultados a la vez, lo cual casi siempre es más rápido a escala. Si un cursor es realmente la herramienta correcta, por ejemplo en un script administrativo que debe ejecutarse en una secuencia estricta, di que sí y explica por qué.

También se te puede pedir que compares una tabla temporal y una variable de tabla. Una buena respuesta cubre alcance, comportamiento de registro de transacciones y el hecho de que el optimizador crea estadísticas para tablas temporales pero no para variables de tabla, lo que importa para planes de consultas en recuentos de filas más grandes. Mantén la explicación práctica: describe cuándo realmente elegiste una sobre la otra y qué cambió como resultado.

Espera al menos una pregunta sobre tipos de unión y construcción de consultas: la diferencia entre un INNER JOIN y un LEFT JOIN, cuándo un CROSS APPLY es útil para lógica fila por fila que un JOIN plano no puede expresar, y cómo una declaración MERGE puede combinar una inserción, actualización y eliminación en una operación. También es posible que obtengas una pregunta corta sobre manejo de errores con TRY/CATCH y cómo XACT_ABORT cambia el comportamiento de reversión dentro de una transacción. Responde cada uno nombrando una situación real donde la usaste, no solo la sintaxis.

Las preguntas de diseño prueban si piensas en un esquema antes de pensar en una consulta. Espera una pregunta sobre normalización: por qué dividir datos en tablas relacionadas reduce anomalías de actualización, y cuándo desnormalizar una tabla a propósito para rendimiento de lectura es un intercambio razonable en lugar de un error.

Preparate para explicar la diferencia entre una clave primaria y una restricción única, por qué una clave foránea importa incluso cuando la aplicación impone la relación en código, y cómo elegirías entre una clave natural y una clave sustituta para una nueva tabla. Si se te pregunta sobre una columna de identidad versus un GUID como clave primaria, menciona el impacto práctico: una identidad secuencial mantiene inserciones de índice clusterizado eficientes, mientras que un GUID aleatorio puede fragmentar el índice rápidamente a menos que uses una variante secuencial.

Una pregunta de seguimiento orientada al diseño podría pedirte que esbocés un esquema para un escenario específico, como un sistema de pedidos con clientes, productos y elementos de línea. Narra tu pensamiento: qué entidades necesitan su propia tabla, qué columnas deberían indexarse para los patrones de consulta esperados, y dónde una restricción atraparía una inserción mala antes de que se convierta en un problema de calidad de datos aguas abajo.

Las preguntas de copia de seguridad y recuperación verifican si entiendes los intercambios detrás de una estrategia de recuperación, no solo los comandos. Prepárate para explicar los tres modelos de recuperación: simple, completo y masivo registrado, y cómo cada uno afecta si la recuperación a un momento específico es incluso posible.

Camina por la diferencia entre una copia de seguridad completa, una copia de seguridad diferencial y una copia de seguridad de registro de transacciones, y cómo se combinan durante una restauración. Los entrevistadores frecuentemente hacen seguimiento con un escenario: la base de datos falló a las 2 p.m., tu última copia de seguridad completa fue anoche, y tienes copias de seguridad de registro cada quince minutos. Responde nombrando la secuencia de restauración y el punto de recuperación resultante, luego conéctalo a RPO y RTO en términos simples: cuánta pérdida de datos es aceptable, y cuán rápidamente el sistema necesita recuperarse.

Las entrevistas más senior también pueden pedirte que compares opciones de alta disponibilidad a nivel conceptual: cómo los grupos de disponibilidad Always On difieren del envío de registro, y por qué una empresa aún podría elegir la opción más simple aunque se recupere más lentamente. No necesitas haber configurado cada opción, pero debes poder explicar qué problema resuelve cada una.

Si has manejado una restauración o conmutación por error real, descríbelo brevemente: qué se rompió, qué cadena de copia de seguridad usaste, cuánto tiempo tomó la restauración, y qué cambiaste después para reducir la ventana de recuperación la próxima vez. Mencionar que realmente pruebas restauraciones en un cronograma, en lugar de asumir que un archivo de copia de seguridad está bien hasta que se demuestre lo contrario, es el tipo de detalle que señala experiencia operativa real.

Las preguntas de transacciones prueban si entiendes qué sucede cuando varios usuarios tocan los mismos datos al mismo tiempo. Comienza con ACID: atomicidad, consistencia, aislamiento y durabilidad, luego muévete rápidamente hacia algo más concreto que el acrónimo.

Prepárate para comparar niveles de aislamiento: lectura confirmada, que es el predeterminado de SQL Server, versus lectura no confirmada, lectura repetible, serializable e aislamiento de instantánea. Explica qué problema resuelve cada uno, como lecturas sucias o lecturas fantasma, y qué cuesta en concurrencia. Un candidato fuerte también puede describir cómo el aislamiento de instantánea utiliza el versionado de filas en tempdb en lugar de bloquear lectores contra escritores, y por qué eso puede intercambiar memoria y carga de tempdb por menos quejas de bloqueo de equipos de aplicaciones.

Las preguntas de punto muerto surgen a menudo. Describe cómo identificarías uno usando el gráfico de punto muerto en Eventos Extendidos, explica qué es realmente un punto muerto, dos sesiones cada una sosteniendo un bloqueo que la otra necesita, y describe una corrección como reordenar consistentemente el acceso a tablas o acortar la transacción. Si el entrevistador pregunta sobre pistas de bloqueo como NOLOCK o ROWLOCK, explica el intercambio claramente: NOLOCK evita bloqueo pero puede devolver filas no confirmadas o duplicadas, por lo que pertenece a consultas de informes donde resultados aproximados son aceptables, no en cálculos financieros.

Un candidato que puede narrar una investigación de punto muerto paso a paso, desde notar el tiempo de espera, hasta obtener el gráfico, hasta identificar qué consulta reescribir, generalmente se destaca más que uno que solo define el término.

Una pregunta frecuente de entrevista de SQL Server te pide que expliques cómo diagnosticar un servidor que de repente se ralentiza. Trátalo como una narración de solución de problemas en vivo, no como una lista de herramientas. Comienza con lo que verificarías primero: estadísticas de espera actuales, solicitudes activas y sesiones de bloqueo, usando vistas como sys.dm_exec_requests, sys.dm_exec_sessions y sys.dm_os_wait_stats.

Explica cómo distinguirías entre un problema vinculado a CPU, un problema vinculado a E/S y una cadena de bloqueo nombrando los tipos de espera que buscarías, como esperas PAGEIOLATCH señalando presión de disco o esperas LCK_M_X señalando bloqueo. Menciona contención de tempdb como una causa común pero frecuentemente pasada por alto de lentitud inexplicable, especialmente en servidores con actividad pesada de tablas temporales o clasificación, y menciona "parameter sniffing" como una causa de una consulta que se ejecuta rápido para una entrada y lentamente para otra usando el mismo plan en caché.

Si el entrevistador presiona más, describe cómo aislarías la consulta específica: capturando una sesión de seguimiento o Eventos Extendidos, luego revisando el plan de ejecución para la declaración ofensiva, y comparando recuentos de filas estimados versus reales para confirmar si una estimación mala está causando la lentitud.

Los entrevistadores hacen estas preguntas basadas en escenarios porque leer una definición de una diapositiva es fácil, pero narrar una investigación en vivo bajo presión de tiempo no lo es. Practicar la secuencia en voz alta, en el orden que realmente la realizarías, hace la diferencia obvia para cualquiera que escuche.

Construye una lista breve de escenarios reales de tu trabajo: una corrección de indexación, una investigación de punto muerto o bloqueo, una situación de copia de seguridad o restauración, y una reescritura de consulta que mejorara el rendimiento. Para cada uno, escribe el síntoma, tus pasos de diagnóstico, la corrección y el resultado medible.

Luego practica diciendo cada historia en voz alta, no solo leyéndola silenciosamente. Las entrevistas técnicas recompensan candidatos que pueden explicar una decisión claramente bajo presión de tiempo, y esa habilidad no viene de releer notas. SayNow te permite ensayar preguntas de entrevista de SQL Server con indicaciones de seguimiento realistas, para que te acostumbres a explicar un plan de ejecución o una opción de nivel de aislamiento en conversación en lugar de en tu cabeza por primera vez durante la entrevista real.

Ensayar en voz alta también expone las brechas que la revisión silenciosa oculta. Es común pensar que entiendes claramente los niveles de aislamiento hasta que intentas explicar el aislamiento de instantánea a otra persona y te das cuenta de que tu explicación se desmorona a mitad de camino. Atraparlo en la práctica es mucho mejor que atraparlo frente a un panel de contratación.

Finalmente, prepara un par de preguntas propias: cómo el equipo monitorea el rendimiento de consultas, cómo se ve su proceso de prueba de copia de seguridad y recuperación, o cómo se revisan los cambios de esquema. Las preguntas reflexivas señalan el mismo juicio operativo que la entrevista estaba probando en primer lugar.