¿Alguna vez has tenido que cubrir un puesto relacionado con bases de datos SQL y has sentido que el perfil parecía más un conjuro que una oferta de empleo? Tranquilo, no estás solo. Lo de “buscamos un DBA que también sepa de Power BI, Python, backups, modelado de datos, administración de Azure, tuning de consultas, y que además tenga skills de comunicación” no es una exageración. Es literalmente lo que me he encontrado más de una vez. Y no, no es viable.
Este artículo no es para criticar (bueno, solo un poco), sino para ayudar. Está dirigido a profesionales de selección de personal que, sin ser técnicos, tienen que enfrentarse al reto de reclutar a alguien que sí lo es. Alguien que, además, trabaja con eso tan abstracto y escurridizo que es “el mundo SQL”.
Vamos a dejar claras las diferencias entre los principales perfiles de datos que tocan SQL, porque no todos hacen lo mismo, y desde luego no se les puede tratar como si fueran intercambiables. También repasaremos un glosario básico de términos que no hacen falta dominar, pero sí reconocer para no quedar en evidencia durante una entrevista.
Todos tocan SQL, pero no son lo mismo
Lo primero que hay que entender es que “saber SQL” no define un perfil. Es como decir que alguien que sabe escribir puede ser novelista, abogado, periodista o copywriter. Todos escriben, pero no tienen el mismo rol ni se enfrentan a los mismos problemas.
El DBA (Database Administrator)
El DBA es el responsable de que la base de datos funcione. Y no me refiero solo a que “funcione”, sino a que sea segura, estable, rápida y que no explote cuando más falta hace. Hay varios tipos de DBAs: los hay de infraestructura (montan y configuran el servidor, las instancias, se pelean con el almacenamiento), de rendimiento (se dedican a afinar consultas, crear índices, revisar planes de ejecución), y también los que cubren todo y sobreviven a base de café y alerts.
No confundas un DBA de SQL Server con uno de Oracle, ni con uno de PostgreSQL. No, no son equivalentes. Los conceptos se parecen, pero los comandos, herramientas, modos de operar y hasta las buenas prácticas cambian.
El desarrollador SQL o de BI
Este perfil sí escribe SQL todos los días, pero con un objetivo muy distinto al del DBA. Se dedica a generar consultas, crear procedimientos almacenados, hacer informes, alimentar modelos de datos o integrar fuentes externas. Suele moverse en entornos de reporting, ETL o modelado. Si sabe hacer backups, probablemente es porque un día le tocó hacerlo a él y no había nadie más.
El analista de datos
Aquí la confusión es habitual. El analista suele consumir datos, no gestionarlos. Sabe lanzar consultas (normalmente sencillas), trabajar con herramientas de visualización como Power BI o Tableau, y generar conclusiones. No se le puede pedir que optimice un índice ni que diseñe un modelo físico de base de datos. Es otro rol.
El ingeniero de datos
Este perfil está más cerca de la infraestructura moderna, los pipelines, la automatización y las arquitecturas distribuidas. Sabe de SQL, pero también de Spark, Azure Data Factory, Synapse, Databricks y similares. Le puedes hablar de particionamiento, de lag en streaming y de integración con data lakes, pero probablemente no sabe mucho de tuning en SQL Server.
Y sí, la tecnología importa
Cada sistema gestor tiene sus peculiaridades. Un experto en MySQL no puede entrar mañana a administrar SQL Server sin un mínimo periodo de adaptación. Ni los comandos son los mismos, ni las herramientas de administración, ni el enfoque. Que todos hablen SQL no significa que hagan lo mismo.
Errores frecuentes al redactar una oferta de trabajo técnica con SQL
Si has cometido alguno de estos, no te preocupes. A todos nos ha pasado. Pero aquí van unas cuantas cosas que conviene evitar:
- Mezclar perfiles incompatibles. Pedir un “DBA que también haga ETLs y reporting” es como buscar un fontanero que repare calderas y además pinte retratos al óleo. Existen, pero no son baratos, y no es razonable esperarlo por defecto.
- Lista de tecnologías sin criterio. SSIS, Airflow, Glue, Informatica, Talend… todos en el mismo párrafo. Sin contexto. Como si fueran toppings de pizza. A veces da la sensación de que la lista la ha hecho alguien buscando palabras clave en LinkedIn.
- Pedir cosas que no existen. Sí, me han preguntado por experiencia en “Azure SSMS”. No existe. También he visto peticiones de “conocimiento en procedimientos triggers” (¿?) o “optimización de tablas SQL BI” (lo que quiera que eso signifique).
- No diferenciar versiones ni entornos. SQL Server 2008 no es lo mismo que SQL Server 2019. Trabajar on-prem no tiene nada que ver con gestionar instancias en Azure SQL Database. Acláralo en la oferta. Y si no lo sabes, pregunta.
Glosario básico para RRHH sin miedo a SQL
Aquí tienes una lista de términos que deberías reconocer, aunque sea para no pronunciar mal en una entrevista. No hace falta que los expliques, pero sí que te suenen:
- SQL: Es el lenguaje universal de consultas en las bases de datos relacionales.
- SQL Server: Es el servidor de bases de datos relacionales de Microsoft. Otros servidores de bases de datos son Oracle, MySQL o PostgreSQL. No son lo mismo aunque hacen más o menos lo mismo. Gestionar bases de datos.
- Índice: estructura que acelera la búsqueda de datos. Como un índice en un libro. Si no lo hay, todo va más lento.
- Consulta / Query: es el código SQL que se lanza para obtener o modificar datos. “SELECT * FROM…” es un clásico.
- Stored Procedure: código SQL almacenado en la base de datos, que encapsula lógica de negocio o consultas complejas.
- Backup / Restore: copia de seguridad y su recuperación. Sin esto, todo lo demás da igual. Pregunta por esto siempre.
- Job: tarea programada que se ejecuta en el servidor de base de datos. Sirve para automatizar procesos.
- ETL / ELT: extracción, transformación y carga de datos. Básico en entornos de integración y reporting.
- T-SQL: dialecto de SQL propio de Microsoft SQL Server. No es igual que PL/SQL (Oracle) ni que el de PostgreSQL (PG/SQL).
- Instancia / Servidor / Motor: conceptos que conviene no confundir. Una instancia es una instalación del motor de base de datos, que puede convivir con otras en el mismo servidor físico o virtual.
- Alta disponibilidad (HA): técnicas para asegurar que la base de datos siga funcionando aunque haya fallos.
- Licenciamiento: aquí es donde empieza el dolor. SQL Server se licencia por núcleo, y en la nube cada modelo cambia.
- On-prem / Cloud / Híbrido: dónde vive la base de datos. En tu infraestructura, en la nube, o una mezcla.
- Monitorización: observar en tiempo real qué pasa en la base de datos. Métricas, alertas, salud del sistema.
- Tuning / Plan de ejecución: afinar consultas lentas, revisar cómo se ejecutan internamente y optimizarlas.
- Always On: Es una solución de Alta Disponibilidad avanzada propia de SQL Server.
Cómo no hacer el ridículo en una entrevista técnica
Muchas veces me ha pasado que me llama un reclutador al que han dado una lista de deseos y se ve que es la primera vez que lee alguno de los términos. Es que hasta se traban al leer las palabras técnicas raras. No se trata de fingir que sabes. Eso se nota. Pero tampoco de leer la oferta delante del candidato y esperar que te la explique. Aquí algunos consejos:
- Haz preguntas abiertas. Por ejemplo: “¿Qué tareas asumías como DBA en tu anterior puesto?”, en vez de recitar tecnologías.
- Escucha palabras clave. Si te dicen que hacían backups, mantenimiento, planes de ejecución… vas por buen camino.
- No interrumpas con tecnicismos que no manejas. Si el candidato menciona un término que no conoces, anótalo y consulta después. Preguntar “¿y eso es como un Excel, pero en la nube?” no ayuda.
- Si hay técnico en el equipo, involúcralo. Un screening técnico a tiempo evita semanas de procesos mal encaminados.
- Entiende lo que buscas. No se trata de que seas un experto pero lee antes la oferta, busca en google los conceptos que no entiendas. No tienes que profundizar pero, por lo menos que te suene de qué va la cosa.
- Y sobre todo, no improvises. Si el perfil es muy técnico y no sabes por dónde empezar, reconoce tus límites. No es debilidad. Es profesionalidad.
Conclusión
Buscar talento técnico sin entender lo que se busca no solo alarga el proceso, sino que lo devalúa. Quien sabe del tema nota al vuelo cuándo quien lo entrevista no ha leído ni entendido la mitad del puesto. Si el candidato es bueno, se irá. Y si no se va, pregúntate por qué.
Este artículo no pretende convertirte en DBA, ni falta que hace. Pero sí ayudarte a no tratar a todos los perfiles SQL como si fueran lo mismo. Porque no lo son. Y porque si seguimos publicando ofertas imposibles, al final lo único que vamos a reclutar… es silencio.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
